draft-ietf-mpls-generalized-cr-ldp-04.txt		draft-ietf-mpls-generalized-cr-ldp-05.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: January 2002 Lou Berger (Movaz Networks)		Expiration Date: May 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)
	Don Fedyk (Nortel Networks Corp.)		Don Fedyk (Nortel Networks Corp.)
	Kireeti Kompella (Juniper Networks, Inc.)		Kireeti Kompella (Juniper Networks, Inc.)
	Eric Mannie (EBONE)		Eric Mannie (EBONE)
	Jonathan P. Lang (Calient Networks)		Jonathan P. Lang (Calient Networks)
	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 (Metanoia, Inc.)
	George Swallow (Cisco Systems)		George Swallow (Cisco Systems)
	Z. Bo Tang (Tellium, Inc.)		Z. Bo Tang (Tellium, Inc.)
	July 2001		November 2001
	Generalized MPLS Signaling - CR-LDP Extensions		Generalized MPLS Signaling - CR-LDP Extensions
	draft-ietf-mpls-generalized-cr-ldp-04.txt		draft-ietf-mpls-generalized-cr-ldp-05.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
	skipping to change at page 2, line 17		skipping to change at page 3, line ?
	1 Introduction .............................................. 3		1 Introduction .............................................. 3
	2 Label Related Formats .................................... 3		2 Label Related Formats .................................... 3
	2.1 Generalized Label Request ................................. 4		2.1 Generalized Label Request ................................. 4
	2.1.1 Procedures ................................................ 4		2.1.1 Procedures ................................................ 4
	2.1.2 Bandwidth Encoding ........................................ 5		2.1.2 Bandwidth Encoding ........................................ 5
	2.2 Generalized Label ......................................... 5		2.2 Generalized Label ......................................... 5
	2.2.1 Procedures ................................................ 5		2.2.1 Procedures ................................................ 5
	2.3 Waveband Switching ........................................ 6		2.3 Waveband Switching ........................................ 6
	2.3.1 Procedures ................................................ 6		2.3.1 Procedures ................................................ 6
	2.4 Suggested Label ........................................... 7		2.4 Suggested Label ........................................... 7
	2.5 Label Set ................................................. 7		2.5 Label Set ................................................. 8
	2.5.1 Procedures ................................................ 8		2.5.1 Procedures ................................................ 8
	3 Bidirectional LSPs ........................................ 9		3 Bidirectional LSPs ........................................ 9
	3.1 Procedures ................................................ 9		3.1 Procedures ................................................ 9
	4 Notification on Label Error ............................... 10		4 Notification on Label Error ............................... 10
	5 Explicit Label Control .................................... 10		5 Explicit Label Control .................................... 11
	5.1 Procedures ................................................ 11		5.1 Procedures ................................................ 11
	6 Protection TLV ............................................ 12		6 Protection TLV ............................................ 12
	6.1 Procedures ................................................ 12		6.1 Procedures ................................................ 12
	7 Administrative Status Information ......................... 12		7 Administrative Status Information ......................... 13
	7.1 Admin Status Object ....................................... 12		7.1 Admin Status TLV .......................................... 13
	7.2 REQUEST and MAPPING Message Procedures .................... 13		7.2 REQUEST and MAPPING Message Procedures .................... 13
	7.3 Modification Message Procedures ........................... 13		7.2.1 Deletion procedure ........................................ 14
	7.3.1 Deletion procedure ........................................ 14		7.3 Notification Message Procedures ........................... 14
	7.3.2 Compatibility ............................................. 14		7.3.1 Compatibility and Error Procedures ........................ 15
	7.3.3 Notify Message Procedures ................................. 14
	8 Control Channel Separation ................................ 15		8 Control Channel Separation ................................ 15
	8.1 Interface Identification .................................. 15		8.1 Interface Identification .................................. 15
	8.2 Procedures ................................................ 16		8.2 Procedures ................................................ 16
	9 Fault Handling ......................................... 16		8.3 Errored Interface Identification .......................... 17
	10 Acknowledgments ........................................... 16		8.3.1 IF_ID Status TLVs ......................................... 17
	11 Security Considerations ................................... 17		8.3.2 Procedures ................................................ 18
	12 References ................................................ 17		9 Fault Handling ......................................... 18
	13 Authors' Addresses ........................................ 17		10 Acknowledgments ........................................... 19
			11 Security Considerations ................................... 19
			12 IANA Considerations ....................................... 19
			13 References ................................................ 20
			14 Authors' Addresses ........................................ 20
			[Editor's note: changes to be removed prior to publication as an RFC.]
	Changes from previous version:		Changes from previous version:
	o Fixed Label Set format (for LDP)		o Revised Admin Status Usage
	o Removed unassigned values		o Clarified text related to interface bundling
	o Added Switching type of LSP being requested		(To be consistent with updated bundling draft.)
	o Added Administrative Status Information (based on last call comments)		o Added IANA Considerations
	o Added section on Control Channel Separation		o Minor editorial changes and clarifications
	(based on last call comments)
	Covers:
	- Separation of control and data channels
	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 CR-LDP		switching is provided in [GMPLS-SIG]. This document presents CR-LDP
	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 4, line 45		skipping to change at page 4, line 45
	dynamically established or may be solely administratively controlled.		dynamically established or may be solely administratively controlled.
	For more information on tunnels and processing of ER hops when using		For more information on tunnels and processing of ER hops when using
	tunnels see [MPLS-HIERARCHY].		tunnels see [MPLS-HIERARCHY].
	Transit and egress nodes MUST verify that the node itself and, where		Transit and egress nodes MUST verify that the node itself and, where
	appropriate, that the outgoing interface or tunnel can support the		appropriate, that the outgoing interface or tunnel can support the
	requested LSP Encoding Type. If encoding cannot be supported, the		requested LSP Encoding Type. If encoding cannot be supported, the
	node MUST generate a NOTIFICATION message, with a "Routing		node MUST generate a NOTIFICATION message, with a "Routing
	problem/Unsupported Encoding" indication.		problem/Unsupported Encoding" indication.
			Nodes MUST verify that the type indicated in the Switching Type
			parameter is supported on the corresponding incoming interface. If
			the type cannot be supported, the node MUST generate a NOTIFICATION
			message with a "Routing problem/Switching Type" indication.
	The G-PID parameter is normally only examined at the egress. If the		The G-PID parameter is normally only examined at the egress. If the
	indicated G-PID cannot be supported then the egress MUST generate a		indicated G-PID cannot be supported then the egress MUST generate a
	NOTIFICATION message, with a "Routing problem/Unsupported GPID"		NOTIFICATION message, with a "Routing problem/Unsupported GPID"
	indication. In the case of PSC and when penultimate hop popping		indication. In the case of PSC and when penultimate hop popping
	(PHP) is requested, the penultimate hop also examines the (stored) G-		(PHP) is requested, the penultimate hop also examines the (stored) G-
	PID during the processing of the MAPPING message. In this case if		PID during the processing of the MAPPING message. In this case if
	the G-PID is not supported, then the penultimate hop MUST generate a		the G-PID is not supported, then the penultimate hop MUST generate a
	NOTIFICATION message with a "Routing problem/Unacceptable label		NOTIFICATION message with a "Routing problem/Unacceptable label
	value" indication. The generated NOTIFICATION message MAY include an		value" indication. The generated NOTIFICATION message MAY include an
	Acceptable Label Set, see Section 4.		Acceptable Label Set, see Section 4.
	skipping to change at page 6, line 13		skipping to change at page 6, line 17
	The recipient of a MAPPING message containing a Generalized Label		The recipient of a MAPPING 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 NOTIFICATION message		unacceptable then the recipient MUST generate a NOTIFICATION message
	with a "Routing problem/MPLS label allocation failure" indication.		with a "Routing problem/MPLS label allocation failure" indication.
	The generated NOTIFICATION message MAY include an Acceptable Label		The generated NOTIFICATION message MAY include an Acceptable Label
	Set, see Section 4.		Set, see Section 4.
	2.3. Waveband Switching		2.3. 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. The type (0x0903) is assigned for the Waveband Label.		section 2.2. The type TBA is assigned for the Waveband Label.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| Type (TBA by IANA) | Length |		|U|F| Type (TBA by IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Waveband Id |		| Waveband Id |
	skipping to change at page 7, line 16		skipping to change at page 7, line 21
	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 REQUEST messages. Suggested Label uses type = 0x904.		It is used in REQUEST messages. Suggested Label uses type = 0x904.
	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.
			Per [GMPLS-SIG], if a downstream node passes a label value that
			differs from the suggested label upstream, the upstream LSR MUST
			either reconfigure itself so that it uses the label specified by the
			downstream node or generate a NOTIFICATION message with a "Routing
			problem/Unacceptable label value" indication. Furthermore, an
			ingress node SHOULD NOT transmit data traffic using a suggested label
			until the downstream node passes corresponding a label upstream.
	2.5. Label Set		2.5. Label Set
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| type=0x0905 | Length |		|U|F| Type (TBA by IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Action | Reserved | Label Type |		| Action | Reserved | Label Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Subchannel 1 |		| Subchannel 1 |
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: : :		: : :
	: : :		: : :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Subchannel N |		| Subchannel N |
	skipping to change at page 8, line 7		skipping to change at page 8, line 35
	Label Type: 14 bits		Label Type: 14 bits
	Indicates the type and format of the labels carried in the TLV.		Indicates the type and format of the labels carried in the TLV.
	Values match the TLV type of the appropriate Label TLV.		Values match the TLV type of the appropriate Label TLV.
	See [GMPLS-SIG] for a description of other parameters.		See [GMPLS-SIG] for a description of other parameters.
	2.5.1. Procedures		2.5.1. Procedures
	A Label Set is defined via one or more Label_Set TLVs. Specific		A Label Set is defined via one or more Label Set TLVs. 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) TLVs respectively. Ranges of		Action zero (0) and one (1) TLVs 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) TLVs respectively. When the Label_Set		Action two (2) and three (3) TLVs respectively. When the Label Set
	TLVs only list labels/subchannels to exclude, this implies that all		TLVs only list labels/subchannels to exclude, this implies that all
	other labels are acceptable.		other labels are acceptable.
	The absence of any Label_Set TLVs implies that all labels are		The absence of any Label Set TLVs implies that all labels are
	acceptable. A Label Set is included when a node wishes to restrict		acceptable. A Label Set is included when a node wishes to restrict
	the label(s) that may be used downstream.		the label(s) that may be used downstream.
	On reception of a REQUEST message, the receiving node will restrict		On reception of a REQUEST message, the receiving node will restrict
	its choice of labels to one, which is in the Label Set. Nodes		its choice of labels to one, which is in the Label Set. Nodes
	capable of performing label conversion may also remove the Label Set		capable of performing label conversion may also remove the Label Set
	prior to forwarding the REQUEST message. If the node is unable to		prior to forwarding the REQUEST message. If the node is unable to
	pick a label from the Label Set or if there is a problem parsing the		pick a label from the Label Set or if there is a problem parsing the
	Label_Set TLVs, then the request is terminated and a NOTIFICATION		Label Set TLVs, then the request is terminated and a NOTIFICATION
	message with a "Routing problem/Label Set" indication MUST be		message with a "Routing problem/Label Set" indication MUST be
	generated. It is a local matter if the Label Set is stored for later		generated. It is a local matter if the Label Set is stored for later
	selection on the MAPPING or if the selection is made immediately for		selection on the MAPPING message or if the selection is made
	propagation in the MAPPING.		immediately for propagation in the MAPPING message.
	On reception of a REQUEST message, the Label Set represented in the		On reception of a REQUEST message, the Label Set represented in the
	message is compared against the set of available labels at the		message is compared against the set of available labels at the
	downstream interface and the resulting intersecting Label Set is		downstream interface and the resulting intersecting Label Set is
	forwarded in a REQUEST message. When the resulting Label Set is		forwarded in a REQUEST message. When the resulting Label Set is
	empty, the REQUEST must be terminated, and a NOTIFICATION message,		empty, the REQUEST must be terminated, and a NOTIFICATION message,
	and a "Routing problem/Label Set" indication MUST be generated. Note		and a "Routing problem/Label Set" indication MUST be generated. Note
	that intersection is based on the physical labels (actual		that intersection is based on the physical labels (actual
	wavelength/band values) which may have different logical values on		wavelength/band values) which may have different logical values on
	different links, as a result it is the responsibility of the node to		different links, as a result it is the responsibility of the node to
	skipping to change at page 9, line 9		skipping to change at page 9, line 37
	Note, on reception of a MAPPING message a node that is incapable of		Note, on reception of a MAPPING message a node that is incapable of
	performing label conversion has no other choice than to use the same		performing label conversion has no other choice than to use the same
	physical label (wavelength/band) as received in the MAPPING message.		physical label (wavelength/band) as received in the MAPPING message.
	In this case, the use and propagation of a Label Set will		In this case, the use and propagation of a Label Set will
	significantly reduce the chances that this allocation will fail.		significantly reduce the chances that this allocation will fail.
	3. Bidirectional LSPs		3. Bidirectional LSPs
	Bidirectional LSP setup is indicated by the presence of an Upstream		Bidirectional LSP setup is indicated by the presence of an Upstream
	Label in the REQUEST message. An Upstream Label has the same format		Label in the REQUEST message. An Upstream Label has the same format
	as the generalized label, see Section 2.2. Upstream Label uses		as the generalized label, see Section 2.2. Upstream Label uses type=
	type=0x0906		TBA
	3.1. Procedures		3.1. Procedures
	The process of establishing a bidirectional LSP follows the		The process of establishing a bidirectional LSP follows the
	establishment of a unidirectional LSP with some additions. To		establishment of a unidirectional LSP with some additions. To
	support bidirectional LSPs an Upstream Label is added to the REQUEST		support bidirectional LSPs an Upstream Label is added to the REQUEST
	message. The Upstream Label MUST indicate a label that is valid for		message. The Upstream Label MUST indicate a label that is valid for
	forwarding at the time the REQUEST message is sent.		forwarding at the time the REQUEST message is sent.
	When a REQUEST message containing an Upstream Label is received, the		When a REQUEST message containing an Upstream Label is received, the
	skipping to change at page 10, line 7		skipping to change at page 10, line 26
	exception that the upstream label can immediately be used to		exception that the upstream label can immediately be used to
	transport data traffic associated with the LSP upstream towards the		transport data traffic associated with the LSP upstream towards the
	initiator.		initiator.
	When a bidirectional LSP is removed, both upstream and downstream		When a bidirectional LSP is removed, both upstream and downstream
	labels are invalidated and it is no longer valid to send data using		labels are invalidated and it is no longer valid to send data using
	the associated labels.		the associated labels.
	4. Notification on Label Error		4. Notification on Label Error
	This section defines the Acceptable_Label_Set TLV to support		This section defines the Acceptable Label Set TLV to support
	Notification on Label Error per [GMPLS-SIG]. An Acceptable_Label_Set		Notification on Label Error per [GMPLS-SIG]. An Acceptable Label Set
	TLV uses a type value of 0x0907. The remaining contents of the TLV		TLV uses a type value of TBA The remaining contents of the TLV have
	have the identical format as the Label_Set TLV, see Section 2.5.		the identical format as the Label Set TLV, see Section 2.5.
	Acceptable_Label_Set TLVs may be carried in NOTIFICATION messages.		Acceptable Label Set TLVs may be carried in NOTIFICATION messages.
	The procedures for defining an Acceptable Label Set follow the		The procedures for defining an Acceptable Label Set follow the
	procedures for defining a Label Set, see Section 2.5.1.		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 TLVs. Specific labels/subchannels can be added		Acceptable Label Set TLVs. Specific labels/subchannels can be added
	to or excluded from an Acceptable Label Set via Action zero (0) and		to or excluded from an Acceptable Label Set via Action zero (0) and
	one (1) TLVs respectively. Ranges of labels/subchannels can be added		one (1) TLVs respectively. Ranges of labels/subchannels can be added
	to or excluded from an Acceptable Label Set via Action two (2) and		to or excluded from an Acceptable Label Set via Action two (2) and
	three (3) TLVs respectively. When the Acceptable_Label_Set TLVs only		three (3) TLVs respectively. When the Acceptable Label Set TLVs only
	list labels/subchannels to exclude, this implies that all other		list labels/subchannels to exclude, this implies that all other
	labels are acceptable.		labels are acceptable.
	The inclusion of Acceptable_Label_Set TLVs is optional. If included,		The inclusion of Acceptable Label Set TLVs is optional. If included,
	the NOTIFICATION message SHOULD contain a "Routing		the NOTIFICATION message SHOULD contain a "Routing
	problem/Unacceptable label value" indication. The absence of		problem/Unacceptable label value" indication. The absence of
	Acceptable_Label_Set TLVs does not have any specific meaning.		Acceptable Label Set TLVs does not have any specific meaning.
	5. Explicit Label Control		5. Explicit Label Control
	The Label ER-Hop is defined as follows:		The Label ER-Hop TLV 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Type (TBA by IANA) | Length |		|0|0| Type (TBA by IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|L|U| Reserved | Label |		|L|U| Reserved | Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label (continued) |		| Label (continued) |
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of L, U and Label parameters.		See [GMPLS-SIG] for a description of L, U and Label parameters.
	5.1. Procedures		5.1. Procedures
	The Label ER-Hop follows a ER-Hop containing the IP address, or the		The Label ER-Hop follows a ER-Hop containing the IP address, or the
	interface identifier [MPLS-UNNUM], associated with the link on which		interface identifier [MPLS-UNNUM], associated with the link on which
	it is to be used. The preceding ER-Hop must be strict. Up to two		it is to be used. Up to two label ER-Hops may be present, one for
	label ER-Hops may be present, one for the downstream label and one		the downstream label and one for the upstream label. The following
	for the upstream label. The following SHOULD result in "Bad		SHOULD result in "Bad EXPLICIT_ROUTE" errors:
	EXPLICIT_ROUTE" errors:
	- If the first label ER-Hop is not preceded by a ER-Hop		- If the first label ER-Hop is not preceded by a ER-Hop
	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 ER-Hop to follow a ER-Hop that has the L-bit		- For a label ER-Hop to follow a ER-Hop that has the L-bit
	set		set
	- On unidirectional LSP setup, for there to be a label ER-Hop		- On unidirectional LSP setup, for there to be a label ER-Hop
	with the U-bit set		with the U-bit set
	- For there to be two label ER-Hops with the same U-bit values		- For there to be two label ER-Hops with the same U-bit values
	To support the label ER-Hop, a node must check to see if the ER-Hop		To support the label ER-Hop, a node must check to see if the ER-Hop
	following its associate address/interface is a label ER-Hop. If it		following its associate address/interface is a label ER-Hop. If it
	is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops		is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops
	for bidirectional LSPs. If the U-bit of the ER-Hop being examined is		for bidirectional LSPs. If the U-bit of the ER-Hop being examined is
	clear (0), then value of the label is copied into a new Label_Set		clear (0), then value of the label is copied into a new Label Set
	TLV. This Label_Set TLV MUST be included on the corresponding		TLV. This Label Set TLV MUST be included on the corresponding
	outgoing MAPPING message.		outgoing REQUEST message.
	If the U-bit of the ER-Hop being examined is set (1), then value of		If the U-bit of the ER-Hop being examined is set (1), then value of
	the label is label to be used for upstream traffic associated with		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" error SHOULD be generated. If the label is		EXPLICIT_ROUTE" error SHOULD be generated. If the label is
	acceptable, the label is copied into a new Upstream Label TLV. This		acceptable, the label is copied into a new Upstream Label TLV. This
	Upstream Label TLV MUST be included on the corresponding outgoing		Upstream Label TLV MUST be included on the corresponding outgoing
	MAPPING message.		REQUEST message.
	After processing, the label ER-Hops are removed from the ER.		After processing, the label ER-Hops are removed from the ER.
	Note an implication of the above procedures is that the label ER-Hop		Note an implication of the above procedures is that the label ER-Hop
	should never be the first ER-Hop in a newly received message. If the		should never be the first ER-Hop in a newly received message. If the
	label ER-Hop is the first ER-Hop an a received ER, then it SHOULD be		label ER-Hop is the first ER-Hop an a received ER, then it SHOULD be
	treated as a "Bad strict node" error.		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 ER-Hop are outside the		information needed to construct the Label ER-Hop are outside the
	skipping to change at page 12, line 35		skipping to change at page 13, line 10
	TLV MUST verify that the requested protection can be satisfied by the		TLV MUST verify that the requested protection can be satisfied by the
	outgoing interface or tunnel (FA). If it cannot, the node MUST		outgoing interface or tunnel (FA). If it cannot, the node MUST
	generate a NOTIFICATION message, with a "Routing problem/Unsupported		generate a NOTIFICATION message, with a "Routing problem/Unsupported
	Link Protection" indication.		Link Protection" indication.
	7. Administrative Status Information		7. Administrative Status Information
	Administrative Status Information is carried in the Admin Status TLV.		Administrative Status Information is carried in the Admin Status TLV.
	The TLV provides information related to the administrative state of a		The TLV provides information related to the administrative state of a
	particular LSP. The information is used in two ways. In the first,		particular LSP. The information is used in two ways. In the first,
	the object is carried in REQUEST and MAPPING messages to indicate the		the TLV is carried in REQUEST and MAPPING messages to indicate the
	administrative state of an LSP. In the second, the TLV is carried in		administrative state of an LSP. In the second, the TLV is carried in
	a REQUEST and MAPPING message with the modification bit set to		Notification message to request a change to the administrative state
	request a change to the administrative state of an LSP.		of an LSP.
	7.1. Admin Status Object
	The use of the Admin Status TLV is optional.		7.1. Admin Status TLV
	The format of the TLV is:		The use of the Admin Status TLV is optional. It uses Type = TBA. The
			format of the TLV is:
	The format of Admin Status TLV in REQUEST, MAPPING Messages is:		The format of Admin Status TLV in REQUEST, MAPPING and Notification
			Messages 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| Type (TBA by IANA) | Length |		|U|F| Type (TBA by IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |T|D|		|R| Reserved |T|A|D|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The U Bit Should be set to 1. The F bit should be set to 1.
	See [GMPLS-SIG] for a description of parameters.		See [GMPLS-SIG] for a description of parameters.
	7.2. REQUEST and MAPPING Message Procedures		7.2. REQUEST and MAPPING Message Procedures
	The Admin Status TLV is used to notify each node along the path of		The Admin Status TLV is used to notify each node along the path of
	the status of the LSP. Status information is processed by each node		the status of the LSP. Each node processes status information based
	based on local policy and then propagated in the corresponding		on local policy and then propagated in the corresponding outgoing
	outgoing messages. The TLV is inserted in REQUEST messages at the		messages. The TLV is inserted in REQUEST messages at the discretion
	discretion of the ingress node.		of the ingress node. The absence of the TLV is the equivalent to
			receiving a TLV containing values all set to zero.
	Transit nodes receiving a REQUEST message containing an Admin Status		Transit nodes receiving a REQUEST message containing an Admin Status
	TLV, update their local state, take any appropriate local action		TLV, update their local state, take any appropriate local action
	based on the indicated status and then propagate the received Admin		based on the indicated status and then propagate the received Admin
	Status TLV in the outgoing REQUEST message.		Status TLV in the outgoing REQUEST message.
	Egress nodes receiving a REQUEST message containing an Admin Status		Edge nodes receiving a REQUEST message containing an Admin Status
	TLV, also update their local state and take any appropriate local		TLV, also update their local state and take any appropriate local
	action based on the indicated status.		action based on the indicated status. When the ADMIN Status TLV is
			received with the R bit set, the receiving edge node should reflect
	The subsequent MAPPING message MUST carry back the Admin Status TLV		the received values in a corresponding MAPPING message.
	if the corresponding request message had the Admin Status TLV.		Specifically, if an egress node receives a Request message with the R
			bit of the Admin_Status TLV set and the node the node SHOULD send a
	7.3. Modification Message Procedures		Mapping message containing an Admin_Status TLV with the same values
			set, with the exception of the R bit, as received in the
	Subsequent messaging Admin Status messaging is all performed by		corresponding Request message.
	REQUEST and MAPPING Messages using the modification action indicator
	flag. The ingress may begin the propagation of a Message with an
	Admin Status TLV. Each subsequent node propagates the REQUEST with
	the Admin Status TLV from the ingress to the egress and then the
	egress node returns the MAPPING messages back Upstream carrying the
	Admin Status TLV. A modification message of this type would
	typically only carry the mandatory CR-LDP TLVs and the Admin Status
	TLV.
	7.3.1. Deletion procedure		7.2.1. Deletion procedure
	In some circumstances, particularly optical networks, it is useful to		In some circumstances, particularly optical networks, it is useful to
	set the administrative status of an LSP before tearing it down. In		set the administrative status of an LSP before tearing it down.
	such circumstances the procedure SHOULD be followed when deleting an
	LSP:
	The ingress node precedes an LSP deletion by inserting an Admin		In such circumstances the procedure SHOULD be followed when deleting
	Status TLV in a REQUEST Message with the modification action		an LSP from the ingress: The ingress node precedes an LSP deletion by
	indicator set to modify message and setting the Down (D) bit.		inserting an Admin Status TLV in a Notification Message setting the
			Reflect (R) and Delete (D) bits. Transit nodes process the Admin
			Status TLV by passing the Notification message. The egress node May
			respond with a Notification message with the Admin Status TLV. Upon
			receiving the Admin Status TLV with the Delete (D) bit set in the
			Notification message, the egress SHOULD respond with a LABEL WITHDRAW
			message and normal CR-LDP processing takes place.
	Transit and egress nodes process the Admin Status TLV as described		In such circumstances the procedure SHOULD be followed when deleting
	above.		an LSP from the egress: The egress node indicates its desire for
			deletion by inserting an Admin Status TLV in a Notification message
			and setting Delete (D) bit. Transit nodes process the Admin Status
			TLV as described above. Upon receiving the Admin Status TLV with the
			Delete (D) bit set in the Notification message, the ingress node
			sends a LABEL RELEASE message downstream to remove the LSP and normal
			CR-LDP processing takes place.
	Upon receiving the Admin Status TLV with the Down (D) bit set in the		7.3. Notification Message Procedures
	MAPPING message with the modification action indicator set to modify
	the ingress node sends a RELEASE message downstream to remove the LSP
	and normal CR-LDP processing takes place.
	7.3.2. Compatibility		Subsequent messaging Admin Status messaging may be performed by
			Notification Messages. The ingress may begin the propagation of a
			Notification Message with an Admin Status TLV. Each subsequent node
			propagates the Notification with the Admin Status TLV from the
			ingress to the egress and then the egress node returns the
			Notification messages back Upstream carrying the Admin Status TLV.
	It is possible that some nodes along an LSP will not support the		Intermediate and egress nodes may trigger the setting of
	Admin Status TLV. In the case of a non-supporting transit node, the		administrative status via the use of Notification messages. To
	TLV will pass through the node unmodified and normal processing can		accomplish this, an intermediate or egress node generates a
	continue. In the case of a non-supporting egress node, the Admin		Notification message with the corresponding upstream notify session
	Status TLV may not be reflected back in the MAPPING Message. In this		information. The Admin Status TLV MUST be included in the session
	case, the ingress SHOULD continue to set the contents of the object		information, with the appropriate bit or bits set. The Reflect (R)
	normally but, when processing an LSP deletion, it MUST NOT wait for		bit MUST NOT be set.
	an updated Admin Status TLV in a MAPPING message before issuing a
	RELEASE/WITHDRAW message.
	7.3.3. Notify Message Procedures		An ingress or egress node receiving a Notification message containing
			an Admin Status TLV with the Delete (D) bit set, SHOULD initiate the
			deletion procedure described in the previous section.
	Intermediate and egress nodes may trigger the setting of		7.3.1. Compatibility and Error Procedures
	administrative status before a deletion via the use of REQUEST
	messages. To accomplish this, an intermediate or egress node
	generates a REQUEST message with the modification action indicator
	set to modify and with the corresponding upstream. The Admin Status
	TLV MUST be included in the message, with the Down (D) bit set.
	An ingress node receiving a MAPPING message containing an Admin		Some special processing is required in order to cover the case of
	Status TLV with the Down (D) bit set, SHOULD initiate the deletion		nodes that do not support the Admin Status TLV and other error
	procedure described in the previous section.		conditions. Specifically, a node that sends a Notification message
			containing an Admin Status TLV with the Down (D) bit set MUST verify
			that it receives a corresponding LABEL RELEASE message within a
			configurable period of time. By default this period of time SHOULD
			be 30 seconds. If the node does not receive such a LABEL RELEASE
			message, it SHOULD send a Label Release message downstream and a
			LABEL WITHDRAW message upstream.
	8. Control Channel Separation		8. Control Channel Separation
	This section provides the protocol specific formats and procedures to		This section provides the protocol specific formats and procedures to
	required support a control channel not being in-band with a data		required support a control channel not being in-band with a data
	channel.		channel.
	8.1. Interface Identification		8.1. Interface Identification
	The choice of the data interface to use is always made by the sender		The choice of the data interface to use is always made by the sender
	of the REQUEST message. The choice of the data interface is indicated		of the REQUEST message. The choice of the data interface is indicated
	by the sender of the REQUEST message by including the data channel's		by the sender of the REQUEST message by including the data channel's
	interface identifier in the message using a new Interface TLV. type.		interface identifier in the message using a new Interface TLV. type.
	For bidirectional LSPs, the sender chooses the data interface in each		For bidirectional LSPs, the sender chooses the data interface in each
	direction. In all cases but bundling [MPLS-BUNDLE] the upstream		direction. In all cases but bundling [MPLS-BUNDLE] the upstream
	interface is implied by the downstream interface. For bundling, the		interface is implied by the downstream interface. For bundling, the
	path sender explicitly identifies the component interface used in		REQUEST sender explicitly identifies the component interface used in
	each direction.		each direction.
	The format of Interface ID in REQUEST, MAPPING Messages is:
			The format of IPV4 Interface ID in REQUEST, MAPPING Messages 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| Type (TBA by IANA) | Length |		|U|F| Type (TBA by IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv4 Next/Previous Hop Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Logical Interface ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface ID TLVS see [GMLPS-SIG] |		| Interface ID TLVS see [GMLPS-SIG] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The format of IPV6 Interface ID TLV in REQUEST, MAPPING Messages is:
	The U Bit Should be set to 0. The F bit should be set to 0.		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|U|F| Type (TBA by IANA) | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv6 Next/Previous Hop Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Logical Interface ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Interface ID TLVS see [GMLPS-SIG] |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.		See [GMPLS-SIG] for a description of parameters.
	See [CR-LDP] for a description of signaling address. See [GMPLS-SIG]		See [CR-LDP] for a description of signaling address. See [GMPLS-SIG]
	for a description of parameters and encoding of TLVs.		for a description of parameters and encoding of TLVs.
	8.2. Procedures		8.2. Procedures
	An IF_ID TLV is used on links where there is not a one-to- one		An IF_ID TLV is used on links where there is not a one-to- one
	association of a control channel to a data channel, see [GMPLS- SIG].		association of a control channel to a data channel, see [GMPLS- SIG].
	The LDP session uses the IF_ID TLV to identify the data channel(s)		The LDP session uses the IF_ID TLV to identify the data channel(s)
	associated with the LSP. For a unidirectional LSP, a forward channel		associated with the LSP. For a unidirectional LSP, a downstream data
	MUST be indicated. For a bidirectional LSP that use bundled links, a		channel MUST be indicated. For bidirectional LSPs, a common
	reverse channel MUST be indicated. Data channels are specified from		downstream and upstream data channel is normally indicated. In the
	the viewpoint of the sender of the REQUEST message.		special case where a bidirectional LSP that traverses a bundled link,
			it is possible to specify a downstream data channel that differs from
			the upstream data channel. Data channels are specified from the view
			point of the sender of the Path message. The IF_ID TLV SHOULD NOT be
			used when no TLVs are needed.
			A node receiving one or more IF_ID TLVs in a REQUEST message saves
			their values and returns them in the subsequent MAPPING message sent
			to the node that originated the TLVs.
			As with [MPLS-TE], the node originating an IF_ID TLV must ensure that
			the selected outgoing interface is consistent with the outgoing ER
			TLV. A node that receives an IF_ID TLV SHOULD check whether the
			information carried in this TLV is consistent with the information
			carried in a received ER TLV, and if not it MUST send a LABEL ABORT
			Message with the status code of "Bad Explicit Routing TLV Error"
			toward the sender.
			8.3. Errored Interface Identification
			There are cases where it is useful to indicate a specific interface
			associated with an error. To support these cases the IF_ID Status
			TLV are defined.
			8.3.1. IF_ID Status TLVs
			The format of the IPv4 IF_ID Status TLV 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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|U|F| Type (TBA by IANA) | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv4 Next/Previous Hop Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Status Code |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ TLVs ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The format of the IPv6 IF_ID Status TLV 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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|U|F| Type (TBA by IANA) | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			| IPv6 Error Node Address |
			| |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Status Code |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ TLVs ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			See [RFC3036] for a description of status code value fields.
			See [GMPLS-SIG] for a description of parameters and encoding of
			TLVs.
			8.3.2. Procedures
			Nodes wishing to indicate that an error is related to a specific
			interface SHOULD use the appropriate IF_ID Status TLV in the
			corresponding LABEL WITHDRAW or LABEL RELEASE message. IF_ID Status
			TLV SHOULD be generated and processed as any other Status TLV, see
			[RFC3036].
	9. Fault Handling		9. Fault Handling
	In optical transport networks, failures in the out-of-fiber signaling		In optical transport networks, failures in the out-of-fiber signaling
	communication or optical control plane should not have service impact		communication or optical control plane should not have service impact
	on the existing optical connections. Under such circumstances, a		on the existing optical connections. Under such circumstances, a
	mechanism MUST exist to detect a signaling communication failure and		mechanism MUST exist to detect a signaling communication failure and
	a recovery procedure SHALL guarantee connection integrity at both		a recovery procedure SHALL guarantee connection integrity at both
	ends of the signaling channel.		ends of the signaling channel.
	The LDP Fault tolerant draft [LDP-FT] specifies the procedures for		The LDP Fault tolerant draft [LDP-FT] specifies the procedures for
	recovering LDP and CR-LDP sessions under failure. Please refer to		recovering LDP and CR-LDP sessions under failure. Please refer to his
	this draft for procedures on recovering optical connections.		draft for procedures on recovering optical connections. Currently
	Currently the Fault tolerant draft covers many of the common failure		the Fault tolerant draft covers many of the common failure modes for
	modes for a separated control and data plane.		a separated control and data plane.
	10. Acknowledgments		10. 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
	Valuable comments and input were received from a number of people,		Valuable comments and input were received from a number of people,
	notably Adrian Farrel.		notably Adrian Farrel.
	11. Security Considerations		11. Security Considerations
	This draft introduce no new security considerations to [CR-LDP].		This draft introduce no new security considerations to [CR-LDP].
	12. References		12. IANA Considerations
			This draft uses the LDP [RFC 3031] name spaces, which require
			assignment for the following TLVs.
			o Generalized Label Request (TLV TBA)
			o Generalized Label (TLV TBA)
			o Upstream Label (TLV TBA)
			o Label Set (TLV TBA)
			o Waveband Label (TLV TBA)
			o ER-Hop (TLV TBA)
			o Acceptable Label Set (TLV TBA)
			o Admin Status (TLV TBA)
			o Interface ID (TLV TBA)
			o IPV4 Interface ID (TLV TBA)
			o IPV6 Interface ID (TLV TBA)
			o IPv4 IF_ID Status (TLV TBA)
			o IPv6 IF_ID Status (TLV TBA)
			13. References
	[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",		[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
	draft-ietf-mpls-cr-ldp-05.txt, Feb., 2001.		Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, Jul., 2001.
			[RFC3036] Andersson et al., "LDP Specification",
			RFC 3036.
	[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, Sep., 2001.
	[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
	in CR-LDP", Internet Draft,		[MPLS-UNNUM] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling
	draft-ietf-mpls-crldp-unnum-01.txt, February 2001		Unnumbered Links in CR-LDP", Internet Draft,
			draft-ietf-mpls-crldp-unnum-02.txt, Sep. 2001
	[GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -		[GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
	RSVP-TE Extensions", Internet Draft,		RSVP-TE Extensions", Internet Draft,
	draft-ietf-mpls-generalized-rsvp-te-01.txt,		draft-ietf-mpls-generalized-rsvp-te-06.txt,
	February 2001.		November 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-07.txt,
	February 2001.		November 2001.
	[LDP-FT] Farrel, A. et al, "Fault Tolerance for LDP		[LDP-FT] Farrel, A. et al, "Fault Tolerance for LDP
	and CR-LDP", Internet Draft,		and CR-LDP", Internet Draft,
	draft-ietf-mpls-ldp-ft-02.txt,		draft-ietf-mpls-ldp-ft-02.txt,
	February 2001.		May 2001.
			[MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling
			in MPLS Traffic Engineering", Internet Draft,
			draft-kompella-mpls-bundle-05.txt, Sep., 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.
	13. 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
	Calient Networks		Calient Networks
	skipping to change at page 18, line 35		skipping to change at page 21, line 35
	John Drake		John Drake
	Calient Networks		Calient Networks
	5853 Rue Ferrari		5853 Rue Ferrari
	San Jose, CA 95138		San Jose, CA 95138
	Phone: +1 408 972 3720		Phone: +1 408 972 3720
	Email: jdrake@calient.net		Email: jdrake@calient.net
	Yanhe Fan		Yanhe Fan
	Axiowave Networks, Inc.		Axiowave Networks, Inc.
	100 Nickerson Road		200 Nickerson Road
	Marlborough, MA 01752		Marlborough, MA 01752
	Phone: +1 508 460 6969 Ext. 627		Phone: + 1 774 348 4627
	Email: yfan@axiowave.com		Email: yfan@axiowave.com
	Don Fedyk		Don Fedyk
	Nortel Networks Corp.		Nortel Networks Corp.
	600 Technology Park		600 Technology Park
	Billerica MA 01821		Billerica MA 01821
	Phone: +1 978 288 3041		Phone: +1 978 288 3041
	Fax: +1 978 288 0620		Fax: +1 978 288 0620
	Email: dwfedyk@nortelnetworks.com		Email: dwfedyk@nortelnetworks.com
	Kireeti Kompella		Kireeti Kompella
	skipping to change at page 20, line 5		skipping to change at page 23, line 5
	Email: yakov@juniper.net		Email: yakov@juniper.net
	Debanjan Saha		Debanjan Saha
	Tellium Optical Systems		Tellium Optical Systems
	2 Crescent Place		2 Crescent Place
	Oceanport, NJ 07757-0901		Oceanport, NJ 07757-0901
	Phone: +1 732 923 4264		Phone: +1 732 923 4264
	Fax: +1 732 923 9804		Fax: +1 732 923 9804
	Email: dsaha@tellium.com		Email: dsaha@tellium.com
	Vishal Sharma		Vishal Sharma
	Jasmine Networks, Inc.		Metanoia, Inc.
	3061 Zanker Road, Suite B		335 Elan Village Lane, Unit 203
	San Jose, CA 95134		San Jose, CA 95134-2539
	Phone: +1 408 895 5030		Phone: +1 408-943-1794
	Fax: +1 408 895 5050		Email: v.sharma@ieee.org
	Email: vsharma@jasminenetworks.com
	George Swallow		George Swallow
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo Drive		250 Apollo Drive
	Chelmsford, MA 01824		Chelmsford, MA 01824
	Voice: +1 978 244 8143		Voice: +1 978 244 8143
	Email: swallow@cisco.com		Email: swallow@cisco.com
	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: Fri Jul 20 16:49:49 EDT 2001		Generated on: Wed Nov 21 15:23:23 EST 2001
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/