draft-ietf-mpls-generalized-cr-ldp-01.txt   draft-ietf-mpls-generalized-cr-ldp-02.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: September 2001 Lou Berger (Movaz Networks) Expiration Date: October 2001 Lou Berger (Movaz Networks)
Greg Bernstein (Ciena Corporation) Greg Bernstein (Ciena Corporation)
John Drake (Calient Networks) John Drake (Calient Networks)
Yanhe Fan (Axiowave Networks) Yanhe Fan (Axiowave Networks)
Kireeti Kompella (Juniper Networks, Inc.) Kireeti Kompella (Juniper Networks, Inc.)
Eric Mannie (EBONE) 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 (Jasmine Networks)
George Swallow (Cisco Systems) George Swallow (Cisco Systems)
Z. Bo Tang (Tellium, Inc.) Z. Bo Tang (Tellium, Inc.)
March 2001 April 2001
Generalized MPLS Signaling - CR-LDP Extensions Generalized MPLS Signaling - CR-LDP Extensions
draft-ietf-mpls-generalized-cr-ldp-01.txt draft-ietf-mpls-generalized-cr-ldp-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow http://www.ietf.org/1id-abstracts.html
Directory, see http://www.ietf.org/shadow.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to CR-LDP signaling required to This document describes extensions to CR-LDP signaling required to
support Generalized MPLS. Generalized MPLS extends MPLS to encompass support Generalized MPLS. Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or spatial switching (e.g. incoming port or fiber to outgoing port or
fiber). This document presents a CR-LDP specific description of the fiber). This document presents a CR-LDP specific description of the
extensions. An RSVP-TE specific description can be found in [GMPLS- extensions. An RSVP-TE specific description can be found in [GMPLS-
RSVP]. A generic functional description is presented in [GMPLS-SIG]. RSVP]. A generic functional description is presented in [GMPLS-SIG].
Contents Contents
1 Introduction .............................................. 3 1 Introduction .............................................. 3
2 Label Related Formats .................................... 3 2 Label Related Formats .................................... 3
2.1 Generalized Label Request ................................. 4 2.1 Generalized Label Request ................................. 3
2.1.1 Generalized Label Request with SONET/SDH Label Range ...... 4 2.1.1 Procedures ................................................ 4
2.1.2 Procedures ................................................ 4 2.1.2 Bandwidth Encoding ........................................ 5
2.1.3 Bandwidth Encoding ........................................ 5 2.2 Generalized Label ......................................... 5
2.2 Generalized Label ......................................... 6 2.2.1 Procedures ................................................ 5
2.2.1 Procedures ................................................ 6
2.3 Waveband Switching ........................................ 6 2.3 Waveband Switching ........................................ 6
2.3.1 Procedures ................................................ 7 2.3.1 Procedures ................................................ 6
2.4 Suggested Label ........................................... 8 2.4 Suggested Label ........................................... 7
2.5 Label Set ................................................. 8 2.5 Label Set ................................................. 7
2.5.1 Procedures ................................................ 8 2.5.1 Procedures ................................................ 7
3 Bidirectional LSPs ........................................ 9 3 Bidirectional LSPs ........................................ 8
3.1 Procedures ................................................ 10 3.1 Procedures ................................................ 9
4 Explicit Label Control .................................... 10 4 Notification on Label Error ............................... 9
4.1 Procedures ................................................ 11 5 Explicit Label Control .................................... 10
5 Protection TLV ............................................ 12 5.1 Procedures ................................................ 10
5.1 Procedures ................................................ 12 6 Protection TLV ............................................ 11
6 Acknowledgments ........................................... 12 6.1 Procedures ................................................ 12
7 Security Considerations ................................... 13 7 Acknowledgments ........................................... 12
8 References ................................................ 13 8 Security Considerations ................................... 12
9 Authors' Addresses ........................................ 13 9 References ................................................ 12
10 Authors' Addresses ........................................ 13
Changes from previous version: Changes from previous version:
o Revised label request o Removed SONET/SDH specifics.
o Moved protection flags to separate object o Added Acceptable Label Set
o Minor text cleanup
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
interfaces. RSVP-TE extensions can be found in [GMPLS-RSVP]. interfaces. RSVP-TE extensions can be found in [GMPLS-RSVP].
[GMPLS-SIG] should be viewed as a companion document to this [GMPLS-SIG] should be viewed as a companion document to this
document. The format of this document parallels [GMPLS-SIG]. It document. The format of this document parallels [GMPLS-SIG]. It
should be noted that the RSVP-TE specific version of Generalized MPLS should be noted that the RSVP-TE specific version of Generalized MPLS
includes RSVP specific support for rapid failure notification, see includes RSVP specific support for rapid failure notification, see
Section 4 [GMPLS-RSVP]. For CR-LDP there is not currently a similar Section 4 [GMPLS-RSVP]. For CR-LDP there is not currently a similar
mechanism. When a failure is detected it will be propagated with mechanism. When a failure is detected it will be propagated with
RELEASE/WITHDRAW messages radially outward from the point of failure. RELEASE/WITHDRAW messages radially outward from the point of failure.
Resources are to be released in this phase and actual resource Resources are to be released in this phase and actual resource
information is fed back to the source using the feedback mechanisms information may be fed back to the source using a feedback
of [FEEDBACK]. In this manner the source will have an accurate view mechanisms.
of available resources and can start rerouting much sooner.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Label Related Formats 2. Label Related Formats
This section defines formats for a generalized label request, a This section defines formats for a generalized label request, a
generalized label, support for waveband switching, suggested label generalized label, support for waveband switching, suggested label
and label sets. and label sets.
skipping to change at page 4, line 24 skipping to change at page 4, line 17
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| 0x0901 | Length | |U|F| 0x0901 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type | Reserved | G-PID | | LSP Enc. Type | Reserved | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [GMPLS-SIG] for a description of parameters.
2.1.1. Generalized Label Request with SONET/SDH Label Range 2.1.1. Procedures
The format of a Generalized Label Request with SONET/SDH label range
(in CR-LDP) 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| 0x0902 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type | Reserved | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RNC | Signal Type |Rsrved.| RGT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters.
2.1.2. Procedures
A node processing a REQUEST message containing a Generalized Label A node processing a REQUEST message containing a Generalized Label
Request must verify that the requested parameters can be satisfied by Request must verify that the requested parameters can be satisfied by
the incoming interface, the node and by the outgoing interface. The 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), 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 i.e., another class of switching. In either case, each parameter
must be checked. must be checked.
Note that local node policy dictates when tunnels may be used and 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 when they may be created. Local policy may allow for tunnels to be
skipping to change at page 5, line 23 skipping to change at page 4, line 46
problem/Unsupported Encoding" indication. problem/Unsupported Encoding" 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. 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 When an error message is not generated, normal processing occurs. In
the transit case this will typically result in a REQUEST message the transit case this will typically result in a REQUEST message
being propagated. In the egress case and PHP special case this will being propagated. In the egress case and PHP special case this will
typically result in a MAPPING message being generated. typically result in a MAPPING message being generated.
2.1.3. Bandwidth Encoding 2.1.2. Bandwidth Encoding
Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV. Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV.
See [GMPLS-SIG] for a definition of values to be used for specific 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 signal types. These values are set in the Peak and Committed Data
Rate fields of the Traffic Parameters TLV. Other bandwidth/service Rate fields of the Traffic Parameters TLV. Other bandwidth/service
related parameters in the TLV are ignored and carried transparently. related parameters in the TLV are ignored and carried transparently.
2.2. Generalized Label 2.2. Generalized Label
The format of a Generalized Label is: The format of a Generalized Label is:
skipping to change at page 6, line 19 skipping to change at page 5, line 28
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| 0x0902 | Length | |U|F| 0x0902 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | | Label |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters and encoding of See [GMPLS-SIG] for a description of parameters and encoding of
SDH, SONET, port, wavelength and other labels. labels.
2.2.1. Procedures 2.2.1. Procedures
The Generalized Label travels in the upstream direction in MAPPING The Generalized Label travels in the upstream direction in MAPPING
messages. messages.
The presence of both a generalized and normal label TLV in a 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 message is a protocol error and should treated as a malformed message
by the recipient. by the recipient.
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
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 (0x0903) 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
skipping to change at page 9, line 9 skipping to change at page 8, line 9
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 a CI-capable interface will On reception of a REQUEST message, the receiving node will restrict
restrict its choice of labels to one which is in the Label Set. The its choice of labels to one which is in the Label Set. Nodes capable
CI-capable receiver may also remove the Label Set prior to forwarding of performing label conversion may also remove the Label Set prior to
the REQUEST message. If the node is unable to pick a label from the forwarding the REQUEST message. If the node is unable to pick a
Label Set or if there is a problem parsing the Label_Set TLVs, then label from the Label Set or if there is a problem parsing the
the request is terminated and a NOTIFICATION message with a "Routing Label_Set TLVs, then the request is terminated and a NOTIFICATION
problem/Label Set" indication MUST be generated. It is a local matter message with a "Routing problem/Label Set" indication MUST be
if the Label Set is stored for later selection on the MAPPING or if generated. It is a local matter if the Label Set is stored for later
the selection is made immediately for propagation in the MAPPING. 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 On reception of a REQUEST message, the Label Set represented in the
Label Set represented in the message is compared against the set of message is compared against the set of available labels at the
available labels at the downstream interface and the resulting downstream interface and the resulting intersecting Label Set is
intersecting Label Set is forwarded in a REQUEST message. When the forwarded in a REQUEST message. When the resulting Label Set is
resulting Label Set is empty, the REQUEST must be terminated, and a empty, the REQUEST must be terminated, and a NOTIFICATION message,
NOTIFICATION message, and a "Routing problem/Label Set" indication and a "Routing problem/Label Set" indication MUST be generated. Note
MUST be generated. Note that intersection is based on the physical that intersection is based on the physical labels (actual
labels (actual wavelength/band values) which may have different wavelength/band values) which may have different logical values on
logical values on different links, as a result it is the different links, as a result it is the responsibility of the node to
responsibility of the node to map these values so that they have a map these values so that they have a consistent physical meaning, or
consistent physical meaning, or to drop the particular values from to drop the particular values from the set if no suitable logical
the set if no suitable logical label value exists. label value exists.
When processing a MAPPING message at an intermediate node, the label When processing a MAPPING message at an intermediate node, the label
propagated upstream MUST fall within the Label Set. propagated upstream MUST fall within the Label Set.
Note, on reception of a MAPPING message for an interface which is CI- Note, on reception of a MAPPING message a node that is incapable of
incapable it has no other choice than to use the same physical label performing label conversion has no other choice than to use the same
(wavelength/band) as received in the MAPPING. In this case, the use physical label (wavelength/band) as received in the MAPPING message.
and propagation of a Label Set will significantly reduce the chances In this case, the use and propagation of a Label Set will
that this allocation will fail when CI-incapable nodes are traversed. 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=0x0906 type=0x0906
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
receiver first verifies that the upstream label is acceptable. If receiver first verifies that the upstream label is acceptable. If
the label is not acceptable, the receiver MUST issue a NOTIFICATION the label is not acceptable, the receiver MUST issue a NOTIFICATION
message with a "Routing problem/Unacceptable label value" indication. 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 An intermediate node must also allocate a label on the outgoing
interface and establish internal data paths before filling in an interface and establish internal data paths before filling in an
outgoing Upstream Label and propagating the REQUEST message. If an outgoing Upstream Label and propagating the REQUEST message. If an
intermediate node is unable to allocate a label or internal intermediate node is unable to allocate a label or internal
resources, then it MUST issue a NOTIFICATION message with a "Routing resources, then it MUST issue a NOTIFICATION message with a "Routing
problem/Label allocation failure" indication. problem/Label allocation failure" indication.
Terminator nodes process REQUEST messages as usual, with the Terminator nodes process REQUEST messages as usual, with the
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. Explicit Label Control 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 0x0907. 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 is defined as follows: The Label ER-Hop 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| 0x901 | Length | |0|0| 0x0806 | 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.
4.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. The preceding ER-Hop must be strict. Up to two
label ER-Hops may be present, one for the downstream label and one label ER-Hops may be present, one for the downstream label and one
for the upstream label. The following SHOULD result in "Bad for the upstream label. The following 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.
skipping to change at page 12, line 5 skipping to change at page 11, line 27
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 the first ER-Hop an a received ER, then it SHOULD label ER-Hop is the the first ER-Hop an a received ER, then it SHOULD
be treated as a "Bad strict node" error. be treated as a "Bad strict node" error.
Procedures by which an LSR at the head-end of an LSP obtains the Procedures by which an LSR at the head-end of an LSP obtains the
information needed to construct the Label ER-Hop are outside the information needed to construct the Label ER-Hop are outside the
scope of this document. scope of this document.
5. Protection TLV 6. Protection TLV
The use of the Protection Object is optional. The object is included The use of the Protection TLV is optional. The TLV is included to
to indicate specific protection attributes of an LSP. indicate specific protection attributes of an LSP.
The format of Protection Flags Object is: The format of Protection Information TLV 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| TBA | Length | |U|F| 0x0908 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags| |S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [GMPLS-SIG] for a description of parameters.
5.1. Procedures 6.1. Procedures
Transit nodes processing a REQUEST message containing a Protection Transit nodes processing a REQUEST message containing a Protection
Object MUST verify that the requested protection can be satisfied by TLV MUST verify that the requested protection can be satisfied by the
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.
6. Acknowledgments 7. 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.
7. Security Considerations 8. Security Considerations
This draft introduce no new security considerations to [CR-LDP]. This draft introduce no new security considerations to [CR-LDP].
8. References 9. 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-04.txt, July, 2000. draft-ietf-mpls-cr-ldp-05.txt, Feb., 2001.
[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-00.txt, July 2000. draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001.
[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in CR-LDP", Internet Draft,
draft-ietf-mpls-crldp-unnum-01.txt, February 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-01.txt,
February 2001. February 2001.
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft, Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-02.txt, draft-ietf-mpls-generalized-signaling-02.txt,
February 2001. February 2001.
[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.
[FEEDBACK] P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, 10. Authors' Addresses
"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 Peter Ashwood-Smith
Nortel Networks Corp. Nortel Networks Corp.
P.O. Box 3511 Station C, P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7
Canada Canada
Phone: +1 613 763 4534 Phone: +1 613 763 4534
Email: petera@nortelnetworks.com Email: petera@nortelnetworks.com
Ayan Banerjee Ayan Banerjee
skipping to change at page 16, line 4 skipping to change at page 15, line 26
Phone: +1 408 895 5030 Phone: +1 408 895 5030
Fax: +1 408 895 5050 Fax: +1 408 895 5050
Email: vsharma@jasminenetworks.com 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 Mar 2 14:09:47 EST 2001 Generated on: Mon Apr 16 19:49:24 EDT 2001
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/