draft-ietf-mpls-ldp-upstream-05.txt		draft-ietf-mpls-ldp-upstream-06.txt
	Network Working Group R. Aggarwal		Network Working Group R. Aggarwal
	Internet Draft Juniper Networks		Internet Draft Juniper Networks
	Expiration Date: July 2010		Expiration Date: August 2010
	J. L. Le Roux		J. L. Le Roux
	France Telecom		France Telecom
	January 29, 2010		February 25, 2010
	MPLS Upstream Label Assignment for LDP		MPLS Upstream Label Assignment for LDP
	draft-ietf-mpls-ldp-upstream-05.txt		draft-ietf-mpls-ldp-upstream-06.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 2, line 34		skipping to change at page 2, line 34
	Table of Contents		Table of Contents
	1 Specification of requirements ......................... 3		1 Specification of requirements ......................... 3
	2 Introduction .......................................... 3		2 Introduction .......................................... 3
	3 LDP Upstream Label Assignment Capability .............. 3		3 LDP Upstream Label Assignment Capability .............. 3
	4 Distributing Upstream-Assigned Labels in LDP .......... 4		4 Distributing Upstream-Assigned Labels in LDP .......... 4
	4.1 Procedures ............................................ 5		4.1 Procedures ............................................ 5
	5 LDP Tunnel Identifier Exchange ........................ 6		5 LDP Tunnel Identifier Exchange ........................ 6
	6 LDP Point-to-Multipoint LSPs on a LAN ................. 7		6 LDP Point-to-Multipoint LSPs on a LAN ................. 7
	7 IANA Considerations ................................... 9		7 IANA Considerations ................................... 9
	8 Acknowledgements ...................................... 9		8 Security Considerations ............................... 9
	9 References ............................................ 10		9 Acknowledgements ...................................... 10
	9.1 Normative References .................................. 10		10 References ............................................ 10
	9.2 Informative References ................................ 10		10.1 Normative References .................................. 10
	10 Author's Address ...................................... 11		10.2 Informative References ................................ 10
			11 Author's Address ...................................... 11
	1. Specification of requirements		1. Specification of requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	This document describes procedures for distributing upstream-assigned		This document describes procedures for distributing upstream-assigned
	labels [RFC5331] for Label Distribution Protocol (LDP). These		labels [RFC5331] for Label Distribution Protocol (LDP). These
	skipping to change at page 3, line 39		skipping to change at page 3, line 39
	According to [RFC5331], upstream-assigned label bindings MUST NOT be		According to [RFC5331], upstream-assigned label bindings MUST NOT be
	used unless it is known that a downstream LSR supports them. This		used unless it is known that a downstream LSR supports them. This
	implies that there MUST be a mechanism to enable a LSR to advertise		implies that there MUST be a mechanism to enable a LSR to advertise
	to its LDP neighbor LSR(s) its support of upstream-assigned labels.		to its LDP neighbor LSR(s) its support of upstream-assigned labels.
	A new Capability Parameter, the LDP Upstream Label Assignment		A new Capability Parameter, the LDP Upstream Label Assignment
	Capability, is introduced to allow an LDP peer to exchange with its		Capability, is introduced to allow an LDP peer to exchange with its
	peers, its support of upstream label assignment. This parameter		peers, its support of upstream label assignment. This parameter
	follows the format and procedures for exchanging Capability		follows the format and procedures for exchanging Capability
	Parameters defined in [LDP-CAP].		Parameters defined in [RFC5561].
	Following is the format of the LDP Upstream Label Assignment		Following is the format of the LDP Upstream Label Assignment
	Capability Parameter:		Capability Parameter:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) |		|1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1| Reserved |		|1| Reserved |
	skipping to change at page 4, line 43		skipping to change at page 4, line 43
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Upstream Ass Label (TBD) | Length |		|0|0| Upstream Ass Label (TBD) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |		| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label |		| Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Label
	This is a 20-bit label value as specified in [RFC3032] represented as		This is a 20-bit label value as specified in [RFC3032] represented as
	a 20-bit number in a 4 octet field.		a 20-bit number in a 4 octet field.
	4.1. Procedures		4.1. Procedures
	Procedures for Label Mapping, Label Request, Label Abort, Label		Procedures for Label Mapping, Label Request, Label Abort, Label
	Withdraw and Label Release follow [RFC3036] other than the		Withdraw and Label Release follow [RFC5036] other than the
	modifications pointed out in this section.		modifications pointed out in this section.
	A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a		A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a
	neighboring LSR if the neighboring LSR had not previously advertised		neighboring LSR if the neighboring LSR had not previously advertised
	the Upstream Label Assignment Capability in its LDP Initialization		the Upstream Label Assignment Capability in its LDP Initialization
	messages. A LDP LSR MUST NOT send the Upstream Assigned Label		messages. A LDP LSR MUST NOT send the Upstream Assigned Label
	Request TLV to a neighboring LSR if the neighboring LSR had not		Request TLV to a neighboring LSR if the neighboring LSR had not
	previously advertised the Upstream Label Assignment Capability in its		previously advertised the Upstream Label Assignment Capability in its
	LDP Initialization messages.		LDP Initialization messages.
	As described in [RFC5331] the distribution of upstream-assigned		As described in [RFC5331] the distribution of upstream-assigned
	labels is similar to either ordered LSP control or independent LSP		labels is similar to either ordered LSP control or independent LSP
	control of the downstream assigned labels.		control of the downstream assigned labels.
	When the label distributed in a Label Mapping message is an upstream-		When the label distributed in a Label Mapping message is an upstream-
	assigned label, the Upstream Assigned Label TLV MUST be included in		assigned label, the Upstream Assigned Label TLV MUST be included in
	the Label Mapping message. When a LSR receives a Label Mapping		the Label Mapping message. When a LSR receives a Label Mapping
	message with an Upstream Assigned Label TLV and it does not recognize		message with an Upstream Assigned Label TLV and it does not recognize
	the TLV, it MUST generate a Notification message with a status code		the TLV, it MUST generate a Notification message with a status code
	of "Unknown TLV" [RFC3036]. If it does recognize the TLV but is		of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is
	unable to process the upstream label, it MUST generate a Notification		unable to process the upstream label, it MUST generate a Notification
	message with a status code of "No Label Resources". If the Label		message with a status code of "No Label Resources". If the Label
	Mapping message was generated in response to a Label Request message,		Mapping message was generated in response to a Label Request message,
	the Label Request message MUST contain an Upstream Assigned Label		the Label Request message MUST contain an Upstream Assigned Label
	Request TLV. A LSR that generates an upstream assigned label request		Request TLV. A LSR that generates an upstream assigned label request
	to a neighbor LSR, for a given FEC, MUST NOT send a downstream label		to a neighbor LSR, for a given FEC, MUST NOT send a downstream label
	mapping to the neighbor LSR for that FEC unless it withdraws the		mapping to the neighbor LSR for that FEC unless it withdraws the
	upstream-assigned label binding. Similarly if a LSR generates a		upstream-assigned label binding. Similarly if a LSR generates a
	downstream assigned label request to a neighbor LSR, for a given FEC,		downstream assigned label request to a neighbor LSR, for a given FEC,
	it MUST NOT send an upstream label mapping to that LSR for that FEC,		it MUST NOT send an upstream label mapping to that LSR for that FEC,
	skipping to change at page 9, line 15		skipping to change at page 9, line 15
	LSRs on the LAN do not support upstream label assignment. Ingress		LSRs on the LAN do not support upstream label assignment. Ingress
	replication and downstream label assignment will continue to be used		replication and downstream label assignment will continue to be used
	for LSRs that do not support upstream label assignment.		for LSRs that do not support upstream label assignment.
	7. IANA Considerations		7. IANA Considerations
	This document defines a new LDP Upstream Label Assignment Capability		This document defines a new LDP Upstream Label Assignment Capability
	Parameter. IANA is requested to assign the value 0x0507 to this		Parameter. IANA is requested to assign the value 0x0507 to this
	Parameter.		Parameter.
	This document defines a new LDP Upstream-Assigned Label Request TLV,
	IANA is requested to assign the type value of this TLV.
	This document defines a new LDP Upstream-Assigned Label TLV, IANA is		This document defines a new LDP Upstream-Assigned Label TLV, IANA is
	requested to assign the type value of this TLV.		requested to assign the type value of 0x204 to this TLV.
			This document defines a new LDP Upstream-Assigned Label Request TLV,
			IANA is requested to assign the type value of 0x205 to this TLV.
	This document defines four new Interface ID TLVs:		This document defines four new Interface ID TLVs:
	- RSVP-TE P2MP LSP TLV		- RSVP-TE P2MP LSP TLV
	- LDP P2MP LSP TLV		- LDP P2MP LSP TLV
	- IP Multicast Tunnel TLV		- IP Multicast Tunnel TLV
	- MPLS Context Label TLV		- MPLS Context Label TLV
	IANA is requested to assign the type values of these TLVs.		These values are assigned from the Interface_ID Type space defined in
			[RFC3471]. IANA is requested to assign the type value 6 to RSVP-TE
			P2MP LSP TLV, type value 7 to LDP P2MP LSP TLV, type value 8 to IP
			Multicast Tunnel TLV and type value 9 to MPLS Context Label TLV.
	8. Acknowledgements		8. Security Considerations
			The security considerations discussed in RFC 5331 and RFC 5332 apply
			to this document.
			More detailed discussion of security issues that are relevant in the
			context of MPLS and GMPLS, including security threats, related
			defensive techniques, and the mechanisms for detection and reporting,
			are discussed in "Security Framework for MPLS and GMPLS Networks
			[MPLS-SEC].
			9. Acknowledgements
	Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and		Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and
	Thomas Morin for their comments. The hashing algorithm used on LAN		Thomas Morin for their comments. The hashing algorithm used on LAN
	interfaces is taken from [MLDP].		interfaces is taken from [MLDP].
	9. References		10. References
	9.1. Normative References
	[RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon,		10.1. Normative References
	RFC 3031.
	[RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label		[RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
	Assignment and Context Specific Label Space", RFC5331		Assignment and Context Specific Label Space", RFC5331
	[RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332		[RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332
	[RFC2119] "Key words for use in RFCs to Indicate Requirement		[RFC2119] "Key words for use in RFCs to Indicate Requirement
	Levels.", Bradner, March 1997		Levels.", Bradner, March 1997
	[RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized		[RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized
	Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based		Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based
	Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472,		Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472,
	January 2003.		January 2003.
	[RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label		[RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Functional Description", RFC 3471 January		Switching (GMPLS) Signaling Functional Description", RFC 3471 January
	2003.		2003.
	[RFC3036] L. Andersson, et. al., "LDP Specification", January 2001.		[RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036.
	9.2. Informative References
	[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs",		10.2. Informative References
	draft-ietf-l3vpn-2547bis-mcast-08.txt
	[RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors],		[RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors],
	"Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875		"Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875
	[MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for		[MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for
	Point-to-Multipoint Label Switched Paths", draft-etf-mpls-ldp-		Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
	p2mp-07.txt		Paths", draft-ietf-mpls-ldp-p2mp-08.txt
	[LDP-CAP] B. Thomas, et. al., "LDP Capabilities", draft-thomas-mpls-		[RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux,
	ldp-capabilities-04.txt		"LDP Capabilities", RFC5561
	10. Author's Address		[MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS
			Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt
			[RFC3032] E. Rosen et. al, "MPLS Label Stack Encoding", RFC 3032
			11. Author's Address
	Rahul Aggarwal		Rahul Aggarwal
	Juniper Networks		Juniper Networks
	1194 North Mathilda Ave.		1194 North Mathilda Ave.
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	Phone: +1-408-936-2720		Phone: +1-408-936-2720
	Email: rahul@juniper.net		Email: rahul@juniper.net
	Jean-Louis Le Roux		Jean-Louis Le Roux
	France Telecom		France Telecom
End of changes. 19 change blocks.
	34 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/