Network Working Group        Peter Ashwood-Smith (Nortel Networks Corp.)
Internet Draft                          Ayan Banerjee (Calient Networks)
Expiration Date: May September 2001              Lou Berger (Movaz Networks)
Greg Bernstein (Ciena Corporation)
John Drake (Calient Networks)
Yanhe Fan (Axiowave Networks)
Kireeti Kompella (Juniper Networks, Inc.)
Eric Mannie (GTS) (EBONE)
Jonathan P. Lang (Calient Networks)
Bala Rajagopalan (Tellium, Inc.)
Yakov Rekhter (Cisco Systems) (Juniper Networks, Inc.)
Debanjan Saha (Tellium, Inc.)
Vishal Sharma (Tellabs) (Jasmine Networks)
George Swallow (Cisco Systems)
Z. Bo Tang (Tellium, Inc.)
Generalized MPLS Signaling - CR-LDP Extensions
draft-ietf-mpls-generalized-cr-ldp-00.txt
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.
The list of
To view the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list status of Internet-Draft any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow Directories can be accessed at
Directory, see http://www.ietf.org/shadow.html.
This document describes extensions to CR-LDP signaling required to
support Generalized MPLS.  Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET 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.  An RSVP-TE specific description can be found in [GMPLS-
RSVP].  A generic functional description is presented in [GMPLS-SIG].
1      Introduction  ..............................................   3
2      Label Related Formats   ....................................   3
2.1    Generalized Label Request  .................................   4
2.1.1  Generalized Label Request with SONET/SDH Label Range  ......   4
2.1.2  Procedures  ................................................   4
2.1.3  Bandwidth Encoding  ........................................   5
2.2    Generalized Label  .........................................   6
2.3    Waveband Switching  ........................................   6
2.4    Suggested Label  ...........................................   8
2.5    Label Set  .................................................   8
3      Bidirectional LSPs  ........................................   9
3.1    Procedures  ................................................  10
4      Explicit Label Control  ....................................  10
5      Protection TLV  ............................................  12
6      Acknowledgments  ...........................................  12
7      Security Considerations  ...................................  12
8      References  ................................................  12
9      Authors' Addresses  ........................................  13
Changes from previous version:
o  Moved protocol specific details into two documents, one for RSVP-TE
and one for CR-LDP.  Revised label request
o  Clarified Label Set  Moved protection flags to separate object
o  Minor text cleanup
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 is fed back to the source using the feedback mechanisms
of [FEEDBACK].  In this manner the source will have an accurate view
of available resources and can start rerouting much sooner.
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 format of a Generalized Label Request is:
0                   1                   2                     3
|U|F|          0x0901           |             Length            |
| LSP Enc. Type |Link Prot.Flags| |    Reserved   |             G-PID             |
See [GMPLS-SIG] for a description of parameters.
2.1.1. Generalized Label Request with SONET/SDH Label Range
The format of a Generalized Label Request with SONET/SDH label range
(in CR-LDP) is:
| LSP Enc. Type |Link Prot.Flags|             G-PID             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  RGT    Reserved   |   RT             G-PID             |    Reserved
|             RNC               |  Signal Type  |Rsrved.|  RGT  |
2.1.2. Procedures
A node processing the a REQUEST message containing the 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.
Transit nodes MUST verify that the outgoing interface or tunnel can
support the requested Link Protection Flags.  If it cannot, the node
MUST generate a NOTIFICATION message, with a "Routing
problem/Unsupported Link Protection" 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.
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.3. 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:
|U|F|          0x0902           |      Length                   |
|                             Label                             |
|                              ...                              |
See [GMPLS-SIG] for a description of parameters and encoding of
SDH, SONET, port, wavelength and other labels.
The Generalized Label travels in the upstream direction in MAPPING
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
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.
2.3. Waveband Switching
Waveband switching uses the same format as the generalized label, see
section 2.2.  The type (0x0903) is assigned for the Waveband Label.
In the context of waveband switching, the generalized label has the
following format:
|                          Waveband Id                          |
|                          Start Label                          |
|                           End Label                           |
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 which 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.
2.5. Label Set
The format of a Label_Set is:
|U|F|  type=0x0905              |      Length                   |
|            Reserved           |  Label Type   |    Action     |
|                          Subchannel 1                         |
:                               :                               :
|                          Subchannel N                         |
Label Type: 8 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.
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
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 a CI-capable interface will
restrict its choice of labels to one which is in the Label Set.  The
CI-capable receiver 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 or if
the selection is made immediately for propagation in the MAPPING.
On reception of a REQUEST message for a CI-incapable interface, 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 for an interface which is CI-
incapable it has no other choice than to use the same physical label
(wavelength/band) as received in the MAPPING. In this case, the use
and propagation of a Label Set will significantly reduce the chances
that this allocation will fail when CI-incapable nodes are traversed.
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=0x0906
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.
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. Explicit Label Control
The Label ER-Hop is defined as follows:
|0|0|          0x901            |      Length                   |
|L|U|      Reserved             |   Label                       |
|                       Label (continued)                       |
See [GMPLS-SIG] for a description of L, U and Label parameters.
Specifies the length of the value field in bytes.
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.  The preceding ER-Hop must be strict.  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
-  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 it's 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 MAPPING 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
MAPPING 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 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.
5. Protection TLV
The use of the Protection Object is optional.  The object is included
to indicate specific protection attributes of an LSP.
The format of Protection Flags Object  is:
|U|F|          TBA              |             Length            |
|S|                  Reserved                       | Link Flags|
Transit nodes processing a REQUEST message containing a Protection
Object 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.
6. 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.
7. Security Considerations
This draft introduce no new security considerations to [CR-LDP].
[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
draft-ietf-mpls-cr-ldp-04.txt, July, 2000.
[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
MPLS TE", Internet Draft,
draft-ietf-mpls-lsp-hierarchy-00.txt, July 2000.
[GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
RSVP-TE Extensions", Internet Draft,
draft-ietf-mpls-generalized-rsvp-te-00.txt,
February 2001.
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-01.txt,
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[FEEDBACK] P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki,
"Improving Topology Data Base Accuracy With LSP Feedback
via CR-LDP", Internet Draft, draft-ietf-mpls-te-feed-00.txt.
9. Authors' Addresses
Peter Ashwood-Smith
Nortel Networks Corp.
P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7
Phone:  +1 613 763 4534
Email:  petera@nortelnetworks.com
Ayan Banerjee
Calient Networks
5853 Rue Ferrari
Phone:  +1 408 972-3645
Email:  abanerjee@calient.net
Lou Berger
Movaz Networks Networks, Inc.
McLean VA, 22102
Phone:  +1 301 468 9228 703 847-1801
Email:  lberger@movaz.com
Greg Bernstein
Ciena Corporation
10480 Ridgeview Court
Email:  greg@ciena.com
Email:  jdrake@calient.net
Yanhe Fan
Axiowave Networks, Inc.
100 Nickerson Road
Phone:  +1 508 460 6969 Ext. 627
Email:  yfan@axiowave.com
Juniper Networks, Inc.
Email:  kireeti@juniper.net
Jonathan P. Lang
25 Castilian
Email:  jplang@calient.net
Eric Mannie
EBONE
Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium
Phone:  +32 2 658 56 52
Fax:    +32 2 658 51 18
Email:  eric.mannie@gts.com  eric.mannie@ebone.com
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
Oceanport, NJ 07757-0901
Fax:    +1 732 923 9804
Email:  braja@tellium.com
Yakov Rekhter
Email:  yakov@cisco.com  yakov@juniper.net
Debanjan Saha
Tellium Optical Systems
Email:  dsaha@tellium.com
Vishal Sharma
Tellabs Research Center
One Kendall Square
Bldg. 100, Ste. 121
Jasmine Networks, Inc.
3061 Zanker Road, Suite B
Phone:  +1 617 577 8760 408 895 5030
Email:  Vishal.Sharma@tellabs.com vsharma@jasminenetworks.com
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Voice:  +1 978 244 8143
Email:  swallow@cisco.com
Z. Bo Tang
Email:  btang@tellium.com
Generated on: Fri Mar 2 14:09:47 EST 2001