draft-ietf-mpls-generalized-rsvp-te-07.txt		draft-ietf-mpls-generalized-rsvp-te-08.txt
	Network Working Group Lou Berger - Editor (Movaz Networks)		Network Working Group Lou Berger - Editor (Movaz Networks)
	Internet Draft Peter Ashwood-Smith (Nortel Networks)		Internet Draft
	Expiration Date: October 2002 Ayan Banerjee (Calient Networks)		Expiration Date: February 2003
	Greg Bernstein (Ciena Corporation)
	John Drake (Calient Networks)
	Yanhe Fan (Axiowave Networks)
	Kireeti Kompella (Juniper Networks)
	Jonathan P. Lang (Calient Networks)
	Fong Liaw (Solas Research)
	Eric Mannie (KPNQwest)
	Ping Pan (Juniper Networks, Inc.)
	Bala Rajagopalan (Tellium)
	Yakov Rekhter (Juniper Networks)
	Debanjan Saha (Tellium)
	Vishal Sharma (Metanoia)
	George Swallow (Cisco Systems)
	Z. Bo Tang (Tellium)
	April 2002		August 2002
	Generalized MPLS Signaling - RSVP-TE Extensions		Generalized MPLS Signaling - RSVP-TE Extensions
	draft-ietf-mpls-generalized-rsvp-te-07.txt		draft-ietf-mpls-generalized-rsvp-te-08.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		all provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	To view the current status of any Internet-Draft, please check the		To view the current status of any Internet-Draft, please check the
	"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow		"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
	Directory, see http://www.ietf.org/shadow.html.		Directory, see http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document describes extensions to RSVP-TE signaling required to		This document describes extensions to MPLS (Multi-Protocol Label
	support Generalized MPLS. Generalized MPLS extends MPLS to encompass		Switching) RSVP-TE (Resource ReserVation Protocol - Traffic
	time-division (e.g. SONET/SDH ADMs), wavelength (optical lambdas) and		Engineering) signaling required to support Generalized MPLS.
	spatial switching (e.g. incoming port or fiber to outgoing port or		Generalized MPLS extends the MPLS control plane to encompass time-
	fiber). This document presents an RSVP-TE specific description of		division (e.g., Synchronous Optical Network and Synchronous Digital
	the extensions. A generic functional description and a CR-LDP		Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial
	specific description can be found in separate documents.		switching (e.g. incoming port or fiber to outgoing port or fiber).
			This document presents a RSVP-TE specific description of the
			extensions. A generic functional description can be found in
			separate documents.
	Contents		Contents
	1 Introduction ................................................ 3		1 Introduction ................................................ 3
	2 Label Related Formats ...................................... 3		2 Label Related Formats ...................................... 3
	2.1 Generalized Label Request Object ............................ 3		2.1 Generalized Label Request Object ............................ 3
	2.2 Generalized Label Object .................................... 5		2.2 Bandwidth Encoding .......................................... 5
	2.3 Waveband Switching .......................................... 6		2.3 Generalized Label Object .................................... 5
	2.4 Suggested Label ............................................. 7		2.4 Waveband Switching .......................................... 6
	2.5 Label Set ................................................... 7		2.5 Suggested Label ............................................. 7
			2.6 Label Set ................................................... 7
	3 Bidirectional LSPs .......................................... 9		3 Bidirectional LSPs .......................................... 9
	3.1 Procedures .................................................. 9		3.1 Procedures .................................................. 9
	3.2 Contention Resolution ....................................... 10		3.2 Contention Resolution ....................................... 10
	4 Notification ................................................ 10		4 Notification ................................................ 10
	4.1 Acceptable Label Set Object ................................. 10		4.1 Acceptable Label Set Object ................................. 10
	4.2 Notify Request Objects ...................................... 11		4.2 Notify Request Objects ...................................... 11
	4.3 Notify Message .............................................. 12		4.3 Notify Message .............................................. 12
	4.4 Removing State with a PathErr message ....................... 14		4.4 Removing State with a PathErr message ....................... 14
	5 Explicit Label Control ...................................... 15		5 Explicit Label Control ...................................... 15
	5.1 Label ERO subobject ......................................... 15		5.1 Label ERO subobject ......................................... 15
	skipping to change at page 2, line 44		skipping to change at page 2, line 45
	9 Fault Handling .............................................. 25		9 Fault Handling .............................................. 25
	9.1 Restart_Cap Object .......................................... 26		9.1 Restart_Cap Object .......................................... 26
	9.2 Processing of Restart_Cap Object ............................ 27		9.2 Processing of Restart_Cap Object ............................ 27
	9.3 Modification to Hello Processing to Support State Recovery .. 27		9.3 Modification to Hello Processing to Support State Recovery .. 27
	9.4 Control Channel Faults ...................................... 28		9.4 Control Channel Faults ...................................... 28
	9.5 Nodal Faults ................................................ 28		9.5 Nodal Faults ................................................ 28
	10 RSVP Message Formats and Handling ........................... 31		10 RSVP Message Formats and Handling ........................... 31
	10.1 RSVP Message Formats ........................................ 31		10.1 RSVP Message Formats ........................................ 31
	10.2 Addressing Path and PathTear Messages ...................... 33		10.2 Addressing Path and PathTear Messages ...................... 33
	11 Acknowledgments ............................................. 33		11 Acknowledgments ............................................. 33
	12 Security Considerations ..................................... 33		12 Security Considerations ..................................... 34
	13 IANA Considerations ......................................... 34		13 IANA Considerations ......................................... 34
	13.1 IANA [Suggestions /] Assignments ............................ 35		13.1 IANA [Suggestions /] Assignments ............................ 35
	14 References .................................................. 36		14 Intellectual Property Considerations ........................ 37
	14.1 Normative References ........................................ 37		15 References .................................................. 37
	14.2 Informative References ...................................... 37		15.1 Normative References ........................................ 37
	15 Authors' Addresses .......................................... 38		15.2 Informative References ...................................... 38
			16 Contributors ................................................ 38
	[Editor's note: changes to be removed prior to publication as an RFC.]		17 Contact Address ............................................. 41
	Changes from previous version:
	o Reorder author's list to indicate primary contact
	o Fixed indication of infinite restart time
	o Added IANA [Suggestions /] Assignments Section
	o Split references section
	o Minor editorial changes and clarifications
	1. Introduction		1. Introduction
	Generalized MPLS extends MPLS from supporting packet (PSC) interfaces		Generalized MPLS extends MPLS from supporting packet (PSC) interfaces
	and switching to include support of three new classes of interfaces		and switching to include support of three new classes of interfaces
	and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and		and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and
	Fiber-Switch (FSC). A functional description of the extensions to		Fiber-Switch (FSC). A functional description of the extensions to
	MPLS signaling needed to support the new classes of interfaces and		MPLS signaling needed to support the new classes of interfaces and
	switching is provided in [GMPLS-SIG]. This document presents RSVP-TE		switching is provided in [GMPLS-SIG]. This document presents RSVP-TE
	specific formats and mechanisms needed to support all four classes of		specific formats and mechanisms needed to support all four classes of
	interfaces. CR-LDP extensions can be found in [GMPLS-LDP].		interfaces.
	[GMPLS-SIG] should be viewed as a companion document to this		[GMPLS-SIG] should be viewed as a companion document to this
	document. The format of this document parallels [GMPLS-SIG]. In		document. The format of this document parallels [GMPLS-SIG]. In
	addition to the other features of Generalized MPLS, this document		addition to the other features of Generalized MPLS, this document
	also defines RSVP-TE specific features to support rapid failure		also defines RSVP-TE specific features to support rapid failure
	notification, see Sections 4.2 and 4.3.		notification, see Sections 4.2 and 4.3.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Label Related Formats		2. Label Related Formats
	This section defines formats for a generalized label request, a		This section defines formats for a generalized label request, a
	generalized label, support for waveband switching, suggested label		generalized label, support for waveband switching, suggested label
	and label sets.		and label sets.
	2.1. Generalized Label Request Object		2.1. Generalized Label Request Object
	A Path message SHOULD contain as specific an LSP Encoding Type as		A Path message SHOULD contain as specific an LSP (Label Switched
	possible to allow the maximum flexibility in switching by transit		Path) Encoding Type as possible to allow the maximum flexibility in
	LSRs. A Generalized Label Request object is set by the ingress node,		switching by transit LSRs. A Generalized Label Request object is set
	transparently passed by transit nodes, and used by the egress node.		by the ingress node, transparently passed by transit nodes, and used
	The Switching Type field may also be updated hop-by-hop.		by the egress node. The Switching Type field may also be updated
			hop-by-hop.
	The format of a Generalized Label Request object is:		The format of a Generalized Label Request object is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num (19)|C-Type (4)[TBA]|		| Length | Class-Num (19)|C-Type (4)[TBA]|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSP Enc. Type |Switching Type | G-PID |		| LSP Enc. Type |Switching Type | G-PID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 12		skipping to change at page 5, line 5
	G-PID is not supported, then the penultimate hop MUST generate a		G-PID is not supported, then the penultimate hop MUST generate a
	ResvErr message with a "Routing problem/Unacceptable label value"		ResvErr message with a "Routing problem/Unacceptable label value"
	indication. The generated ResvErr message MAY include an Acceptable		indication. The generated ResvErr message MAY include an Acceptable
	Label Set, see Section 4.1.		Label Set, see Section 4.1.
	When an error message is not generated, normal processing occurs. In		When an error message is not generated, normal processing occurs. In
	the transit case this will typically result in a Path message being		the transit case this will typically result in a Path message being
	propagated. In the egress case and PHP special case this will		propagated. In the egress case and PHP special case this will
	typically result in a Resv message being generated.		typically result in a Resv message being generated.
	2.1.2. Bandwidth Encoding		2.2. Bandwidth Encoding
	Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC		Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC
	objects. See [GMPLS-SIG] for a definition of values to be used for		objects. See [GMPLS-SIG] for a definition of values to be used for
	specific signal types. These values are set in the Peak Data Rate		specific signal types. These values are set in the Peak Data Rate
	field of Int-Serv objects. Other bandwidth/service related		field of Int-Serv objects, see [RFC2210]. Other bandwidth/service
	parameters in the object are ignored and carried transparently.		related parameters in the object are ignored and carried
			transparently.
	2.2. Generalized Label Object		2.3. Generalized Label Object
	The format of a Generalized Label object is:		The format of a Generalized Label object is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num (16)| C-Type (2) |		| Length | Class-Num (16)| C-Type (2) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label |		| Label |
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters and encoding of		See [GMPLS-SIG] for a description of parameters and encoding of
	labels.		labels.
	2.2.1. Procedures		2.3.1. Procedures
	The Generalized Label travels in the upstream direction in Resv		The Generalized Label travels in the upstream direction in Resv
	messages.		messages.
	The presence of both a generalized and normal label object in a Resv		The presence of both a generalized and normal label object in a Resv
	message is a protocol error and should treated as a malformed message		message is a protocol error and should treated as a malformed message
	by the recipient.		by the recipient.
	The recipient of a Resv message containing a Generalized Label		The recipient of a Resv message containing a Generalized Label
	verifies that the values passed are acceptable. If the label is		verifies that the values passed are acceptable. If the label is
	unacceptable then the recipient MUST generate a ResvErr message with		unacceptable then the recipient MUST generate a ResvErr message with
	a "Routing problem/MPLS label allocation failure" indication.		a "Routing problem/MPLS label allocation failure" indication.
	2.3. Waveband Switching		2.4. Waveband Switching
	Waveband switching uses the same format as the generalized label, see		Waveband switching uses the same format as the generalized label, see
	section 2.2. Waveband Label uses C-Type (3),		section 2.2. Waveband Label uses C-Type (3),
	In the context of waveband switching, the generalized label has the		In the context of waveband switching, the generalized label has the
	following format:		following format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 29		skipping to change at page 6, line 27
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Waveband Id |		| Waveband Id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Start Label |		| Start Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| End Label |		| End Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.		See [GMPLS-SIG] for a description of parameters.
	2.3.1. Procedures		2.4.1. Procedures
	The procedures defined in Section 2.2.1 apply to waveband switching.		The procedures defined in Section 2.2.1 apply to waveband switching.
	This includes generating a ResvErr message with a "Routing		This includes generating a ResvErr message with a "Routing
	problem/MPLS label allocation failure" indication if any of the label		problem/MPLS label allocation failure" indication if any of the label
	fields are unrecognized or unacceptable.		fields are unrecognized or unacceptable.
	Additionally, when a waveband is switched to another waveband, it is		Additionally, when a waveband is switched to another waveband, it is
	possible that the wavelengths within the waveband will be mirrored		possible that the wavelengths within the waveband will be mirrored
	about a center frequency. When this type of switching is employed,		about a center frequency. When this type of switching is employed,
	the start and end label in the waveband label object MUST be flipped		the start and end label in the waveband label object MUST be flipped
	before forwarding the label object with the new waveband Id. In this		before forwarding the label object with the new waveband Id. In this
	manner an egress/ingress LSR which receives a waveband label which		manner an egress/ingress LSR which receives a waveband label which
	has these values inverted, knows that it must also invert its egress		has these values inverted, knows that it must also invert its egress
	association to pick up the proper wavelengths.		association to pick up the proper wavelengths.
	This operation MUST be performed in both directions when a		This operation MUST be performed in both directions when a
	bidirectional waveband tunnel is being established.		bidirectional waveband tunnel is being established.
	2.4. Suggested Label		2.5. Suggested Label
	The format of a Suggested_Label object is identical to a generalized		The format of a Suggested_Label object is identical to a generalized
	label. It is used in Path messages. A Suggested_Label object uses		label. It is used in Path messages. A Suggested_Label object uses
	Class-Number TBA (of form 10bbbbbb) and the C-Type of the label being		Class-Number TBA (of form 10bbbbbb) and the C-Type of the label being
	suggested.		suggested.
	Errors in received Suggested_Label objects MUST be ignored. This		Errors in received Suggested_Label objects MUST be ignored. This
	includes any received inconsistent or unacceptable values.		includes any received inconsistent or unacceptable values.
	Per [GMPLS-SIG], if a downstream node passes a label value that		Per [GMPLS-SIG], if a downstream node passes a label value that
	differs from the suggested label upstream, the upstream LSR MUST		differs from the suggested label upstream, the upstream LSR MUST
	either reconfigure itself so that it uses the label specified by the		either reconfigure itself so that it uses the label specified by the
	downstream node or generate a ResvErr message with a "Routing		downstream node or generate a ResvErr message with a "Routing
	problem/Unacceptable label value" indication. Furthermore, an		problem/Unacceptable label value" indication. Furthermore, an
	ingress node SHOULD NOT transmit data traffic using a suggested label		ingress node SHOULD NOT transmit data traffic using a suggested label
	until the downstream node passes a corresponding label upstream.		until the downstream node passes a corresponding label upstream.
	2.5. Label Set		2.6. Label Set
	The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the		The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the
	C-Type of 1. It is used in Path messages.		C-Type of 1. It is used in Path messages.
	The format of a Label_Set is:		The format of a Label_Set is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num(TBA)| C-Type (1) |		| Length | Class-Num(TBA)| C-Type (1) |
	skipping to change at page 8, line 12		skipping to change at page 8, line 12
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Label Type: 14 bits		Label Type: 14 bits
	Indicates the type and format of the labels carried in the		Indicates the type and format of the labels carried in the
	object. Values match the C-Type of the appropriate Label		object. Values match the C-Type of the appropriate Label
	object. Only the low order 8 bits are used in this field.		object. Only the low order 8 bits are used in this field.
	See [GMPLS-SIG] for a description of other parameters.		See [GMPLS-SIG] for a description of other parameters.
	2.5.1. Procedures		2.6.1. Procedures
	A Label Set is defined via one or more Label_Set objects. Specific		A Label Set is defined via one or more Label_Set objects. Specific
	labels/subchannels can be added to or excluded from a Label Set via		labels/subchannels can be added to or excluded from a Label Set via
	Action zero (0) and one (1) objects respectively. Ranges of		Action zero (0) and one (1) objects respectively. Ranges of
	labels/subchannels can be added to or excluded from a Label Set via		labels/subchannels can be added to or excluded from a Label Set via
	Action two (2) and three (3) objects respectively. When the		Action two (2) and three (3) objects respectively. When the
	Label_Set objects only list labels/subchannels to exclude, this		Label_Set objects only list labels/subchannels to exclude, this
	implies that all other labels are acceptable.		implies that all other labels are acceptable.
	The absence of any Label_Set objects implies that all labels are		The absence of any Label_Set objects implies that all labels are
	skipping to change at page 10, line 32		skipping to change at page 10, line 32
	extension, the Notify Request object, identifies where event		extension, the Notify Request object, identifies where event
	notifications are to be sent. The third extension, the Notify		notifications are to be sent. The third extension, the Notify
	message, provides for general event notification.) The final		message, provides for general event notification.) The final
	notification related extension allows for the removal of Path state		notification related extension allows for the removal of Path state
	on handling of PathErr messages.		on handling of PathErr messages.
	4.1. Acceptable Label Set Object		4.1. Acceptable Label Set Object
	Acceptable_Label_Set objects use a Class-Number TBA (of form		Acceptable_Label_Set objects use a Class-Number TBA (of form
	10bbbbbb). The remaining contents of the object, including C-Type,		10bbbbbb). The remaining contents of the object, including C-Type,
	have the identical format as the Label_Set object, see Section 2.5.		have the identical format as the Label_Set object, see Section 2.6.
	Acceptable_Label_Set objects may be carried in PathErr and ResvErr		Acceptable_Label_Set objects may be carried in PathErr and ResvErr
	messages. The procedures for defining an Acceptable Label Set follow		messages. The procedures for defining an Acceptable Label Set follow
	the procedures for defining a Label Set, see Section 2.5.1.		the procedures for defining a Label Set, see Section 2.6.1.
	Specifically, an Acceptable Label Set is defined via one or more		Specifically, an Acceptable Label Set is defined via one or more
	Acceptable_Label_Set objects. Specific labels/subchannels can be		Acceptable_Label_Set objects. Specific labels/subchannels can be
	added to or excluded from an Acceptable Label Set via Action zero		added to or excluded from an Acceptable Label Set via Action zero
	(0) and one (1) objects respectively. Ranges of labels/subchannels		(0) and one (1) objects respectively. Ranges of labels/subchannels
	can be added to or excluded from an Acceptable Label Set via Action		can be added to or excluded from an Acceptable Label Set via Action
	two (2) and three (3) objects respectively. When the		two (2) and three (3) objects respectively. When the
	Acceptable_Label_Set objects only list labels/subchannels to exclude,		Acceptable_Label_Set objects only list labels/subchannels to exclude,
	this implies that all other labels are acceptable.		this implies that all other labels are acceptable.
	The inclusion of Acceptable_Label_Set objects is optional. If		The inclusion of Acceptable_Label_Set objects is optional. If
	skipping to change at page 12, line 36		skipping to change at page 12, line 36
	The Notify message provides a mechanism to inform non-adjacent nodes		The Notify message provides a mechanism to inform non-adjacent nodes
	of LSP related events. Notify messages are normally generated only		of LSP related events. Notify messages are normally generated only
	after a Notify Request object has been received. The Notify message		after a Notify Request object has been received. The Notify message
	differs from the currently defined error messages (i.e., PathErr and		differs from the currently defined error messages (i.e., PathErr and
	ResvErr messages) in that it can be "targeted" to a node other than		ResvErr messages) in that it can be "targeted" to a node other than
	the immediate upstream or downstream neighbor and that it is a		the immediate upstream or downstream neighbor and that it is a
	generalized notification mechanism. The Notify message does not		generalized notification mechanism. The Notify message does not
	replace existing error messages. The Notify message may be sent		replace existing error messages. The Notify message may be sent
	either (a) normally, where non-target nodes just forward the Notify		either (a) normally, where non-target nodes just forward the Notify
	message to the target node, similar to ResvConf processing in [RSVP];		message to the target node, similar to ResvConf processing in
	or (b) encapsulated in a new IP header whose destination is equal to		[RFC2205]; or (b) encapsulated in a new IP header whose destination
	the target IP address. Regardless of the transmission mechanism,		is equal to the target IP address. Regardless of the transmission
	nodes receiving a Notify message not destined to the node forward the		mechanism, nodes receiving a Notify message not destined to the node
	message, unmodified, towards the target.		forward the message, unmodified, towards the target.
	To support reliable delivery of the Notify message, an Ack Message		To support reliable delivery of the Notify message, an Ack Message
	[RFC2961] is used to acknowledge the receipt of a Notify Message.		[RFC2961] is used to acknowledge the receipt of a Notify Message.
	See [RFC2961] for details on reliable RSVP message delivery.		See [RFC2961] for details on reliable RSVP message delivery.
	4.3.1. Required Information		4.3.1. Required Information
	The Notify message is a generalized notification message. The IP		The Notify message is a generalized notification message. The IP
	destination address is set to the IP address of the intended		destination address is set to the IP address of the intended
	receiver. The Notify message is sent without the router alert		receiver. The Notify message is sent without the router alert
	skipping to change at page 15, line 23		skipping to change at page 15, line 23
	an error with the Path_State_Removed flag set to zero MUST NOT set		an error with the Path_State_Removed flag set to zero MUST NOT set
	this flag unless it also generates a corresponding PathTear message.		this flag unless it also generates a corresponding PathTear message.
	Note that the use of this flag does not result in any		Note that the use of this flag does not result in any
	interoperability incompatibilities.		interoperability incompatibilities.
	5. Explicit Label Control		5. Explicit Label Control
	The Label ERO and RRO subobjects are defined to support Explicit		The Label ERO and RRO subobjects are defined to support Explicit
	Label Control. Note that the Label RRO subobject was defined in		Label Control. Note that the Label RRO subobject was defined in
	[RFC3209] and is being revised to support bidirectional LSPs.		[RFC3209] and is being extended to support bidirectional LSPs.
	5.1. Label ERO subobject		5.1. Label ERO subobject
	The Label ERO subobject is defined as follows:		The Label ERO subobject is defined as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|L| Type | Length |U| Reserved | C-Type |		|L| Type | Length |U| Reserved | C-Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 16, line 23		skipping to change at page 16, line 23
	Object.		Object.
	5.1.1. Procedures		5.1.1. Procedures
	The Label subobject follows a subobject containing the IP address, or		The Label subobject follows a subobject containing the IP address, or
	the interface identifier [MPLS-UNNUM], associated with the link on		the interface identifier [MPLS-UNNUM], associated with the link on
	which it is to be used. Up to two label subobjects may be present,		which it is to be used. Up to two label subobjects may be present,
	one for the downstream label and one for the upstream label. The		one for the downstream label and one for the upstream label. The
	following SHOULD result in "Bad EXPLICIT_ROUTE object" errors:		following SHOULD result in "Bad EXPLICIT_ROUTE object" errors:
	- If the first label subobject is not preceded by a subobject		- If the first label subobject is not preceded by a subobject
	containing an IP address, or a interface identifier		containing an IP address, or an interface identifier
	[MPLS-UNNUM], associated with an output link.		[MPLS-UNNUM], associated with an output link.
	- For a label subobject to follow a subobject that has the L-bit		- For a label subobject to follow a subobject that has the L-bit
	set		set
	- On unidirectional LSP setup, for there to be a label subobject		- On unidirectional LSP setup, for there to be a label subobject
	with the U-bit set		with the U-bit set
	- For there to be two label subobjects with the same U-bit values		- For there to be two label subobjects with the same U-bit values
	To support the label subobject, a node must check to see if the		To support the label subobject, a node must check to see if the
	subobject following its associate address/interface is a label		subobject following its associate address/interface is a label
	subobject. If it is, one subobject is examined for unidirectional		subobject. If it is, one subobject is examined for unidirectional
	skipping to change at page 23, line 49		skipping to change at page 23, line 49
	bidirectional LSP that traverses a bundled link, it is possible to		bidirectional LSP that traverses a bundled link, it is possible to
	specify a downstream data channel that differs from the upstream data		specify a downstream data channel that differs from the upstream data
	channel. Data channels are specified from the view point of the		channel. Data channels are specified from the view point of the
	sender of the Path message. The IF_ID RSVP_HOP object SHOULD NOT be		sender of the Path message. The IF_ID RSVP_HOP object SHOULD NOT be
	used when no TLVs are needed.		used when no TLVs are needed.
	A node receiving one or more TLVs in a Path message saves their		A node receiving one or more TLVs in a Path message saves their
	values and returns them in the HOP objects of subsequent Resv		values and returns them in the HOP objects of subsequent Resv
	messages sent to the node that originated the TLVs.		messages sent to the node that originated the TLVs.
	As with [MPLS-TE], the node originating an IF_ID object must ensure		Note, the node originating an IF_ID object MUST ensure that the
	that the selected outgoing interface is consistent with the outgoing		selected outgoing interface, as specified in the IF_ID object, is
	ERO. A node that receives an IF_ID object SHOULD check whether the		consistent with an ERO. A node that receives an IF_ID object SHOULD
	information carried in this object is consistent with the information		check whether the information carried in this object is consistent
	carried in a received ERO, and if not it MUST send a PathErr with the		with the information carried in a received ERO, and if not it MUST
	error code "Routing Error" and error value of "Bad Explicit Route		send a PathErr Message with the error code "Routing Error" and error
	Object" toward the sender.		value of "Bad Explicit Route Object" toward the sender. This check
			CANNOT be performed when the initial ERO subobject is not the
			incoming interface.
	8.2. Errored Interface Identification		8.2. Errored Interface Identification
	There are cases where it is useful to indicate a specific interface		There are cases where it is useful to indicate a specific interface
	associated with an error. To support these cases the IF_ID		associated with an error. To support these cases the IF_ID
	ERROR_SPEC Objects are defined.		ERROR_SPEC Objects are defined.
	8.2.1. IF_ID ERROR_SPEC Objects		8.2.1. IF_ID ERROR_SPEC Objects
	The format of the IPv4 IF_ID ERROR_SPEC Object is:		The format of the IPv4 IF_ID ERROR_SPEC Object is:
	skipping to change at page 25, line 25		skipping to change at page 25, line 25
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Error Code | Error Value |		| Flags | Error Code | Error Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ TLVs ~		~ TLVs ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [RFC2205] for a description of address, flags, error code and		See [RFC2205] for a description of address, flags, error code and
	error value fields. See [GMPLS-SIG] for a description of		error value fields. See [GMPLS-SIG] for a description of
	parameters and encoding of TLVs.n		parameters and encoding of TLVs.
	8.2.2. Procedures		8.2.2. Procedures
	Nodes wishing to indicate that an error is related to a specific		Nodes wishing to indicate that an error is related to a specific
	interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the		interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the
	corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects		corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects
	SHOULD be generated and processed as any other ERROR_SPEC Object, see		SHOULD be generated and processed as any other ERROR_SPEC Object, see
	[RFC2205].		[RFC2205].
	9. Fault Handling		9. Fault Handling
	skipping to change at page 27, line 23		skipping to change at page 27, line 23
	When a node receives a Hello message with the Restart_Cap object, it		When a node receives a Hello message with the Restart_Cap object, it
	SHOULD record the values of the parameters received.		SHOULD record the values of the parameters received.
	9.3. Modification to Hello Processing to Support State Recovery		9.3. Modification to Hello Processing to Support State Recovery
	When a node determines that RSVP communication with a neighbor has		When a node determines that RSVP communication with a neighbor has
	been lost, and the node previously learned that the neighbor supports		been lost, and the node previously learned that the neighbor supports
	state recovery, the node SHOULD wait at least the amount of time		state recovery, the node SHOULD wait at least the amount of time
	indicated by the Restart Time indicated by the neighbor before		indicated by the Restart Time indicated by the neighbor before
	invoking procedures related to communication loss. A node MAY wait		invoking procedures related to communication loss. A node MAY wait a
	longer based on local policy or configuration information.		different amount of time based on local policy or configuration
			information.
	During this waiting period, all Hello messages MUST be sent with a		During this waiting period, all Hello messages MUST be sent with a
	Dst_Instance value set to zero (0), and Src_Instance should be		Dst_Instance value set to zero (0), and Src_Instance should be
	unchanged. While waiting, the node SHOULD also preserve the RSVP and		unchanged. While waiting, the node SHOULD also preserve the RSVP and
	MPLS forwarding state for (already) established LSPs that traverse		MPLS forwarding state for (already) established LSPs that traverse
	the link(s) between the node and the neighbor. In a sense with		the link(s) between the node and the neighbor. In a sense with
	respect to established LSPs the node behaves as if it continues to		respect to established LSPs the node behaves as if it continues to
	receive periodic RSVP refresh messages from the neighbor. The node		receive periodic RSVP refresh messages from the neighbor. The node
	MAY clear RSVP and forwarding state for the LSPs that are in the		MAY clear RSVP and forwarding state for the LSPs that are in the
	process of being established when their refresh timers expire.		process of being established when their refresh timers expire.
	skipping to change at page 36, line 42		skipping to change at page 37, line 5
	o "Routing problem/Label Set" (Suggested value =11)		o "Routing problem/Label Set" (Suggested value =11)
	o "Routing problem/Switching Type" (Suggested value =12)		o "Routing problem/Switching Type" (Suggested value =12)
	(duplicate code 13 dropped)		(duplicate code 13 dropped)
	o "Routing problem/Unsupported Encoding" (Suggested value =14)		o "Routing problem/Unsupported Encoding" (Suggested value =14)
	o "Routing problem/Unsupported Link Protection" (Suggested value =15)		o "Routing problem/Unsupported Link Protection" (Suggested value =15)
	o "Notify Error/Control Channel Active State" (Suggested value =4)		o "Notify Error/Control Channel Active State" (Suggested value =4)
	o "Notify Error/Control Channel Degraded State" (Suggested value =5)		o "Notify Error/Control Channel Degraded State" (Suggested value =5)
	---------------------------------------------------------------------		---------------------------------------------------------------------
	14. References		14. Intellectual Property Considerations
	14.1. Normative References		This section is taken from Section 10.4 of [RFC2026].
	[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links		The IETF takes no position regarding the validity or scope of any
	in RSVP-TE", Internet Draft,		intellectual property or other rights that might be claimed to
	draft-ietf-mpls-rsvp-unnum-02.txt, August 2001		pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track 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 attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
			15. References
			15.1. Normative References
	[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -		[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
	Signaling Functional Description", Internet Draft,		Signaling Functional Description", Internet Draft,
	draft-ietf-mpls-generalized-signaling-08.txt,		draft-ietf-mpls-generalized-signaling-09.txt,
	April 2002.		August 2002.
			[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
			in RSVP-TE", Internet Draft,
			draft-ietf-mpls-rsvp-unnum-07.txt, July 2002.
	[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol		[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
	-- Version 1 Functional Specification", RFC 2205,		-- Version 1 Functional Specification", RFC 2205,
	September 1997.		September 1997.
			[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
			Services," RFC 2210, September 1997.
	[RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction		[RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction
	Extensions", RFC 2961, April 2001		Extensions", RFC 2961, April 2001
	[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for		[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for
	LSP Tunnels", RFC 3209, December 2001.		LSP Tunnels", RFC 3209, December 2001.
	14.2. Informative References		15.2. Informative References
	[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.		Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with		[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
	MPLS TE", Internet Draft,		MPLS TE", Internet Draft,
	draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001.		draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001.
	[GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
	CR-LDP Extensions", Internet Draft,
	draft-ietf-mpls-generalized-cr-ldp-06.txt,
	April 2002.
	[PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE",		[PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE",
	Internet Draft, draft-pan-rsvp-te-restart-01.txt,		Internet Draft, draft-pan-rsvp-te-restart-01.txt,
	July 2001.		July 2001.
			[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3,"
			RFC 2026.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels," RFC 2119.		Requirement Levels," RFC 2119.
	15. Authors' Addresses		16. Contributors
	Peter Ashwood-Smith		Peter Ashwood-Smith
	Nortel Networks Corp.		Nortel Networks Corp.
	P.O. Box 3511 Station C,		P.O. Box 3511 Station C,
	Ottawa, ON K1Y 4H7		Ottawa, ON K1Y 4H7
	Canada		Canada
	Phone: +1 613 763 4534		Phone: +1 613 763 4534
	Email: petera@nortelnetworks.com		Email: petera@nortelnetworks.com
	Ayan Banerjee		Ayan Banerjee
	Calient Networks		Calient Networks
	5853 Rue Ferrari		5853 Rue Ferrari
	San Jose, CA 95138		San Jose, CA 95138
	Phone: +1 408 972-3645		Phone: +1 408 972-3645
	Email: abanerjee@calient.net		Email: abanerjee@calient.net
			Lou Berger
	Lou Berger Editor & Primary Point of Contact
	Movaz Networks, Inc.		Movaz Networks, Inc.
	7926 Jones Branch Drive		7926 Jones Branch Drive
	Suite 615		Suite 615
	McLean VA, 22102		McLean VA, 22102
	Phone: +1 703 847-1801		Phone: +1 703 847-1801
	Email: lberger@movaz.com		Email: lberger@movaz.com
	Greg Bernstein		Greg Bernstein
	Ciena Corporation		Ciena Corporation
	10480 Ridgeview Court		10480 Ridgeview Court
	skipping to change at page 39, line 30		skipping to change at page 40, line 14
	Eric Mannie		Eric Mannie
	KPNQwest		KPNQwest
	Terhulpsesteenweg 6A		Terhulpsesteenweg 6A
	1560 Hoeilaart - Belgium		1560 Hoeilaart - Belgium
	Phone: +32 2 658 56 52		Phone: +32 2 658 56 52
	Mobile: +32 496 58 56 52		Mobile: +32 496 58 56 52
	Fax: +32 2 658 51 18		Fax: +32 2 658 51 18
	Email: eric.mannie@kpnqwest.com		Email: eric.mannie@kpnqwest.com
	Ping Pan		Ping Pan
	Juniper Networks		Ciena
	1194 N.Mathilda Ave		10480 Ridgeview Court
	Sunnyvale, CA 94089		Cupertino, CA 95014
	Email: pingpan@juniper.net		Phone: 408-366-4700
			Email: ppan@ciena.com
	Bala Rajagopalan		Bala Rajagopalan
	Tellium, Inc.		Tellium, Inc.
	2 Crescent Place		2 Crescent Place
	P.O. Box 901		P.O. Box 901
	Oceanport, NJ 07757-0901		Oceanport, NJ 07757-0901
	Phone: +1 732 923 4237		Phone: +1 732 923 4237
	Fax: +1 732 923 9804		Fax: +1 732 923 9804
	Email: braja@tellium.com		Email: braja@tellium.com
	skipping to change at line 1748		skipping to change at page 41, line 20
	Z. Bo Tang		Z. Bo Tang
	Tellium, Inc.		Tellium, Inc.
	2 Crescent Place		2 Crescent Place
	P.O. Box 901		P.O. Box 901
	Oceanport, NJ 07757-0901		Oceanport, NJ 07757-0901
	Phone: +1 732 923 4231		Phone: +1 732 923 4231
	Fax: +1 732 923 9804		Fax: +1 732 923 9804
	Email: btang@tellium.com		Email: btang@tellium.com
	Generated on: Thu Apr 25 12:57:53 2002		17. Contact Address
			Lou Berger
			Movaz Networks, Inc.
			7926 Jones Branch Drive
			Suite 615
			McLean VA, 22102
			Phone: +1 703 847-1801
			Email: lberger@movaz.com
			Generated on: Wed Aug 28 10:40:33 2002
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/