draft-ietf-mpls-rsvpte-attributes-02.txt		draft-ietf-mpls-rsvpte-attributes-03.txt
	skipping to change at line 14		skipping to change at line 14
	Category: Standards Track		Category: Standards Track
	Expires: July 2004 Dimitri Papadimitriou		Expires: July 2004 Dimitri Papadimitriou
	Alcatel		Alcatel
	Jean-Philippe Vasseur		Jean-Philippe Vasseur
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Arthi Ayyangar		Arthi Ayyangar
	Juniper Networks		Juniper Networks
	January 2004		March 2004
	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-02.txt		draft-ietf-mpls-rsvpte-attributes-03.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance		This document is an Internet-Draft and is in full conformance
	with all provisions of Section 10 of RFC 2026 [RFC2026].		with all provisions of Section 10 of RFC 2026 [RFC2026].
	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 line 66		skipping to change at line 66
	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		0. Change History
	This section to be removed before publication.		This section to be removed before publication.
	0.1 Changes from 01 to 02 Version		0.1 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.2 Changes from 01 to 02 Version
	- Minor typographical changes.		- Minor typographical changes.
	0.2 Changes from 00 to 01 Version		0.3 Changes from 00 to 01 Version
	- Change Attributes Flags TLV to be variable length so that more bits		- Change Attributes Flags TLV to be variable length so that more bits
	can easily be added in the future.		can easily be added in the future.
	- Define default behaviors for bits absent from the TLV and for		- Define default behaviors for bits absent from the TLV and for
	absence of the TLV.		absence of the TLV.
	- Clarify the IANA requirements for tracking Attributes Flags bits.		- Clarify the IANA requirements for tracking Attributes Flags bits.
	- Introduce RRO Attibutes Subobject and describe usage.		- Introduce RRO Attributes Subobject and describe usage.
	- Move Fast Reroute reference to informational.		- Move Fast Reroute reference to informational.
	- Update security considerations to handle new RRO subobject		- Update security considerations to handle new RRO subobject
	- Remove section that explained the need for this document in		- Remove section that explained the need for this document in
	advance of any definitive bit definitions.		advance of any definitive bit definitions.
	- Tighten rules for processing LSP_ATTRIBUTES object in cases where		- Tighten rules for processing LSP_ATTRIBUTES object in cases where
	TLVs are unknown or unsupported.		TLVs are unknown or unsupported.
	- Clarify that LSP Attributes apply to individual LSPs and not to		- Clarify that LSP Attributes apply to individual LSPs and not to
	entire sessions.		entire sessions.
			Contents
			1. Introduction and Problem Statement 3
			1.1 Applicability to Generalized MPLS 4
			1.2 A Rejected Alternate Solution 4
			2. Terminology 5
			3. Attributes TLVs 5
			3.1 Attributes Flags TLV 5
			4. LSP_ATTRIBUTES Object 6
			4.1 Format 7
			4.2 Generic Processing Rules for Path Messages 7
			4.3 Generic Processing Rules for Resv Messages 7
			5. LSP_REQUIRED_ATTRIBUTES Object 8
			5.1 Format 8
			5.2 Generic Processing Rules 8
			6. Inheritance Rules 9
			7. Recording Attributes Per-LSP 9
			7.1 Requirements 9
			7.2 RRO Attributes Subobject 10
			7.3 Procedures 10
			7.3.1 Subobject Presence Rules 10
			7.3.2 Reporting Compliance with LSP Attributes 11
			7.3.3 Reporting Per-Hop Attributes 11
			7.3.4 Default Behavior 11
			8. Summary of Attribute Bit Allocation 11
			9. Message Formats 12
			10. IANA Considerations 13
			10.1 New RSVP C-Nums and C-Types 13
			10.2 New TLV Space 13
			10.3 Attributes Flags 14
			10.4 SESSION_ATTRIBUTE Flags Field 14
			10.5 New Error Codes 14
			10.6 New Record Route Subobject Identifier 14
			11. Security Considerations 15
			12. Acknowledgements 15
			13. Intellectual Property Consideration 15
			13.1 IPR Disclosure Acknowledgement 16
			14. Normative References 16
			15. Informative References 16
			16. Authors' Addresses 17
			17. Full Copyright Statement 17
	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
	three of those bits are assigned in [RFC3209]. A further two bits are		three of those bits are assigned in [RFC3209]. A further two bits are
	skipping to change at line 120		skipping to change at line 169
	of:		of:
	- further bit flags if further, distinct uses are discovered		- further bit flags if further, distinct uses are discovered
	- arbitrary options and attributes parameters carried as individual		- arbitrary options and attributes parameters carried as individual
	TLVs.		TLVs.
	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 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 and egress. Special transit
	LSRs, such as area or AS Border Routers (ABR/ASBRs) may also fall		LSRs, such as Area or AS Border Routers (ABRs/ASBRs) may also fall
	into this category. This means that the new options and attributes		into this category. This means that the new options and attributes
	should be signaled transparently, and only examined at those points		should be signaled transparently, and only examined at those points
	that need to act on them.		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.
			Moreover, some features just require action on specific intermediate
			hops, and not on every visited LSR.
	Note that options already specified for the SESSION_ATTRIBUTE object		Note that options already specified for the SESSION_ATTRIBUTE object
	in pre-existing RFCs are not migrated to the new mechanisms described		in pre-existing RFCs are not migrated to the new mechanisms described
	in this documnet.		in this document.
	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 with 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: the first may be passed
	transparently by LSRs that do not recognize it, the second must cause		transparently by LSRs that do not recognize it, the second must cause
	LSP setup failure with the generation of a PathErr message with an		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.
	skipping to change at line 186		skipping to change at line 237
	act on the attributes.		act on the attributes.
	- Support for arbitrary attributes parameters through TLVs would		- Support for arbitrary attributes parameters through TLVs would
	have meant a significant change of substance to the existing		have meant a significant change of substance to the existing
	object.		object.
	2. Terminology		2. Terminology
	This document uses terminology from the MPLS architecture document		This document uses terminology from the MPLS architecture document
	[RFC3031] and from the RSVP-TE protocol specification [RFC3209] which		[RFC3031] and from the RSVP-TE protocol specification [RFC3209] which
	inherits from the RSVP specification [RFC2205].		inherits from the RSVP specification [RFC2205]. It also makes uses of
			the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and
			[RFC3473].
	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 [6].		document are to be interpreted as described in RFC2119 [6].
	3. Attributes TLVs		3. Attributes TLVs
	Attributes carried by the new objects defined in this document are		Attributes carried by the new objects defined in this document are
	encoded within TLVs. One or more TLVs may be present in each object.		encoded within TLVs. One or more TLVs may be present in each object.
	There are no ordering rules for TLVs and no interpretation should be		There are no ordering rules for TLVs and no interpretation should be
	skipping to change at line 235		skipping to change at line 288
	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.
	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. The bits in the TLV		and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5.
	represent the same attributes regardless of which object carries the		The bits in the TLV represent the same attributes regardless of which
	TLV. Documents that define individual bits MUST specify whether the		object carries the TLV. Documents that define individual bits MUST
	bit may be set in one object or the other, or both. It is not		specify whether the bit may be set in one object or the other, or
	expected that a bit will be set in both objects on a single Path		both. It is not expected that a bit will be set in both objects on a
	message at the same time, but this is not ruled out by this document.		single Path message at the same time, but this is not ruled out by
			this document.
	The Attributes Flags TLV value field is a variable length array of		The Attributes Flags TLV value field is a variable length array of
	flags numbered from the MSB as bit zero. The length field for this		flags numbered from the MSB as bit zero. The length field for this
	TLV is always a multiple of 4 bytes, regardless of the number bits		TLV is always a multiple of 4 bytes, regardless of the number bits
	carried.		carried.
	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 in the		on transmission by the originator of the object. Bits not contained
	TLV MUST be assumed to be set to zero. If the TLV is absent either		in the TLV MUST be assumed to be set to zero. If the TLV is absent
	because it is not contained in the LSP_ATTRIBUTES or LSP_REQUIRED_		either because it is not contained in the LSP_ATTRIBUTES or LSP_
	ATTRIBUTES object, or because those objects are themselves absent,		REQUIRED_ATTRIBUTES object, or because those objects are themselves
	all processing MUST be performed as though the bits were present		absent, all processing MUST be performed as though the bits were
	and set to zero.		present and 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.
	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.
	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.		objects through TLVs.
	Note that some function may require an LSR to inspect both the		Note that some function may require an LSR to inspect both the
	SESSION_ATTRIBUTE object, and the LSP_ATTRIBUTES or		SESSION_ATTRIBUTE object, and the LSP_ATTRIBUTES or
	LSP_REQUIRED_ATTIBUTES object.		LSP_REQUIRED_ATTRIBUTES object.
			The LSP_ATTRIBUTES object may also be used to report LSP operational
			state on a Resv even when no LSP_ATTRIBUTES or LSP_REQUIRED_
			ATTRIBUTES object was carried on the corresponding Path message. The
			object is added or updated by LSRs that support the object. LSRs that
			do not understand the object or have nothing to report, do not add
			the object and forward it unchanged on Resv messages that they
			generate.
	The LSP_ATTRIBUTES object class is TBD of the form 11bbbbbb. This		The LSP_ATTRIBUTES object class is TBD of the form 11bbbbbb. This
	C-Num value (see section 7) ensures that LSRs that do not recognize		C-Num value (see Section 8) ensures that LSRs that do not recognize
	the object pass it on transparently.		the object pass it on transparently.
	One C-Type is defined, C-Type = 1 for LSP Attributes.		One C-Type is defined, C-Type = 1 for LSP Attributes.
	This object is optional and may be placed on Path messages to convey		This object is optional and may be placed on Path messages to convey
	additional information about the desired attributes of the LSP.		additional information about the desired attributes of the LSP, and.
			on Resv messages to report operational state.
	4.1 Format		4.1 Format
	LSP_ATTRIBUTES class = TBD, C-Type = 1		LSP_ATTRIBUTES class = TBD, C-Type = 1
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// 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		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 will pass it on unaltered
	because of the C-Num.		because of the C-Num.
	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
	skipping to change at line 320		skipping to change at line 383
	the document that defines the TLV.		the document that defines the TLV.
	An LSR that supports the Attributes Flags TLV, but does not		An LSR that supports the Attributes Flags TLV, but does not
	recognize a bit set in the Attributes Flags TLV MUST forward the		recognize a bit set in the Attributes Flags TLV MUST forward the
	TLV unchanged.		TLV unchanged.
	An LSR that supports the Attributes Flags TLV and recognizes a bit		An LSR that supports the Attributes Flags TLV and recognizes a bit
	that is set but does not support the indicated attribute MUST act as		that is set but does not support the indicated attribute MUST act as
	specified in the document that defines the bit.		specified in the document that defines the bit.
			4.3 Generic Processing Rules for Resv Messages
			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
			carried in a Resv message.
			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
			achieved using the LSP Attributes subobject of the Record Route
			object as described in Section 7.
			The bits in the Attributes TLV may be used to report operational
			status for the whole LSP. For example, an egress may report a
			particular status by setting a bit. LSRs within the network that
			determine that this status has not been achieved may clear the bit
			as they forward the Resv message.
			Observe that LSRs that do not support the object or do not support
			the function characterized by a particular bit in the Attributes TLV
			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
			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.
			Additional TLVs may also be defined to be carried in this object on
			a Resv.
			An LSR that does not support this object will pass it on unaltered
			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.		transparently.
	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		This C-Num value ensures that LSRs that do not
	recognize the object reject the LSP setup effectively saying that		recognize the object reject the LSP setup effectively saying that
	they do not support the attributes requested. This means that this		they do not support the attributes requested. This means that this
	object SHOULD only be used for attributes that require support at		object SHOULD only be used for attributes that require support at
	some transit LSRs and so require examination at all transit LSRs. See		some transit LSRs and so require examination at all transit LSRs. See
	section 4 for how end-to-end and selective attributes are signaled.		Section 4 for how end-to-end and selective attributes are signaled.
	One C-Type is defined, C-Type = 1 for LSP Required Attributes.		One C-Type is defined, C-Type = 1 for LSP Required Attributes.
	This object is optional and may be placed on Path messages to convey		This object is optional and may be placed on Path messages to convey
	additional information about the desired attributes of the LSP.		additional information about the desired attributes of the LSP.
	5.1 Format		5.1 Format
	LSP_REQUIRED_ATTRIBUTES class = TBD, C-Type = 1		LSP_REQUIRED_ATTRIBUTES class = TBD, C-Type = 1
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// Attributes TLVs //		// Attributes TLVs //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Attributes TLVs are encoded as described in section 3.		The Attributes TLVs are encoded as described in Section 3.
	5.2 Generic Processing Rules		5.2 Generic Processing Rules
	An LSR that does not support this object will use a PathErr to reject		An LSR that does not support this object will use a PathErr to reject
	the Path message based on the C-Num using the error code "Unknown		the Path message based on the C-Num using the error code "Unknown
	Object Class".		Object Class".
	An LSR that does not recognize a TLV type code carried in this object		An LSR that does not recognize a TLV type code carried in this object
	MUST reject the Path message using a PathErr with Error Code		MUST reject the Path message using a PathErr with Error Code
	"Unknown Attributes TLV" and Error Value set to the value of the		"Unknown Attributes TLV" and Error Value set to the value of the
	skipping to change at line 380		skipping to change at line 473
	An LSR that does not recognize a bit set in the Attributes Flags		An LSR that does not recognize a bit set in the Attributes Flags
	TLV MUST reject the Path message using a PathErr with Error Code		TLV MUST reject the Path message using a PathErr with Error Code
	"Unknown Attributes Bit" and Error Value set to the bit number of		"Unknown Attributes Bit" and Error Value set to the bit number of
	the unknown bit in the Attributes Flags.		the unknown bit in the Attributes Flags.
	An LSR that recognizes an attribute, however encoded, but which does		An LSR that recognizes an attribute, however encoded, but which does
	not support that attribute MUST act according to the behavior		not support that attribute MUST act according to the behavior
	specified in the document that defines that specific attribute.		specified in the document that defines that specific attribute.
	6. Recording Attributes		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
			Attributes subobject in the Record Route object (see Section 7) must
			be used.
	6.1 Requirements		6. Inheritance Rules
			In certain circumstances, when reaching an LSP region boundary, a
			FA-LSP (see [MPLS-HIER]) is initially setup to allow the establishment
			of the LSP carrying the LSP ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES
			objects. In this case, when the boundary LSR supports LSP_ATTRIBUTES
			and LSP_REQUIRED_ATTRIBUTES processing, the FA-LSP MAY upon local
			policy inherit a subset of the Attributes TLVs, in particular when the
			FA-LSP belongs to the same switching capability class than the
			triggering LSP.
			When these conditions are met, the LSP_ATTRIBUTES and/or
			LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited
			Attributes TLVs in the Path message used to establish the FA-LSP. By
			default (and in order to simplify deployment), none of the incoming
			LSP Attributes TLV are considered as inheritable. Note that when the
			FA-LSP establishment itself requires one or more Attributes TLVs, an
			'OR' operation is performed with the inherited set of values.
			Documents that define individual bits for the LSP Attributes Flags
			TLV MUST specify whether these bits MAY be inherited or not (including
			the condition to be met in order for this inheritance to occur). The
			same applies for any other TLV that will be defined following the
			rules specified in Section 3.
			7. Recording Attributes Per-LSP
			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
	function. In this case, it may be useful to the ingress LSR to know		function. In this case, it may be useful to the ingress LSR to know
	which LSRs acted on the request and which ignored it.		which LSRs acted on the request and which ignored it.
	Additionally, there may be other qualities that need to be reported		Additionally, there may be other qualities that need to be reported
	on a hop-by-hop basis. These are currently indicated in the Flags		on a hop-by-hop basis. These are currently indicated in the Flags
	field of RRO subobjects. Since there are only eight bits available		field of RRO subobjects. Since there are only eight bits available
	in this field, and since some are already assigned and there is also		in this field, and since some are already assigned and there is also
	likely to be an increase in allocations in new documents, there is a		likely to be an increase in allocations in new documents, there is a
	need for some other method to report per-hop attributes.		need for some other method to report per-hop attributes.
	6.2 RRO Attributes Subobject		7.2 RRO Attributes Subobject
	The RRO Attributes Subobject may be carried in the RECORD_ROUTE		The RRO Attributes Subobject may be carried in the RECORD_ROUTE
	object if it is present. The subobject uses the standard format of		object if it is present. The subobject uses the standard format of
	an RRO subobject.		an RRO subobject.
	The length is variable as for the Attributes Flags TLV. The content		The length is variable as for the Attributes Flags TLV. The content
	is the same as the Attribute Flags TLV - that is, it is a series of		is the same as the Attribute Flags TLV - that is, it is a series of
	bit flags.		bit flags.
	There is a one-to-one correspondance between bits in the Attributes		There is a one-to-one correspondence between bits in the Attributes
	Flags TLV and the RRO Attributes Subobject. If a bit is only required		Flags TLV and the RRO Attributes Subobject. If a bit is only required
	in one of the two places, it is reserved in the other place. See		in one of the two places, it is reserved in the other place. See
	the procedures sections, below, for more information.		the procedures sections, below, for more information.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	skipping to change at line 438		skipping to change at line 561
	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.
	6.3 Procedures		7.3 Procedures
	6.3.1 Subobject Presence Rules		7.3.1 Subobject Presence Rules
	The Attributes subobject is pushed onto the RECORD_ROUTE object		The Attributes subobject is pushed onto the RECORD_ROUTE object
	immediately prior to pushing the node's IP address or link		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.
	skipping to change at line 465		skipping to change at line 588
	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 [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 stop 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.
	6.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 7) 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.
	The requirement to report compliance MUST be specified in the		The requirement to report compliance MUST be specified in the
	document that defines the usage of any bit. This will reduce to a		document that defines the usage of any bit. This will reduce to a
	statement of whether hop-by-hop acknowledgement is required.		statement of whether hop-by-hop acknowledgement is required.
	6.3.3 Reporting Per-Hop Attributes		7.3.3 Reporting Per-Hop Attributes
	To report a per-hop attribute, an LSR sets the appropriate bit in the		To report a per-hop attribute, an LSR sets the appropriate bit in the
	Attributes subobject.		Attributes subobject.
	The requirement to report a per-hop attribute MUST be specified in		The requirement to report a per-hop attribute MUST be specified in
	the document that defines the usage of the bit.		the document that defines the usage of the bit.
	6.3.4 Default Behavior		7.3.4 Default Behavior
	By default all bits in an Attibutes subobject SHOULD be set to zero.		By default all bits in an Attributes subobject SHOULD be set to zero.
	If a received Attribute subobject is not long enough to include a		If a received Attribute subobject is not long enough to include a
	specific numbered bit, that bit MUST be treated as though present and		specific numbered bit, that bit MUST be treated as though present and
	as if set to zero.		as if set to zero.
	If the RRO subobject is not present for a hop in the LSP, all bits		If the RRO subobject is not present for a hop in the LSP, all bits
	MUST be assumed to be set to zero.		MUST be assumed to be set to zero.
	7. Summary of Attribute Bit Allocation		8. Summary of Attribute Bit Allocation
	This document defines two uses of per-LSP attribute flag bit fields.		This document defines two uses of per-LSP attribute flag bit fields.
	The bit numbering in the Attributes Flags TLV and the RRO Attributes		The bit numbering in the Attributes Flags TLV and the RRO Attributes
	subobject is identical. That is, the same attribute is indicated by		subobject is identical. That is, the same attribute is indicated by
	the same bit in both places. This means that only a single registry		the same bit in both places. This means that only a single registry
	of bits is maintained.		of bits is maintained.
	The consequence is a degree of clarity in implementation and		The consequence is a degree of clarity in implementation and
	registration.		registration.
	skipping to change at line 521		skipping to change at line 644
	requirement to report the attributes of an LSP on a hop-by-hop basis,		requirement to report the attributes of an LSP on a hop-by-hop basis,
	but there is no corresponding request attribute.		but there is no corresponding request attribute.
	In these cases, a single bit number is still assigned for both the		In these cases, a single bit number is still assigned for both the
	Attributes Flags TLV and the RRO Attributes subobject even though the		Attributes Flags TLV and the RRO Attributes subobject even though the
	bit may be irrelevant in either the Attributes Flags or the RRO		bit may be irrelevant in either the Attributes Flags or the RRO
	Attributes subobject. The document that defines the usage of the new		Attributes subobject. The document that defines the usage of the new
	bit MUST state in which places it is used and MUST handle a default		bit MUST state in which places it is used and MUST handle a default
	setting of zero.		setting of zero.
	8. Message Formats		9. Message Formats
	The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY		The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY
	be carried in a Path message.		be carried in a Path message. The LSP_ATTRIBUTES object MAY be
			carried in a Resv message.
	The order of objects in RSVP-TE messages is recommended, but		The order of objects in RSVP-TE messages is recommended, but
	implementations must be capable of receiving the objects in any		implementations must be capable of receiving the objects in any
	meaningful order. The LSP_ATTRIBUTES object and LSP_REQUIRED_		meaningful order.
			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 SHOULD 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 transparently.		forwarded unchanged.
	9. IANA Considerations		On a Resv message, the LSP_ATTRIBUTES object is placed in the flow
			descriptor and is associated with the FILTER_SPEC object that
			precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be
			placed immediately after the LABEL object.
	9.1 New RSVP C-Nums and C-Types		LSRs SHOULD be prepared to receive this object in any order in any
			position within a Resv message subject to the previous note. Only
			one instance of the LSP_ATTRIBUTES object is meaningful within the
			context of a FILTER_SPEC object. Subsequent instances of the object
			SHOULD be ignored and MUST be forwarded unchanged.
			10. IANA Considerations
			10.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 576		skipping to change at line 713
	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.
	9.2 New TLV Space		10.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.
	9.3 Attributes Flags		10.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 through 2039.
	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 Attibute Flags TLV (yes/no)		- Whether there is meaning in the Attribute Flags TLV on a Path
	- Whether there is meaning in the RRO Attributes Subobject (yes/no).		- Whether there is meaning in the Attribute Flags TLV on a Resv
			- 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.)
	9.4 SESSION_ATTRIBUTE Flags Field		10.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.
	9.5 New Error Codes		10.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.
	9.6 New Record Route Subobject Identifier		10.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.
	10. Security Considerations		11. 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 671		skipping to change at line 809
	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.
	11. Acknowledgements		12. 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.		to a similar problem.
	Thanks to Rahul Aggarwal for his careful review and support of this		Thanks to Rahul Aggarwal for his careful review and support of this
	work. Thanks also to Raymond Zhang, Kireeti Kompella, Philip Matthews		work. Thanks also to Raymond Zhang, Kireeti Kompella, Philip Matthews,
	and Jim Gibson for their input.		Jim Gibson and Alan Kullberg for their input.
	12. Intellectual Property Consideration		13. Intellectual Property Consideration
	The IETF takes no position regarding the validity or scope		The IETF takes no position regarding the validity or scope of any
	of any intellectual property or other rights that might be		Intellectual Property Rights or other rights that might be claimed
	claimed to pertain to the implementation or use of the		to pertain to the implementation or use of the technology
	technology described in this document or the extent to		described in this document or the extent to which any license
	which any license under such rights might or might not be		under such rights might or might not be available; nor does it
	available; neither does it represent that it has made any		represent that it has made any independent effort to identify any
	effort to identify any such rights. Information on the		such rights. Information on the procedures with respect to rights
	IETF's procedures with respect to rights in standards-track		in RFC documents can be found in BCP 78 and BCP 79.
	and standards-related documentation can be found in BCP-11.
	Copies of claims of rights made available for publication
	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
	implementors or users of this specification can be obtained
	from the IETF Secretariat.
	The IETF invites any interested party to bring to its		Copies of IPR disclosures made to the IETF Secretariat and any
	attention any copyrights, patents or patent applications, or		assurances of licenses to be made available, or the result of an
	other proprietary rights which may cover technology that may		attempt made to obtain a general license or permission for the use
	be required to practice this standard. Please address the		of such proprietary rights by implementers or users of this
	information to the IETF Executive Director.		specification can be obtained from the IETF on-line IPR repository
			at http://www.ietf.org/ipr.
	13. Normative References		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.
			13.1 IPR Disclosure Acknowledgement
			By submitting this Internet-Draft, I certify that any applicable
			patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
			14. 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.
	14. Informative References		[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
			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.
	[INTER-AS] Vasseur, JP., Zhang, R., "Inter-AS MPLS Traffic		[INTER-AS] Vasseur, JP., Zhang, R., "Inter-AS MPLS Traffic
	Engineering", <draft-vasseur-inter-as-te-03.txt>,		Engineering", <draft-vasseur-inter-as-te-03.txt>,
	skipping to change at line 752		skipping to change at line 903
	[OSPF-CAPS] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S.,		[OSPF-CAPS] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S.,
	Vasseur, JP., "Extensions to OSPF for Advertising		Vasseur, JP., "Extensions to OSPF for Advertising
	Optional Router Capabilities", <draft-ietf-ospf-cap-		Optional Router Capabilities", <draft-ietf-ospf-cap-
	00.txt>, Internet Draft, work in progress.		00.txt>, Internet Draft, work in progress.
	[REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS		[REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS
	Traffic Engineering loosely routed explicit LSP path",		Traffic Engineering loosely routed explicit LSP path",
	<draft-vasseur-mpls-loose-path-reopt-02.txt>, Internet		<draft-vasseur-mpls-loose-path-reopt-02.txt>, Internet
	Draft, work in progress.		Draft, work in progress.
	15. Authors' Addresses		[MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
			MPLS TE", Work in Progress.
			16. 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 779		skipping to change at line 933
	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
	16. Full Copyright Statement		17. Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights
	Reserved.
	This document and translations of it may be copied and		Copyright (C) The Internet Society (2004). This document is
	furnished to others, and derivative works that comment on		subject to the rights, licenses and restrictions contained in BCP
	or otherwise explain it or assist in its implementation may		78, and except as set forth therein, the authors retain all their
	be prepared, copied, published and distributed, in whole or		rights.
	in part, without restriction of any kind, provided that the
	above copyright notice and this paragraph are included on
	all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by
	removing the copyright notice or references to the Internet
	Society or other Internet organizations, except as needed
	for the purpose of developing Internet standards in which
	case the procedures for copyrights defined in the Internet
	Standards process must be followed, or as required to
	translate it into languages other than English.
	The limited permissions granted above are perpetual and		This document and the information contained herein are provided
	will not be revoked by the Internet Society or its		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	successors or assigns. This document and the information		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	contained herein is provided on an "AS IS" basis and THE		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
	NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		PARTICULAR PURPOSE.
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
	PURPOSE.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/