draft-ietf-mpls-generalized-cr-ldp-03.txt   draft-ietf-mpls-generalized-cr-ldp-04.txt 
Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.)
Internet Draft Ayan Banerjee (Calient Networks) Internet Draft Ayan Banerjee (Calient Networks)
Expiration Date: November 2001 Lou Berger (Movaz Networks) Expiration Date: January 2002 Lou Berger (Movaz Networks)
Greg Bernstein (Ciena Corporation) Greg Bernstein (Ciena Corporation)
John Drake (Calient Networks) John Drake (Calient Networks)
Yanhe Fan (Axiowave Networks) Yanhe Fan (Axiowave Networks)
Don Fedyk (Nortel Networks Corp.)
Kireeti Kompella (Juniper Networks, Inc.) Kireeti Kompella (Juniper Networks, Inc.)
Eric Mannie (EBONE) Eric Mannie (EBONE)
Jonathan P. Lang (Calient Networks) Jonathan P. Lang (Calient Networks)
Bala Rajagopalan (Tellium, Inc.) Bala Rajagopalan (Tellium, Inc.)
Yakov Rekhter (Juniper Networks, Inc.) Yakov Rekhter (Juniper Networks, Inc.)
Debanjan Saha (Tellium, Inc.) Debanjan Saha (Tellium, Inc.)
Vishal Sharma (Jasmine Networks) Vishal Sharma (Jasmine Networks)
George Swallow (Cisco Systems) George Swallow (Cisco Systems)
Z. Bo Tang (Tellium, Inc.) Z. Bo Tang (Tellium, Inc.)
May 2001 July 2001
Generalized MPLS Signaling - CR-LDP Extensions Generalized MPLS Signaling - CR-LDP Extensions
draft-ietf-mpls-generalized-cr-ldp-03.txt draft-ietf-mpls-generalized-cr-ldp-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the current status of any Internet-Draft, please check the To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html. Directory, see http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to 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 ................................. 3 2.1 Generalized Label Request ................................. 4
2.1.1 Procedures ................................................ 4 2.1.1 Procedures ................................................ 4
2.1.2 Bandwidth Encoding ........................................ 5 2.1.2 Bandwidth Encoding ........................................ 5
2.2 Generalized Label ......................................... 5 2.2 Generalized Label ......................................... 5
2.2.1 Procedures ................................................ 5 2.2.1 Procedures ................................................ 5
2.3 Waveband Switching ........................................ 6 2.3 Waveband Switching ........................................ 6
2.3.1 Procedures ................................................ 6 2.3.1 Procedures ................................................ 6
2.4 Suggested Label ........................................... 7 2.4 Suggested Label ........................................... 7
2.5 Label Set ................................................. 7 2.5 Label Set ................................................. 7
2.5.1 Procedures ................................................ 7 2.5.1 Procedures ................................................ 8
3 Bidirectional LSPs ........................................ 8 3 Bidirectional LSPs ........................................ 9
3.1 Procedures ................................................ 9 3.1 Procedures ................................................ 9
4 Notification on Label Error ............................... 9 4 Notification on Label Error ............................... 10
5 Explicit Label Control .................................... 10 5 Explicit Label Control .................................... 10
5.1 Procedures ................................................ 10 5.1 Procedures ................................................ 11
6 Protection TLV ............................................ 11 6 Protection TLV ............................................ 12
6.1 Procedures ................................................ 12 6.1 Procedures ................................................ 12
7 Acknowledgments ........................................... 12 7 Administrative Status Information ......................... 12
8 Security Considerations ................................... 12 7.1 Admin Status Object ....................................... 12
9 References ................................................ 12 7.2 REQUEST and MAPPING Message Procedures .................... 13
10 Authors' Addresses ........................................ 13 7.3 Modification Message Procedures ........................... 13
7.3.1 Deletion procedure ........................................ 14
7.3.2 Compatibility ............................................. 14
7.3.3 Notify Message Procedures ................................. 14
8 Control Channel Separation ................................ 15
8.1 Interface Identification .................................. 15
8.2 Procedures ................................................ 16
9 Fault Handling ......................................... 16
10 Acknowledgments ........................................... 16
11 Security Considerations ................................... 17
12 References ................................................ 17
13 Authors' Addresses ........................................ 17
Changes from previous version: Changes from previous version:
o Fixed Label Set format o Fixed Label Set format (for LDP)
o Removed unassigned values
o Added Switching type of LSP being requested
o Added Administrative Status Information (based on last call comments)
o Added section on Control Channel Separation
(based on last call comments)
Covers:
- Separation of control and data channels
1. Introduction 1. Introduction
Generalized MPLS extends MPLS from supporting packet (PSC) interfaces Generalized MPLS extends MPLS from supporting packet (PSC) interfaces
and switching to include support of three new classes of interfaces and switching to include support of three new classes of interfaces
and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and
Fiber-Switch (FSC). A functional description of the extensions to Fiber-Switch (FSC). A functional description of the extensions to
MPLS signaling needed to support the new classes of interfaces and MPLS signaling needed to support the new classes of interfaces and
switching is provided in [GMPLS-SIG]. This document presents CR-LDP switching is provided in [GMPLS-SIG]. This document presents CR-LDP
specific formats and mechanisms needed to support all four classes of specific formats and mechanisms needed to support all four classes of
skipping to change at page 4, line 10 skipping to change at page 4, line 17
A REQUEST message SHOULD contain as specific an LSP Encoding Type as A REQUEST message SHOULD contain as specific an LSP Encoding Type as
possible to allow the maximum flexibility in switching by transit possible to allow the maximum flexibility in switching by transit
LSRs. A Generalized Label Request TLV is set by the ingress node, LSRs. A Generalized Label Request TLV is set by the ingress node,
transparently passed by transit nodes, and used by the egress node. transparently passed by transit nodes, and used by the egress node.
The format of a Generalized Label Request is: The format of a Generalized Label Request 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| 0x0901 | Length | |U|F| Type (TBA by IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type | Reserved | G-PID | | LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [GMPLS-SIG] for a description of parameters.
2.1.1. Procedures 2.1.1. Procedures
A node processing a 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),
skipping to change at page 5, line 21 skipping to change at page 5, line 28
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:
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| Type (TBA by IANA) | 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
labels. labels.
2.2.1. Procedures 2.2.1. Procedures
skipping to change at page 6, line 16 skipping to change at page 6, line 21
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
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| 0x0903 | Length | |U|F| Type (TBA by IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id | | Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label | | Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label | | End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [GMPLS-SIG] for a description of parameters.
skipping to change at page 6, line 39 skipping to change at page 6, line 44
The procedures defined in Section 2.2.1 apply to waveband switching. The procedures defined in Section 2.2.1 apply to waveband switching.
This includes generating a NOTIFICATION message with a "Routing This includes generating a NOTIFICATION message with a "Routing
problem/MPLS label allocation failure" indication if any of the label problem/MPLS label allocation failure" indication if any of the label
fields are unrecognized or unacceptable. fields are unrecognized or unacceptable.
Additionally, when a waveband is switched to another waveband, it is Additionally, when a waveband is switched to another waveband, it is
possible that the wavelengths within the waveband will be mirrored possible that the wavelengths within the waveband will be mirrored
about a center frequency. When this type of switching is employed, about a center frequency. When this type of switching is employed,
the start and end label in the waveband label TLV MUST be flipped 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 before forwarding the label TLV with the new waveband Id. In this
manner an egress/ingress LSR which receives a waveband label which manner an egress/ingress LSR that receives a waveband label which has
has these values inverted, knows that it must also invert its egress these values inverted, knows that it must also invert its egress
association to pick up the proper wavelengths. Without this association to pick up the proper wavelengths. Without this
mechanism and with an odd number of mirrored switching operations, mechanism and with an odd number of mirrored switching operations,
the egress LSRs will not know that an input wavelength of say L1 will the egress LSRs will not know that an input wavelength of say L1 will
emerge from the waveband tunnel as L100. emerge from the waveband tunnel as L100.
This operation MUST be performed in both directions when a This operation MUST be performed in both directions when a
bidirectional waveband tunnel is being established. bidirectional waveband tunnel is being established.
2.4. Suggested Label 2.4. Suggested Label
skipping to change at page 8, line 10 skipping to change at page 8, line 20
labels/subchannels can be added to or excluded from a Label Set via labels/subchannels can be added to or excluded from a Label Set via
Action two (2) and three (3) TLVs respectively. When the Label_Set Action two (2) and three (3) TLVs respectively. When the Label_Set
TLVs only list labels/subchannels to exclude, this implies that all TLVs only list labels/subchannels to exclude, this implies that all
other labels are acceptable. other labels are acceptable.
The absence of any Label_Set TLVs implies that all labels are The absence of any Label_Set TLVs implies that all labels are
acceptable. A Label Set is included when a node wishes to restrict acceptable. A Label Set is included when a node wishes to restrict
the label(s) that may be used downstream. the label(s) that may be used downstream.
On reception of a REQUEST message, the receiving node will restrict On reception of a REQUEST message, the receiving node will restrict
its choice of labels to one which is in the Label Set. Nodes capable its choice of labels to one, which is in the Label Set. Nodes
of performing label conversion may also remove the Label Set prior to capable of performing label conversion may also remove the Label Set
forwarding the REQUEST message. If the node is unable to pick a prior to forwarding the REQUEST message. If the node is unable to
label from the Label Set or if there is a problem parsing the pick a label from the Label Set or if there is a problem parsing the
Label_Set TLVs, then the request is terminated and a NOTIFICATION Label_Set TLVs, then the request is terminated and a NOTIFICATION
message with a "Routing problem/Label Set" indication MUST be message with a "Routing problem/Label Set" indication MUST be
generated. It is a local matter if the Label Set is stored for later generated. It is a local matter if the Label Set is stored for later
selection on the MAPPING or if the selection is made immediately for selection on the MAPPING or if the selection is made immediately for
propagation in the MAPPING. propagation in the MAPPING.
On reception of a REQUEST message, the Label Set represented in the On reception of a REQUEST message, the Label Set represented in the
message is compared against the set of available labels at the message is compared against the set of available labels at the
downstream interface and the resulting intersecting Label Set is downstream interface and the resulting intersecting Label Set is
forwarded in a REQUEST message. When the resulting Label Set is forwarded in a REQUEST message. When the resulting Label Set is
skipping to change at page 10, line 19 skipping to change at page 10, line 36
problem/Unacceptable label value" indication. The absence of problem/Unacceptable label value" indication. The absence of
Acceptable_Label_Set TLVs does not have any specific meaning. Acceptable_Label_Set TLVs does not have any specific meaning.
5. Explicit Label Control 5. Explicit Label Control
The Label ER-Hop is defined as follows: The Label ER-Hop 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| 0x0806 | Length | |0|0| Type (TBA by IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|U| Reserved | Label | |L|U| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label (continued) | | Label (continued) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of L, U and Label parameters. See [GMPLS-SIG] for a description of L, U and Label parameters.
5.1. Procedures 5.1. Procedures
skipping to change at page 10, line 47 skipping to change at page 11, line 23
- If the first label ER-Hop is not preceded by a ER-Hop - If the first label ER-Hop is not preceded by a ER-Hop
containing an IP address, or a interface identifier containing an IP address, or a interface identifier
[MPLS-UNNUM], associated with an output link. [MPLS-UNNUM], associated with an output link.
- For a label ER-Hop to follow a ER-Hop that has the L-bit - For a label ER-Hop to follow a ER-Hop that has the L-bit
set set
- On unidirectional LSP setup, for there to be a label ER-Hop - On unidirectional LSP setup, for there to be a label ER-Hop
with the U-bit set with the U-bit set
- For there to be two label ER-Hops with the same U-bit values - For there to be two label ER-Hops with the same U-bit values
To support the label ER-Hop, a node must check to see if the ER-Hop To support the label ER-Hop, a node must check to see if the ER-Hop
following it's associate address/interface is a label ER-Hop. If it following its associate address/interface is a label ER-Hop. If it
is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops
for bidirectional LSPs. If the U-bit of the ER-Hop being examined is for bidirectional LSPs. If the U-bit of the ER-Hop being examined is
clear (0), then value of the label is copied into a new Label_Set clear (0), then value of the label is copied into a new Label_Set
TLV. This Label_Set TLV MUST be included on the corresponding TLV. This Label_Set TLV MUST be included on the corresponding
outgoing MAPPING message. outgoing MAPPING message.
If the U-bit of the ER-Hop being examined is set (1), then value of If the U-bit of the ER-Hop being examined is set (1), then value of
the label is label to be used for upstream traffic associated with the label is label to be used for upstream traffic associated with
the bidirectional LSP. If this label is not acceptable, a "Bad the bidirectional LSP. If this label is not acceptable, a "Bad
EXPLICIT_ROUTE" error SHOULD be generated. If the label is EXPLICIT_ROUTE" error SHOULD be generated. If the label is
acceptable, the label is copied into a new Upstream Label TLV. This acceptable, the label is copied into a new Upstream Label TLV. This
Upstream Label TLV MUST be included on the corresponding outgoing Upstream Label TLV MUST be included on the corresponding outgoing
MAPPING message. MAPPING message.
After processing, the label ER-Hops are removed from the ER. After processing, the label ER-Hops are removed from the ER.
Note an implication of the above procedures is that the label ER-Hop Note an implication of the above procedures is that the label ER-Hop
should never be the first ER-Hop in a newly received message. If the should never be the first ER-Hop in a newly received message. If the
label ER-Hop is the the first ER-Hop an a received ER, then it SHOULD label ER-Hop is the first ER-Hop an a received ER, then it SHOULD be
be treated as a "Bad strict node" error. treated as a "Bad strict node" error.
Procedures by which an LSR at the head-end of an LSP obtains the Procedures by which an LSR at the head-end of an LSP obtains the
information needed to construct the Label ER-Hop are outside the information needed to construct the Label ER-Hop are outside the
scope of this document. scope of this document.
6. Protection TLV 6. Protection TLV
The use of the Protection TLV is optional. The TLV is included to The use of the Protection TLV is optional. The TLV is included to
indicate specific protection attributes of an LSP. indicate specific protection attributes of an LSP.
The format of Protection Information TLV 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| 0x0908 | Length | |U|F| Type (TBA by IANA) | 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.
6.1. Procedures 6.1. Procedures
Transit nodes processing a REQUEST message containing a Protection Transit nodes processing a REQUEST message containing a Protection
TLV MUST verify that the requested protection can be satisfied by the TLV MUST verify that the requested protection can be satisfied by the
outgoing interface or tunnel (FA). If it cannot, the node MUST outgoing interface or tunnel (FA). If it cannot, the node MUST
generate a NOTIFICATION message, with a "Routing problem/Unsupported generate a NOTIFICATION message, with a "Routing problem/Unsupported
Link Protection" indication. Link Protection" indication.
7. Acknowledgments 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 object is carried in REQUEST and MAPPING messages to indicate the
administrative state of an LSP. In the second, the TLV is carried in
a REQUEST and MAPPING message with the modification bit set to
request a change to the administrative state of an LSP.
7.1. Admin Status Object
The use of the Admin Status TLV is optional.
The format of the TLV is:
The format of Admin Status 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The U Bit Should be set to 1. The F bit should be set to 1.
See [GMPLS-SIG] for a description of parameters.
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. Status information is processed by each node
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.
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.
Egress 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.
The subsequent MAPPING message MUST carry back the Admin Status TLV
if the corresponding request message had the Admin Status TLV.
7.3. Modification Message Procedures
Subsequent messaging Admin Status messaging is all performed by
REQUEST and MAPPING Messages using the modification action indicator
flag. The ingress may begin the propagation of a Message with an
Admin Status TLV. Each subsequent node propagates the REQUEST with
the Admin Status TLV from the ingress to the egress and then the
egress node returns the MAPPING messages back Upstream carrying the
Admin Status TLV. A modification message of this type would
typically only carry the mandatory CR-LDP TLVs and the Admin Status
TLV.
7.3.1. Deletion procedure
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:
The ingress node precedes an LSP deletion by inserting an Admin
Status TLV in a REQUEST Message with the modification action
indicator set to modify message and setting the Down (D) bit.
Transit and egress nodes process the Admin Status TLV as described
above.
Upon receiving the Admin Status TLV with the Down (D) bit set in the
MAPPING message with the modification action indicator set to modify
the ingress node sends a RELEASE message downstream to remove the LSP
and normal CR-LDP processing takes place.
7.3.2. Compatibility
It is possible that some nodes along an LSP will not support the
Admin Status TLV. In the case of a non-supporting transit node, the
TLV will pass through the node unmodified and normal processing can
continue. In the case of a non-supporting egress node, the Admin
Status TLV may not be reflected back in the MAPPING Message. In this
case, the ingress SHOULD continue to set the contents of the object
normally but, when processing an LSP deletion, it MUST NOT wait for
an updated Admin Status TLV in a MAPPING message before issuing a
RELEASE/WITHDRAW message.
7.3.3. Notify Message Procedures
Intermediate and egress nodes may trigger the setting of
administrative status before a deletion via the use of REQUEST
messages. To accomplish this, an intermediate or egress node
generates a REQUEST message with the modification action indicator
set to modify and with the corresponding upstream. The Admin Status
TLV MUST be included in the message, with the Down (D) bit set.
An ingress node receiving a MAPPING message containing an Admin
Status TLV with the Down (D) bit set, SHOULD initiate the deletion
procedure described in the previous section.
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 [MPLS-BUNDLE] the upstream
interface is implied by the downstream interface. For bundling, the
path sender explicitly identifies the component interface used in
each direction.
The format of 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID TLVS see [GMLPS-SIG] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The U Bit Should be set to 0. The F bit should be set to 0.
See [GMPLS-SIG] for a description of parameters.
See [CR-LDP] 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 forward channel
MUST be indicated. For a bidirectional LSP that use bundled links, a
reverse channel MUST be indicated. Data channels are specified from
the viewpoint of the sender of the REQUEST message.
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
this 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 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.
8. Security Considerations 11. Security Considerations
This draft introduce no new security considerations to [CR-LDP]. This draft introduce no new security considerations to [CR-LDP].
9. References 12. References
[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
draft-ietf-mpls-cr-ldp-05.txt, Feb., 2001. 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-02.txt, Feb., 2001. draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001.
[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in CR-LDP", Internet Draft, in CR-LDP", Internet Draft,
draft-ietf-mpls-crldp-unnum-01.txt, February 2001 draft-ietf-mpls-crldp-unnum-01.txt, February 2001
skipping to change at page 13, line 10 skipping to change at page 17, line 31
[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.
[LDP-FT] Farrel, A. et al, "Fault Tolerance for LDP
and CR-LDP", Internet Draft,
draft-ietf-mpls-ldp-ft-02.txt,
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.
10. Authors' Addresses 13. Authors' Addresses
Peter Ashwood-Smith Peter Ashwood-Smith
Nortel Networks Corp. Nortel Networks Corp.
P.O. Box 3511 Station C, P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7
Canada Canada
Phone: +1 613 763 4534 Phone: +1 613 763 4534
Email: petera@nortelnetworks.com Email: petera@nortelnetworks.com
Ayan Banerjee Ayan Banerjee
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
Phone: +1 408 972-3645 Phone: +1 408 972-3645
Email: abanerjee@calient.net Email: abanerjee@calient.net
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
skipping to change at page 14, line 4 skipping to change at page 18, line 32
Cupertino, CA 94014 Cupertino, CA 94014
Phone: +1 408 366 4713 Phone: +1 408 366 4713
Email: greg@ciena.com Email: greg@ciena.com
John Drake John Drake
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
Phone: +1 408 972 3720 Phone: +1 408 972 3720
Email: jdrake@calient.net Email: jdrake@calient.net
Yanhe Fan Yanhe Fan
Axiowave Networks, Inc. Axiowave Networks, Inc.
100 Nickerson Road 100 Nickerson Road
Marlborough, MA 01752 Marlborough, MA 01752
Phone: +1 508 460 6969 Ext. 627 Phone: +1 508 460 6969 Ext. 627
Email: yfan@axiowave.com Email: yfan@axiowave.com
Don Fedyk
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 Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net Email: kireeti@juniper.net
Jonathan P. Lang Jonathan P. Lang
Calient Networks Calient Networks
25 Castilian 25 Castilian
Goleta, CA 93117 Goleta, CA 93117
skipping to change at line 642 skipping to change at line 833
Z. Bo Tang Z. Bo Tang
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4231 Phone: +1 732 923 4231
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: btang@tellium.com Email: btang@tellium.com
Generated on: Tue May 1 16:25:40 EDT 2001 Generated on: Fri Jul 20 16:49:49 EDT 2001
 End of changes. 

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