draft-ietf-mpls-generalized-cr-ldp-06.txt		draft-ietf-mpls-generalized-cr-ldp-07.txt
	Network Working Group		A new Request for Comments is now available in online RFC libraries.
	Internet Draft Peter Ashwood-Smith - Editor (Nortel Networks)
	Expiration Date: October 2002 Lou Berger - Editor (Movaz Networks)
	Ayan Banerjee (Calient Networks)
	Greg Bernstein (Ciena Corporation)
	John Drake (Calient Networks)
	Yanhe Fan (Axiowave Networks)
	Don Fedyk (Nortel Networks)
	Kireeti Kompella (Juniper Networks)
	Eric Mannie (KPNQwest)
	Jonathan P. Lang (Calient Networks)
	Bala Rajagopalan (Tellium)
	Yakov Rekhter (Juniper Networks)
	Debanjan Saha (Tellium)
	Vishal Sharma (Metanoia)
	George Swallow (Cisco Systems)
	Z. Bo Tang (Tellium)
	April 2002
	Generalized MPLS Signaling - CR-LDP Extensions
	draft-ietf-mpls-generalized-cr-ldp-06.txt
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	To view the current status of any Internet-Draft, please check the
	"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
	Directory, see http://www.ietf.org/shadow.html.
	Abstract
	This document describes extensions to CR-LDP signaling required to
	support Generalized MPLS. Generalized MPLS extends MPLS to encompass
	time-division (e.g. SONET/SDH ADMs), wavelength (optical lambdas) and
	spatial switching (e.g. incoming port or fiber to outgoing port or
	fiber). This document presents a CR-LDP specific description of the
	extensions. A generic functional description and an RSVP-TE specific
	description can be found in separate documents.
	Contents
	1 Introduction .............................................. 3
	2 Label Related Formats .................................... 3
	2.1 Generalized Label Request ................................. 4
	2.1.1 Procedures ................................................ 4
	2.1.2 Bandwidth Encoding ........................................ 5
	2.2 Generalized Label ......................................... 5
	2.2.1 Procedures ................................................ 6
	2.3 Waveband Switching ........................................ 6
	2.3.1 Procedures ................................................ 6
	2.4 Suggested Label ........................................... 7
	2.5 Label Set ................................................. 8
	2.5.1 Procedures ................................................ 8
	3 Bidirectional LSPs ........................................ 9
	3.1 Procedures ................................................ 9
	4 Notification on Label Error ............................... 10
	5 Explicit Label Control .................................... 11
	5.1 Procedures ................................................ 11
	6 Protection TLV ............................................ 12
	6.1 Procedures ................................................ 12
	7 Administrative Status Information ......................... 13
	7.1 Admin Status TLV .......................................... 13
	7.2 REQUEST and MAPPING Message Procedures .................... 13
	7.2.1 Deletion procedure ........................................ 14
	7.3 Notification Message Procedures ........................... 15
	7.3.1 Compatibility and Error Procedures ........................ 15
	8 Control Channel Separation ................................ 15
	8.1 Interface Identification .................................. 16
	8.2 Procedures ................................................ 17
	8.3 Errored Interface Identification .......................... 17
	8.3.1 IF_ID Status TLVs ......................................... 17
	8.3.2 Procedures ................................................ 18
	9 Fault Handling ......................................... 19
	10 Acknowledgments ........................................... 19
	11 Security Considerations ................................... 19
	12 IANA Considerations ....................................... 19
	13 References ................................................ 20
	13.1 Normative References ...................................... 20
	13.2 Informative References .................................... 20
	14 Authors' Addresses ........................................ 21
	[Editor's note: changes to be removed prior to publication as an RFC.]
	Changes from previous version:
	o Reorder author's list to indicate primary contact
	o Split references section
	o Fixed formatting of section 7.2.1
	o Minor editorial changes and clarifications
	1. Introduction
	Generalized MPLS extends MPLS from supporting packet (PSC) interfaces
	and switching to include support of three new classes of interfaces
	and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and
	Fiber-Switch (FSC). A functional description of the extensions to
	MPLS signaling needed to support the new classes of interfaces and
	switching is provided in [GMPLS-SIG]. This document presents CR-LDP
	specific formats and mechanisms needed to support all four classes of
	interfaces. RSVP-TE extensions can be found in [GMPLS-RSVP].
	[GMPLS-SIG] should be viewed as a companion document to this
	document. The format of this document parallels [GMPLS-SIG]. It
	should be noted that the RSVP-TE specific version of Generalized MPLS
	includes RSVP specific support for rapid failure notification, see
	Section 4 [GMPLS-RSVP]. For CR-LDP there is not currently a similar
	mechanism. When a failure is detected it will be propagated with
	RELEASE/WITHDRAW messages radially outward from the point of failure.
	Resources are to be released in this phase and actual resource
	information may be fed back to the source using a feedback
	mechanisms.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	2. Label Related Formats
	This section defines formats for a generalized label request, a
	generalized label, support for waveband switching, suggested label
	and label sets.
	2.1. Generalized Label Request
	A REQUEST message SHOULD contain as specific an LSP Encoding Type as
	possible to allow the maximum flexibility in switching by transit
	LSRs. A Generalized Label Request TLV is set by the ingress node,
	transparently passed by transit nodes, and used by the egress node.
	The Switching Type field may also be updated hop-by-hop.
	The format of a Generalized Label Request 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSP Enc. Type |Switching Type | G-PID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.
	2.1.1. Procedures
	A node processing a REQUEST message containing a Generalized Label
	Request must verify that the requested parameters can be satisfied by
	the incoming interface, the node and by the outgoing interface. The
	node may either directly support the LSP or it may use a tunnel (FA),
	i.e., another class of switching. In either case, each parameter
	must be checked.
	Note that local node policy dictates when tunnels may be used and
	when they may be created. Local policy may allow for tunnels to be
	dynamically established or may be solely administratively controlled.
	For more information on tunnels and processing of ER hops when using
	tunnels see [MPLS-HIERARCHY].
	Transit and egress nodes MUST verify that the node itself and, where
	appropriate, that the outgoing interface or tunnel can support the
	requested LSP Encoding Type. If encoding cannot be supported, the
	node MUST generate a NOTIFICATION message, with a "Routing
	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
	indicated G-PID cannot be supported then the egress MUST generate a
	NOTIFICATION message, with a "Routing problem/Unsupported GPID"
	indication. In the case of PSC and when penultimate hop popping
	(PHP) is requested, the penultimate hop also examines the (stored) G-
	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
	NOTIFICATION message with a "Routing problem/Unacceptable label
	value" indication. The generated NOTIFICATION message MAY include an
	Acceptable Label Set, see Section 4.
	When an error message is not generated, normal processing occurs. In
	the transit case this will typically result in a REQUEST message
	being propagated. In the egress case and PHP special case this will
	typically result in a MAPPING message being generated.
	2.1.2. Bandwidth Encoding
	Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV.
	See [GMPLS-SIG] for a definition of values to be used for specific
	signal types. These values are set in the Peak and Committed Data
	Rate fields of the Traffic Parameters TLV. Other bandwidth/service
	related parameters in the TLV are ignored and carried transparently.
	2.2. Generalized Label
	The format of a Generalized Label 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label |
	| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters and encoding of
	labels.
	2.2.1. Procedures
	The Generalized Label travels in the upstream direction in MAPPING
	messages.
	The presence of both a generalized and normal label TLV in a MAPPING
	message is a protocol error and should treated as a malformed message
	by the recipient.
	The recipient of a MAPPING message containing a Generalized Label
	verifies that the values passed are acceptable. If the label is
	unacceptable then the recipient MUST generate a NOTIFICATION message
	with a "Routing problem/MPLS label allocation failure" indication.
	The generated NOTIFICATION message MAY include an Acceptable Label
	Set, see Section 4.
	2.3. Waveband Switching
	Waveband switching uses the same format as the generalized label, see
	section 2.2. The type TBA is assigned for the Waveband Label.
	In the context of waveband switching, the generalized label has the
	following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Waveband Id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Start Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| End Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.
	2.3.1. Procedures
	The procedures defined in Section 2.2.1 apply to waveband switching.
	This includes generating a NOTIFICATION message with a "Routing
	problem/MPLS label allocation failure" indication if any of the label
	fields are unrecognized or unacceptable.
	Additionally, when a waveband is switched to another waveband, it is
	possible that the wavelengths within the waveband will be mirrored
	about a center frequency. When this type of switching is employed,
	the start and end label in the waveband label TLV MUST be flipped
	before forwarding the label TLV with the new waveband Id. In this
	manner an egress/ingress LSR that receives a waveband label which has
	these values inverted, knows that it must also invert its egress
	association to pick up the proper wavelengths. Without this
	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
	bidirectional waveband tunnel is being established.
	2.4. Suggested Label
	The format of a suggested label is identical to a generalized label.
	It is used in REQUEST messages. Suggested Label uses type = 0x904.
	Errors in received Suggested Labels MUST be ignored. This includes
	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
	The format of a Label Set 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Action | Reserved | Label Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Subchannel 1 |
	| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: : :
	: : :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Subchannel N |
	| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Label Type: 14 bits
	Indicates the type and format of the labels carried in the TLV.
	Values match the TLV type of the appropriate Label TLV.
	See [GMPLS-SIG] for a description of other parameters.
	2.5.1. Procedures
	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
	Action zero (0) and one (1) TLVs respectively. Ranges of
	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
	TLVs only list labels/subchannels to exclude, this implies that all
	other labels are acceptable.
	The absence of any Label Set TLVs implies that all labels are
	acceptable. A Label Set is included when a node wishes to restrict
	the label(s) that may be used downstream.
	On reception of a REQUEST message, the receiving node will restrict
	its choice of labels to one, which is in the Label Set. Nodes
	capable of performing label conversion may also remove the Label Set
	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
	Label Set TLVs, then the request is terminated and a NOTIFICATION
	message with a "Routing problem/Label Set" indication MUST be
	generated. It is a local matter if the Label Set is stored for later
	selection on the MAPPING message or if the selection is made
	immediately for propagation in the MAPPING message.
	On reception of a REQUEST message, the Label Set represented in the
	message is compared against the set of available labels at the
	downstream interface and the resulting intersecting Label Set is
	forwarded in a REQUEST message. When the resulting Label Set is
	empty, the REQUEST must be terminated, and a NOTIFICATION message,
	and a "Routing problem/Label Set" indication MUST be generated. Note
	that intersection is based on the physical labels (actual
	wavelength/band values) which may have different logical values on
	different links, as a result it is the responsibility of the node to
	map these values so that they have a consistent physical meaning, or
	to drop the particular values from the set if no suitable logical
	label value exists.
	When processing a MAPPING message at an intermediate node, the label
	propagated upstream MUST fall within the Label Set.
	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
	physical label (wavelength/band) as received in the MAPPING message.
	In this case, the use and propagation of a Label Set will
	significantly reduce the chances that this allocation will fail.
	3. Bidirectional LSPs
	Bidirectional LSP setup is indicated by the presence of an Upstream
	Label in the REQUEST message. An Upstream Label has the same format
	as the generalized label, see Section 2.2. Upstream Label uses type=
	TBA
	3.1. Procedures
	The process of establishing a bidirectional LSP follows the
	establishment of a unidirectional LSP with some additions. To
	support bidirectional LSPs an Upstream Label is added to the REQUEST
	message. The Upstream Label MUST indicate a label that is valid for
	forwarding at the time the REQUEST message is sent.
	When a REQUEST message containing an Upstream Label is received, the
	receiver first verifies that the upstream label is acceptable. If
	the label is not acceptable, the receiver MUST issue a NOTIFICATION
	message with a "Routing problem/Unacceptable label value" indication.
	The generated NOTIFICATION message MAY include an Acceptable Label
	Set, see Section 4.
	An intermediate node must also allocate a label on the outgoing
	interface and establish internal data paths before filling in an
	outgoing Upstream Label and propagating the REQUEST message. If an
	intermediate node is unable to allocate a label or internal
	resources, then it MUST issue a NOTIFICATION message with a "Routing
	problem/Label allocation failure" indication.
	Terminator nodes process REQUEST messages as usual, with the
	exception that the upstream label can immediately be used to
	transport data traffic associated with the LSP upstream towards the
	initiator.
	When a bidirectional LSP is removed, both upstream and downstream
	labels are invalidated and it is no longer valid to send data using
	the associated labels.
	4. Notification on Label Error
	This section defines the Acceptable Label Set TLV to support
	Notification on Label Error per [GMPLS-SIG]. An Acceptable Label Set
	TLV uses a type value of TBA The remaining contents of the TLV have
	the identical format as the Label Set TLV, see Section 2.5.
	Acceptable Label Set TLVs may be carried in NOTIFICATION messages.
	The procedures for defining an Acceptable Label Set follow the
	procedures for defining a Label Set, see Section 2.5.1.
	Specifically, an Acceptable Label Set is defined via one or more
	Acceptable Label Set TLVs. Specific labels/subchannels can be added
	to or excluded from an Acceptable Label Set via Action zero (0) and
	one (1) TLVs respectively. Ranges of labels/subchannels can be added
	to or excluded from an Acceptable Label Set via Action two (2) and
	three (3) TLVs respectively. When the Acceptable Label Set TLVs only
	list labels/subchannels to exclude, this implies that all other
	labels are acceptable.
	The inclusion of Acceptable Label Set TLVs is optional. If included,
	the NOTIFICATION message SHOULD contain a "Routing
	problem/Unacceptable label value" indication. The absence of
	Acceptable Label Set TLVs does not have any specific meaning.
	5. Explicit Label Control
	The Label ER-Hop TLV is defined as follows:
	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|0| Type (TBA by IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|L|U| Reserved | Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label (continued) |
	| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of L, U and Label parameters.
	5.1. Procedures
	The Label ER-Hop follows a ER-Hop containing the IP address, or the
	interface identifier [MPLS-UNNUM], associated with the link on which
	it is to be used. Up to two label ER-Hops may be present, one for
	the downstream label and one for the upstream label. The following
	SHOULD result in "Bad EXPLICIT_ROUTE" errors:
	- If the first label ER-Hop is not preceded by a ER-Hop
	containing an IP address, or a interface identifier
	[MPLS-UNNUM], associated with an output link.
	- For a label ER-Hop to follow a ER-Hop that has the L-bit
	set
	- On unidirectional LSP setup, for there to be a label ER-Hop
	with the U-bit set
	- 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
	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
	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
	TLV. This Label Set TLV MUST be included on the corresponding
	outgoing REQUEST message.
	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 bidirectional LSP. If this label is not acceptable, a "Bad
	EXPLICIT_ROUTE" error SHOULD be generated. If the label is
	acceptable, the label is copied into a new Upstream Label TLV. This
	Upstream Label TLV MUST be included on the corresponding outgoing
	REQUEST message.
	After processing, the label ER-Hops are removed from the ER.
	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
	label ER-Hop is the first ER-Hop an a received ER, 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
	information needed to construct the Label ER-Hop are outside the
	scope of this document.
	6. Protection TLV
	The use of the Protection TLV is optional. The TLV is included to
	indicate specific protection attributes of an LSP.
	The format of Protection Information 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved | Link Flags|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.
	6.1. Procedures
	Transit nodes processing a REQUEST message containing a Protection
	TLV MUST verify that the requested protection can be satisfied by the
	outgoing interface or tunnel (FA). If it cannot, the node MUST
	generate a NOTIFICATION message, with a "Routing problem/Unsupported
	Link Protection" indication.
	7. Administrative Status Information
	Administrative Status Information is carried in the Admin Status TLV.
	The TLV provides information related to the administrative state of a
	particular LSP. The information is used in two ways. In the first,
	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
	Notification message to request a change to the administrative state
	of an LSP.
	7.1. Admin Status TLV
	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 and Notification
	Messages 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Reserved |T|A|D|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.
	7.2. REQUEST and MAPPING Message Procedures
	The Admin Status TLV is used to notify each node along the path of
	the status of the LSP. Each node processes status information based
	on local policy and then propagated in the corresponding outgoing
	messages. The TLV is inserted in REQUEST messages at the discretion
	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
	TLV, update their local state, take any appropriate local action
	based on the indicated status and then propagate the received Admin
	Status TLV in the outgoing REQUEST message.
	Edge nodes receiving a REQUEST message containing an Admin Status
	TLV, also update their local state and take any appropriate local
	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 received values in a corresponding MAPPING message.
	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
	Mapping message containing an Admin_Status TLV with the same values
	set, with the exception of the R bit, as received in the
	corresponding Request 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 from the ingress:
	o The ingress node precedes an LSP deletion by inserting an
	Admin Status TLV in a Notification Message setting the Reflect
	(R) and Delete (D) bits.
	o 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.
	o 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.
	In such circumstances the procedure SHOULD be followed when deleting
	an LSP from the egress:
	o The egress node indicates its desire for deletion by inserting
	an Admin Status TLV in a Notification message and setting
	Delete (D) bit.
	o Transit nodes process the Admin Status TLV as described above.
	o 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.
	7.3. Notification Message Procedures
	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.
	Intermediate and egress nodes may trigger the setting of
	administrative status via the use of Notification messages. To
	accomplish this, an intermediate or egress node generates a
	Notification message with the corresponding upstream notify session
	information. The Admin Status TLV MUST be included in the session
	information, with the appropriate bit or bits set. The Reflect (R)
	bit MUST NOT be set.
	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.
	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 TLV and other error
	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
	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 REQUEST message. The choice of the data interface is indicated
	by the sender of the REQUEST message by including the data channel's
	interface identifier in the message using a new Interface TLV. type.
	For bidirectional LSPs, the sender chooses the data interface in each
	direction. In all cases but bundling, the upstream interface is
	implied by the downstream interface. For bundling, the REQUEST
	sender explicitly identifies the component interface used in each
	direction.
	The format of IPV4 Interface ID in REQUEST, MAPPING Messages 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Logical Interface ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface ID TLVS see [GMLPS-SIG] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The format of IPV6 Interface ID TLV in REQUEST, MAPPING Messages 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 Next/Previous Hop Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Logical Interface ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface ID TLVS see [GMPLS-SIG] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	See [GMPLS-SIG] for a description of parameters.
	See [RFC3212] for a description of signaling address. See [GMPLS-
	SIG] for a description of parameters and encoding of TLVs.
	8.2. Procedures
	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].
	The LDP session uses the IF_ID TLV to identify the data channel(s)
	associated with the LSP. For a unidirectional LSP, a downstream data
	channel MUST be indicated. For bidirectional LSPs, a common
	downstream and upstream data channel is normally indicated. In the
	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
	In optical transport networks, failures in the out-of-fiber signaling
	communication or optical control plane should not have service impact
	on the existing optical connections. Under such circumstances, a
	mechanism MUST exist to detect a signaling communication failure and
	a recovery procedure SHALL guarantee connection integrity at both
	ends of the signaling channel.
	The LDP Fault tolerant draft [LDP-FT] specifies the procedures for
	recovering LDP and CR-LDP sessions under failure. Please refer to his
	draft for procedures on recovering optical connections. Currently
	the Fault tolerant draft covers many of the common failure modes for
	a separated control and data plane.
	10. Acknowledgments
	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
	the drafts from which material and ideas were incorporated follows:
	draft-saha-rsvp-optical-signaling-00.txt
	draft-lang-mpls-rsvp-oxc-00.txt
	draft-kompella-mpls-optical-00.txt
	draft-fan-mpls-lambda-signaling-00.txt
	Valuable comments and input were received from a number of people,
	notably Adrian Farrel.
	11. Security Considerations
	This draft introduce no new security considerations to [RFC3212].
	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
	13.1. Normative References
	[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
	Signaling Functional Description", Internet Draft,
	draft-ietf-mpls-generalized-signaling-08.txt,
	April 2002.
	[RFC3036] Andersson et al., "LDP Specification",
	RFC 3036.
	[RFC3212] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
	RFC 3212, January 2002.
	13.2. Informative References
	[GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
	RSVP-TE Extensions", Internet Draft,
	draft-ietf-mpls-generalized-rsvp-te-07.txt,
	April 2002.
	[LDP-FT] Farrel, A. et al, "Fault Tolerance for LDP
	and CR-LDP", Internet Draft,
	draft-ietf-mpls-ldp-ft-02.txt,
	May 2001.
	[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
	MPLS TE", Internet Draft,
	draft-ietf-mpls-lsp-hierarchy-02.txt, Sep., 2001.
	[MPLS-UNNUM] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling
	Unnumbered Links in CR-LDP", Internet Draft,
	draft-ietf-mpls-crldp-unnum-02.txt, Sep. 2001
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels," RFC 2119.
	14. Authors' Addresses
	Peter Ashwood-Smith
	Nortel Networks Corp.
	P.O. Box 3511 Station C,
	Ottawa, ON K1Y 4H7
	Canada
	Phone: +1 613 763 4534
	Email: petera@nortelnetworks.com
	Ayan Banerjee
	Calient Networks
	5853 Rue Ferrari
	San Jose, CA 95138
	Phone: +1 408 972-3645
	Email: abanerjee@calient.net
	Lou Berger Editor & Primary Point of Contact		RFC 3472
	Movaz Networks, Inc.
	7926 Jones Branch Drive
	Suite 615
	McLean VA, 22102
	Phone: +1 703 847-1801
	Email: lberger@movaz.com
	Greg Bernstein		Title: Generalized Multi-Protocol Label Switching (GMPLS)
	Ciena Corporation		Signaling Constraint-based Routed Label
	10480 Ridgeview Court		Distribution Protocol (CR-LDP) Extensions
	Cupertino, CA 94014		Author(s): P. Ashwood-Smith, L. Berger, Editors
	Phone: +1 408 366 4713		Status: Standards Track
	Email: greg@ciena.com		Date: January 2003
			Mailbox: petera@nortelnetworks.com, lberger@movaz.com
			Pages: 23
			Characters: 49006
			Updates/Obsoletes/SeeAlso: None
	John Drake		I-D Tag: draft-ietf-mpls-generalized-cr-ldp-07.txt
	Calient Networks
	5853 Rue Ferrari
	San Jose, CA 95138
	Phone: +1 408 972 3720
	Email: jdrake@calient.net
	Yanhe Fan
	Axiowave Networks, Inc.
	200 Nickerson Road
	Marlborough, MA 01752
	Phone: + 1 774 348 4627
	Email: yfan@axiowave.com
	Don Fedyk		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3472.txt
	Nortel Networks Corp.
	600 Technology Park
	Billerica MA 01821
	Phone: +1 978 288 3041
	Fax: +1 978 288 0620
	Email: dwfedyk@nortelnetworks.com
	Kireeti Kompella		This document describes extensions to Multi-Protocol Label Switching
	Juniper Networks, Inc.		(MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP)
	1194 N. Mathilda Ave.		signaling required to support Generalized MPLS. Generalized
	Sunnyvale, CA 94089		MPLS extends the MPLS control plane to encompass time-division (e.g.,
	Email: kireeti@juniper.net		Synchronous Optical Network and Synchronous Digital Hierarchy,
			SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
			incoming port or fiber to outgoing port or fiber). This document
			presents a CR-LDP specific description of the extensions. A generic
			functional description can be found in separate documents.
	Jonathan P. Lang		This document is a product of the Common Control and Measurement Plane
	Calient Networks		(ccamp) Working Group of the IETF.
	25 Castilian
	Goleta, CA 93117
	Email: jplang@calient.net
	Eric Mannie		This is now a Proposed Standard Protocol.
	KPNQwest
	Terhulpsesteenweg 6A
	1560 Hoeilaart - Belgium
	Phone: +32 2 658 56 52
	Mobile: +32 496 58 56 52
	Fax: +32 2 658 51 18
	Email: eric.mannie@kpnqwest.com
	Bala Rajagopalan		This document specifies an Internet standards track protocol for
	Tellium, Inc.		the Internet community, and requests discussion and suggestions
	2 Crescent Place		for improvements. Please refer to the current edition of the
	P.O. Box 901		"Internet Official Protocol Standards" (STD 1) for the
	Oceanport, NJ 07757-0901		standardization state and status of this protocol. Distribution
	Phone: +1 732 923 4237		of this memo is unlimited.
	Fax: +1 732 923 9804
	Email: braja@tellium.com
	Yakov Rekhter
	Juniper Networks, Inc.
	Email: yakov@juniper.net
	Debanjan Saha		This announcement is sent to the IETF list and the RFC-DIST list.
	Tellium Optical Systems		Requests to be added to or deleted from the IETF distribution list
	2 Crescent Place		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	Oceanport, NJ 07757-0901		added to or deleted from the RFC-DIST distribution list should
	Phone: +1 732 923 4264		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Fax: +1 732 923 9804
	Email: dsaha@tellium.com
	Vishal Sharma		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	Metanoia, Inc.		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	335 Elan Village Lane, Unit 203		help: ways_to_get_rfcs. For example:
	San Jose, CA 95134-2539
	Phone: +1 408-943-1794
	Email: v.sharma@ieee.org
	George Swallow		To: rfc-info@RFC-EDITOR.ORG
	Cisco Systems, Inc.		Subject: getting rfcs
	250 Apollo Drive
	Chelmsford, MA 01824
	Voice: +1 978 244 8143
	Email: swallow@cisco.com
	Z. Bo Tang		help: ways_to_get_rfcs
	Tellium, Inc.
	2 Crescent Place
	P.O. Box 901
	Oceanport, NJ 07757-0901
	Phone: +1 732 923 4231
	Fax: +1 732 923 9804
	Email: btang@tellium.com
	Generated on: Thu Apr 25 12:58:02 2002		Requests for special distribution should be addressed to either the
			author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/