draft-ietf-mpls-rsvpte-attributes-04.txt		draft-ietf-mpls-rsvpte-attributes-05.txt
	Network Working Group Adrian Farrel (Editor)		Network Working Group Adrian Farrel (Editor)
	Internet Draft Old Dog Consulting		Updates: RFC3209 and RFC3473 Old Dog Consulting
	Category: Standards Track Dimitri Papadimitriou		Category: Standards Track Dimitri Papadimitriou
	Expires: January 2005 Alcatel		Expires: November 2005 Alcatel
	Jean-Philippe Vasseur		Jean-Philippe Vasseur
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Arthi Ayyangar		Arthi Ayyangar
	Juniper Networks		Juniper Networks
	July 2004		May 2005
	Encoding of Attributes for Multiprotocol Label Switching (MPLS)		Encoding of Attributes for Multiprotocol Label Switching (MPLS)
	Label Switched Path (LSP) Establishment Using RSVP-TE		Label Switched Path (LSP) Establishment Using RSVP-TE
	draft-ietf-mpls-rsvpte-attributes-04.txt		draft-ietf-mpls-rsvpte-attributes-05.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	or will be disclosed, and any of which I become aware will be		have been or will be disclosed, and any of which he or she becomes
	disclosed, in accordance with RFC 3668.		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 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.
	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."
	skipping to change at line 61		skipping to change at line 60
	This document defines a new object for RSVP-TE messages that allows		This document defines a new object for RSVP-TE messages that allows
	the signaling of further attribute bits and also the carriage of		the signaling of further attribute bits and also the carriage of
	arbitrary attribute parameters to make RSVP-TE easily extensible to		arbitrary attribute parameters to make RSVP-TE easily extensible to
	support new requirements. Additionally, this document defines a way		support new requirements. Additionally, this document defines a way
	to record the attributes applied to the LSP on a hop-by-hop basis.		to record the attributes applied to the LSP on a hop-by-hop basis.
	The object mechanisms defined in this document are equally applicable		The object mechanisms defined in this document are equally applicable
	to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to		to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to
	GMPLS non-PSC LSPs.		GMPLS non-PSC LSPs.
	0. Change History
	This section to be removed before publication as an RFC.
	0.1 Changes from 03 to 04 Version
	- New IPR and copyright text
	- Update referneces
	0.2 Changes from 02 to 03 Version
	- Allow LSP_ATTRIBUTES object on Resv message.
	- Document inheritance rules.
	- Add table of Contents.
	- New IPR and Copyright boiler-plate.
	0.3 Changes from 01 to 02 Version
	- Minor typographical changes.
	0.4 Changes from 00 to 01 Version
	- Change Attributes Flags TLV to be variable length so that more bits
	can easily be added in the future.
	- Define default behaviors for bits absent from the TLV and for
	absence of the TLV.
	- Clarify the IANA requirements for tracking Attributes Flags bits.
	- Introduce RRO Attributes Subobject and describe usage.
	- Move Fast Reroute reference to informational.
	- Update security considerations to handle new RRO subobject
	- Remove section that explained the need for this document in
	advance of any definitive bit definitions.
	- Tighten rules for processing LSP_ATTRIBUTES object in cases where
	TLVs are unknown or unsupported.
	- Clarify that LSP Attributes apply to individual LSPs and not to
	entire sessions.
	Contents		Contents
	1. Introduction and Problem Statement 3		1. Introduction and Problem Statement 3
	1.1 Applicability to Generalized MPLS 4		1.1 Applicability to Generalized MPLS 4
	1.2 A Rejected Alternate Solution 4		1.2 A Rejected Alternate Solution 4
	2. Terminology 5		2. Terminology 5
	3. Attributes TLVs 5		3. Attributes TLVs 5
	3.1 Attributes Flags TLV 5		3.1 Attributes Flags TLV 6
	4. LSP_ATTRIBUTES Object 6		4. LSP_ATTRIBUTES Object 6
	4.1 Format 7		4.1 Format 7
	4.2 Generic Processing Rules for Path Messages 7		4.2 Generic Processing Rules for Path Messages 7
	4.3 Generic Processing Rules for Resv Messages 7		4.3 Generic Processing Rules for Resv Messages 8
	5. LSP_REQUIRED_ATTRIBUTES Object 8		5. LSP_REQUIRED_ATTRIBUTES Object 8
	5.1 Format 8		5.1 Format 9
	5.2 Generic Processing Rules 9		5.2 Generic Processing Rules 9
	6. Inheritance Rules 9		6. Inheritance Rules 10
	7. Recording Attributes Per-LSP 9		7. Recording Attributes Per-LSP 10
	7.1 Requirements 9		7.1 Requirements 10
	7.2 RRO Attributes Subobject 10		7.2 RRO Attributes Subobject 10
	7.3 Procedures 10		7.3 Procedures 11
	7.3.1 Subobject Presence Rules 10		7.3.1 Subobject Presence Rules 11
	7.3.2 Reporting Compliance with LSP Attributes 11		7.3.2 Reporting Compliance with LSP Attributes 12
	7.3.3 Reporting Per-Hop Attributes 11		7.3.3 Reporting Per-Hop Attributes 12
	7.3.4 Default Behavior 11		7.3.4 Default Behavior 12
	8. Summary of Attribute Bit Allocation 11		8. Summary of Attribute Bit Allocation 12
	9. Message Formats 12		9. Message Formats 13
	10. IANA Considerations 13		10. Guidance for Key Application Scenarios 14
	10.1 New RSVP C-Nums and C-Types 13		10.1 Communicating to Egress LSRs 14
	10.2 New TLV Space 13		10.2 Communicating to Key Transit LSRs 15
	10.3 Attributes Flags 14		10.3 Communicating to All LSRs 15
	10.4 SESSION_ATTRIBUTE Flags Field 14		11. IANA Considerations 15
	10.5 New Error Codes 14		11.1 New RSVP C-Nums and C-Types 15
	10.6 New Record Route Subobject Identifier 14		11.2 New TLV Space 16
	11. Security Considerations 15		11.3 Attributes Flags 16
	12. Acknowledgements 15		11.4 SESSION_ATTRIBUTE Flags Field 17
	13. Intellectual Property Consideration 15		11.5 New Error Codes 17
	13.1 IPR Disclosure Acknowledgement 16		11.6 New Record Route Subobject Identifier 17
	14. Normative References 16		12. Security Considerations 17
	15. Informative References 16		13. Acknowledgements 18
	16. Authors' Addresses 16		14. Intellectual Property Consideration 18
	17. Full Copyright Statement 17		15. Normative References 18
			16. Informative References 19
			17. Authors' Addresses 19
			18. Disclaimer of Validity 20
			19. Full Copyright Statement 20
	1. Introduction and Problem Statement		1. Introduction and Problem Statement
	Traffic Engineered Multiprotocol Label Switching (MPLS) Label		Traffic Engineered Multiprotocol Label Switching (MPLS) Label
	Switched Paths (LSPs) [RFC3031] may be set up using the Path message		Switched Paths (LSPs) [RFC3031] may be set up using the Path message
	of the RSVP-TE signaling protocol [RFC3209]. The Path message		of the RSVP-TE signaling protocol [RFC3209]. The Path message
	includes the SESSION_ATTRIBUTE object which carries a flags field		includes the SESSION_ATTRIBUTE object which carries a flags field
	used to indicate desired options and attributes of the LSP.		used to indicate desired options and attributes of the LSP.
	The flags field in the SESSION_ATTRIBUTE object has eight bits. Just		The flags field in the SESSION_ATTRIBUTE object has eight bits. Just
	skipping to change at line 161		skipping to change at line 127
	three bits available. Several recent proposals and Internet Drafts		three bits available. Several recent proposals and Internet Drafts
	have demonstrated that there is a high demand for the use of the		have demonstrated that there is a high demand for the use of the
	other three bits. Some, if not all, of those proposals are likely to		other three bits. Some, if not all, of those proposals are likely to
	go forward as RFCs resulting in depletion or near depletion of the		go forward as RFCs resulting in depletion or near depletion of the
	flags field and a consequent difficulty in signaling new options and		flags field and a consequent difficulty in signaling new options and
	attributes that may be developed in the future.		attributes that may be developed in the future.
	This document defines a new object for RSVP-TE messages that allows		This document defines a new object for RSVP-TE messages that allows
	the signaling of further attributes bits. The new object is		the signaling of further attributes bits. The new object is
	constructed from TLVs, and a new TLV is defined to carry a variable		constructed from TLVs, and a new TLV is defined to carry a variable
	number of attributes bits. Because of the nature of the TLV		number of attributes bits.
	construction the object is flexible and allows the future definition		The new RSVP-TE message object is quite flexible, due to the use of
	of:		the TLV format and allows:
	- further bit flags if further, distinct uses are discovered		- future specification of bit flags
	- arbitrary options and attributes parameters carried as individual		- additional options and atttribute paramerters carried in TLV
	TLVs.		format.
	Note that the LSP Attributes defined in this document are		Note that the LSP Attributes defined in this document are
	specifically scoped to an LSP. They may be set differently on		specifically scoped to an LSP. They may be set differently on
	separate LSPs with the same Tunnel ID between the same source and		separate LSPs with the same Tunnel ID between the same source and
	destination (that is, within the same Session).		destination (that is, within the same Session).
	It is noted that some options and attributes do not need to be		It is noted that some options and attributes do not need to be
	acted on by all Label Switched Routers (LSRs) along the path of the		acted on by all Label Switched Routers (LSRs) along the path of the
	LSP. In particular, these options and attributes may apply only to		LSP. In particular, these options and attributes may apply only to
	key LSRs on the path such as the ingress and egress. Special transit		key LSRs on the path such as the ingress LSR and egress LSR. Special
	LSRs, such as Area or AS Border Routers (ABRs/ASBRs) may also fall		transit LSRs, such as Area or AS Border Routers (ABRs/ASBRs) may also
	into this category. This means that the new options and attributes		fall into this category. This means that the new options and
	should be signaled transparently, and only examined at those points		attributes should be signaled transparently, and only examined at
	that need to act on them.		those points that need to act on them.
	On the other hand, other options and attributes may require action		On the other hand, other options and attributes may require action
	at all transit LSRs along the path of the LSP. Inability to support		at all transit LSRs along the path of the LSP. Inability to support
	the required attributes by one of those transit LSRs may require the		the required attributes by one of those transit LSRs may require the
	LSR to refuse the establishment of the LSP.		LSR to refuse the establishment of the LSP.
	These considerations are particularly important in the context of		These considerations are particularly important in the context of
	backwards compatibility. In general, it should be possible to provide		backwards compatibility. In general, it should be possible to provide
	new MPLS services across a legacy network without upgrading those		new MPLS services across a legacy network without upgrading those
	LSRs that do not need to participate actively in the new services.		LSRs that do not need to participate actively in the new services.
	skipping to change at line 208		skipping to change at line 175
	RSVP includes a way for unrecognized objects to be transparently		RSVP includes a way for unrecognized objects to be transparently
	forwarded by transit nodes without them refusing the incoming		forwarded by transit nodes without them refusing the incoming
	protocol messages and without the objects being stripped from the		protocol messages and without the objects being stripped from the
	outgoing protocol message (see [RFC2205] Section 3.10). This		outgoing protocol message (see [RFC2205] Section 3.10). This
	capability extends to RSVP-TE and provides a good way to ensure that		capability extends to RSVP-TE and provides a good way to ensure that
	only those LSRs that understand a particular object examine it.		only those LSRs that understand a particular object examine it.
	This document distinguishes between options and attributes that are		This document distinguishes between options and attributes that are
	only required at key LSRs along the path of the LSP, and those that		only required at key LSRs along the path of the LSP, and those that
	must be acted on by every LSR along the LSP. Two LSP Attributes		must be acted on by every LSR along the LSP. Two LSP Attributes
	objects are defined in this document: the first may be passed		objects are defined in this document: using the C-Num definition
	transparently by LSRs that do not recognize it, the second must cause		rules inherrited from [RFC2205], the first is passed transparently
	LSP setup failure with the generation of a PathErr message with an		by LSRs that do not recognize it, and the second causes LSP setup
			failure with the generation of a PathErr message with an
	appropriate Error Code if an LSR does not recognize it.		appropriate Error Code if an LSR does not recognize it.
	1.1 Applicability to Generalized MPLS		1.1 Applicability to Generalized MPLS
	The RSVP-TE signaling protocol also forms the basis of a signaling		The RSVP-TE signaling protocol also forms the basis of a signaling
	protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and		protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and
	[RFC3473]. The extensions described in this document are intended to		[RFC3473]. The extensions described in this document are equally
	be equally applicable to MPLS and GMPLS.		applicable to MPLS and GMPLS.
	1.2 A Rejected Alternate Solution		1.2 A Rejected Alternate Solution
	A rejected alternate solution was to define a new C-Type for the		A rejected alternate solution was to define a new C-Type for the
	existing SESSION_ATTRIBUTE object. This new C-Type could allow a		existing SESSION_ATTRIBUTE object. This new C-Type could allow a
	larger Flags field and address the immediate problem.		larger Flags field and address the immediate problem.
	This solution was rejected because:		This solution was rejected because:
	- A new C-Type is not backward compatible with deployed		- A new C-Type is not backward compatible with deployed
	implementations that expect to see a C-Type of 1 or 7. It is		implementations that expect to see a C-Type of 1 or 7. It is
	skipping to change at line 289		skipping to change at line 256
	eight byte TLV with length field set to one.		eight byte TLV with length field set to one.
	Value		Value
	The data for the TLV padded as described above.		The data for the TLV padded as described above.
	3.1 Attributes Flags TLV		3.1 Attributes Flags TLV
	This document defines only one TLV type value. Type 1 indicates the		This document defines only one TLV type value. Type 1 indicates the
	Attributes Flags TLV. Other TLV types may be defined in future with		Attributes Flags TLV. Other TLV types may be defined in future with
	type values assigned by IANA.		type values assigned by IANA (see section 11.2).
	The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object		The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object
	and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5.		and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5.
	The bits in the TLV represent the same attributes regardless of which		The bits in the TLV represent the same attributes regardless of which
	object carries the TLV. Documents that define individual bits MUST		object carries the TLV. Documents that define individual bits MUST
	specify whether the bit may be set in one object or the other, or		specify whether the bit may be set in one object or the other, or
	both. It is not expected that a bit will be set in both objects on a		both. It is not expected that a bit will be set in both objects on a
	single Path message at the same time, but this is not ruled out by		single Path message at the same time, but this is not ruled out by
	this document.		this document.
	The Attributes Flags TLV value field is a variable length array of		The Attribute Flags TLV value field is an array of units of 32 flags
	flags numbered from the MSB as bit zero. The length field for this		numbered from the MSB as bit zero. The length field for this TLV is
	TLV is always a multiple of 4 bytes, regardless of the number bits		therefore always a multiple of 4 bytes, regardless of the number of
	carried.		bits carried and no padding is required.
	Unassigned bits are considered as reserved and MUST be set to zero		Unassigned bits are considered as reserved and MUST be set to zero
	on transmission by the originator of the object. Bits not contained		on transmission by the originator of the object. Bits not contained
	in the TLV MUST be assumed to be set to zero. If the TLV is absent		in the TLV MUST be assumed to be set to zero. If the TLV is absent
	either because it is not contained in the LSP_ATTRIBUTES or LSP_		either because it is not contained in the LSP_ATTRIBUTES or
	REQUIRED_ATTRIBUTES object, or because those objects are themselves		LSP_REQUIRED_ATTRIBUTES object, or because those objects are
	absent, all processing MUST be performed as though the bits were		themselves absent, all processing MUST be performed as though the
	present and set to zero.		bits were present and set to zero. That is to say, assigned bits that
			are not present either because the TLV is deliberatley forshortened,
			or because the TLV is not included MUST be treated as though they are
			present and are set to zero.
	No bits are defined in this document. The assignment of bits is		No bits are defined in this document. The assignment of bits is
	managed by IANA.		managed by IANA (see section 11.3).
	4. LSP_ATTRIBUTES Object		4. LSP_ATTRIBUTES Object
	The LSP_ATTRIBUTES object is used to signal attributes required in		The LSP_ATTRIBUTES object is used to signal attributes required in
	support of an LSP, or to indicate the nature or use of an LSP where		support of an LSP, or to indicate the nature or use of an LSP where
	that information is not required to be acted on by all transit LSRs.		that information is not required to be acted on by all transit LSRs.
	Specifically, if an LSR does not support the object, it forwards it		Specifically, if an LSR does not support the object, it forwards it
	unexamined and unchanged. This facilitates the exchange of attributes		unexamined and unchanged. This facilitates the exchange of attributes
	across legacy networks that do not support this new object.		across legacy networks that do not support this new object.
	skipping to change at line 367		skipping to change at line 337
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// Attributes TLVs //		// Attributes TLVs //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Attributes TLVs are encoded as described in Section 3.		The Attributes TLVs are encoded as described in Section 3.
	4.2 Generic Processing Rules for Path Messages		4.2 Generic Processing Rules for Path Messages
	An LSR that does not support this object will pass it on unaltered		An LSR that does not support this object is required to pass it on
	because of the C-Num.		unaltered as indicated by the C-Num and the rules defined in
			[RFC2205].
	An LSR that does support this object, but does not recognize a TLV		An LSR that does support this object, but does not recognize a TLV
	type code carried in this object MUST pass the TLV on unaltered		type code carried in this object MUST pass the TLV on unaltered
	in the LSP_ATTRIBUTES object that it places in the Path message		in the LSP_ATTRIBUTES object that it places in the Path message
	that it sends downstream.		that it sends downstream.
	An LSR that does support this object and recognizes a TLV but does		An LSR that does support this object and recognizes a TLV but does
	not support the attribute defined by the TLV MUST act as specified in		not support the attribute defined by the TLV MUST act as specified in
	the document that defines the TLV.		the document that defines the TLV.
	skipping to change at line 399		skipping to change at line 370
	An LSR that wishes to report operational status of an LSP may include		An LSR that wishes to report operational status of an LSP may include
	this object in a Resv message, or update the object that is already		this object in a Resv message, or update the object that is already
	carried in a Resv message.		carried in a Resv message.
	Note that this usage reports the state of the entire LSP and not the		Note that this usage reports the state of the entire LSP and not the
	state of the LSP at an individual LSR. This latter function is		state of the LSP at an individual LSR. This latter function is
	achieved using the LSP Attributes subobject of the Record Route		achieved using the LSP Attributes subobject of the Record Route
	object as described in Section 7.		object as described in Section 7.
	The bits in the Attributes TLV may be used to report operational		The bits in the Attributes TLV may be used to report operational
	status for the whole LSP. For example, an egress may report a		status for the whole LSP. For example, an egress LSR may report a
	particular status by setting a bit. LSRs within the network that		particular status by setting a bit. LSRs within the network that
	determine that this status has not been achieved may clear the bit		determine that this status has not been achieved may clear the bit
	as they forward the Resv message.		as they forward the Resv message.
	Observe that LSRs that do not support the object or do not support		Observe that LSRs that do not support the object or do not support
	the function characterized by a particular bit in the Attributes TLV		the function characterized by a particular bit in the Attributes TLV
	will not clear the bit when forwarding the Resv. Thus, care must be		will not clear the bit when forwarding the Resv. Thus, care must be
	taken in defining the usage of this object on a Resv. The usage of		taken in defining the usage of this object on a Resv. The usage of
	an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object		an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object
	on a Resv must be fully defined in the document that defines the bit.		on a Resv must be fully defined in the document that defines the bit.
	skipping to change at line 424		skipping to change at line 395
	An LSR that does not support this object will pass it on unaltered		An LSR that does not support this object will pass it on unaltered
	because of the C-Num.		because of the C-Num.
	5. LSP_REQUIRED_ATTRIBUTES Object		5. LSP_REQUIRED_ATTRIBUTES Object
	The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes		The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes
	required in support of an LSP, or to indicate the nature or use of		required in support of an LSP, or to indicate the nature or use of
	an LSP where that information MUST be inspected at each transit LSR.		an LSP where that information MUST be inspected at each transit LSR.
	Specifically, each transit LSR MUST examine the attributes in the		Specifically, each transit LSR MUST examine the attributes in the
	LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object		LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object
	transparently.		without acting on its contents.
	This object effectively extends the flags field in the SESSION_		This object effectively extends the flags field in the SESSION_
	ATTRIBUTE object and allows for the future inclusion of more complex		ATTRIBUTE object and allows for the future inclusion of more complex
	objects through TLVs. It complements the LSP_ATTRIBUTES object.		objects through TLVs. It complements the LSP_ATTRIBUTES object.
	The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb.		The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb.
	This C-Num value ensures that LSRs that do not recognize the object		This C-Num value ensures that LSRs that do not recognize the object
	reject the LSP setup effectively saying that they do not support the		reject the LSP setup effectively saying that they do not support the
	attributes requested. This means that this object SHOULD only be used		attributes requested. This means that this object SHOULD only be used
	for attributes that require support at some transit LSRs and so		for attributes that require support at some transit LSRs and so
	skipping to change at line 485		skipping to change at line 456
	specified in the document that defines that specific attribute.		specified in the document that defines that specific attribute.
	Note that this object is not used on a Resv. In order to report the		Note that this object is not used on a Resv. In order to report the
	status of an LSP either the LSP_ATTRIBUTES object on a Resv or the		status of an LSP either the LSP_ATTRIBUTES object on a Resv or the
	Attributes subobject in the Record Route object (see Section 7) must		Attributes subobject in the Record Route object (see Section 7) must
	be used.		be used.
	6. Inheritance Rules		6. Inheritance Rules
	In certain circumstances, when reaching an LSP region boundary, a		In certain circumstances, when reaching an LSP region boundary, a
	FA-LSP (see [MPLS-HIER]) is initially setup to allow the establishment		FA-LSP (see [MPLS-HIER]) is initially setup to allow the
	of the LSP carrying the LSP ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES		establishment of the LSP carrying the LSP ATTRIBUTES and/or
	objects. In this case, when the boundary LSR supports LSP_ATTRIBUTES		LSP_REQUIRED_ATTRIBUTES objects. In this case, when the boundary LSR
	and LSP_REQUIRED_ATTRIBUTES processing, the FA-LSP MAY upon local		supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES processing, the
	policy inherit a subset of the Attributes TLVs, in particular when the		FA-LSP MAY upon local policy inherit a subset of the Attributes TLVs,
	FA-LSP belongs to the same switching capability class than the		in particular when the FA-LSP belongs to the same switching
	triggering LSP.		capability class as the triggering LSP.
	When these conditions are met, the LSP_ATTRIBUTES and/or		When these conditions are met, the LSP_ATTRIBUTES and/or
	LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited		LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited
	Attributes TLVs in the Path message used to establish the FA-LSP. By		Attributes TLVs in the Path message used to establish the FA-LSP. By
	default (and in order to simplify deployment), none of the incoming		default (and in order to simplify deployment), none of the incoming
	LSP Attributes TLV are considered as inheritable. Note that when the		LSP Attributes TLV are considered as inheritable. Note that when the
	FA-LSP establishment itself requires one or more Attributes TLVs, an		FA-LSP establishment itself requires one or more Attributes TLVs, an
	'OR' operation is performed with the inherited set of values.		'OR' operation is performed with the inherited set of values.
	Documents that define individual bits for the LSP Attributes Flags		Documents that define individual bits for the LSP Attributes Flags
	TLV MUST specify whether these bits MAY be inherited or not (including		TLV MUST specify whether these bits MAY be inherited or not
	the condition to be met in order for this inheritance to occur). The		(including the condition to be met in order for this inheritance to
	same applies for any other TLV that will be defined following the		occur). The same applies for any other TLV that will be defined
	rules specified in Section 3.		following the rules specified in Section 3.
	7. Recording Attributes Per-LSP		7. Recording Attributes Per-LSP
	7.1 Requirements		7.1 Requirements
	In some circumstances it is useful to determine which of the		In some circumstances it is useful to determine which of the
	requested LSP attributes have been applied at which LSRs along the		requested LSP attributes have been applied at which LSRs along the
	path of the LSP. For example, an attribute may be requested in the		path of the LSP. For example, an attribute may be requested in the
	LSP_ATTRIBUTES object such that LSRs that do not support the object		LSP_ATTRIBUTES object such that LSRs that do not support the object
	are not required to support the attribute or provide the requested		are not required to support the attribute or provide the requested
	skipping to change at line 553		skipping to change at line 524
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// Attribute Flags //		// Attribute Flags //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	0x?? TBD RRO Attribute Subobject		0x?? TBD by IANA RRO Attribute Subobject (see section 11.6).
	Length		Length
	The Length contains the total length of the subobject in bytes,		The Length contains the total length of the subobject in bytes,
	including the Type and Length fields. This length must be a		including the Type and Length fields. This length must be a
	multiple of 4 and must be at least 8.		multiple of 4 and must be at least 8.
	Attribute Flags		Attribute Flags
	The attribute flags recorded for the specific hop.		The attribute flags recorded for the specific hop.
	7.3 Procedures		7.3 Procedures
	7.3.1 Subobject Presence Rules		7.3.1 Subobject Presence Rules
	The Attributes subobject is pushed onto the RECORD_ROUTE object		As will be clear from [RFC3209], the RECORD_ROUTE object is managed
	immediately prior to pushing the node's IP address or link		as a "stack" with each LSR adding sub-objects to the start of the
			object. The Attributes subobject is pushed onto the RECORD_ROUTE
			object immediately prior to pushing the node's IP address or link
	identifier. Thus, if label recording is being used, the Attributes		identifier. Thus, if label recording is being used, the Attributes
	subobject SHOULD be pushed onto the RECORD_ROUTE object after the		subobject SHOULD be pushed onto the RECORD_ROUTE object after the
	Record Label subobject(s).		Record Label subobject(s).
	A node MUST NOT push an Attributes subobject on to the RECORD_ROUTE		A node MUST NOT push an Attributes subobject on to the RECORD_ROUTE
	object without also pushing an IPv4, IPv6 or Unnumbered Interface ID		object without also pushing an IPv4, IPv6 or Unnumbered Interface ID
	subobject.		subobject.
	This means that an Attributes subobject is bound to the LSR		This means that an Attributes subobject is bound to the LSR
	identified by the subobject found in the RRO immediately before the		identified by the subobject found in the RRO immediately before the
	Attributes subobject.		Attributes subobject.
	If the new subobject causes the RRO to be too big to fit in a Path		If the new subobject causes the RRO to be too big to fit in a Path
	(or Resv) message, the processing MUST be as described in [RFC3209].		(or Resv) message, the processing MUST be as described in section
			4.4.3 of [RFC3209].
	If more than one Attributes subobject is found between a pair of		If more than one Attributes subobject is found between a pair of
	subobjects that identify LSRs, only the first one found (that is, the		subobjects that identify LSRs, only the first one found (that is, the
	nearest to the stop of the stack) SHALL have any meaning within the		nearest to the top of the stack) SHALL have any meaning within the
	context of this document. All such subobjects MUST be forwarded		context of this document. All such subobjects MUST be forwarded
	unmodified by transit LSRs.		unmodified by transit LSRs.
	7.3.2 Reporting Compliance with LSP Attributes		7.3.2 Reporting Compliance with LSP Attributes
	To report compliance with an attribute requested in the Attributes		To report compliance with an attribute requested in the Attributes
	Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in		Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in
	the Attributes subobject. To report non-compliance, an LSR MAY clear		the Attributes subobject. To report non-compliance, an LSR MAY clear
	the corresponding bit in the Attributes subobject.		the corresponding bit in the Attributes subobject.
	skipping to change at line 667		skipping to change at line 641
	On a Path message, the LSP_ATTRIBUTES object and LSP_REQUIRED_		On a Path message, the LSP_ATTRIBUTES object and LSP_REQUIRED_
	ATTRIBUTES objects are RECOMMENDED to be placed immediately after the		ATTRIBUTES objects are RECOMMENDED to be placed immediately after the
	SESSION_ATTRIBUTE object if it is present, or otherwise immediately		SESSION_ATTRIBUTE object if it is present, or otherwise immediately
	after the LABEL_REQUEST object.		after the LABEL_REQUEST object.
	If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES		If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES
	object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED		object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED
	to be placed first.		to be placed first.
	LSRs SHOULD be prepared to receive these objects in any order in any		LSRs MUST be prepared to receive these objects in any order in any
	position within a Path message. Subsequent instances of these objects		position within a Path message. Subsequent instances of these objects
	within a Path message SHOULD be ignored and those objects MUST be		within a Path message SHOULD be ignored and those objects MUST be
	forwarded unchanged.		forwarded unchanged.
	On a Resv message, the LSP_ATTRIBUTES object is placed in the flow		On a Resv message, the LSP_ATTRIBUTES object is placed in the flow
	descriptor and is associated with the FILTER_SPEC object that		descriptor and is associated with the FILTER_SPEC object that
	precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be		precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be
	placed immediately after the LABEL object.		placed immediately after the LABEL object.
	LSRs SHOULD be prepared to receive this object in any order in any		LSRs MUST be prepared to receive this object in any order in any
	position within a Resv message subject to the previous note. Only		position within a Resv message subject to the previous note. Only
	one instance of the LSP_ATTRIBUTES object is meaningful within the		one instance of the LSP_ATTRIBUTES object is meaningful within the
	context of a FILTER_SPEC object. Subsequent instances of the object		context of a FILTER_SPEC object. Subsequent instances of the object
	SHOULD be ignored and MUST be forwarded unchanged.		SHOULD be ignored and MUST be forwarded unchanged.
	10. IANA Considerations		10. Guidance for Key Application Scenarios
	10.1 New RSVP C-Nums and C-Types		As described in the Introduction section of this document, it may be
			that requested LSP attributes need to be acted on by only the egress
			LSR of the LSP, by certain key transit points (such as ABRs and
			ASBRs) or by all LSRs along the LSP. This section briefly describes
			how each of these scenarios is met. This section is informational and
			does not define any new procedures.
			10.1. Communicating to Egress LSRs
			When communicating LSP attributes that must be acted on only by the
			LSP egress LSR, the attributes should be communicated in the
			LSP_ATTRIBUTES object. Because of its C-Num, this object may be
			ignored (passed onwards, untouched) by transit LSRs that do not
			understand it. This means that the Path message will not be rejected
			by LSRs that do not understand the object. In this way, the requested
			LSP attributes are guaranteed to reach the egress LSR.
			Attributes are set within the LSP_ATTRIBUTES object according to
			which LSP attributes are required. Each attribute is defined in some
			RFC and is accompanied by a statement of what the expected behavior
			is. This behavior will include whether the attribute must be acted on
			by any LSR that recognises it, or specifically by the egress LSR.
			Thus any attribute that must be acted on only by an egress LSR will
			be defined in this way - any transit LSR seeing this attribute will
			either understand the semantics of the attribute and ignore it
			(forwarding it, unchanged), or will not understand the attribute and
			will ignore it (forwarding it, unchanged) according to the rules of
			the LSP_ATTRIBUTES object.
			The remaining issue is how the ingress LSR can know whether the
			egress LSR has acted correctly on the required LSP attribute. Another
			part of the definition of the attribute (in the defining RFC) is
			whether reporting is required. If reporting is required, the egress
			LSR is required to use the RRO Attributes subobject to report whether
			it has acted on the received attribute.
			If an egress LSR understands a received attribute as mandatory for an
			egress LSR, but does not wish to satisfy the request, it will reject
			the Path message. If an egress LSR understands the attribute, but
			believes it to be optional and does not wish to satisfy the request,
			it will report its non-compliance in the RRO Attributes subobject. If
			the egress LSR does not understand the received attribute, it may
			report non-compliance in the RRO Attributes subobject explicitly, or
			may omit the RRO Attributes subobject implying that it has not
			satisfied the request.
			10.2. Communicating to Key Transit LSRs
			Processing for key transit LSRs (such as ABRs and ASBRs) follows
			exactly as for egress LSR. The only difference is that the definition
			of the LSP attribute in the defining RFC will state that the
			attribute must be acted on by these transit LSRs.
			10.3. Communicating to All LSRs
			In order to force all LSRs to examine the LSP attributes, the
			LSP_REQUIRED_ATTRIBUTES object is used. The C-Num of this object is
			such that any LSR that does not recognise the object must reject a
			received Path message containing the object.
			An LSR that recognises the LSP_REQUIRED_ATTRIBUTES object, but that
			does not recognize an attributes will reject the Path message.
			An LSR that recognizes an attribute, but which does not wish to
			support the attribute reacts according to the definition of the
			attribute in the defining RFC. This may allow the LSR to ignore the
			attribute and forward it unchanged, or may require it to fail the LSP
			setup. The LSR may additionally be required to report whether it
			supports the attribute using the RRO Attributes subobject.
			11. IANA Considerations
			11.1 New RSVP C-Nums and C-Types
	Two new RSVP C-Nums are defined in this document and should be		Two new RSVP C-Nums are defined in this document and should be
	assigned by IANA.		assigned by IANA.
	o LSP_ATTRIBUTES object		o LSP_ATTRIBUTES object
	The C-Num should be of the form 11bbbbbb so that LSRs that do not		The C-Num should be of the form 11bbbbbb so that LSRs that do not
	recognize the object will ignore the object but forward it,		recognize the object will ignore the object but forward it,
	unexamined and unmodified, in all messages resulting from this		unexamined and unmodified, in all messages resulting from this
	message.		message.
	skipping to change at line 717		skipping to change at line 763
	recognize the object will reject the message that carries it with		recognize the object will reject the message that carries it with
	an "Unknown Object Class" error.		an "Unknown Object Class" error.
	One C-Type is defined for this object and should be assigned by		One C-Type is defined for this object and should be assigned by
	IANA.		IANA.
	o LSP Required Attributes TLVs		o LSP Required Attributes TLVs
	Recommended C-Type value 1.		Recommended C-Type value 1.
	10.2 New TLV Space		11.2 New TLV Space
	The two new objects referenced above are constructed from TLVs. Each		The two new objects referenced above are constructed from TLVs. Each
	TLV includes a 16-bit type identifier (the T-field). The same T-field		TLV includes a 16-bit type identifier (the T-field). The same T-field
	values are applicable to both objects.		values are applicable to both objects.
	IANA is requested to manage TLV type identifiers as follows:		IANA is requested to manage TLV type identifiers as follows:
	- TLV Type (T-field value)		- TLV Type (T-field value)
	- TLV Name		- TLV Name
	- Whether allowed on LSP_ATTRIBUTES object		- Whether allowed on LSP_ATTRIBUTES object
	- Whether allowed on LSP_REQUIRED_ATTRIBUTES object.		- Whether allowed on LSP_REQUIRED_ATTRIBUTES object.
	This document defines one TLV type as follows:		This document defines one TLV type as follows:
	- TLV Type = 1		- TLV Type = 1
	- TLV Name = Attributes Flags TLV		- TLV Name = Attributes Flags TLV
	- allowed on LSP_ATTRIBUTES object		- allowed on LSP_ATTRIBUTES object
	- allowed on LSP_REQUIRED_ATTRIBUTES object.		- allowed on LSP_REQUIRED_ATTRIBUTES object.
	10.3 Attributes Flags		New TLV type values may be allocated only by an IETF Consensus
			action.
			11.3 Attributes Flags
	This document provides new attributes bit flags for use in other		This document provides new attributes bit flags for use in other
	documents that specify new RSVP-TE attributes. These flags are		documents that specify new RSVP-TE attributes. These flags are
	present in the Attributes Flags TLV referenced in the previous		present in the Attributes Flags TLV referenced in the previous
	section.		section.
	IANA is requested to manage the space of attributes bit flags		IANA is requested to manage the space of attributes bit flags
	numbering them in the usual IETF notation starting at zero and		numbering them in the usual IETF notation starting at zero and
	continuing through 2039.		continuing at least through 31.
			New bit numbers may be allocated only by an IETF Consensus action.
	Each bit should be tracked with the following qualities:		Each bit should be tracked with the following qualities:
	- Bit number		- Bit number
	- Defining RFC		- Defining RFC
	- Name of bit		- Name of bit
	- Whether there is meaning in the Attribute Flags TLV on a Path		- Whether there is meaning in the Attribute Flags TLV on a Path
	- Whether there is meaning in the Attribute Flags TLV on a Resv		- Whether there is meaning in the Attribute Flags TLV on a Resv
	- Whether there is meaning in the RRO Attributes Subobject.		- Whether there is meaning in the RRO Attributes Subobject.
	Note that this means that all bits in the Attribute Flags TLV and the		Note that this means that all bits in the Attribute Flags TLV and the
	RRO Attributes Subobject use the same bit number regardless of		RRO Attributes Subobject use the same bit number regardless of
	whether they are used in one or both places. Thus, only one list of		whether they are used in one or both places. Thus, only one list of
	bits is required to be maintained. (It would be meaningless in the		bits is required to be maintained. (It would be meaningless in the
	context of this document for a bit to have no meaning in neither the		context of this document for a bit to have no meaning in neither the
	Attribute Flags TLV nor the RRO Attributes Subobject.)		Attribute Flags TLV nor the RRO Attributes Subobject.)
	10.4 SESSION_ATTRIBUTE Flags Field		11.4 SESSION_ATTRIBUTE Flags Field
	This document does not make any alterations to the definition of the		This document does not make any alterations to the definition of the
	existing SESSION_ATTRIBUTE object nor to the definition of meanings		existing SESSION_ATTRIBUTE object nor to the definition of meanings
	assigned to the flags in the Flags field of that object. These flags		assigned to the flags in the Flags field of that object. These flags
	are assigned meanings in various other RFCs and Internet Drafts.		are assigned meanings in various other RFCs and Internet Drafts.
	It is suggested that IANA manage the allocation of meaning to the		It is suggested that IANA manage the allocation of meaning to the
	bits in the Flags field of the SESSION_ATTRIBUTE object to prevent		bits in the Flags field of the SESSION_ATTRIBUTE object to prevent
	accidental double allocation of any one bit.		accidental double allocation of any one bit.
	10.5 New Error Codes		It is suggested that new SESSION_ATTRIBUTE Flags be allocated only by
			an IETF Consensus action.
			11.5 New Error Codes
	This document defines the following new error codes and error values.		This document defines the following new error codes and error values.
	Numeric values should be assigned by IANA.		Numeric values should be assigned by IANA.
	Error Code Error Value		Error Code Error Value
	"Unknown Attributes TLV" Identifies the unknown TLV type code.		"Unknown Attributes TLV" Identifies the unknown TLV type code.
	"Unknown Attributes Bit" Identifies the unknown Attribute Bit.		"Unknown Attributes Bit" Identifies the unknown Attribute Bit.
	10.6 New Record Route Subobject Identifier		11.6 New Record Route Subobject Identifier
	A new subobject is defined for inclusion in the RECORD_ROUTE object.		A new subobject is defined for inclusion in the RECORD_ROUTE object.
	The RRO Attributes subobject is identified by a Type value of TBD.		The RRO Attributes subobject is identified by a Type value of TBD.
	11. Security Considerations		12. Security Considerations
	This document adds two new objects to the RSVP Path message as used		This document adds two new objects to the RSVP Path message as used
	in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE		in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE
	object carried on may RSVP messages. It does not introduce any new		object carried on may RSVP messages. It does not introduce any new
	direct security issues and the reader is referred to the security		direct security issues and the reader is referred to the security
	considerations expressed in [RFC2205], [RFC3209] and [RFC3473].		considerations expressed in [RFC2205], [RFC3209] and [RFC3473].
	It is of passing note that any signaling request that indicates the		It is of passing note that any signaling request that indicates the
	functional preferences or attributes of an MPLS LSP may provide		functional preferences or attributes of an MPLS LSP may provide
	anyone with unauthorized access to the contents of the message with		anyone with unauthorized access to the contents of the message with
	skipping to change at line 813		skipping to change at line 867
	signaling message.		signaling message.
	Similarly, the addition of attribute recording information to the		Similarly, the addition of attribute recording information to the
	RRO may reveal information about the status of the LSP and the		RRO may reveal information about the status of the LSP and the
	capabilities of individual LSRs that operators wish to keep secret.		capabilities of individual LSRs that operators wish to keep secret.
	The same strategy that applies to other RRO subobjects also applies		The same strategy that applies to other RRO subobjects also applies
	here. Note, however, that there is a tension between notifying the		here. Note, however, that there is a tension between notifying the
	head end of the LSP status at transit LSRs, and hiding the existence		head end of the LSP status at transit LSRs, and hiding the existence
	or identity of the transit LSRs.		or identity of the transit LSRs.
	12. Acknowledgements		13. Acknowledgements
	Credit to the OSPF Working Group for inspiration from their solution		Credit to the OSPF Working Group for inspiration from their solution
	to a similar problem. Thanks to Rahul Aggarwal for his careful review		to a similar problem. Thanks to Rahul Aggarwal for his careful review
	and support of this work. Thanks also to Raymond Zhang, Kireeti		and support of this work. Thanks also to Raymond Zhang, Kireeti
	Kompella, Philip Matthews, Jim Gibson and Alan Kullberg for their		Kompella, Philip Matthews, Jim Gibson and Alan Kullberg for their
	input. As so often, thanks to John Drake for useful offline		input. As so often, thanks to John Drake for useful offline
	discussions.		discussions. Thanks to Mike Shand for providing the Routing
			Directorate review and to Joel Halpern for the General Area review -
			both picked up on some unclarities.
	13. Intellectual Property Consideration		14. Intellectual Property Consideration
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at line 846		skipping to change at line 902
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	14. Normative References		15. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S.		[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S.
	and S. Jamin, "Resource ReserVation Protocol --		and S. Jamin, "Resource ReserVation Protocol --
	Version 1 Functional Specification", RFC 2205,		Version 1 Functional Specification", RFC 2205,
	September 1997.		September 1997.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
	Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions		Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
	to RSVP for LSP Tunnels", RFC 3209, December 2001.		to RSVP for LSP Tunnels", RFC 3209, December 2001.
	[RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label		[RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Functional Description",		Switching (GMPLS) Signaling Functional Description",
	RFC 3471, January 2003.		RFC 3471, January 2003.
	[RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling -		[RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling -
	RSVP-TE Extensions", RFC 3473 January 2003.		RSVP-TE Extensions", RFC 3473 January 2003.
	[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,		16. Informative References
	RFC 3667, February 2004.
	[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
	Technology", BCP 79, RFC 3668, February 2004.
	15. Informative References
	[RFC2026] Bradner, S., "The Internet Standards Process		[RFC2026] Bradner, S., "The Internet Standards Process
	-- Revision 3", RFC 2026, October 1996.		-- Revision 3", RFC 2026, October 1996.
	[RFC3031] Rosen, E., Viswanathan, A., and Callon, R.,		[RFC3031] Rosen, E., Viswanathan, A., and Callon, R.,
	"Multiprotocol Label Switching		"Multiprotocol Label Switching
	Architecture", RFC 3031, January 2001.		Architecture", RFC 3031, January 2001.
	[FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for		[FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for
	LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-06		LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute,
	.txt>, Internet Draft, work in progress.		work in progress.
	[MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with		[MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
	MPLS TE", Work in Progress.		MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in
			progress.
	16. Authors' Addresses		17. Authors' Addresses
	Adrian Farrel		Adrian Farrel
	Old Dog Consulting		Old Dog Consulting
	Phone: +44 (0) 1978 860944		Phone: +44 (0) 1978 860944
	EMail: adrian@olddog.co.uk		EMail: adrian@olddog.co.uk
	Dimitri Papadimitriou (Alcatel)		Dimitri Papadimitriou (Alcatel)
	Fr. Wellesplein 1,		Fr. Wellesplein 1,
	B-2018 Antwerpen, Belgium		B-2018 Antwerpen, Belgium
	Phone: +32 3 240-8491		Phone: +32 3 240-8491
	skipping to change at line 915		skipping to change at line 966
	USA		USA
	EMail: jpv@cisco.com		EMail: jpv@cisco.com
	Arthi Ayyangar		Arthi Ayyangar
	Juniper Networks, Inc.		Juniper Networks, Inc.
	1194 N.Mathilda Ave		1194 N.Mathilda Ave
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	USA		USA
	EMail: arthi@juniper.net		EMail: arthi@juniper.net
	17. Disclaimer of Validity		18. Disclaimer of Validity
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	18. Full Copyright Statement		19. Full Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/