draft-ietf-mpls-generalized-rsvp-te-03.txt		draft-ietf-mpls-generalized-rsvp-te-04.txt
	Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.)		Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.)
	Internet Draft Ayan Banerjee (Calient Networks)		Internet Draft Ayan Banerjee (Calient Networks)
	Expiration Date: November 2001 Lou Berger (Movaz Networks)		Expiration Date: January 2002 Lou Berger (Movaz Networks)
	Greg Bernstein (Ciena Corporation)		Greg Bernstein (Ciena Corporation)
	John Drake (Calient Networks)		John Drake (Calient Networks)
	Yanhe Fan (Axiowave Networks)		Yanhe Fan (Axiowave Networks)
	Kireeti Kompella (Juniper Networks, Inc.)		Kireeti Kompella (Juniper Networks, Inc.)
	Eric Mannie (EBONE)
	Jonathan P. Lang (Calient Networks)		Jonathan P. Lang (Calient Networks)
			Fong Liaw (Zaffire Inc.)
			Eric Mannie (EBONE)
			Ping Pan (Juniper Networks, Inc.)
	Bala Rajagopalan (Tellium, Inc.)		Bala Rajagopalan (Tellium, Inc.)
	Yakov Rekhter (Juniper Networks, Inc.)		Yakov Rekhter (Juniper Networks, Inc.)
	Debanjan Saha (Tellium, Inc.)		Debanjan Saha (Tellium, Inc.)
	Vishal Sharma (Jasmine Networks)		Vishal Sharma (Jasmine Networks)
	George Swallow (Cisco Systems)		George Swallow (Cisco Systems)
	Z. Bo Tang (Tellium, Inc.)		Z. Bo Tang (Tellium, Inc.)
	May 2001		July 2001
	Generalized MPLS Signaling - RSVP-TE Extensions		Generalized MPLS Signaling - RSVP-TE Extensions
	draft-ietf-mpls-generalized-rsvp-te-03.txt		draft-ietf-mpls-generalized-rsvp-te-04.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."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	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 RSVP-TE signaling required to
	support Generalized MPLS. Generalized MPLS extends MPLS to encompass		support Generalized MPLS. Generalized MPLS extends MPLS to encompass
	time-division (e.g. SONET ADMs), wavelength (optical lambdas) and		time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
	spatial switching (e.g. incoming port or fiber to outgoing port or		spatial switching (e.g. incoming port or fiber to outgoing port or
	fiber). This document presents an RSVP-TE specific description of		fiber). This document presents an RSVP-TE specific description of
	the extensions. A CR-LDP specific description can be found in		the extensions. A CR-LDP specific description can be found in
	[GMPLS-LDP]. A generic functional description is presented in		[GMPLS-LDP]. A generic functional description is presented in
	[GMPLS-SIG].		[GMPLS-SIG].
	Contents		Contents
	1 Introduction .............................................. 3		1 Introduction ................................................ 3
	2 Label Related Formats .................................... 3		2 Label Related Formats ...................................... 3
	2.1 Generalized Label Request ................................ 3		2.1 Generalized Label Request Object ............................ 4
	2.1.1 Procedures ................................................ 4		2.2 Generalized Label Object .................................... 5
	2.1.2 Bandwidth Encoding ........................................ 5		2.3 Waveband Switching .......................................... 6
	2.2 Generalized Label ......................................... 5		2.4 Suggested Label ............................................. 7
	2.2.1 Procedures ................................................ 5		2.5 Label Set ................................................... 7
	2.3 Waveband Switching ........................................ 6		3 Bidirectional LSPs .......................................... 9
	2.3.1 Procedures ................................................ 6		3.1 Procedures .................................................. 9
	2.4 Suggested Label ........................................... 7		3.2 Contention Resolution ....................................... 9
	2.5 Label Set ................................................. 7		4 Notification ................................................ 10
	2.5.1 Procedures ................................................ 8		4.1 Acceptable Label Set Object ................................. 10
	3 Bidirectional LSPs ........................................ 9		4.2 Notify Request Objects ...................................... 11
	3.1 Procedures ................................................ 9		4.3 Notify Message .............................................. 12
	3.2 Contention Resolution ..................................... 9		4.4 Removing State with a PathErr message ....................... 14
	4 Notification .............................................. 10		5 Explicit Label Control ...................................... 15
	4.1 Acceptable Label Set Object ............................... 10		5.1 Procedures .................................................. 16
	4.2 Notify Request Objects .................................... 11		6 Protection Object ........................................... 17
	4.2.1 Required Information ...................................... 11		6.1 Procedures .................................................. 17
	4.2.2 Procedures ................................................ 12		7 Administrative Status Information ........................... 17
	4.3 Notify Message ............................................ 12		7.1 Admin Status Object ......................................... 17
	4.3.1 Required Information ...................................... 13		7.2 Path and Resv Message Procedures ............................ 18
	4.3.2 Procedures ................................................ 13		7.3 Notify Message Procedures ................................... 19
	4.4 Removing State with a PathErr message ..................... 14		8 Control Channel Separation .................................. 20
	5 Explicit Label Control .................................... 15		8.1 Interface Identification .................................... 20
	5.1 Procedures ................................................ 16		9 Fault Handling .............................................. 22
	6 Protection Object ......................................... 17		9.1 RESTART_CAP Object .......................................... 22
	6.1 Procedures ................................................ 17		9.2 Processing of RESTART_CAP Object ............................ 23
	7 RSVP Message Formats ...................................... 17		9.3 Modification to Hello Processing to Support State Recovery .. 23
	8 Acknowledgments ........................................... 19		9.4 Control Channel Faults ...................................... 24
	9 Security Considerations ................................... 20		9.5 Nodal Faults ................................................ 24
	10 References ................................................ 20		10 RSVP Message Formats and Handling ........................... 27
	11 Authors' Addresses ........................................ 21		10.1 RSVP Message Formats ........................................ 27
			10.2 Addressing Path and PathTear Messages ...................... 29
			11 Acknowledgments ............................................. 29
			12 Security Considerations ..................................... 29
			13 References .................................................. 30
			14 Authors' Addresses .......................................... 31
	Changes from previous version:		Changes from previous version:
	o Fixed Label Set format (for LDP)		o Fixed Label Set format (for LDP)
			o Added Switching type of LSP being requested
			o Added Administrative Status Information (based on last call comments)
			o Added section on Control Channel Separation
			(based on last call comments)
			Covers:
			- Separation of control and data channels
			- Restoration of state post control channel failures
	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
	skipping to change at page 3, line 36		skipping to change at page 4, line 5
	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		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 Encoding Type as
	possible to allow the maximum flexibility in switching by transit		possible to allow the maximum flexibility in switching by transit
	LSRs. A Generalized Label Request object is set by the ingress node,		LSRs. A Generalized Label Request object is set by the ingress node,
	transparently passed by transit nodes, and used by the egress node.		transparently passed by transit nodes, and used by the egress node.
	The format of a Generalized Label Request 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 | Reserved | G-PID |		| LSP Enc. Type |Switching Type | G-PID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.		See [GMPLS-SIG] for a description of parameters.
	2.1.1. Procedures		2.1.1. Procedures
	A node processing a Path message containing a Generalized Label		A node processing a Path message containing a Generalized Label
	Request must verify that the requested parameters can be satisfied by		Request must verify that the requested parameters can be satisfied by
	the interface on which the incoming label is to be allocated, the		the interface on which the incoming label is to be allocated, the
	node itself, and by the interface on which the traffic will be		node itself, and by the interface on which the traffic will be
	skipping to change at page 5, line 15		skipping to change at page 5, line 22
	typically result in a Resv message being generated.		typically result in a Resv message being generated.
	2.1.2. Bandwidth Encoding		2.1.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. Other bandwidth/service related
	parameters in the object are ignored and carried transparently.		parameters in the object are ignored and carried transparently.
	2.2. Generalized Label		2.2. Generalized Label Object
	The format of a Generalized Label 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 |
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 42		skipping to change at page 6, line 47
	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. Without this		association to pick up the proper wavelengths.
	mechanism and with an odd number of mirrored switching operations,
	the egress LSRs will not know that an input wavelength of say L1 will
	emerge from the waveband tunnel as L100.
	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.4. Suggested Label
	The format of a suggested label is identical to a generalized label.		The format of a suggested label is identical to a generalized label.
	It is used in Path messages. Suggested Label uses a new Class-Number		It is used in Path messages. Suggested Label uses Class-Number TBA
	(TBA of form 10bbbbbb) and the C-type of the label being suggested.		(of form 10bbbbbb) and the C-type of the label being suggested.
	Errors in received Suggested Labels MUST be ignored. This includes		Errors in received Suggested Labels MUST be ignored. This includes
	any received inconsistent or unacceptable values.		any received inconsistent or unacceptable values.
	2.5. Label Set		2.5. Label Set
	The Label_Set object uses a Class-Number TBA (of form 0bbbbbbb) and		The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the
	the C-type of 1.		C-type of 1.
	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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Action | Reserved | Label Type |		| Action | Reserved | Label Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 10, line 16		skipping to change at page 10, line 16
	4. Notification		4. Notification
	This section covers several notification related extensions. The		This section covers several notification related extensions. The
	first extension defines the Acceptable Label Set object to support		first extension defines the Acceptable Label Set object to support
	Notification on Label Error, per [GMPLS-SIG]. The second and third		Notification on Label Error, per [GMPLS-SIG]. The second and third
	extensions enable expedited notification of failures and other events		extensions enable expedited notification of failures and other events
	to nodes responsible for restoring failed LSPs. (The second		to nodes responsible for restoring failed LSPs. (The second
	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
	extension allows for the removal of Path state on handling of PathErr		notification related extension allows for the removal of Path state
	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
	11bbbbbb). 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.5.
	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.5.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
	skipping to change at page 13, line 26		skipping to change at page 13, line 26
	<Notify message> ::= <Common Header> [<INTEGRITY>]		<Notify message> ::= <Common Header> [<INTEGRITY>]
	[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]		[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
	[ <MESSAGE_ID> ]		[ <MESSAGE_ID> ]
	<ERROR_SPEC> <notify session list>		<ERROR_SPEC> <notify session list>
	<notify session list> ::= [ <notify session list> ]		<notify session list> ::= [ <notify session list> ]
	<upstream notify session> |		<upstream notify session> |
	<downstream notify session>		<downstream notify session>
	<upstream notify session> ::= <SESSION> [<POLICY_DATA>...]		<upstream notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
			[<POLICY_DATA>...]
	<sender descriptor>		<sender descriptor>
	<downstream notify session> ::= <SESSION> [<POLICY_DATA>...]		<downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
	<flow descriptor list descriptor>		<flow descriptor list descriptor>
	The ERROR_SPEC object specifies the error and includes the IP address		The ERROR_SPEC object specifies the error and includes the IP address
	of either the node that detected the error or the link that has		of either the node that detected the error or the link that has
	failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and		failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and
	related objects are defined in [RSVP-RR] and are used when refresh		related objects are defined in [RSVP-RR] and are used when refresh
	reductions is supported.		reductions is supported.
	skipping to change at page 16, line 23		skipping to change at page 16, line 23
	- 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 a 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 it's 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
	LSPs and two subobjects for bidirectional LSPs. If the U-bit of the		LSPs and two subobjects for bidirectional LSPs. If the U-bit of the
	subobject being examined is clear (0), then value of the label is		subobject being examined is clear (0), then value of the label is
	copied into a new Label_Set object. This Label_Set object MUST be		copied into a new Label_Set object. This Label_Set object MUST be
	included on the corresponding outgoing Path message.		included on the corresponding outgoing Path message.
	If the U-bit of the subobject being examined is set (1), then value		If the U-bit of the subobject being examined is set (1), then value
	of the label is label to be used for upstream traffic associated with		of the label is label to be used for upstream traffic associated with
	the bidirectional LSP. If this label is not acceptable, a "Bad		the bidirectional LSP. If this label is not acceptable, a "Bad
	EXPLICIT_ROUTE object" error SHOULD be generated. If the label is		EXPLICIT_ROUTE object" error SHOULD be generated. If the label is
	skipping to change at page 17, line 9		skipping to change at page 17, line 9
	received ERO, then it SHOULD be treated as a "Bad strict node" error.		received ERO, then it SHOULD be treated as a "Bad strict node" error.
	Procedures by which an LSR at the head-end of an LSP obtains the		Procedures by which an LSR at the head-end of an LSP obtains the
	information needed to construct the Label subobject are outside the		information needed to construct the Label subobject are outside the
	scope of this document.		scope of this document.
	6. Protection Object		6. Protection Object
	The use of the Protection Object is optional. The object is included		The use of the Protection Object is optional. The object is included
	to indicate specific protection attributes of an LSP. The Protection		to indicate specific protection attributes of an LSP. The Protection
	Object uses a Class-Number TBA (of form 0bbbbbbb).		Object uses Class-Number TBA (of form 0bbbbbbb).
	The format of Protection Information Object is:		The format of the Protection Object is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Class-Num(TBA)| C-Type (1) |		| Length | Class-Num(TBA)| C-Type (1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved | Link Flags|		|S| Reserved | Link Flags|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.		See [GMPLS-SIG] for a description of parameters.
	6.1. Procedures		6.1. Procedures
	Transit nodes processing a Path message containing a Protection		Transit nodes processing a Path message containing a Protection
	Object MUST verify that the requested protection can be satisfied by		Object MUST verify that the requested protection can be satisfied by
	the outgoing interface or tunnel (FA). If it cannot, the node MUST		the outgoing interface or tunnel (FA). If it cannot, the node MUST
	generate a PathErr message, with a "Routing problem/Unsupported Link		generate a PathErr message, with a "Routing problem/Unsupported Link
	Protection" indication.		Protection" indication.
	7. RSVP Message Formats		7. Administrative Status Information
			Administrative Status Information is carried in the Admin Status
			Object. The object provides information related to the
			administrative state of a particular LSP. The information is used in
			two ways. In the first, the object is carried in Path and Resv
			messages to indicate the administrative state of an LSP. In the
			second, the object is carried in a Notification message to request
			that the ingress node change the administrative state of an LSP.
			7.1. Admin Status Object
			The use of the Admin Status Object is optional. It uses Class-Number
			TBA (of form 11bbbbbb).
			The format of the Admin Status Object is:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Length | Class-Num(TBA)| C-Type (1) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Reserved |T|D|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			See [GMPLS-SIG] for a description of parameters.
			7.2. Path and Resv Message Procedures
			The Admin Status Object is used to notify each node along the path of
			the status of the LSP. Status information is processed by each node
			based on local policy and then propagated in the corresponding
			outgoing messages. The object is inserted in Path messages at the
			discretion of the ingress node.
			Transit nodes receiving a non-refresh Path message containing an
			Admin Status Object, update their local state, take any appropriate
			local action based on the indicated status and then propagate the
			received Admin Status Object in the outgoing Path message.
			Egress nodes receiving a non-refresh Path message containing an Admin
			Status Object, also update their local state and take any appropriate
			local action based on the indicated status. If an egress node has
			issued a Resv message corresponding to the Path message it MUST send
			an updated Resv message containing an Admin Status Object with the
			same values set as received in the corresponding Path message. The
			egress node MUST also ensure that all subsequent Resv messages sent
			by the node contain the same Admin Status Objects matching the
			corresponding Path message.
			Transit nodes receiving a non-refresh Resv message containing an
			Admin Status Object, update their local state, take any appropriate
			local action based on the indicated status and then propagate the
			received Admin Status Object in the outgoing Resv message.
			7.2.1. Deletion procedure
			In some circumstances, particularly optical networks, it is useful to
			set the administrative status of an LSP before tearing it down. In
			such circumstances the procedure SHOULD be followed when deleting an
			LSP:
			1. The ingress node precedes an LSP deletion by inserting an Admin
			Status Object in Path message and setting the Down (D) bit.
			2. Transit and egress nodes process the Admin Status Object as
			described above.
			3. Upon receiving the Admin Status Object with the Down (D) bit set in
			the Resv message, the ingress node sends a PathTear message
			downstream to remove the LSP and normal RSVP processing takes place.
			7.2.2. Compatibility
			It is possible that some nodes along an LSP will not support the
			Admin Status Object. In the case of a non-supporting transit node,
			the object will pass through the node unmodified and normal
			processing can continue. In the case of a non-supporting egress
			node, the Admin Status Object will not be reflected back in the Resv
			Message. In this case, the ingress SHOULD continue to set the
			contents of the object normally but, when processing an LSP deletion,
			it MUST NOT wait for an updated Admin Status Object in a Resv message
			before issuing a PathTear message.
			7.3. Notify Message Procedures
			Intermediate and egress nodes may trigger the setting of
			administrative status before a deletion via the use of Notify
			messages. To accomplish this, an intermediate or egress node
			generates a Notify message with the corresponding upstream notify
			session information. The Admin Status Object MUST be included in the
			session information, with the Down (D) bit set. The Notify message
			may, but is not required to be, encapsulated, see Section 4.3.
			An ingress node receiving a Notify message containing an Admin Status
			Object with the Down (D) bit set, SHOULD initiate the deletion
			procedure described in the previous section.
			7.3.1. Compatibility and Error Procedures
			Some special processing is required in order to cover the case of
			nodes that do not support the Admin Status Object and other error
			conditions. Specifically, a node that sends a Notify message
			containing an Admin Status Object with the Down (D) bit set MUST
			verify that it receives a corresponding Path message with the Down
			(D) bit set within a configurable period of time. By default this
			period of time SHOULD be 30 seconds. If the node does not receive
			such a Path message, it SHOULD send a ResvTear message upstream and a
			PathTear message downstream.
			8. Control Channel Separation
			This section provides the protocol specific formats and procedures to
			required support a control channel not being in-band with a data
			channel.
			8.1. Interface Identification
			The choice of the data interface to use is always made by the sender
			of the Path message. The choice of the data interface is indicated by
			the sender of the Path message by including the data channel's
			interface identifier in the message using a new RSVP_HOP object sub-
			type. For bidirectional LSPs, the sender chooses the data interface
			in each direction. In all cases but bundling [MPLS-BUNDLE] the
			upstream interface is implied by the downstream interface. For
			bundling, the path sender explicitly identifies the component
			interface used in each direction. The new RSVP_HOP object is used in
			Resv message to indicate the downstream node's usage of the indicated
			interface(s).
			8.1.1. IF_ID RSVP_HOP Objects
			The format of the IPv4 IF_ID RSVP_HOP Object is:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Length | Class-Num (3) | C-Type (3)TBA |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv4 Next/Previous Hop Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Logical Interface Handle |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ TLVs ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The format of the IPv6 IF_ID RSVP_HOP Object is:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Length | Class-Num (3) | C-Type (3)TBA |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			| IPv6 Next/Previous Hop Address |
			| |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Logical Interface Handle |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ TLVs ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			See [RFC2205] for a description of hop address and handle fields.
			See [GMPLS-SIG] for a description of parameters and encoding of
			TLVs.
			8.1.2. Procedures
			An IF_ID RSVP_HOP object is used in place of previously defined
			RSVP_HOP objects. It is used on links where there is not a one-to-
			one association of a control channel to a data channel, see [GMPLS-
			SIG]. The Hop Address and Logical Interface Handle fields are used
			per standard RSVP [RFC2205].
			TLVs are used to identify the data channel(s) associated with the
			LSP. For a unidirectional LSP, a forward channel MUST be indicated.
			For a bidirectional LSP that uses bundled links, a reverse channel
			MUST be indicated. Data channels are specified from the view point
			of the sender of the Path message. The IF_ID RSVP_HOP object SHOULD
			NOT be used when no TLVs are needed.
			A node receiving one or more TLVs in a Path message saves their
			values and returns them in the HOP objects of subsequent Resv
			messages sent to the node that originated the TLVs.
			9. Fault Handling
			The handling of two types of control communication faults are
			described in this section. The first, referred to as nodal faults,
			relates to the case where a node losses its control state (e.g.,
			after a restart) but does not loose its data forwarding state. In
			the second, referred to as control channel faults, relates to the
			case where control communication is lost between two nodes. The
			handling of both faults are supported by a the RESTART_CAP object
			defined below and require the use of Hello messages.
			Please note this section is derived from [PAN-RESTART].
			9.1. RESTART_CAP Object
			The RESTART_CAP Object is carried in Hello messages. The modified
			Hello message format is:
			<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
			[ <RESTART_CAP> ]
			The format of the RESTART_CAP Object is:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Length | Class-Num(TBD)| C-Type (1) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Restart Time |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Recovery Time |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Restart Time: 32 bits
			Restart Time is measured in milliseconds. Restart Time SHOULD
			be set to the sum of the time it takes the sender of the object
			to restart its RSVP-TE component (to the point where it can
			exchange RSVP Hello with its neighbors) and the communication
			channel that is used for RSVP communication.
			Recovery Time: 32 bits
			The period of time, in milliseconds, that the sender desires
			for the recipient to resyncronize RSVP and MPLS forwarding
			state with the sender after the re-establishment of Hello
			synchronization. A value of zero (0) indicates that MPLS
			forwarding state was not preserved across a particular reboot.
			A value of 0xffffffff indicates that resynchronization may
			occur at a rate selected by the receiver.
			9.2. Processing of RESTART_CAP Object
			Nodes supporting state recovery MUST advertise this capability by
			carrying the RESTART_CAP object in the Hello messages it sends to the
			neighbors. Usage of the special case Recovery Time values is
			described in greater detail below.
			When a node receives a Hello message with the RESTART_CAP object, it
			SHOULD record the values of the parameters received. Note that the
			RESTART_CAP Object will only be present when the Dst_Instance value
			is set to zero (0).
			9.3. Modification to Hello Processing to Support State Recovery
			Nodes supporting state recovery MUST include the RESTART_CAP object
			in all Hello messages which are sent with Dst_Instance value set to
			zero (0).
			When an LSR determines that RSVP communication with a neighbor has
			been lost, and the LSR previously learned that the neighbor supports
			state recovery, the LSR SHOULD wait at least the amount of time
			indicated by the Restart Time indicated by the neighbor before
			invoking procedures related to communication loss. An LSR MAY wait
			longer based on local policy or configuration information.
			During this waiting period, all Hello messages MUST be sent with a
			Dst_Instance value set to zero (0), and Src_Instance should be
			unchanged. While waiting, the LSR SHOULD also preserve the RSVP and
			MPLS forwarding state for (already) established LSPs that traverse
			the link(s) between the LSR and the neighbor. In a sense with
			respect to established LSPs the LSR behaves as if it continues to
			receive periodic RSVP refresh messages from the neighbor. The LSR
			MAY clear RSVP and forwarding state for the LSPs that are in the
			process of being established when their refresh timers expire.
			Refreshing of Resv state SHOULD be suppressed during this waiting
			period.
			During this waiting period, the LSR MAY inform other nodes of the
			communication loss via send a PathErr and/or upstream Notify message
			with "Control Channel Degraded State" indication. If such
			notification has been sent, then upon restoration of the control
			channel the LSR MUST inform other nodes of the restoration via a
			PathErr and/or upstream Notify message with "Control Channel Active
			State" indication. (Specific error codes are to be assigned IANA.)
			When a new Hello message is received from the neighbor, the LSR must
			determine if the fault was limited to the control channel or was a
			nodal fault. This determination is based on the Src_Instance
			received from the neighbor. If the value is different than the value
			that was received from the neighbor prior to the fault, then the
			neighbor should be treated as if it has restarted. Otherwise, the
			the fault was limited control channel. Procedures for handling each
			case are described below.
			9.4. Control Channel Faults
			In the case of control channel faults, the LSR SHOULD refresh all
			state shared with the neighbor. Summary Refreshes [RSVP-RR] with the
			ACK_Desired flag set SHOULD be used, if supported. Note that if a
			large number of messages are need, some pacing should be applied.
			All state SHOULD be refreshed within the Recovery time advertised by
			the neighbor.
			9.5. Nodal Faults
			Recovering from nodal faults primarily relies on existing protocol
			messages and objects.
			9.5.1. Procedures for the Restarting LSR
			After an LSR restarts its control plane, an LSR that supports state
			recovery SHOULD check whether it was able to preserve its MPLS
			forwarding state. If no forwarding state from prior to the restart
			was preserved, then the LSR MUST set the Recovery Time to 0 in the
			Hello message the LSR sends to its neighbors.
			If the forwarding state was preserved, then the LSR initiates the
			state recovery process. The LSR MUST be prepared to support the
			recovery process for at least the time it advertised in the Recovery
			Time in the Hello messages used during initial Hello message
			exchange, i.e., when the Dst_Instance that the LSR advertises to the
			neighbor was 0. The period during which a node is prepared to
			support the recovery process is referred to as the Recovery Period.
			Note, a Recovery Time value of 0xffffffff indicates that the Recovery
			Period is effectively infinite. State that is not resynchronized
			during the Recovery Period SHOULD be removed at the end of the
			Period. Note that if during Hello synchronization the restarting
			LSR determines that a neighbor does not support state recovery, and
			the restarting LSR maintains its MPLS forwarding state on a per
			neighbor basis, the restarting LSR should immediately consider the
			Recovery Period with that neighbor completed. Note forwarding state
			can be considered to be maintained on a per neighbor basis when per
			interface labels are used on point-to-point interfaces.
			When an LSR receives a Path message during the Recovery Period, the
			LSR first checks if it has an RSVP state associated with the message.
			If the state is found, then the LSR handles this message according to
			previously defined procedures.
			If the RSVP state is not found, and the message does not carry a
			SUGGESTED_LABEL object, the LSR treats this as a setup for a new LSP,
			and handles it according to previously defined procedures.
			If the RSVP state is not found, and the message carries the
			SUGGESTED_LABEL object, the LSR searches its MPLS forwarding table
			(the one that was preserved across the restart) for an entry whose
			incoming interface matches the Path message and whose incoming label
			is equal to the label carried in the SUGGESTED_LABEL object.
			If the MPLS forwarding table entry is not found, the LSR treats this
			as a setup for a new LSP, and handles it according to previously
			defined procedures.
			If the MPLS forwarding table entry is found, the appropriate RSVP
			state is created, the entry is bound to the LSP associated with the
			message, and related forwarding state should be considered as valid
			and refreshed. Normal Path message processing should also be
			conducted. When sending the corresponding outgoing Path message the
			node SHOULD include a SUGGESTED_LABEL object with a label value
			matching the outgoing label from the now restored forwarding entry.
			The outgoing interface SHOULD also be selected based on the
			forwarding entry.
			Additionally, for bidirectional LSPs, the LSR extracts the label from
			the UPSTREAM_LABEL object carried in the received Path message, and
			searches its MPLS forwarding table for an entry whose outgoing label
			is equal to the label carried in the object (in the case of link
			bundling, this may also involved first identifying the appropriate
			incoming component link).
			If the MPLS forwarding table entry is not found, the LSR treats this
			as a setup for a new LSP, and handles it according to previously
			defined procedures.
			If the MPLS forwarding table entry is found, the entry is bound to
			the LSP associated with the Path message, and the entry is no longer
			considered as stale. In addition, if the LSR is not the tail-end of
			the LSP, the corresponding outgoing Path messages is sent with the
			incoming label from that entry carried in the UPSTREAM_LABEL object.
			During the Recovery Period, Resv messages are processed normally with
			two exceptions. In the case that a forwarding entry is recovered, no
			new label or resource allocation is required while processing the
			Resv message. The second exception applies only if the Recovery Time
			is not 0xffffffff. In this case, ResvErr messages SHOULD NOT be
			generated when a Resv message with no matching Path state is
			received. In this case the Resv message SHOULD just be sighlently
			discarded.
			9.5.2. Procedures for the Neighbor of a Restarting LSR
			The following specifies the procedures that apply when the LSR
			reestablishes communication with the neighbor's control plane within
			the Restart Time, the LSR determines (using the procedures defined in
			Section 5 of [RSVP-TE]) that the neighbor's control plane has
			restarted, and the neighbor was able to preserve its forwarding state
			across the restart (as was indicated by a non-zero Recovery Time
			carried in the RESTART_CAP object of the RSVP Hello messages received
			from the neighbor).
			Upon detecting a restart with a neighbor that supports state
			recovery, an LSR SHOULD refresh all Path state shared with that
			neighbor. The outgoing Path messages MUST include the
			SUGGESTED_LABEL object containing the label value received in the
			most recently received corresponding Resv message. All Path state
			SHOULD be refreshed within approximately 1/2 of the Recovery time
			advertised by the restarted neighbor. If there are many LSP's going
			through the restarting LSR, the neighbor LSR should avoid sending
			Path messages in a short time interval, as to avoid unnecessary
			stressing the restarting LSR's CPU. Instead, it should spread the
			messages across 1/2 the Recovery Time interval.
			During the recovery period, new Path state being advertised to the
			restarted neighbor SHOULD not include the SUGGESTED_LABEL object in
			the corresponding outgoing Path message. This will prevent the
			restarting node from erroneously reusing a saved forwarding entry.
			After detecting a restart of a neighbor that supports state recovery,
			all Resv state shared with the restarting node MUST NOT be refreshed
			until a corresponding Path message is received. This requires
			suppression of normal Resv and Summary Refresh processing to the
			neighbor during the Recovery Time advertised by the restarted
			neighbor. As soon as a corresponding Path message is received a Resv
			message SHOULD be generated and normal state processing may be re-
			enabled.
			10. RSVP Message Formats and Handling
			This message summarizes RSVP message formats and handling as modified
			by GMPLS.
			10.1. RSVP Message Formats
	This section presents the RSVP message related formats as modified by		This section presents the RSVP message related formats as modified by
	this document. Where they differ, formats for unidirectional LSPs		this document. Where they differ, formats for unidirectional LSPs
	are presented separately from bidirectional LSPs. Unmodified formats		are presented separately from bidirectional LSPs. Unmodified formats
	are not listed. Again, MESSAGE_ID and related objects are defined in		are not listed. Again, MESSAGE_ID and related objects are defined in
	[RSVP-RR].		[RSVP-RR].
	The format of a Path message is as follows:		The format of a Path message is as follows:
	<Path Message> ::= <Common Header> [ <INTEGRITY> ]		<Path Message> ::= <Common Header> [ <INTEGRITY> ]
	[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]		[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
	[ <MESSAGE_ID> ]		[ <MESSAGE_ID> ]
	<SESSION> <RSVP_HOP>		<SESSION> <RSVP_HOP>
	<TIME_VALUES>		<TIME_VALUES>
	[ <EXPLICIT_ROUTE> ]		[ <EXPLICIT_ROUTE> ]
	<LABEL_REQUEST>		<LABEL_REQUEST>
	[ <PROTECTION> ]		[ <PROTECTION> ]
	[ <LABEL_SET> ... ]		[ <LABEL_SET> ... ]
	[ <SESSION_ATTRIBUTE> ]		[ <SESSION_ATTRIBUTE> ]
	[ <NOTIFY_REQUEST> ]		[ <NOTIFY_REQUEST> ]
			[ <ADMIN_STATUS> ]
	[ <POLICY_DATA> ... ]		[ <POLICY_DATA> ... ]
	<sender descriptor>		<sender descriptor>
	The format of the sender description for unidirectional LSPs is:		The format of the sender description for unidirectional LSPs is:
	<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>		<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
	[ <ADSPEC> ]		[ <ADSPEC> ]
	[ <RECORD_ROUTE> ]		[ <RECORD_ROUTE> ]
	[ <SUGGESTED_LABEL> ]		[ <SUGGESTED_LABEL> ]
	The format of the sender description for bidirectional LSPs is:		The format of the sender description for bidirectional LSPs is:
	<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>		<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
	[ <ADSPEC> ]		[ <ADSPEC> ]
	[ <RECORD_ROUTE> ]		[ <RECORD_ROUTE> ]
	[ <SUGGESTED_LABEL> ]		[ <SUGGESTED_LABEL> ]
	<UPSTREAM_LABEL>		<UPSTREAM_LABEL>
	The format of a PathErr message is as follows:		The format of a PathErr message is as follows:
	skipping to change at page 19, line 4		skipping to change at page 28, line 21
	The format of a PathErr message is as follows:		The format of a PathErr message is as follows:
	<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]		<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
	[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]		[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
	[ <MESSAGE_ID> ]		[ <MESSAGE_ID> ]
	<SESSION> <ERROR_SPEC>		<SESSION> <ERROR_SPEC>
	[ <ACCEPTABLE_LABEL_SET> ... ]		[ <ACCEPTABLE_LABEL_SET> ... ]
	[ <POLICY_DATA> ... ]		[ <POLICY_DATA> ... ]
	<sender descriptor>		<sender descriptor>
	The format of a Resv message is as follows:		The format of a Resv message is as follows:
	<Resv Message> ::= <Common Header> [ <INTEGRITY> ]		<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
	[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]		[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
	[ <MESSAGE_ID> ]		[ <MESSAGE_ID> ]
	<SESSION> <RSVP_HOP>		<SESSION> <RSVP_HOP>
	<TIME_VALUES>		<TIME_VALUES>
	[ <RESV_CONFIRM> ] [ <SCOPE> ]		[ <RESV_CONFIRM> ] [ <SCOPE> ]
	[ <NOTIFY_REQUEST> ]		[ <NOTIFY_REQUEST> ]
			[ <ADMIN_STATUS> ]
	[ <POLICY_DATA> ... ]		[ <POLICY_DATA> ... ]
	<STYLE> <flow descriptor list>		<STYLE> <flow descriptor list>
	<flow descriptor list> is not modified by this document.		<flow descriptor list> is not modified by this document.
	The format of a Resv message is as follows:		The format of a ResvErr message is as follows:
	<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]		<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
	[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]		[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
	[ <MESSAGE_ID> ]		[ <MESSAGE_ID> ]
	<SESSION> <RSVP_HOP>		<SESSION> <RSVP_HOP>
	<ERROR_SPEC> [ <SCOPE> ]		<ERROR_SPEC> [ <SCOPE> ]
	[ <ACCEPTABLE_LABEL_SET> ... ]		[ <ACCEPTABLE_LABEL_SET> ... ]
	[ <POLICY_DATA> ... ]		[ <POLICY_DATA> ... ]
	<STYLE> <error flow descriptor>		<STYLE> <error flow descriptor>
	8. Acknowledgments		10.2. Addressing Path and PathTear Messages
			RSVP was designed to handle dynamic (non-explicit) path changes and
			non RSVP hops along the path. To this end, the Path and PathTear
			messages carry the destination address of the session in the IP
			header. In generalized signaling, routes are usually explicitly
			signaled. Further, hops that cannot allocate labels cannot exist in
			the path of an LSP. A further difference with traditional RSVP is
			that at times, an RSVP message may travel out of band with respect to
			an LSP's data channel.
			When a node is sending a Path or PathTear message to a node that it
			knows to be adjacent at the data plane (i.e. along the path of the
			LSP) it SHOULD address the message directly to that node. In this
			case the router-alert option SHOULD not be included.
			11. Acknowledgments
	This draft is the work of numerous authors and consists of a		This draft is the work of numerous authors and consists of a
	composition of a number of previous drafts in this area. A list of		composition of a number of previous drafts in this area. A list of
	the drafts from which material and ideas were incorporated follows:		the drafts from which material and ideas were incorporated follows:
	draft-saha-rsvp-optical-signaling-00.txt		draft-saha-rsvp-optical-signaling-00.txt
	draft-lang-mpls-rsvp-oxc-00.txt		draft-lang-mpls-rsvp-oxc-00.txt
	draft-kompella-mpls-optical-00.txt		draft-kompella-mpls-optical-00.txt
	draft-fan-mpls-lambda-signaling-00.txt		draft-fan-mpls-lambda-signaling-00.txt
			draft-pan-rsvp-te-restart-01.txt
	Valuable comments and input were received from a number of people,		Valuable comments and input were received from a number of people,
	including Igor Bryskin and Adrian Farrel. Portions of Section 4 are		including Igor Bryskin, and Adrian Farrel. Portions of Section 4 are
	based on suggestions and text proposed by Adrian Farrel.		based on suggestions and text proposed by Adrian Farrel.
	9. Security Considerations		12. Security Considerations
	The transmission of notify messages using IP in IP, break RSVP's hop-		The transmission of notify messages using IP in IP, breaks RSVP's
	by-hop integrity and authentication model. Fortunately, such usage		hop-by-hop integrity and authentication model. Fortunately, such
	mirrors the IP end-to-end model. In the case where RSVP is		usage mirrors the IP end-to-end model. In the case where RSVP is
	generating end-to-end messages and integrity and/or authentication		generating end-to-end messages and integrity and/or authentication
	are desired, the standard IPSEC based integrity and authentication		are desired, the standard IPSEC based integrity and authentication
	methods SHOULD be used.		methods SHOULD be used.
	This draft introduces no other new security considerations to [RSVP-		This draft introduces no other new security considerations to [RSVP-
	TE].		TE].
	10. References		13. References
	[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.
	[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links		[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
	in RSVP-TE", Internet Draft,		in RSVP-TE", Internet Draft,
	draft-ietf-mpls-rsvp-unnum-01.txt, February 2001		draft-ietf-mpls-rsvp-unnum-01.txt, February 2001
	[GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -		[GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
	CR-LDP Extensions", Internet Draft,		CR-LDP Extensions", Internet Draft,
	draft-ietf-mpls-generalized-cr-ldp-01.txt,		draft-ietf-mpls-generalized-cr-ldp-01.txt,
	February 2001.		February 2001.
	[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-02.txt,		draft-ietf-mpls-generalized-signaling-02.txt,
	February 2001.		February 2001.
			[PAN-RESTART] Pan, et al, "Graceful Restart Mechanism for RSVP-TE",
			Internet Draft, draft-pan-rsvp-te-restart-01.txt,
			July 2001.
	[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.
	[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.
	[RSVP-TE] Awduche, D.O., Berger, L., Gan, D.-H., Li, T., Swallow, G.,		[RSVP-TE] Awduche, D.O., Berger, L., Gan, D.-H., Li, T., Swallow, G.,
	and Srinivasan, V., "RSVP-TE: Extensions to RSVP for LSP		and Srinivasan, V., "RSVP-TE: Extensions to RSVP for LSP
	Tunnels," Internet Draft,		Tunnels," Internet Draft,
	draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001.		draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001.
	[RSVP-RR] Berger L., Gan D., Swallow G., Pan P., Tommasi F.,		[RSVP-RR] Berger, L. et al, "RFC 2961: RSVP Refresh Overhead
	Molendini S., "RSVP Refresh Overhead Reduction Extensions",		Reduction Extensions", RFC2961.
	draft-ietf-rsvp-refresh-reduct-05.txt, June 2000.
	11. Authors' Addresses		14. Authors' Addresses
	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
	skipping to change at page 22, line 23		skipping to change at page 32, line 16
	1194 N. Mathilda Ave.		1194 N. Mathilda Ave.
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	Email: kireeti@juniper.net		Email: kireeti@juniper.net
	Jonathan P. Lang		Jonathan P. Lang
	Calient Networks		Calient Networks
	25 Castilian		25 Castilian
	Goleta, CA 93117		Goleta, CA 93117
	Email: jplang@calient.net		Email: jplang@calient.net
			Fong Liaw
			Zaffire Inc.
			2630 Orchard Parkway,
			San Jose, CA 95134
			Email: fliaw@zaffire.com
	Eric Mannie		Eric Mannie
	EBONE		EBONE
	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@ebone.com		Email: eric.mannie@ebone.com
			Ping Pan
			Juniper Networks
			1194 N.Mathilda Ave
			Sunnyvale, CA 94089
			Email: pingpan@juniper.net
	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
	Yakov Rekhter		Yakov Rekhter
	skipping to change at line 979		skipping to change at line 1450
	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: Tue May 1 16:25:28 EDT 2001		Generated on: Fri Jul 20 16:38:09 EDT 2001
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/