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

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