draft-ietf-mpls-rsvpte-attributes-00.txt		draft-ietf-mpls-rsvpte-attributes-01.txt
	Network Working Group Adrian Farrel (Editor)		Network Working Group Adrian Farrel (Editor)
	Internet Draft Old Dog Consulting		Internet Draft Old Dog Consulting
	Category: Standards Track		Category: Standards Track
	Expires: May 2004 Dimitri Papadimitriou		Expires: June 2004 Dimitri Papadimitriou
	Alcatel		Alcatel
	Jean-Philippe Vasseur		Jean-Philippe Vasseur
	Cisco Systems, Inc.		Cisco Systems, Inc.
	November 2003		Arthi Ayyangar
			Juniper Networks
			December 2003
	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-00.txt		draft-ietf-mpls-rsvpte-attributes-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full		This document is an Internet-Draft and is in full conformance
	conformance with all provisions of Section 10 of RFC 2026		with all provisions of Section 10 of RFC 2026 [RFC2026].
	[RFC2026].
	Internet-Drafts are working documents of the Internet		Internet-Drafts are working documents of the Internet
	Engineering Task Force (IETF), its areas, and its working		Engineering Task Force (IETF), its areas, and its working
	groups. Note that other groups may also distribute working		groups. Note that other groups may also distribute working
	documents as Internet-Drafts.		documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of		Internet-Drafts are draft documents valid for a maximum of
	six months and may be updated, replaced, or obsoleted by		six months and may be updated, replaced, or obsoleted by
	other documents at any time. It is inappropriate to use		other documents at any time. It is inappropriate to use
	Internet-Drafts as reference material or to cite them other		Internet-Drafts as reference material or to cite them other
	skipping to change at line 56		skipping to change at line 58
	(the SESSION_ATTRIBUTE object) which carries a flags field used to		(the SESSION_ATTRIBUTE object) which carries a flags field used to
	indicate options and attributes of the LSP. That flags field has		indicate options and attributes of the LSP. That flags field has
	eight bits allowing for eight options to be set.		eight bits allowing for eight options to be set.
	Recent proposals in many documents that extend RSVP-TE for signaling		Recent proposals in many documents that extend RSVP-TE for signaling
	additional features and function for MPLS LSPs have suggested uses		additional features and function for MPLS LSPs have suggested uses
	for each of the previously unused bits.		for each of the previously unused bits.
	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. This makes RSVP-TE easily extensible		arbitrary attribute parameters to make RSVP-TE easily extensible to
	to support new requirements.		support new requirements. Additionally, this document defines a way
			to record the attributes applied to the LSP on a hop-by-hop basis.
			0. Change History
			This section to be removed before publication.
			0.1 Changes 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 Attibutes 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.
	1. Introduction and Problem Statement		1. Introduction and Problem Statement
	Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)		Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
	[RFC3031] may be established using the RSVP-TE signaling protocol		[RFC3031] may be established using the RSVP-TE signaling protocol
	[RFC3209]. This protocol uses the Path message to request that a LSP		[RFC3209]. This protocol uses the Path message to request that a LSP
	be set up. The Path message includes the SESSION_ATTRIBUTE object		be set up. The Path message includes the SESSION_ATTRIBUTE object
	which carries a flags field used to indicate desired options and		which carries a flags field used to indicate desired options and
	attributes of the LSP.		attributes of the LSP.
	skipping to change at line 80		skipping to change at line 104
	assigned in [FRR] for fast re-reroute functionality leaving only		assigned in [FRR] for fast re-reroute functionality leaving only
	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 up to thirty		constructed from TLVs, and a new TLV is defined to carry a variable
	two new attributes bits. Because of the nature of the TLV		number of attributes bits. Because of the nature of the TLV
	construction the object is flexible and allows the future definition		construction the object is flexible and allows the future definition
	of:		of:
	- further sets of thirty two bits if more flags are needed to carry		- further sets of bits flags if further, distinct uses are discovered
	yet more attributes
	- 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
			specifically scoped to an LSP. They may be set differently on
			separate LSPs within the same Session.
	It is noted that that some options and attributes do not need to be		It is noted that 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 AS Border Routers (ASBRs) may also fall into this		LSRs, such as AS Border Routers (ASBRs) may also fall into this
	category. This means that the new options and attributes should be		category. This means that the new options and attributes should be
	signaled transparently, and only examined at those points that need		signaled transparently, and only examined at those points that need
	to act on them.		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
	skipping to change at line 151		skipping to change at line 178
	- A C-Type is not backward compatible with deployed implementations		- A C-Type is not backward compatible with deployed implementations
	that expect to see a C-Type of 1 or 7. It is important that any		that expect to see a C-Type of 1 or 7. It is important that any
	solution be capable of carrying new attributes transparently		solution be capable of carrying new attributes transparently
	across legacy LSRs if those LSRs are not required to act on the		across legacy LSRs if those LSRs are not required to act on the
	attributes.		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.
	1.3 Protocol Developments Without an Explicit Need
	[This section to be removed if this draft proceeds towards an RFC.
	References in this section are not intended to be normative.]
	It is unusual and inadvised for the IETF to accept a speculative
	change to a protocol without an explicit need. That is, in this case,
	although there is an obvious problem identified, there is no existing
	Working Group proposal that requires further option bits. For today,
	the existing protocol objects are adequate.
	There are, however, several Internet Drafts that propose additional
	attributes associated with LSP setup. These include [CRANKBACK],
	[REOPT] and [INTER-AS]. In view of the likelihood of one or more of
	these drafts advancing to RFC, and considering the probable
	requirement to be able to signal further options and attributes for
	other purposes in the very near future, it is proposed that this
	document be debated within the MPLS Working Group so that a solution
	will be available should the need arise.
	Further, the lack of a considered approach to handle the shortage of
	SESSION_ATTRIBUTE flags might give rise to a range of diverse
	solutions each developed within the context of a single protocol
	extension. Clearly a single coherent solution is better.
	[This section to be removed if this draft proceeds towards an RFC.]
	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].
	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].
	skipping to change at line 230		skipping to change at line 230
	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.
	The Attributes Flags TLV value field is a 32 bit array of flags		The Attibutes Flags TLV may be present in an LSP_ATTRIBUTES object
	numbered from the MSB as bit zero. The length field for this TLV is		and/or an LSP_REQUIRED_ATTRIBUTES object. The bits in the TLV
	set to 4.		represent the same attributes regardeless of which object carries the
			TLV. Documents that define individual bits MUST specify whether the
			bit may be set in one object or the other, or both.
			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
			TLV is always a multiple of 4 bytes, regardless of the number bits
			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 and ignored on receipt.		on transmission and ignored on receipt. Bits not contained 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_REQUIRED_
			ATTRIBUTES object, or because those objects are themselves absent,
			all processing MUST be performed as though the bits were 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
	skipping to change at line 282		skipping to change at line 294
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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
	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, or recognizes the TLV but does not		type code carried in this object MUST pass the TLV on un-altered
	support the attribute MUST act as specified in the document that		in the LSP_ATTRIBUTES object that it places in the Path message
	defines the TLV.		that it sends downstream.
			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
			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
	object 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.
	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 a LSP, or to indicate the nature or use of		required in support of a LSP, or to indicate the nature or use of
	a LSP where that information MUST be inspected at each transit LSR.		a LSP where that information MUST be inspected at each transit LSR.
	skipping to change at line 322		skipping to change at line 338
	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_REAQUIRED_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.
	skipping to change at line 348		skipping to change at line 364
	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
	unknown TLV type code.		unknown TLV type code.
	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 (that is a number between 0		the unknown bit in the Attributes Flags.
	and 32).
	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. Message Formats		6. Recording Attributes
			6.1 Requirements
			In some circumstances it is useful to determine which of 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
			LSP_ATTRIBUTES object such that LSRs that do not support the object
			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
			which LSRs acted on the request and which ignored it.
			Additionally, there may be other qualities that need to be reported
			on a hop-by-hop basis. These are currently indicated in the Flags
			field of RRO subobjects. Since there are only eight bits available
			in this field, and since some are already assigned and there is also
			likely to an increase in allocations in new documents, there is a
			need for some other method to report per-hop attributes.
			6.2 RRO Attributes Subobject
			The RRO Attributes Subobject may be carried in the RECORD_ROUTE
			object if it is present. The subobject uses the standard format of
			an RRO subobject.
			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
			bit flags.
			There is a one-to-one correspondance between bits in the Attributes
			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
			the procedures sections, below, for more information.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			// Attribute Flags //
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type
			0x?? TBD RRO Attribute Subobject
			Length
			The Length contains the total length of the subobject in bytes,
			including the Type and Length fields. This length must be a
			multiple of 4 and must be at least 8.
			Attribute Flags
			The attribute flags recorded for the specific hop.
			6.3 Procedures
			6.3.1 Subobject Presence Rules
			The Attributes subobject is pushed onto the RECORD_ROUTE object
			immediately prior to pushing on the node's IP address. Thus, if
			label recording is being used, the Attributes subobject SHOULD be
			pushed onto the RECORD_ROUTE object after the Record Label
			subobject(s).
			A node MUST NOT push on a Attributes subobject without also
			pushing on an IPv4 or IPv6 subobject.
			This means that an Attributes subobject is bound to the LSR
			identified by the IP address subobject found in the RRO immediately
			before the Attributes subobject.
			If the newly added subobject causes the RRO to be too big to fit in a
			Path (or Resv) message, the processing SHALL be as described in
			[RFC3209].
			If more than one Attributes subobject is found between a pair of
			subobjects that identify LSRs, only the first one found SHALL have
			any meaning within the context of this document. All such subobjects
			shall be forwarded unmodified by transit LSRs.
			6.3.2 Reporting Compliance with LSP Attributes
			To report compliance with an attribute requested in the Attributes
			Flags TLV, an LSR MAY set the corresponding bit (see section 7) in
			the Attributes subobject. To report non-compliance, an LSR MAY clear
			the corresponding bit in the Attributes subobject.
			The requirement to report compliance MUST be specified in the
			document that defines the usage of any bit. This will reduce to a
			statement of whether hop-by-hop acknowledgement is required.
			6.3.3 Reporting Per-Hop Attributes
			To report a per-hop attribute, an LSR sets the appropriate bit in the
			Attributes subobject.
			The requirement to report a per-hop attribute MUST be specified in
			the document that defines the usage of the bit.
			6.3.4 Default Behavior
			By default all bits in an Attibutes subobject SHOULD be set to zero.
			If an Attribute subobject is not long enough to include a specific
			bit, the bit MUST be assumed to be set to zero.
			If the RRO subobject is not present for a hop in the LSP, all bits
			MUST be assumed to be set to zero.
			7. Summary of Attribute Bit Allocation
			This document defines two uses of per-LSP attribute flag bit fields.
			The bit numbering in the Attributes Flags TLV and the RRO Attributes
			subobject is identical. That is the same attribute is indicated by
			the same bit in both places. This means that only a single registry
			of bits is maintained.
			The consequence is a degree of clarity in implementation and
			registration.
			Note, however, that it is not always the case that a bit will be used
			in both the Attributes Flags TLV and the RRO Attributes subobject.
			For example, an attribute may be requested using the Attributes Flags
			TLV, but there is no requirement to report the handling of the
			attribute on a hop-by-hop basis. Conversely, there may be a
			requirement to report the attributes of an LSP on a hop-by-hop basis,
			but there is no corresponding request attribute.
			In these cases, a single bit number is still assigned for both the
			Attributes Flags TLV and the RRO 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 setting of zero.
			8. 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 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. 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.		within a Path message SHOULD be ignored.
	7. IANA Considerations		9. IANA Considerations
	7.1 New RSVP C-Nums and C-Types		9.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 409		skipping to change at line 561
	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.
	7.2 New TLV Space		9.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 the space of TLV type identifiers as		IANA is requested to manage TLV type identifiers as follows:
	follows:
	- TLV Type		- TLV Type
	- 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 = LSP Attributes Flags		- 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.
	7.3 Attributes Flags		9.3 Attributes Flags
	This document provides 32 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 LSP 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.		numbering them in the usual IETF notation starting at zero and
			continuing through 2039.
	7.4 SESSION_ATTRIBUTE Flags Field		Each bit should be tracked with the following qualities:
			- Bit number
			- Defining RFC
			- Name of bit
			- Whether there is meaning in the Attibute Flags TLV (yes/no)
			- Whether there is meaning in the RRO Attributes Subobject (yes/no).
			Note that this means that all bits in the Attribute Flags TLV and the
			RRO Attributes Subobject use the same bit number regardless of
			whether they are used in one or both places. Thus, only one list of
			bits is required to be maintained.
			9.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.
	7.5 New Error Codes		9.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.
	8. Security Considerations		9.6 New Record Route Subobject Identifier
			A new subobject is defined for inclusion in the RECORD_ROUTE object.
			The RRO Attributes subobject is identified by a Type value of TBD.
			10. 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. It does not introduce any new direct		in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE
	security issues and the reader is referred to the security		object carried on may RSVP messages. It does not introduce any new
			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
	information about the LSP that an administrator may wish to keep		information about the LSP that an administrator may wish to keep
	secret. Although this document adds new objects for signaling desired		secret. Although this document adds new objects for signaling desired
	LSP attributes, it does not contribute to this issue which can		LSP attributes, it does not contribute to this issue which can
	only be satisfactorily handled by encrypting the content of the		only be satisfactorily handled by encrypting the content of the
	signaling message.		signaling message.
	9. Acknowledgements		Similarly, the addition of attribute recording information to the
			RRO may reveal information about the status of the LSP and the
			capabilities of individual LSRs that operators wish to keep secret.
			The same strategy that applies to other RRO subobjects also applies
			here. Note, however, that there is a tension between notifying the
			head end of the LSP status at transit LSRs, and hiding the existence
			or identity of the transit LSRs.
			11. 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 for his input.		work. Thanks also to Raymond Zhang, Kireeti Kompella and Philip
			Matthews for their input.
	10. Intellectual Property Consideration		12. 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 intellectual property or other rights that might be		of any intellectual property or other rights that might be
	claimed to pertain to the implementation or use of the		claimed to pertain to the implementation or use of the
	technology described in this document or the extent to		technology described in this document or the extent to
	which any license under such rights might or might not be		which any license under such rights might or might not be
	available; neither does it represent that it has made any		available; neither does it represent that it has made any
	effort to identify any such rights. Information on the		effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track		IETF's procedures with respect to rights in standards-track
	and standards-related documentation can be found in BCP-11.		and standards-related documentation can be found in BCP-11.
	skipping to change at line 507		skipping to change at line 687
	permission for the use of such proprietary rights by		permission for the use of such proprietary rights by
	implementors or users of this specification can be obtained		implementors or users of this specification can be obtained
	from the IETF Secretariat.		from the IETF Secretariat.
	The IETF invites any interested party to bring to its		The IETF invites any interested party to bring to its
	attention any copyrights, patents or patent applications, or		attention any copyrights, patents or patent applications, or
	other proprietary rights which may cover technology that may		other proprietary rights which may cover technology that may
	be required to practice this standard. Please address the		be required to practice this standard. Please address the
	information to the IETF Executive Director.		information to the IETF Executive Director.
	11. Normative References		13. 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.
	[FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for		14. Informative References
	LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-03
	.txt>, Internet Draft, work in progress.
	12. 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-01.txt>,		Engineering", <draft-vasseur-inter-as-te-01.txt>,
	Internet Draft, work in progress.		Internet Draft, work in progress.
			[FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for
			LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-03
			.txt>, Internet Draft, work in progress.
	[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.
	13. Authors' Addresses		15. 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
	EMail: dimitri.papadimitriou@alcatel.be		EMail: dimitri.papadimitriou@alcatel.be
	Jean Philippe Vasseur		Jean Philippe Vasseur
	Cisco Systems, Inc.		Cisco Systems, Inc.
	300 Apollo Drive		300 Apollo Drive
	Chelmsford, MA 01824		Chelmsford, MA 01824
	300 Beaver Brook Road		300 Beaver Brook Road
	Boxborough , MA - 01719		Boxborough , MA - 01719
	USA		USA
	Email: jpv@cisco.com		EMail: jpv@cisco.com
	14. Full Copyright Statement		Arthi Ayyangar
			Juniper Networks, Inc.
			1194 N.Mathilda Ave
			Sunnyvale, CA 94089
			USA
			EMail: arthi@juniper.net
			16. Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights		Copyright (C) The Internet Society (2003). All Rights
	Reserved.		Reserved.
	This document and translations of it may be copied and		This document and translations of it may be copied and
	furnished to others, and derivative works that comment on		furnished to others, and derivative works that comment on
	or otherwise explain it or assist in its implementation may		or otherwise explain it or assist in its implementation may
	be prepared, copied, published and distributed, in whole or		be prepared, copied, published and distributed, in whole or
	in part, without restriction of any kind, provided that the		in part, without restriction of any kind, provided that the
	above copyright notice and this paragraph are included on		above copyright notice and this paragraph are included on
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/