draft-ietf-mpls-rsvp-upstream-03.txt		draft-ietf-mpls-rsvp-upstream-04.txt
	Network Working Group R. Aggarwal		Network Working Group R. Aggarwal
	Internet Draft Juniper Networks		Internet Draft Juniper Networks
	Expiration Date: January 2009		Expiration Date: January 2010
	J. L. Le Roux		J. L. Le Roux
	France Telecom		France Telecom
	July 8, 2008		July 12, 2009
	MPLS Upstream Label Assignment for RSVP-TE		MPLS Upstream Label Assignment for RSVP-TE
	draft-ietf-mpls-rsvp-upstream-03.txt		draft-ietf-mpls-rsvp-upstream-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of 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		Task Force (IETF), its areas, and its working groups. Note that other
	other groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-Drafts.
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
			Copyright and License Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
			This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Abstract		Abstract
	This document describes procedures for distributing upstream-assigned		This document describes procedures for distributing upstream-assigned
	labels for Resource Reservation Protocol - Traffic Engineering (RSVP-		labels for Resource Reservation Protocol - Traffic Engineering (RSVP-
	TE). It also describes how these procedures can be used for avoiding		TE). It also describes how these procedures can be used for avoiding
	branch LSR traffic replication on a LAN for RSVP-TE point-to-		branch LSR traffic replication on a LAN for RSVP-TE point-to-
	multipoint (P2MP)LSPs.		multipoint (P2MP)LSPs.
	Table of Contents		Table of Contents
	1 Specification of requirements ......................... 2		1 Specification of requirements ......................... 3
	2 Introduction .......................................... 2		2 Introduction .......................................... 3
	3 RSVP-TE Upstream Label Assignment Capability .......... 3		3 RSVP-TE Upstream Label Assignment Capability .......... 3
	4 Distributing Upstream-Assigned Labels in RSVP-TE ...... 4		4 Distributing Upstream-Assigned Labels in RSVP-TE ...... 4
	4.1 Procedures ............................................ 4		4.1 Procedures ............................................ 5
	5 RSVP-TE Tunnel Identifier Exchange .................... 5		5 RSVP-TE Tunnel Identifier Exchange .................... 5
	6 RSVP-TE Point-to-Multipoint LSPs on a LAN ............. 6		6 RSVP-TE Point-to-Multipoint LSPs on a LAN ............. 7
	7 Acknowledgements ...................................... 7		7 IANA Considerations ................................... 8
	8 References ............................................ 7		8 Acknowledgements ...................................... 8
	8.1 Normative References .................................. 7		9 References ............................................ 9
	8.2 Informative References ................................ 8		9.1 Normative References .................................. 9
	9 Author's Address ...................................... 8		9.2 Informative References ................................ 9
	10 Intellectual Property Statement ....................... 8		10 Author's Address ...................................... 10
	11 Full Copyright Statement .............................. 9
	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 [MPLS-UPSTREAM] for Resource Reservation Protocol with Traffic		labels [RFC5331] for Resource Reservation Protocol with Traffic
	Engineering (RSVP-TE). These procedures follow the architecture for		Engineering (RSVP-TE). These procedures follow the architecture for
	MPLS Upstream Label Assignment described in [MPLS-UPSTREAM].		MPLS Upstream Label Assignment described in [RFC5331].
	This document describes extensions to RSVP-TE that a LSR can use to		This document describes extensions to RSVP-TE that a LSR can use to
	advertise to its neighboring LSRs whether the LSR supports upstream		advertise to its neighboring LSRs whether the LSR supports upstream
	label assignment.		label assignment.
	This document also describes extensions to RSVP-TE to distribute		This document also describes extensions to RSVP-TE to distribute
	upstream-assigned labels.		upstream-assigned labels.
	The usage of MPLS upstream label assignment using RSVP-TE for		The usage of MPLS upstream label assignment using RSVP-TE for
	avoiding branch LSR [RSVP-P2MP] traffic replication on a LAN for		avoiding branch LSR [RSVP-P2MP] traffic replication on a LAN for
	RSVP-TE P2MP TE LSPs [RFC4875] is also described.		RSVP-TE P2MP TE LSPs [RFC4875] is also described.
	3. RSVP-TE Upstream Label Assignment Capability		3. RSVP-TE Upstream Label Assignment Capability
	According to [MPLS-UPSTREAM], upstream-assigned label bindings MUST		According to [RFC5331], upstream-assigned label bindings MUST NOT be
	NOT be used unless it is known that a downstream LSR supports them.		used unless it is known that a downstream LSR supports them. This
	This implies that there MUST be a mechanism to enable a LSR to		implies that there MUST be a mechanism to enable a LSR to advertise
	advertise to its RSVP-TE neighbor LSR(s) its support of upstream-		to its RSVP-TE neighbor LSR(s) its support of upstream-assigned
	assigned labels.		labels.
	[RSVP-RESTART] defines a CAPABILITY object to be carried within Hello		[RFC5063] defines a CAPABILITY object to be carried within Hello
	messages, and used to indicate the set of capabilities supported by a		messages, and used to indicate the set of capabilities supported by a
	node. Currently one flag is defined, the R flag indicating the		node. This object provides the ability to encode a set of capability
	support for RecoveryPath Srefresh. This document defines a new flag,		flags. This document defines a new flag, the U flag, to signal a
	the U flag, to signal a LSR's support of upstream label assignment to		LSR's support of upstream label assignment to its RSVP-TE neighbors.
	its RSVP-TE neighbors.
	The format of a Capability object is:		The format of a Capability object is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num(TBA)| C-Type (1) |		| Length | Class-Num(TBA)| C-Type (1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |U|R|		| Reserved |U|T|R|S|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Recovery Path Srefresh Capable (R): 1 bit, defined in [RSVP-RESTART].		T, R and S flags are defined in [RFC5063].
	Upstream Label Assignement Capable (U): 1 bit When set this means		Upstream Label Assignement Capable (U): 1 bit When set this means
	that the LSR is capable of both distributing upstream-assigned label		that the LSR is capable of both distributing upstream-assigned label
	bindings and receiving upstream-assigned label bindings		bindings and receiving upstream-assigned label bindings
	Reserved bits MUST be set to zero on transmission and MUST be ignored		Reserved bits MUST be set to zero on transmission and MUST be ignored
	on receipt.		on receipt.
	The usage of RSVP-TE Hello messages for exchanging upstream label		The usage of RSVP-TE Hello messages for exchanging upstream label
	assignment capability implies that a LSR MAY exchange RSVP-TE Hellos		assignment capability implies that a LSR MAY exchange RSVP-TE Hellos
	skipping to change at page 4, line 40		skipping to change at page 5, line 19
	A RSVP-TE LSR MUST NOT distribute the UPSTREAM_ASSIGNED_LABEL Object		A RSVP-TE LSR MUST NOT distribute the UPSTREAM_ASSIGNED_LABEL Object
	to a downstream LSR if the downstream LSR had not previously		to a downstream LSR if the downstream LSR had not previously
	advertised the CAPABILITY object with the U bit set in its RSVP-TE		advertised the CAPABILITY object with the U bit set in its RSVP-TE
	Hello messages.		Hello messages.
	If a downstream RSVP-TE LSR receives a Path message that carries an		If a downstream RSVP-TE LSR receives a Path message that carries an
	UPSTREAM_ASSIGNED_LABEL Object and the LSR does not support the		UPSTREAM_ASSIGNED_LABEL Object and the LSR does not support the
	object C-Num/C-Type it will return an "Unknown Object C-Num/C-Type"		object C-Num/C-Type it will return an "Unknown Object C-Num/C-Type"
	error. If the LSR does support the object, but is unable to process		error. If the LSR does support the object, but is unable to process
	the upstream-assigned label as described in [MPLS-UPSTREAM] it SHOULD		the upstream-assigned label as described in [RFC5331] it SHOULD send
	send a PathErr with the error code "Routing problem" and the error		a PathErr with the error code "Routing problem" and the error value
	value "MPLS Upstream Assigned Label Processing Failure". If the LSR		"MPLS Upstream Assigned Label Processing Failure". If the LSR
	successfully processes the Path message and the upstream-assigned		successfully processes the Path message and the upstream-assigned
	label it MUST send a Resv message upstream as per [RFC3209] but it		label it MUST send a Resv message upstream as per [RFC3209] but it
	MUST NOT include the LABEL object with a downstream assigned label in		MUST NOT include the LABEL object with a downstream assigned label in
	the Resv Message. This is because as described in [MPLS-UPSTREAM] two		the Resv Message. This is because as described in [RFC5331] two LSRs
	LSRs Ru and Rd for a LSP that is bound to FEC F, MUST use either		Ru and Rd for a LSP that is bound to FEC F, MUST use either
	downstream-assigned label distribution or upstream-assigned label		downstream-assigned label distribution or upstream-assigned label
	distribution,for FEC F, but NOT both, for packets that are to be		distribution,for FEC F, but NOT both, for packets that are to be
	transmitted on the LSP from Ru to Rd.		transmitted on the LSP from Ru to Rd.
	5. RSVP-TE Tunnel Identifier Exchange		5. RSVP-TE Tunnel Identifier Exchange
	As described in [MPLS-UPSTREAM] an upstream LSR Ru MAY transmit a		As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS
	MPLS packet, the top label of which (L) is upstream-assigned, to a		packet, the top label of which (L) is upstream-assigned, to a
	downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In		downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In
	this case the fact that L is upstream-assigned is determined by Rd by		this case the fact that L is upstream-assigned is determined by Rd by
	the tunnel on which the packet is received. There must be a mechanism		the tunnel on which the packet is received. There must be a mechanism
	for Ru to inform Rd that a particular tunnel from Ru to Rd will be		for Ru to inform Rd that a particular tunnel from Ru to Rd will be
	used by Ru for transmitting MPLS packets with upstream-assigned MPLS		used by Ru for transmitting MPLS packets with upstream-assigned MPLS
	labels.		labels.
	When RSVP-TE is used for upstream label assignment, the IF_ID		When RSVP-TE is used for upstream label assignment, the IF_ID
	RSVP_HOP object is used for signaling the Tunnel Identifier. If Ru		RSVP_HOP object is used for signaling the Tunnel Identifier. If Ru
	uses an IP or MPLS tunnel to transmit MPLS packets with upstream		uses an IP or MPLS tunnel to transmit MPLS packets with upstream
	assigned labels to Rd, Ru MUST include the IF_ID RSVP_HOP object		assigned labels to Rd, Ru MUST include the IF_ID RSVP_HOP object
	[RFC3473] in Path messages along with the UPSTREAM_ASSIGNED_LABEL		[RFC3473] in Path messages along with the UPSTREAM_ASSIGNED_LABEL
	Object.		Object.
	Three new TLVs are introduced in the IF_ID RSVP_HOP object [RFC3471]		Four new TLVs are introduced in the IF_ID RSVP_HOP object [RFC3471]
	to support RSVP-TE P2MP LSPs, IP Multicast Tunnels and context		to support RSVP-TE P2MP LSPs, LDP P2MP LSPs, IP Multicast Tunnels and
	labels. The TLV value acts as the tunnel identifier.		context labels. The TLV value acts as the tunnel identifier.
	1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE		1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE
	P2MP Session Object and optionally the P2MP Sender Template Object		P2MP Session Object and optionally the P2MP Sender Template Object
	[RFC4875]. The TLV value identifies the RSVP-TE P2MP LSP. This		[RFC4875]. The TLV value identifies the RSVP-TE P2MP LSP. This
	mechanism extends RSVP-TE P2P Hierarchy [LSP-HIER] to RSVP-TE P2MP		mechanism extends RSVP-TE P2P Hierarchy [LSP-HIER] to RSVP-TE P2MP
	Hierarchy. It allows Ru to tunnel an "inner" P2MP LSP, the label for		Hierarchy. It allows Ru to tunnel an "inner" RSVP-TE P2MP LSP, the
	which is upstream assigned, over an "outer" P2MP LSP that has leaves		label for which is upstream assigned, over an "outer" RSVP-TE P2MP
			LSP that has leaves <Rd1...Rdn>. The P2MP LSP IF_ID TLV allows Ru to
			signal to <Rd1...Rdn> the binding of the inner P2MP LSP to the outer
			P2MP LSP. The control plane signaling between Ru and <Rd1...Rdn> for
			the inner P2MP LSP uses directed RSVP-TE signaling messages as in
			[LSP-HIER].
			2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC
			as defined in [MLDP]. The TLV value identifies the LDP P2MP LSP. It
			allows Ru to tunnel an "inner" RSVP-TE P2MP LSP, the label for which
			is upstream assigned, over an "outer" LDP P2MP LSP that has leaves
	<Rd1...Rdn>. The P2MP LSP IF_ID TLV allows Ru to signal to		<Rd1...Rdn>. The P2MP LSP IF_ID TLV allows Ru to signal to
	<Rd1...Rdn> the binding of the inner P2MP LSP to the outer P2MP LSP.		<Rd1...Rdn> the binding of the inner LDP P2MP LSP to the outer LDP-
	The control plane signaling between Ru and <Rd1...Rdn> for the inner		P2MP LSP. The control plane signaling between Ru and <Rd1...Rdn> for
	P2MP LSP uses directed RSVP-TE signaling messages as in [LSP-HIER].		the inner P2MP LSP uses directed RSVP-TE signaling messages as in
			[LSP-HIER].
	2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is		2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is
	a <Source Address, Multicast Group Address> tuple. Source Address is		a <Source Address, Multicast Group Address> tuple. Source Address is
	the IP address of the root of the tunnel i.e. Ru, and Multicast Group		the IP address of the root of the tunnel i.e. Ru, and Multicast Group
	Address is the Multicast Group Address used by the tunnel.		Address is the Multicast Group Address used by the tunnel.
	3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is		3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is
	a <Source Address, MPLS Context Label> tuple. The Source Address		a <Source Address, MPLS Context Label> tuple. The Source Address
	belongs to Ru and the MPLS Context Label is an upstream assigned		belongs to Ru and the MPLS Context Label is an upstream assigned
	label, assigned by Ru. This allows Ru to tunnel an "inner" RSVP-TE		label, assigned by Ru. This allows Ru to tunnel an "inner" RSVP-TE
	skipping to change at page 6, line 18		skipping to change at page 6, line 52
	the incoming interface MUST be sufficient for <Rd1...Rdn> to		the incoming interface MUST be sufficient for <Rd1...Rdn> to
	uniquely determine Ru's context specific label space to lookup		uniquely determine Ru's context specific label space to lookup
	the next label on the stack in. <Rd1...Rdn> MUST receive the data		the next label on the stack in. <Rd1...Rdn> MUST receive the data
	sent by Ru with the context specific label assigned by Ru being		sent by Ru with the context specific label assigned by Ru being
	the top label on the label stack.		the top label on the label stack.
	Currently the usage of the context label TLV is limited only to RSVP-		Currently the usage of the context label TLV is limited only to RSVP-
	TE P2MP LSPs on a LAN as specified in the next section. The context		TE P2MP LSPs on a LAN as specified in the next section. The context
	label TLV MUST NOT be used for any other purposes.		label TLV MUST NOT be used for any other purposes.
			Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP
			the above procedures assume that Ru has a priori knowledge of all the
			<Rd1, ... Rdn>. In the scenario where the outer P2MP LSP is signaled
			using RSVP-TE, Ru can obtain this information from RSVP-TE. However,
			in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP
			does not provide this information to Ru. In this scenario the
			procedures by which Ru could acquire this information are outside the
			scope of this document.
	6. RSVP-TE Point-to-Multipoint LSPs on a LAN		6. RSVP-TE Point-to-Multipoint LSPs on a LAN
	This section describes one application of upstream label assignment		This section describes one application of upstream label assignment
	using RSVP-TE. Further applications are to be described in separate		using RSVP-TE. Further applications are to be described in separate
	documents.		documents.
	[RFC4875] describes how to setup RSVP-TE P2MP LSPs. On a LAN the		[RFC4875] describes how to setup RSVP-TE P2MP LSPs. On a LAN the
	solution described in [RFC4875] relies on "ingress replication". A		solution described in [RFC4875] relies on "ingress replication". A
	LSR on a LAN (say Il), that is a branch LSR for a P2MP LSP, (say Ru)		LSR on a LAN (say Il), that is a branch LSR for a P2MP LSP, (say Ru)
	sends a separate copy of a packet that it receives on the P2MP LSP to		sends a separate copy of a packet that it receives on the P2MP LSP to
	skipping to change at page 6, line 46		skipping to change at page 7, line 40
	transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It		transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It
	is possible to achieve this using RSVP-TE upstream-assigned labels		is possible to achieve this using RSVP-TE upstream-assigned labels
	with the following procedures. Assume that Ru and <Rd1...Rdn> support		with the following procedures. Assume that Ru and <Rd1...Rdn> support
	upstream label assignment.		upstream label assignment.
	Ru sends a Path message for the P2MP LSP to each of <Rd1...Rdn> that		Ru sends a Path message for the P2MP LSP to each of <Rd1...Rdn> that
	is adjacent on the P2MP LSP, with the same UPSTREAM_ASSIGNED_LABEL		is adjacent on the P2MP LSP, with the same UPSTREAM_ASSIGNED_LABEL
	object. This object carries an upstream assigned label, L. This		object. This object carries an upstream assigned label, L. This
	message also carries a MPLS Context Label TLV, as described in the		message also carries a MPLS Context Label TLV, as described in the
	previous section, with the value of the MPLS label set to a value		previous section, with the value of the MPLS label set to a value
	assigned by Ru on inteface I1 as specified in [MPLS-UPSTREAM].		assigned by Ru on inteface I1 as specified in [RFC5331]. <Rd1...Rdn>
	<Rd1...Rdn> "reserve" the upstream assigned label in the separate		"reserve" the upstream assigned label in the separate Upstream
	Upstream Neighbor Label Space that they maintain for Ru [MPLS-		Neighbor Label Space that they maintain for Ru [RFC5331].
	UPSTREAM].
	Ru can then transmit a single packet for the P2MP LSP to <Rd1..Rdn>		Ru can then transmit a single packet for the P2MP LSP to <Rd1..Rdn>
	with a top label L using procedures defined in [MPLS-UPSTREAM] and		with a top label L using procedures defined in [RFC5331] and
	[MPLS-MCAST-ENCAPS]. The MPLS packet transmitted by Ru contains as		[RFC5332]. The MPLS packet transmitted by Ru contains as the top
	the top label the context label assigned by Ru on the LAN interface,		label the context label assigned by Ru on the LAN interface, I1. The
	I1. The bottom label is the upstream label assigned by Ru to the		bottom label is the upstream label assigned by Ru to the RSVP-TE P2MP
	RSVP-TE P2MP LSP. The top label is looked up in the context of the		LSP. The top label is looked up in the context of the LAN interface,
	LAN interface, I1, [MPLS-UPSTREAM] by a downstream LSR on the LAN.		I1, [RFC5331] by a downstream LSR on the LAN. This lookup enables the
	This lookup enables the downstream LSR to determine the context		downstream LSR to determine the context specific label space to
	specific label space to lookup the inner label in.		lookup the inner label in.
	If a subset of <Rd1...Rdn> do not support upstream label assignment		If a subset of <Rd1...Rdn> do not support upstream label assignment
	these procedures can still be used between Ru and the remaining		these procedures can still be used between Ru and the remaining
	subset of <Rd1...Rdn>. Ingress replication and downstream label		subset of <Rd1...Rdn>. Ingress replication and downstream label
	assignment will continue to be used for LSRs that do not support		assignment will continue to be used for LSRs that do not support
	upstream label assignment.		upstream label assignment.
	7. Acknowledgements		7. IANA Considerations
			This document defines a new U flag in the CAPABILITY object defined
			by [RFC5063]. IANA is requested to assign a new bit to this flag from
			the 32 bit flags field of the CAPABILITY object.
			This document defines a new RSVP-TE object, the
			UPSTREAM_ASSIGNED_LABEL object. The Class-Num for this object comes
			from the 0bbbbbbb space and IANA is requested to assign this Class-
			Num.
			This document defines four new TLVs in the IF_ID RSVP_HOP object
			[RFC3471]:
			- RSVP-TE P2MP LSP TLV
			- LDP P2MP LSP TLV
			- IP Multicast Tunnel TLV
			- MPLS Context Label TLV
			IANA is requested to assign the type values of these TLVs.
			8. 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.		Thomas Morin for their comments.
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon,		[RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon,
	RFC 3031.		RFC 3031.
	[MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream		[RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
	Label Assignment and Context Specific Label Space", draft-ietf-mpls-		Assignment and Context Specific Label Space", draft-ietf-mpls-
	upstream-label-05.txt		upstream-label-05.txt
	[MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter,		[RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, draft-ietf-
	draft-ietf-mpls-codepoint-08.txt		mpls-codepoint-08.txt
	[RFC3209] Awduche et. al." "RSVP-TE: Extensions to RSVP for LSP		[RFC3209] Awduche et. al." "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	[RFC2119] "Key words for use in RFCs to Indicate Requirement		[RFC2119] "Key words for use in RFCs to Indicate Requirement
	[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label		[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic		Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic
	Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.		Engineering (RSVP-TE) Extensions", RFC 3473, 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.
	[RSVP-RESTART] A. Satyanarayana et. al., "Extensions to GMPLS RSVP		[RFC5063] A. Satyanarayana et. al., "Extensions to GMPLS Resource
	Graceful Restart", draft-ietf-ccamp-rsvp-restart-ext-02.txt		Reservation Protocol (RSVP) Graceful Restart", RFC5063
	8.2. Informative References		9.2. Informative References
	[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs",		[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs",
	draft-ietf-l3vpn-2547bis-mcast-06.txt		draft-ietf-l3vpn-2547bis-mcast-06.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
	9. Author's Address		10. 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
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
	France		France
	E-mail: jeanlouis.leroux@orange-ftgroup.com		E-mail: jeanlouis.leroux@orange-ftgroup.com
	10. Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.
	11. Full Copyright Statement
	Copyright (C) The IETF Trust (2008). This document is subject to the
	rights, licenses and restrictions contained in BCP 78, and except as
	set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 34 change blocks.
	73 lines changed or deleted		134 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/