draft-ietf-mpls-rfc3036bis-02.txt   draft-ietf-mpls-rfc3036bis-03.txt 
Network Working Group Loa Andersson Network Working Group Loa Andersson
Internet Draft Ina Minei Internet Draft Ina Minei
Expiration Date: January 2006 Bob Thomas Expiration Date: April 2006 Bob Thomas
Editors Editors
July 2005 October 2005
LDP Specification LDP Specification
draft-ietf-mpls-rfc3036bis-02.txt draft-ietf-mpls-rfc3036bis-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 8 skipping to change at page 2, line 8
This document is produced as part of advancing the LDP specification This document is produced as part of advancing the LDP specification
to draft standard status. The LDP specification was originally to draft standard status. The LDP specification was originally
published as RFC 3036 in January 2001. It was produced by the MPLS published as RFC 3036 in January 2001. It was produced by the MPLS
working of the IETF and was jointly authored by Loa Andersson, Paul working of the IETF and was jointly authored by Loa Andersson, Paul
Doolan, Nancy Feldman, Andre Fredette and Bob Thomas. Doolan, Nancy Feldman, Andre Fredette and Bob Thomas.
Abstract Abstract
The architecture for Multi Protocol Label Switching (MPLS) is The architecture for Multi Protocol Label Switching (MPLS) is
described in RFC 3031. A fundamental concept in MPLS is that two described in RFC 3031 [RFC3031]. A fundamental concept in MPLS is
Label Switching Routers (LSRs) must agree on the meaning of the that two Label Switching Routers (LSRs) must agree on the meaning of
labels used to forward traffic between and through them. This common the labels used to forward traffic between and through them. This
understanding is achieved by using a set of procedures, called a common understanding is achieved by using a set of procedures, called
label distribution protocol, by which one LSR informs another of a label distribution protocol, by which one LSR informs another of
label bindings it has made. This document defines a set of such label bindings it has made. This document defines a set of such
procedures called LDP (for Label Distribution Protocol) by which LSRs procedures called LDP (for Label Distribution Protocol) by which LSRs
distribute labels to support MPLS forwarding along normally routed distribute labels to support MPLS forwarding along normally routed
paths. paths.
Table of Contents Table of Contents
Source of this document ............................... 1 Source of this document ............................... 1
1 LDP Overview .......................................... 7 1 LDP Overview .......................................... 7
1.1 LDP Peers ............................................. 8 1.1 LDP Peers ............................................. 8
skipping to change at page 18, line 15 skipping to change at page 18, line 15
c. If LSR1 receives a KeepAlive message, LSR2 has accepted its c. If LSR1 receives a KeepAlive message, LSR2 has accepted its
proposed session parameters. proposed session parameters.
d. When LSR1 has received both an acceptable Initialization d. When LSR1 has received both an acceptable Initialization
message and a KeepAlive message the session is operational message and a KeepAlive message the session is operational
from LSR1's point of view. from LSR1's point of view.
Until the LDP session is established, no other messages Until the LDP session is established, no other messages
except those listed in the procedures above may be except those listed in the procedures above may be
exchanged, and the rules for processing the U-bit in LDP exchanged, and the rules for processing the U-bit in LDP
messages are overridden. messages are overridden. If a message other than those
listed in the procedures above is received, a Shutdown msg
MUST be tranmitted and the transport connection MUST be
closed.
It is possible for a pair of incompatibly configured LSRs that It is possible for a pair of incompatibly configured LSRs that
disagree on session parameters to engage in an endless sequence disagree on session parameters to engage in an endless sequence
of messages as each NAKs the other's Initialization messages with of messages as each NAKs the other's Initialization messages with
Error Notification messages. Error Notification messages.
An LSR must throttle its session setup retry attempts with an An LSR MUST throttle its session setup retry attempts with an
exponential backoff in situations where Initialization messages exponential backoff in situations where Initialization messages
are being NAK'd. It is also recommended that an LSR detecting are being NAK'd. It is also recommended that an LSR detecting
such a situation take action to notify an operator. such a situation take action to notify an operator.
The session establishment setup attempt following a NAK'd Ini- The session establishment setup attempt following a NAK'd Ini-
tialization message must be delayed no less than 15 seconds, and tialization message must be delayed no less than 15 seconds, and
subsequent delays must grow to a maximum delay of no less than 2 subsequent delays must grow to a maximum delay of no less than 2
minutes. The specific session establishment action that must be minutes. The specific session establishment action that must be
delayed is the attempt to open the session transport connection delayed is the attempt to open the session transport connection
by the LSR playing the active role. by the LSR playing the active role.
skipping to change at page 34, line 30 skipping to change at page 34, line 30
| | | |
| Value | | Value |
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit U bit
Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear
(=0), a notification must be returned to the message originator (=0), a notification MUST be returned to the message originator
and the entire message must be ignored; if U is set (=1), the and the entire message MUST be ignored; if U is set (=1), the
unknown TLV is silently ignored and the rest of the message is unknown TLV MUST be silently ignored and the rest of the message
processed as if the unknown TLV did not exist. The sections fol- processed as if the unknown TLV did not exist. The sections fol-
lowing that define TLVs specify a value for the U-bit. lowing that define TLVs specify a value for the U-bit.
F bit F bit
Forward unknown TLV bit. This bit applies only when the U bit is Forward unknown TLV bit. This bit applies only when the U bit is
set and the LDP message containing the unknown TLV is to be for- set and the LDP message containing the unknown TLV is to be for-
warded. If F is clear (=0), the unknown TLV is not forwarded with warded. If F is clear (=0), the unknown TLV is not forwarded with
the containing message; if F is set (=1), the unknown TLV is for- the containing message; if F is set (=1), the unknown TLV is for-
warded with the containing message. The sections following that warded with the containing message. The sections following that
define TLVs specify a value for the F-bit. By setting both the U define TLVs specify a value for the F-bit. By setting both the U
skipping to change at page 37, line 37 skipping to change at page 37, line 37
this case the Prefix itself is zero octets). this case the Prefix itself is zero octets).
Prefix Prefix
An address prefix encoded according to the Address Family An address prefix encoded according to the Address Family
field, whose length, in bits, was specified in the PreLen field, whose length, in bits, was specified in the PreLen
field, padded to a byte boundary. field, padded to a byte boundary.
3.4.1.1. FEC Procedures 3.4.1.1. FEC Procedures
If in decoding a FEC TLV an LSR encounters a FEC Element with an If in decoding a FEC TLV an LSR encounters a FEC Element with an
Address Family it does not support, it should stop decoding the FEC Address Family it does not support, it SHOULD stop decoding the FEC
TLV, abort processing the message containing the TLV, and send an TLV, abort processing the message containing the TLV, and send an
"Unsupported Address Family" Notification message to its LDP peer "Unsupported Address Family" Notification message to its LDP peer
signaling an error. signaling an error.
If it encounters a FEC Element type it cannot decode, it should stop If it encounters a FEC Element type it cannot decode, it SHOULD stop
decoding the FEC TLV, abort processing the message containing the decoding the FEC TLV, abort processing the message containing the
TLV, and send an "Unknown FEC" Notification message to its LDP peer TLV, and send an "Unknown FEC" Notification message to its LDP peer
signaling an error. signaling an error.
3.4.2. Label TLVs 3.4.2. Label TLVs
Label TLVs encode labels. Label TLVs are carried by the messages Label TLVs encode labels. Label TLVs are carried by the messages
used to advertise, request, release and withdraw label mappings. used to advertise, request, release and withdraw label mappings.
There are several different kinds of Label TLVs which can appear in There are several different kinds of Label TLVs which can appear in
skipping to change at page 38, line 44 skipping to change at page 38, line 44
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| ATM Label (0x0201) | Length | |0|0| ATM Label (0x0201) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| V | VPI | VCI | |Res| V | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res Res
This field is reserved. It must be set to zero on transmission This field is reserved. It MUST be set to zero on transmission
and must be ignored on receipt. and MUST be ignored on receipt.
V-bits V-bits
Two-bit switching indicator. If V-bits is 00, both the VPI and Two-bit switching indicator. If V-bits is 00, both the VPI and
VCI are significant. If V-bits is 01, only the VPI field is sig- VCI are significant. If V-bits is 01, only the VPI field is sig-
nificant. If V-bit is 10, only the VCI is significant. nificant. If V-bit is 10, only the VCI is significant.
VPI VPI
Virtual Path Identifier. If VPI is less than 12-bits it should be Virtual Path Identifier. If VPI is less than 12-bits it SHOULD be
right justified in this field and preceding bits should be set to right justified in this field and preceding bits SHOULD be set to
0. 0.
VCI VCI
Virtual Channel Identifier. If the VCI is less than 16- bits, it Virtual Channel Identifier. If the VCI is less than 16- bits, it
should be right justified in the field and the preceding bits must SHOULD be right justified in the field and the preceding bits MUST
be set to 0. If Virtual Path switching is indicated in the V-bits be set to 0. If Virtual Path switching is indicated in the V-bits
field, then this field must be ignored by the receiver and set to field, then this field MUST be ignored by the receiver and set to
0 by the sender. 0 by the sender.
3.4.2.3. Frame Relay Label TLV 3.4.2.3. Frame Relay Label TLV
An LSR uses Frame Relay Label TLVs to encode labels for use on Frame An LSR uses Frame Relay Label TLVs to encode labels for use on Frame
Relay links. Relay links.
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| Frame Relay Label (0x0202)| Length | |0|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| DLCI | | Reserved |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res Res
This field is reserved. It must be set to zero on transmission This field is reserved. It MUST be set to zero on transmission
and must be ignored on receipt. and MUST be ignored on receipt.
Len Len
This field specifies the number of bits of the DLCI. The follow- This field specifies the number of bits of the DLCI. The follow-
ing values are supported: ing values are supported:
0 = 10 bits DLCI 0 = 10 bits DLCI
2 = 23 bits DLCI 2 = 23 bits DLCI
Len values 1 and 3 are reserved. Len values 1 and 3 are reserved.
skipping to change at page 41, line 20 skipping to change at page 41, line 20
| HC Value | | HC Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
HC Value HC Value
1 octet unsigned integer hop count value. 1 octet unsigned integer hop count value.
3.4.4.1. Hop Count Procedures 3.4.4.1. Hop Count Procedures
During setup of an LSP an LSR R may receive a Label Mapping or Label During setup of an LSP an LSR R may receive a Label Mapping or Label
Request message for the LSP that contains the Hop Count TLV. If it Request message for the LSP that contains the Hop Count TLV. If it
does, it should record the hop count value. does, it SHOULD record the hop count value.
If LSR R then propagates the Label Mapping message for the LSP to an If LSR R then propagates the Label Mapping message for the LSP to an
upstream peer or the Label Request message to a downstream peer to upstream peer or the Label Request message to a downstream peer to
continue the LSP setup, it must must determine a hop count to include continue the LSP setup, it must determine a hop count to include in
in the propagated message as follows: the propagated message as follows:
- If the message is a Label Request message, R must increment the - If the message is a Label Request message, R MUST increment the
received hop count; received hop count;
- If the message is a Label Mapping message, R determines the hop - If the message is a Label Mapping message, R determines the hop
count as follows: count as follows:
o If R is a member of the edge set of an LSR domain whose LSRs do o If R is a member of the edge set of an LSR domain whose LSRs do
not perform 'TTL-decrement' and the upstream peer is within not perform 'TTL-decrement' and the upstream peer is within
that domain, R must reset the hop count to 1 before propagating that domain, R MUST reset the hop count to 1 before propagating
the message. the message.
o Otherwise, R must increment the received hop count. o Otherwise, R MUST increment the received hop count.
The first LSR in the LSP (ingress for a Label Request message, egress The first LSR in the LSP (ingress for a Label Request message, egress
for a Label Mapping message) should set the hop count value to 1. for a Label Mapping message) SHOULD set the hop count value to 1.
By convention a value of 0 indicates an unknown hop count. The By convention a value of 0 indicates an unknown hop count. The
result of incrementing an unknown hop count is itself an unknown hop result of incrementing an unknown hop count is itself an unknown hop
count (0). count (0).
Use of the unknown hop count value greatly reduces the signaling Use of the unknown hop count value greatly reduces the signaling
overhead when independent control is used. When a new LSP is estab- overhead when independent control is used. When a new LSP is estab-
lished, each LSR starts with unknown hop count. Addition of a new lished, each LSR starts with unknown hop count. Addition of a new
LSR whose hop count is also unknown does not cause a hop count update LSR whose hop count is also unknown does not cause a hop count update
to be propagated upstream since the hop count remains unknown. When to be propagated upstream since the hop count remains unknown. When
skipping to change at page 42, line 20 skipping to change at page 42, line 20
These updates are useless overhead since they don't reflect the hop These updates are useless overhead since they don't reflect the hop
count to the egress. count to the egress.
>From the perspective of the ingress node, the fact that the hop >From the perspective of the ingress node, the fact that the hop
count is unknown implies nothing about whether a packet sent on the count is unknown implies nothing about whether a packet sent on the
LSP will actually make it to the egress. All it implies is that the LSP will actually make it to the egress. All it implies is that the
hop count update from the egress has not yet reached the ingress. hop count update from the egress has not yet reached the ingress.
If an LSR receives a message containing a Hop Count TLV, it must If an LSR receives a message containing a Hop Count TLV, it must
check the hop count value to determine whether the hop count has check the hop count value to determine whether the hop count has
exceeded its configured maximum allowable value. If so, it must exceeded its configured maximum allowable value. If so, it MUST
behave as if the containing message has traversed a loop by sending a behave as if the containing message has traversed a loop by sending a
Notification message signaling Loop Detected in reply to the sender Notification message signaling Loop Detected in reply to the sender
of the message. of the message.
If Loop Detection is configured, the LSR must follow the procedures If Loop Detection is configured, the LSR MUST follow the procedures
specified in Section "Loop Detection". specified in Section "Loop Detection".
3.4.5. Path Vector TLV 3.4.5. Path Vector TLV
The Path Vector TLV is used with the Hop Count TLV in Label Request The Path Vector TLV is used with the Hop Count TLV in Label Request
and Label Mapping messages to implement the optional LDP loop detec- and Label Mapping messages to implement the optional LDP loop detec-
tion mechanism. See Section "Loop Detection". Its use in the Label tion mechanism. See Section "Loop Detection". Its use in the Label
Request message records the path of LSRs the request has traversed. Request message records the path of LSRs the request has traversed.
Its use in the Label Mapping message records the path of LSRs a label Its use in the Label Mapping message records the path of LSRs a label
advertisement has traversed to setup an LSP. Its encoding is: advertisement has traversed to setup an LSP. Its encoding is:
skipping to change at page 43, line 21 skipping to change at page 43, line 21
3.4.5.1. Path Vector Procedures 3.4.5.1. Path Vector Procedures
The Path Vector TLV is carried in Label Mapping and Label Request The Path Vector TLV is carried in Label Mapping and Label Request
messages when loop detection is configured. messages when loop detection is configured.
3.4.5.1.1. Label Request Path Vector 3.4.5.1.1. Label Request Path Vector
Section "Loop Detection" specifies situations when an LSR must Section "Loop Detection" specifies situations when an LSR must
include a Path Vector TLV in a Label Request message. include a Path Vector TLV in a Label Request message.
An LSR that receives a Path Vector in a Label Request message must An LSR that receives a Path Vector in a Label Request message MUST
perform the procedures described in Section "Loop Detection". perform the procedures described in Section "Loop Detection".
If the LSR detects a loop, it must reject the Label Request message. If the LSR detects a loop, it MUST reject the Label Request message.
The LSR must: The LSR MUST:
1. Transmit a Notification message to the sending LSR signaling 1. Transmit a Notification message to the sending LSR signaling
"Loop Detected". "Loop Detected".
2. Not propagate the Label Request message further. 2. Not propagate the Label Request message further.
Note that a Label Request message with Path Vector TLV is forwarded Note that a Label Request message with Path Vector TLV is forwarded
until: until:
1. A loop is found, 1. A loop is found,
skipping to change at page 43, line 48 skipping to change at page 43, line 48
2. The LSP egress is reached, 2. The LSP egress is reached,
3. The maximum Path Vector limit or maximum Hop Count limit is 3. The maximum Path Vector limit or maximum Hop Count limit is
reached. This is treated as if a loop had been detected. reached. This is treated as if a loop had been detected.
3.4.5.1.2. Label Mapping Path Vector 3.4.5.1.2. Label Mapping Path Vector
Section "Loop Detection" specifies the situations when an LSR must Section "Loop Detection" specifies the situations when an LSR must
include a Path Vector TLV in a Label Mapping message. include a Path Vector TLV in a Label Mapping message.
An LSR that receives a Path Vector in a Label Mapping message must An LSR that receives a Path Vector in a Label Mapping message MUST
perform the procedures described in Section "Loop Detection". perform the procedures described in Section "Loop Detection".
If the LSR detects a loop, it must reject the Label Mapping message If the LSR detects a loop, it MUST reject the Label Mapping message
in order to prevent a forwarding loop. The LSR must: in order to prevent a forwarding loop. The LSR MUST:
1. Transmit a Label Release message carrying a Status TLV to the 1. Transmit a Label Release message carrying a Status TLV to the
sending LSR to signal "Loop Detected". sending LSR to signal "Loop Detected".
2. Not propagate the message further. 2. Not propagate the message further.
3. Check whether the Label Mapping message is for an existing LSP. 3. Check whether the Label Mapping message is for an existing LSP.
If so, the LSR must unsplice any upstream labels which are If so, the LSR must unsplice any upstream labels which are
spliced to the downstream label for the FEC. spliced to the downstream label for the FEC.
skipping to change at page 44, line 48 skipping to change at page 44, line 48
|U|F| Status (0x0300) | Length | |U|F| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit U bit
Should be 0 when the Status TLV is sent in a Notification message. SHOULD be 0 when the Status TLV is sent in a Notification message.
Should be 1 when the Status TLV is sent in some other message. SHOULD be 1 when the Status TLV is sent in some other message.
F bit F bit
Should be the same as the setting of the F-bit in the Status Code SHOULD be the same as the setting of the F-bit in the Status Code
field. field.
Status Code Status Code
32-bit unsigned integer encoding the event being signaled. The 32-bit unsigned integer encoding the event being signaled. The
structure of a Status Code is: structure of a Status Code 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|F| Status Data | |E|F| Status Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E bit E bit
Fatal error bit. If set (=1), this is a fatal error notifica- Fatal error bit. If set (=1), this is a fatal error notifica-
tion. If clear (=0), this is an advisory notification. tion. If clear (=0), this is an advisory notification.
F bit F bit
Forward bit. If set (=1), the notification should be forwarded Forward bit. If set (=1), the notification SHOULD be forwarded
to the LSR for the next-hop or previous-hop for the LSP, if to the LSR for the next-hop or previous-hop for the LSP, if
any, associated with the event being signaled. If clear (=0), any, associated with the event being signaled. If clear (=0),
the notification should not be forwarded. the notification SHOULD NOT be forwarded.
Status Data Status Data
30-bit unsigned integer which specifies the status information. 30-bit unsigned integer which specifies the status information.
This specification defines Status Codes (32-bit unsigned integers This specification defines Status Codes (32-bit unsigned integers
with the above encoding). with the above encoding).
A Status Code of 0 signals success. A Status Code of 0 signals success.
Message ID Message ID
skipping to change at page 45, line 50 skipping to change at page 45, line 50
being identified. being identified.
Message Type Message Type
If non-zero, the type of the peer message to which the Status TLV If non-zero, the type of the peer message to which the Status TLV
refers. If zero, the Status TLV does not refer to any specific refers. If zero, the Status TLV does not refer to any specific
message type. message type.
Note that use of the Status TLV is not limited to Notification mes- Note that use of the Status TLV is not limited to Notification mes-
sages. A message other than a Notification message may carry a Sta- sages. A message other than a Notification message may carry a Sta-
tus TLV as an Optional Parameter. When a message other than a Noti- tus TLV as an Optional Parameter. When a message other than a Noti-
fication carries a Status TLV the U-bit of the Status TLV should be fication carries a Status TLV the U-bit of the Status TLV SHOULD be
set to 1 to indicate that the receiver should silently discard the set to 1 to indicate that the receiver SHOULD silently discard the
TLV if unprepared to handle it. TLV if unprepared to handle it.
3.5. LDP Messages 3.5. LDP Messages
All LDP messages have the following format: All LDP messages have the 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| Message Type | Message Length | |U| Message Type | Message Length |
skipping to change at page 46, line 47 skipping to change at page 46, line 47
Identifies the type of message Identifies the type of message
Message Length Message Length
Specifies the cumulative length in octets of the Message ID, Specifies the cumulative length in octets of the Message ID,
Mandatory Parameters, and Optional Parameters. Mandatory Parameters, and Optional Parameters.
Message ID Message ID
32-bit value used to identify this message. Used by the sending 32-bit value used to identify this message. Used by the sending
LSR to facilitate identifying notification messages that may apply LSR to facilitate identifying notification messages that may apply
to this message. An LSR sending a notification message in to this message. An LSR sending a notification message in
response to this message should include this Message Id in the response to this message SHOULD include this Message Id in the
Status TLV carried by the notification message; see Section "Noti- Status TLV carried by the notification message; see Section "Noti-
fication Message". fication Message".
Mandatory Parameters Mandatory Parameters
Variable length set of required message parameters. Some messages Variable length set of required message parameters. Some messages
have no required parameters. have no required parameters.
For messages that have required parameters, the required parame- For messages that have required parameters, the required parame-
ters MUST appear in the order specified by the individual message ters MUST appear in the order specified by the individual message
specifications in the sections that follow. specifications in the sections that follow.
skipping to change at page 49, line 28 skipping to change at page 49, line 28
3.5.1.1. Notification Message Procedures 3.5.1.1. Notification Message Procedures
If an LSR encounters a condition requiring it to notify its peer with If an LSR encounters a condition requiring it to notify its peer with
advisory or error information it sends the peer a Notification mes- advisory or error information it sends the peer a Notification mes-
sage containing a Status TLV that encodes the information and option- sage containing a Status TLV that encodes the information and option-
ally additional TLVs that provide more information about the condi- ally additional TLVs that provide more information about the condi-
tion. tion.
If the condition is one that is a fatal error the Status Code carried If the condition is one that is a fatal error the Status Code carried
in the notification will indicate that. In this case, after sending in the notification will indicate that. In this case, after sending
the Notification message the LSR should terminate the LDP session by the Notification message the LSR SHOULD terminate the LDP session by
closing the session TCP connection and discard all state associated closing the session TCP connection and discard all state associated
with the session, including all label-FEC bindings learned via the with the session, including all label-FEC bindings learned via the
session. session.
When an LSR receives a Notification message that carries a Status When an LSR receives a Notification message that carries a Status
Code that indicates a fatal error, it should terminate the LDP ses- Code that indicates a fatal error, it SHOULD terminate the LDP ses-
sion immediately by closing the session TCP connection and discard sion immediately by closing the session TCP connection and discard
all state associated with the session, including all label-FEC bind- all state associated with the session, including all label-FEC bind-
ings learned via the session. ings learned via the session.
The above statement does not apply to the processing of the shutdown The above statement does not apply to the processing of the Shutdown
message in the session initialization procedure. When an LSR receives message in the session initialization procedure. When an LSR receives
a shutdown message during session initialization, it should transmit a Shutdown message during session initialization, it SHOULD transmit
a shutdown message and then close the transport connection. a Shutdown message and then close the transport connection.
3.5.1.2. Events Signaled by Notification Messages 3.5.1.2. Events Signaled by Notification Messages
It is useful for descriptive purpose to classify events signaled by It is useful for descriptive purpose to classify events signaled by
Notification Messages into the following categories. Notification Messages into the following categories.
3.5.1.2.1. Malformed PDU or Message 3.5.1.2.1. Malformed PDU or Message
Malformed LDP PDUs or Messages that are part of the LDP Discovery Malformed LDP PDUs or Messages that are part of the LDP Discovery
mechanism are handled by silently discarding them. mechanism are handled by silently discarding them.
skipping to change at page 53, line 49 skipping to change at page 53, line 49
request. request.
An LSR initiating Extended Discovery sets R to 1. If R is 1, An LSR initiating Extended Discovery sets R to 1. If R is 1,
the receiving LSR checks whether it has been configured to send the receiving LSR checks whether it has been configured to send
Targeted Hellos to the Hello source in response to Hellos with Targeted Hellos to the Hello source in response to Hellos with
this request. If not, it ignores the request. If so, it ini- this request. If not, it ignores the request. If so, it ini-
tiates periodic transmission of Targeted Hellos to the Hello tiates periodic transmission of Targeted Hellos to the Hello
source. source.
Reserved Reserved
This field is reserved. It must be set to zero on transmission This field is reserved. It MUST be set to zero on transmission
and ignored on receipt. and ignored on receipt.
Optional Parameters Optional Parameters
This variable length field contains 0 or more parameters, each This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters defined by this ver- encoded as a TLV. The optional parameters defined by this ver-
sion of the protocol are sion of the protocol are
Optional Parameter Type Length Value Optional Parameter Type Length Value
IPv4 Transport Address 0x0401 4 See below IPv4 Transport Address 0x0401 4 See below
Configuration 0x0402 4 See below Configuration 0x0402 4 See below
Sequence Number Sequence Number
IPv6 Transport Address 0x0403 16 See below IPv6 Transport Address 0x0403 16 See below
IPv4 Transport Address IPv4 Transport Address
Specifies the IPv4 address to be used for the sending LSR when Specifies the IPv4 address to be used for the sending LSR when
opening the LDP session TCP connection. If this optional TLV opening the LDP session TCP connection. If this optional TLV
is not present the IPv4 source address for the UDP packet car- is not present the IPv4 source address for the UDP packet car-
rying the Hello should be used. rying the Hello SHOULD be used.
Configuration Sequence Number Configuration Sequence Number
Specifies a 4 octet unsigned configuration sequence number that Specifies a 4 octet unsigned configuration sequence number that
identifies the configuration state of the sending LSR. Used by identifies the configuration state of the sending LSR. Used by
the receiving LSR to detect configuration changes on the send- the receiving LSR to detect configuration changes on the send-
ing LSR. ing LSR.
IPv6 Transport Address IPv6 Transport Address
Specifies the IPv6 address to be used for the sending LSR when Specifies the IPv6 address to be used for the sending LSR when
opening the LDP session TCP connection. If this optional TLV opening the LDP session TCP connection. If this optional TLV
is not present the IPv6 source address for the UDP packet car- is not present the IPv6 source address for the UDP packet car-
rying the Hello should be used. rying the Hello SHOULD be used.
3.5.2.1. Hello Message Procedures 3.5.2.1. Hello Message Procedures
An LSR receiving Hellos from another LSR maintains a Hello adjacency An LSR receiving Hellos from another LSR maintains a Hello adjacency
corresponding to the Hellos. The LSR maintains a hold timer with the corresponding to the Hellos. The LSR maintains a hold timer with the
Hello adjacency which it restarts whenever it receives a Hello that Hello adjacency which it restarts whenever it receives a Hello that
matches the Hello adjacency. If the hold timer for a Hello adjacency matches the Hello adjacency. If the hold timer for a Hello adjacency
expires the LSR discards the Hello adjacency: see sections "Maintain- expires the LSR discards the Hello adjacency: see sections "Maintain-
ing Hello Adjacencies" and "Maintaining LDP Sessions". ing Hello Adjacencies" and "Maintaining LDP Sessions".
skipping to change at page 57, line 27 skipping to change at page 57, line 27
Indicates the type of Label advertisement. A value of 0 means Indicates the type of Label advertisement. A value of 0 means
Downstream Unsolicited advertisement; a value of 1 means Down- Downstream Unsolicited advertisement; a value of 1 means Down-
stream On Demand. stream On Demand.
If one LSR proposes Downstream Unsolicited and the other pro- If one LSR proposes Downstream Unsolicited and the other pro-
poses Downstream on Demand, the rules for resolving this dif- poses Downstream on Demand, the rules for resolving this dif-
ference is: ference is:
- If the session is for a label-controlled ATM link or a - If the session is for a label-controlled ATM link or a
label-controlled Frame Relay link, then Downstream on Demand label-controlled Frame Relay link, then Downstream on Demand
must be used. MUST be used.
- Otherwise, Downstream Unsolicited must be used. - Otherwise, Downstream Unsolicited MUST be used.
If the label advertisement discipline determined in this way is If the label advertisement discipline determined in this way is
unacceptable to an LSR, it must send a Session Rejected/Parame- unacceptable to an LSR, it MUST send a Session Rejected/Parame-
ters Advertisement Mode Notification message in response to the ters Advertisement Mode Notification message in response to the
Initialization message and not establish the session. Initialization message and not establish the session.
D, Loop Detection D, Loop Detection
Indicates whether loop detection based on path vectors is Indicates whether loop detection based on path vectors is
enabled. A value of 0 means loop detection is disabled; a enabled. A value of 0 means loop detection is disabled; a
value of 1 means that loop detection is enabled. value of 1 means that loop detection is enabled.
PVLim, Path Vector Limit PVLim, Path Vector Limit
The configured maximum path vector length. Must be 0 if loop The configured maximum path vector length. MUST be 0 if loop
detection is disabled (D = 0). If the loop detection proce- detection is disabled (D = 0). If the loop detection proce-
dures would require the LSR to send a path vector that exceeds dures would require the LSR to send a path vector that exceeds
this limit, the LSR will behave as if a loop had been detected this limit, the LSR will behave as if a loop had been detected
for the FEC in question. for the FEC in question.
When Loop Detection is enabled in a portion of a network, it is When Loop Detection is enabled in a portion of a network, it is
recommended that all LSRs in that portion of the network be recommended that all LSRs in that portion of the network be
configured with the same path vector limit. Although knowledge configured with the same path vector limit. Although knowledge
of a peer's path vector limit will not change an LSR's behav- of a peer's path vector limit will not change an LSR's behav-
ior, it does enable the LSR to alert an operator to a possible ior, it does enable the LSR to alert an operator to a possible
misconfiguration. misconfiguration.
Reserved Reserved
This field is reserved. It must be set to zero on transmission This field is reserved. It MUST be set to zero on transmission
and ignored on receipt. and ignored on receipt.
Max PDU Length Max PDU Length
Two octet unsigned integer that proposes the maximum allowable Two octet unsigned integer that proposes the maximum allowable
length for LDP PDUs for the session. A value of 255 or less length for LDP PDUs for the session. A value of 255 or less
specifies the default maximum length of 4096 octets. specifies the default maximum length of 4096 octets.
The receiving LSR MUST calculate the maximum PDU length for the The receiving LSR MUST calculate the maximum PDU length for the
session by using the smaller of its and its peer's proposals session by using the smaller of its and its peer's proposals
for Max PDU Length. The default maximum PDU length applies for Max PDU Length. The default maximum PDU length applies
before session initialization completes. before session initialization completes.
If the maximum PDU length determined this way is unacceptable If the maximum PDU length determined this way is unacceptable
to an LSR, it must send a Session Rejected/Parameters Max PDU to an LSR, it MUST send a Session Rejected/Parameters Max PDU
Length Notification message in response to the Initialization Length Notification message in response to the Initialization
message and not establish the session. message and not establish the session.
Receiver LDP Identifier Receiver LDP Identifier
Identifies the receiver's label space. This LDP Identifier, Identifies the receiver's label space. This LDP Identifier,
together with the sender's LDP Identifier in the PDU header together with the sender's LDP Identifier in the PDU header
enables the receiver to match the Initialization message with enables the receiver to match the Initialization message with
one of its Hello adjacencies; see Section "Hello Message Proce- one of its Hello adjacencies; see Section "Hello Message Proce-
dures". dures".
If there is no matching Hello adjacency, the LSR must send a If there is no matching Hello adjacency, the LSR MUST send a
Session Rejected/No Hello Notification message in response to Session Rejected/No Hello Notification message in response to
the Initialization message and not establish the session. the Initialization message and not establish the session.
Optional Parameters Optional Parameters
This variable length field contains 0 or more parameters, each This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters are: encoded as a TLV. The optional parameters are:
Optional Parameter Type Length Value Optional Parameter Type Length Value
ATM Session Parameters 0x0501 var See below ATM Session Parameters 0x0501 var See below
skipping to change at page 60, line 17 skipping to change at page 60, line 17
tion on the link only. When either or both of the peers speci- tion on the link only. When either or both of the peers speci-
fies unidirectional VC capability, both LSRs use unidirectional fies unidirectional VC capability, both LSRs use unidirectional
VC label assignment for the link as follows. The LSRs compare VC label assignment for the link as follows. The LSRs compare
their LDP Identifiers as unsigned integers. The LSR with the their LDP Identifiers as unsigned integers. The LSR with the
larger LDP Identifier may assign only odd-numbered VCIs in the larger LDP Identifier may assign only odd-numbered VCIs in the
VPI/VCI range as labels. The system with the smaller LDP Iden- VPI/VCI range as labels. The system with the smaller LDP Iden-
tifier may assign only even-numbered VCIs in the VPI/VCI range tifier may assign only even-numbered VCIs in the VPI/VCI range
as labels. as labels.
Reserved Reserved
This field is reserved. It must be set to zero on transmission This field is reserved. It MUST be set to zero on transmission
and ignored on receipt. and ignored on receipt.
One or more ATM Label Range Components One or more ATM Label Range Components
A list of ATM Label Range Components which together specify the A list of ATM Label Range Components which together specify the
Label range supported by the transmitting LSR. Label range supported by the transmitting LSR.
A receiving LSR MUST calculate the intersection between the A receiving LSR MUST calculate the intersection between the
received range and its own supported label range. The inter- received range and its own supported label range. The inter-
section is the range in which the LSR may allocate and accept section is the range in which the LSR may allocate and accept
labels. LSRs MUST NOT establish a session with neighbors for labels. LSRs MUST NOT establish a session with neighbors for
which the intersection of ranges is NULL. In this case, the which the intersection of ranges is NULL. In this case, the
LSR must send a Session Rejected/Parameters Label Range Notifi- LSR MUST send a Session Rejected/Parameters Label Range Notifi-
cation message in response to the Initialization message and cation message in response to the Initialization message and
not establish the session. not establish the session.
The encoding for an ATM Label Range Component is: The encoding for an ATM Label Range Component 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Minimum VPI | Minimum VCI | | Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI | | Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res Res
This field is reserved. It must be set to zero on transmis- This field is reserved. It MUST be set to zero on transmis-
sion and must be ignored on receipt. sion and MUST be ignored on receipt.
Minimum VPI (12 bits) Minimum VPI (12 bits)
This 12 bit field specifies the lower bound of a block of This 12 bit field specifies the lower bound of a block of
Virtual Path Identifiers that is supported on the originat- Virtual Path Identifiers that is supported on the originat-
ing switch. If the VPI is less than 12-bits it should be ing switch. If the VPI is less than 12-bits it SHOULD be
right justified in this field and preceding bits should be right justified in this field and preceding bits SHOULD be
set to 0. set to 0.
Minimum VCI (16 bits) Minimum VCI (16 bits)
This 16 bit field specifies the lower bound of a block of This 16 bit field specifies the lower bound of a block of
Virtual Connection Identifiers that is supported on the Virtual Connection Identifiers that is supported on the
originating switch. If the VCI is less than 16-bits it originating switch. If the VCI is less than 16-bits it
should be right justified in this field and preceding bits SHOULD be right justified in this field and preceding bits
should be set to 0. SHOULD be set to 0.
Maximum VPI (12 bits) Maximum VPI (12 bits)
This 12 bit field specifies the upper bound of a block of This 12 bit field specifies the upper bound of a block of
Virtual Path Identifiers that is supported on the originat- Virtual Path Identifiers that is supported on the originat-
ing switch. If the VPI is less than 12-bits it should be ing switch. If the VPI is less than 12-bits it SHOULD be
right justified in this field and preceding bits should be right justified in this field and preceding bits SHOULD be
set to 0. set to 0.
Maximum VCI (16 bits) Maximum VCI (16 bits)
This 16 bit field specifies the upper bound of a block of This 16 bit field specifies the upper bound of a block of
Virtual Connection Identifiers that is supported on the Virtual Connection Identifiers that is supported on the
originating switch. If the VCI is less than 16-bits it originating switch. If the VCI is less than 16-bits it
should be right justified in this field and preceding bits SHOULD be right justified in this field and preceding bits
should be set to 0. SHOULD be set to 0.
When peer LSRs are connected indirectly by means of an ATM VP, the When peer LSRs are connected indirectly by means of an ATM VP, the
sending LSR should set the Minimum and Maximum VPI fields to 0, sending LSR SHOULD set the Minimum and Maximum VPI fields to 0,
and the receiving LSR must ignore the Minimum and Maximum VPI and the receiving LSR MUST ignore the Minimum and Maximum VPI
fields. fields.
See [ATM-VP] for specification of the fields for ATM Label Range See [ATM-VP] for specification of the fields for ATM Label Range
Components to be used with VP merge LSRs. Components to be used with VP merge LSRs.
Frame Relay Session Parameters Frame Relay Session Parameters
Used when an LDP session manages label exchange for a Frame Used when an LDP session manages label exchange for a Frame
Relay link to specify Frame Relay-specific session parameters. Relay link to specify Frame Relay-specific session parameters.
0 1 2 3 0 1 2 3
skipping to change at page 62, line 51 skipping to change at page 62, line 51
label mapping for one direction on the link only. Wheneither label mapping for one direction on the link only. Wheneither
or both of the peers specifies unidirectional VC capability, or both of the peers specifies unidirectional VC capability,
both LSRs use unidirectional VC label assignment for the link both LSRs use unidirectional VC label assignment for the link
as follows. The LSRs compare their LDP Identifiers as unsigned as follows. The LSRs compare their LDP Identifiers as unsigned
integers. The LSR with the larger LDP Identifier may assign integers. The LSR with the larger LDP Identifier may assign
only odd-numbered DLCIs in the range as labels. The system only odd-numbered DLCIs in the range as labels. The system
with the smaller LDP Identifier may assign only even-numbered with the smaller LDP Identifier may assign only even-numbered
DLCIs in the range as labels. DLCIs in the range as labels.
Reserved Reserved
This field is reserved. It must be set to zero on transmission This field is reserved. It MUST be set to zero on transmission
and ignored on receipt. and ignored on receipt.
One or more Frame Relay Label Range Components One or more Frame Relay Label Range Components
A list of Frame Relay Label Range Components which together A list of Frame Relay Label Range Components which together
specify the Label range supported by the transmitting LSR. specify the Label range supported by the transmitting LSR.
A receiving LSR MUST calculate the intersection between the A receiving LSR MUST calculate the intersection between the
received range and its own supported label range. The inter- received range and its own supported label range. The inter-
section is the range in which the LSR may allocate and accept section is the range in which the LSR may allocate and accept
labels. LSRs MUST NOT establish a session with neighbors for labels. LSRs MUST NOT establish a session with neighbors for
which the intersection of ranges is NULL. In this case, the which the intersection of ranges is NULL. In this case, the
LSR must send a Session Rejected/Parameters Label Range Notifi- LSR MUST send a Session Rejected/Parameters Label Range Notifi-
cation message in response to the Initialization message and cation message in response to the Initialization message and
not establish the session. not establish the session.
The encoding for a Frame Relay Label Range Component is: The encoding for a Frame Relay Label Range Component 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| Minimum DLCI | | Reserved |Len| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI | | Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Reserved
This field is reserved. It must be set to zero on transmis- This field is reserved. It MUST be set to zero on transmis-
sion and ignored on receipt. sion and ignored on receipt.
Len Len
This field specifies the number of bits of the DLCI. The This field specifies the number of bits of the DLCI. The
following values are supported: following values are supported:
Len DLCI bits Len DLCI bits
0 10 0 10
2 23 2 23
Len values 1 and 3 are reserved. Len values 1 and 3 are reserved.
Minimum DLCI Minimum DLCI
This 23-bit field specifies the lower bound of a block of This 23-bit field specifies the lower bound of a block of
Data Link Connection Identifiers (DLCIs) that is supported Data Link Connection Identifiers (DLCIs) that is supported
on the originating switch. The DLCI should be right justi- on the originating switch. The DLCI SHOULD be right justi-
fied in this field and unused bits should be set to 0. fied in this field and unused bits SHOULD be set to 0.
Maximum DLCI Maximum DLCI
This 23-bit field specifies the upper bound of a block of This 23-bit field specifies the upper bound of a block of
Data Link Connection Identifiers (DLCIs) that is supported Data Link Connection Identifiers (DLCIs) that is supported
on the originating switch. The DLCI should be right on the originating switch. The DLCI SHOULD be right
justified in this field and unused bits should be set to 0. justified in this field and unused bits SHOULD be set to 0.
Note that there is no Generic Session Parameters TLV for sessions Note that there is no Generic Session Parameters TLV for sessions
which advertise Generic Labels. which advertise Generic Labels.
3.5.3.1. Initialization Message Procedures 3.5.3.1. Initialization Message Procedures
See Section "LDP Session Establishment" and particularly Section See Section "LDP Session Establishment" and particularly Section
"Session Initialization" for general procedures for handling the Ini- "Session Initialization" for general procedures for handling the Ini-
tialization Message. tialization Message.
skipping to change at page 65, line 4 skipping to change at page 65, line 4
The KeepAlive Timer mechanism described in Section "Maintaining LDP The KeepAlive Timer mechanism described in Section "Maintaining LDP
Sessions" resets a session KeepAlive timer every time an LDP PDU is Sessions" resets a session KeepAlive timer every time an LDP PDU is
received on the session TCP connection. The KeepAlive Message is received on the session TCP connection. The KeepAlive Message is
provided to allow reset of the KeepAlive Timer in circumstances where provided to allow reset of the KeepAlive Timer in circumstances where
an LSR has no other information to communicate to an LDP peer. an LSR has no other information to communicate to an LDP peer.
An LSR must arrange that its peer receive an LDP Message from it at An LSR must arrange that its peer receive an LDP Message from it at
least every KeepAlive Time period. Any LDP protocol message will do least every KeepAlive Time period. Any LDP protocol message will do
but, in circumstances where no other LDP protocol messages have been but, in circumstances where no other LDP protocol messages have been
sent within the period, a KeepAlive message must be sent. sent within the period, a KeepAlive message MUST be sent.
3.5.5. Address Message 3.5.5. Address Message
An LSR sends the Address Message to an LDP peer to advertise its An LSR sends the Address Message to an LDP peer to advertise its
interface addresses. interface addresses.
The encoding for the Address Message is: The encoding for the Address Message 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
skipping to change at page 65, line 46 skipping to change at page 65, line 46
No optional parameters are defined for the Address message. No optional parameters are defined for the Address message.
3.5.5.1. Address Message Procedures 3.5.5.1. Address Message Procedures
An LSR that receives an Address Message message uses the addresses it An LSR that receives an Address Message message uses the addresses it
learns to maintain a database for mapping between peer LDP Identi- learns to maintain a database for mapping between peer LDP Identi-
fiers and next hop addresses; see Section "LDP Identifiers and Next fiers and next hop addresses; see Section "LDP Identifiers and Next
Hop Addresses". Hop Addresses".
When a new LDP session is initialized and before sending Label Map- When a new LDP session is initialized and before sending Label Map-
ping or Label Request messages an LSR should advertise its interface ping or Label Request messages an LSR SHOULD advertise its interface
addresses with one or more Address messages. addresses with one or more Address messages.
Whenever an LSR "activates" a new interface address, it should Whenever an LSR "activates" a new interface address, it SHOULD
advertise the new address with an Address message. advertise the new address with an Address message.
Whenever an LSR "de-activates" a previously advertised address, it Whenever an LSR "de-activates" a previously advertised address, it
should withdraw the address with an Address Withdraw message; see SHOULD withdraw the address with an Address Withdraw message; see
Section "Address Withdraw Message". Section "Address Withdraw Message".
If an LSR does not support the Address Family specified in the If an LSR does not support the Address Family specified in the
Address List TLV, it should send an "Unsupported Address Family" Address List TLV, it SHOULD send an "Unsupported Address Family"
Notification to its LDP signalling an error and abort processing the Notification to its LDP signalling an error and abort processing the
message. message.
An LSR may re-advertise an address (A) that it has previously adver- An LSR may re-advertise an address (A) that it has previously adver-
tised without explicitly withdrawing the address. If the receiver tised without explicitly withdrawing the address. If the receiver
already has address binding (LSR, A) it should take no further already has address binding (LSR, A) it SHOULD take no further
action. action.
An LSR may withdraw an address (A) without having previously adver- An LSR may withdraw an address (A) without having previously adver-
tised it. If the receiver has no address binding (LSR, A), it should tised it. If the receiver has no address binding (LSR, A), it SHOULD
take no further action. take no further action.
3.5.6. Address Withdraw Message 3.5.6. Address Withdraw Message
An LSR sends the Address Withdraw Message to an LDP peer to withdraw An LSR sends the Address Withdraw Message to an LDP peer to withdraw
previously advertised interface addresses. previously advertised interface addresses.
The encoding for the Address Withdraw Message is: The encoding for the Address Withdraw Message is:
0 1 2 3 0 1 2 3
skipping to change at page 68, line 17 skipping to change at page 68, line 17
Label Request 4 See below Label Request 4 See below
Message ID TLV Message ID TLV
Hop Count TLV 1 See below Hop Count TLV 1 See below
Path Vector TLV variable See below Path Vector TLV variable See below
The encodings for the Hop Count, and Path Vector TLVs can be found The encodings for the Hop Count, and Path Vector TLVs can be found
in Section "TLV Encodings for Commonly Used Parameters". in Section "TLV Encodings for Commonly Used Parameters".
Label Request Message ID Label Request Message ID
If this Label Mapping message is a response to a Label Request If this Label Mapping message is a response to a Label Request
message it must include the Request Message Id optional parame- message it MUST include the Request Message Id optional parame-
ter. The value of this optional parameter is the Message Id of ter. The value of this optional parameter is the Message Id of
the corresponding Label Request Message. the corresponding Label Request Message.
Hop Count Hop Count
Specifies the running total of the number of LSR hops along the Specifies the running total of the number of LSR hops along the
LSP being setup by the Label Message. Section "Hop Count Pro- LSP being setup by the Label Message. Section "Hop Count Pro-
cedures" describes how to handle this TLV. cedures" describes how to handle this TLV.
Path Vector Path Vector
Specifies the LSRs along the LSP being setup by the Label Mes- Specifies the LSRs along the LSP being setup by the Label Mes-
skipping to change at page 68, line 43 skipping to change at page 68, line 43
The Mapping message is used by an LSR to distribute a label mapping The Mapping message is used by an LSR to distribute a label mapping
for a FEC to an LDP peer. If an LSR distributes a mapping for a FEC for a FEC to an LDP peer. If an LSR distributes a mapping for a FEC
to multiple LDP peers, it is a local matter whether it maps a single to multiple LDP peers, it is a local matter whether it maps a single
label to the FEC, and distributes that mapping to all its peers, or label to the FEC, and distributes that mapping to all its peers, or
whether it uses a different mapping for each of its peers. whether it uses a different mapping for each of its peers.
An LSR is responsible for the consistency of the label mappings it An LSR is responsible for the consistency of the label mappings it
has distributed, and that its peers have these mappings. has distributed, and that its peers have these mappings.
An LSR receiving a Label Mapping message from a downstream LSR for a An LSR receiving a Label Mapping message from a downstream LSR for a
Prefix should not use the label for forwarding unless its routing ta- Prefix SHOULD NOT use the label for forwarding unless its routing ta-
ble contains an entry that exactly matches the FEC Element. ble contains an entry that exactly matches the FEC Element.
See Appendix A "LDP Label Distribution Procedures" for more details. See Appendix A "LDP Label Distribution Procedures" for more details.
3.5.7.1.1. Independent Control Mapping 3.5.7.1.1. Independent Control Mapping
If an LSR is configured for independent control, a mapping message is If an LSR is configured for independent control, a mapping message is
transmitted by the LSR upon any of the following conditions: transmitted by the LSR upon any of the following conditions:
1. The LSR recognizes a new FEC via the forwarding table, and the 1. The LSR recognizes a new FEC via the forwarding table, and the
skipping to change at page 70, line 21 skipping to change at page 70, line 21
everything is functioning properly, but no labels are distributed. everything is functioning properly, but no labels are distributed.
For example, consider two LSRs Ru and Rd where Ru is the upstream LSR For example, consider two LSRs Ru and Rd where Ru is the upstream LSR
and Rd is the downstream LSR for a particular FEC. In this example, and Rd is the downstream LSR for a particular FEC. In this example,
Ru is using Downstream Unsolicited advertisement mode and Rd is using Ru is using Downstream Unsolicited advertisement mode and Rd is using
Downstream on Demand mode. In this case, Rd may assume that Ru will Downstream on Demand mode. In this case, Rd may assume that Ru will
request a label mapping when it wants one and Ru may assume that Rd request a label mapping when it wants one and Ru may assume that Rd
will advertise a label if it wants Ru to use one. If Rd and Ru oper- will advertise a label if it wants Ru to use one. If Rd and Ru oper-
ate as suggested, no labels will be distributed from Rd to Ru. ate as suggested, no labels will be distributed from Rd to Ru.
This livelock situation can be avoided if the following rule is This livelock situation can be avoided if the following rule is
observed: an LSR operating in Downstream on Demand mode should not be observed: an LSR operating in Downstream on Demand mode SHOULD NOT be
expected to send unsolicited mapping advertisements. Therefore, if expected to send unsolicited mapping advertisements. Therefore, if
the downstream LSR is operating in Downstream on Demand mode, the the downstream LSR is operating in Downstream on Demand mode, the
upstream LSR is responsible for requesting label mappings as needed. upstream LSR is responsible for requesting label mappings as needed.
3.5.7.1.4. Downstream Unsolicited Label Advertisement 3.5.7.1.4. Downstream Unsolicited Label Advertisement
In general, the downstream LSR is responsible for advertising a label In general, the downstream LSR is responsible for advertising a label
mapping when it wants an upstream LSR to use the label. An upstream mapping when it wants an upstream LSR to use the label. An upstream
LSR may issue a mapping request if it so desires. LSR may issue a mapping request if it so desires.
skipping to change at page 72, line 26 skipping to change at page 72, line 26
ditions: ditions:
1. The LSR recognizes a new FEC via the forwarding table, and the 1. The LSR recognizes a new FEC via the forwarding table, and the
next hop is an LDP peer, and the LSR doesn't already have a next hop is an LDP peer, and the LSR doesn't already have a
mapping from the next hop for the given FEC. mapping from the next hop for the given FEC.
2. The next hop to the FEC changes, and the LSR doesn't already 2. The next hop to the FEC changes, and the LSR doesn't already
have a mapping from that next hop for the given FEC. have a mapping from that next hop for the given FEC.
Note that if the LSR already has a pending Label Request mes- Note that if the LSR already has a pending Label Request mes-
sage for the new next hop it should not issue an additional sage for the new next hop it SHOULD NOT issue an additional
Label Request in response to the next hop change. Label Request in response to the next hop change.
3. The LSR receives a Label Request for a FEC from an upstream LDP 3. The LSR receives a Label Request for a FEC from an upstream LDP
peer, the FEC next hop is an LDP peer, and the LSR doesn't peer, the FEC next hop is an LDP peer, and the LSR doesn't
already have a mapping from the next hop. already have a mapping from the next hop.
Note that since a non-merge LSR must setup a separate LSP for Note that since a non-merge LSR must setup a separate LSP for
each upstream peer requesting a label, it must send a separate each upstream peer requesting a label, it must send a separate
Label Request for each such peer. A consequence of this is Label Request for each such peer. A consequence of this is
that a non-merge LSR may have multiple Label Request messages that a non-merge LSR may have multiple Label Request messages
for a given FEC outstanding at the same time. for a given FEC outstanding at the same time.
The receiving LSR should respond to a Label Request message with a The receiving LSR SHOULD respond to a Label Request message with a
Label Mapping for the requested label or with a Notification message Label Mapping for the requested label or with a Notification message
indicating why it cannot satisfy the request. indicating why it cannot satisfy the request.
When the FEC for which a label is requested is a Prefix FEC Element, When the FEC for which a label is requested is a Prefix FEC Element,
the receiving LSR uses its routing table to determine its response. the receiving LSR uses its routing table to determine its response.
Unless its routing table includes an entry that exactly matches the Unless its routing table includes an entry that exactly matches the
requested Prefix, the LSR must respond with a No Route Notification requested Prefix, the LSR MUST respond with a No Route Notification
message. message.
The message ID of the Label Request message serves as an identifier The message ID of the Label Request message serves as an identifier
for the Label Request transaction. When the receiving LSR responds for the Label Request transaction. When the receiving LSR responds
with a Label Mapping message, the mapping message must include a with a Label Mapping message, the mapping message MUST include a
Label Request/Returned Message ID TLV optional parameter which Label Request/Returned Message ID TLV optional parameter which
includes the message ID of the Label Request message. Note that includes the message ID of the Label Request message. Note that
since LSRs use Label Request message IDs as transaction identifiers since LSRs use Label Request message IDs as transaction identifiers
an LSR should not reuse the message ID of a Label Request message an LSR SHOULD NOT reuse the message ID of a Label Request message
until the corresponding transaction completes. until the corresponding transaction completes.
This version of the protocol defines the following Status Codes for This version of the protocol defines the following Status Codes for
the Notification message that signals a request cannot be satisfied: the Notification message that signals a request cannot be satisfied:
No Route No Route
The FEC for which a label was requested includes a FEC Element The FEC for which a label was requested includes a FEC Element
for which the LSR does not have a route. for which the LSR does not have a route.
No Label Resources No Label Resources
The LSR cannot provide a label because of resource limitations. The LSR cannot provide a label because of resource limitations.
When resources become available the LSR must notify the When resources become available the LSR MUST notify the
requesting LSR by sending a Notification message with the Label requesting LSR by sending a Notification message with the Label
Resources Available Status Code. Resources Available Status Code.
An LSR that receives a No Label Resources response to a Label An LSR that receives a No Label Resources response to a Label
Request message must not issue further Label Request messages Request message MUST NOT issue further Label Request messages
until it receives a Notification message with the Label until it receives a Notification message with the Label
Resources Available Status code. Resources Available Status code.
Loop Detected Loop Detected
The LSR has detected a looping Label Request message. The LSR has detected a looping Label Request message.
See Appendix A "LDP Label Distribution Procedures" for more details. See Appendix A "LDP Label Distribution Procedures" for more details.
3.5.9. Label Abort Request Message 3.5.9. Label Abort Request Message
skipping to change at page 75, line 7 skipping to change at page 75, line 7
Request for FEC from an upstream peer Y and Y is the only Request for FEC from an upstream peer Y and Y is the only
(last) upstream LSR requesting a label for FEC. (last) upstream LSR requesting a label for FEC.
There may be other situations where an LSR may choose to abort an There may be other situations where an LSR may choose to abort an
outstanding Label Request message in order to reclaim resource asso- outstanding Label Request message in order to reclaim resource asso-
ciated with the pending LSP. However, specification of general ciated with the pending LSP. However, specification of general
strategies for using the abort mechanism is beyond the scope of LDP. strategies for using the abort mechanism is beyond the scope of LDP.
When an LSR receives a Label Abort Request message, if it has not When an LSR receives a Label Abort Request message, if it has not
previously responded to the Label Request being aborted with a Label previously responded to the Label Request being aborted with a Label
Mapping message or some other Notification message, it must acknowl- Mapping message or some other Notification message, it MUST acknowl-
edge the abort by responding with a Label Request Aborted Notifica- edge the abort by responding with a Label Request Aborted Notifica-
tion message. The Notification must include a Label Request Message tion message. The Notification MUST include a Label Request Message
ID TLV that carries the message ID of the aborted Label Request mes- ID TLV that carries the message ID of the aborted Label Request mes-
sage. sage.
If an LSR receives a Label Abort Request Message after it has If an LSR receives a Label Abort Request Message after it has
responded to the Label Request in question with a Label Mapping mes- responded to the Label Request in question with a Label Mapping mes-
sage or a Notification message, it ignores the abort request. sage or a Notification message, it ignores the abort request.
If an LSR receives a Label Mapping message in response to a Label If an LSR receives a Label Mapping message in response to a Label
Request message after it has sent a Label Abort Request message to Request message after it has sent a Label Abort Request message to
abort the Label Request, the label in the Label Mapping message is abort the Label Request, the label in the Label Mapping message is
skipping to change at page 75, line 47 skipping to change at page 75, line 47
an LSR may choose to time out receipt of the above. The time out an LSR may choose to time out receipt of the above. The time out
period should be relatively long (several minutes). If the time out period should be relatively long (several minutes). If the time out
period elapses with no reply from the peer the LSR may reuse the Mes- period elapses with no reply from the peer the LSR may reuse the Mes-
sage Id of the Label Request message; if it does so, it should also sage Id of the Label Request message; if it does so, it should also
discard any record of the outstanding Label Request and Label Abort discard any record of the outstanding Label Request and Label Abort
messages. messages.
Note that the response to a Label Abort Request message is never Note that the response to a Label Abort Request message is never
"ordered". That is, the response does not depend on the downstream "ordered". That is, the response does not depend on the downstream
state of the LSP setup being aborted. An LSR receiving a Label Abort state of the LSP setup being aborted. An LSR receiving a Label Abort
Request message must process it immediately, regardless of the down- Request message MUST process it immediately, regardless of the down-
stream state of the LSP, responding with a Label Request Aborted stream state of the LSP, responding with a Label Request Aborted
Notification or ignoring it, as appropriate. Notification or ignoring it, as appropriate.
3.5.10. Label Withdraw Message 3.5.10. Label Withdraw Message
An LSR sends a Label Withdraw Message to an LDP peer to signal the An LSR sends a Label Withdraw Message to an LDP peer to signal the
peer that the peer may not continue to use specific FEC-label map- peer that the peer may not continue to use specific FEC-label map-
pings the LSR had previously advertised. This breaks the mapping pings the LSR had previously advertised. This breaks the mapping
between the FECs and the labels. between the FECs and the labels.
skipping to change at page 77, line 30 skipping to change at page 77, line 30
optional Label TLV is to be withdrawn. optional Label TLV is to be withdrawn.
The FEC TLV may contain the Wildcard FEC Element; if so, it may con- The FEC TLV may contain the Wildcard FEC Element; if so, it may con-
tain no other FEC Elements. In this case, if the Label Withdraw mes- tain no other FEC Elements. In this case, if the Label Withdraw mes-
sage contains an optional Label TLV, then the label is to be with- sage contains an optional Label TLV, then the label is to be with-
drawn from all FECs to which it is bound. If there is not an drawn from all FECs to which it is bound. If there is not an
optional Label TLV in the Label Withdraw message, then the sending optional Label TLV in the Label Withdraw message, then the sending
LSR is withdrawing all label mappings previously advertised to the LSR is withdrawing all label mappings previously advertised to the
receiving LSR. receiving LSR.
An LSR that receives a Label Withdraw message must respond with a An LSR that receives a Label Withdraw message MUST respond with a
Label Release message. Label Release message.
See Appendix A "LDP Label Distribution Procedures" for more details. See Appendix A "LDP Label Distribution Procedures" for more details.
3.5.11. Label Release Message 3.5.11. Label Release Message
An LSR sends a Label Release message to an LDP peer to signal the An LSR sends a Label Release message to an LDP peer to signal the
peer that the LSR no longer needs specific FEC-label mappings previ- peer that the LSR no longer needs specific FEC-label mappings previ-
ously requested of and/or advertised by the peer. ously requested of and/or advertised by the peer.
skipping to change at page 78, line 45 skipping to change at page 78, line 45
Label Label
If present, the label being released (see procedures below). If present, the label being released (see procedures below).
3.5.11.1. Label Release Message Procedures 3.5.11.1. Label Release Message Procedures
An LSR transmits a Label Release message to a peer when it is no An LSR transmits a Label Release message to a peer when it is no
longer needs a label previously received from or requested of that longer needs a label previously received from or requested of that
peer. peer.
An LSR must transmit a Label Release message under any of the follow- An LSR MUST transmit a Label Release message under any of the follow-
ing conditions: ing conditions:
1. The LSR which sent the label mapping is no longer the next hop 1. The LSR which sent the label mapping is no longer the next hop
for the mapped FEC, and the LSR is configured for conservative for the mapped FEC, and the LSR is configured for conservative
operation. operation.
2. The LSR receives a label mapping from an LSR which is not the 2. The LSR receives a label mapping from an LSR which is not the
next hop for the FEC, and the LSR is configured for conserva- next hop for the FEC, and the LSR is configured for conserva-
tive operation. tive operation.
skipping to change at page 80, line 24 skipping to change at page 80, line 24
| | | |
| Data.... | | Data.... |
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit U bit
Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear
(=0), a notification must be returned to the message originator (=0), a notification MUST be returned to the message originator
and the entire message must be ignored; if U is set (=1), the and the entire message MUST be ignored; if U is set (=1), the
unknown TLV is silently ignored and the rest of the message is unknown TLV is silently ignored and the rest of the message is
processed as if the unknown TLV did not exist. processed as if the unknown TLV did not exist.
The determination as to whether a vendor-private message is under- The determination as to whether a vendor-private message is under-
stood is based on the Type and the mandatory Vendor ID field. stood is based on the Type and the mandatory Vendor ID field.
F bit F bit
Forward unknown TLV bit. This bit only applies when the U bit is Forward unknown TLV bit. This bit only applies when the U bit is
set and the LDP message containing the unknown TLV is is to be set and the LDP message containing the unknown TLV is is to be
forwarded. If F is clear (=0), the unknown TLV is not forwarded forwarded. If F is clear (=0), the unknown TLV is not forwarded
skipping to change at page 93, line 23 skipping to change at page 93, line 23
sources. We would like to thank Rick Boivie, Ross Callon, Alex sources. We would like to thank Rick Boivie, Ross Callon, Alex
Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
Rekhter, and Arun Viswanathan for their input for RFC3036. Rekhter, and Arun Viswanathan for their input for RFC3036.
The editors would like to thank Eric Gray for his insight and input The editors would like to thank Eric Gray for his insight and input
to the current document. to the current document.
In addition, the editors would like to thank the members of the mpls In addition, the editors would like to thank the members of the mpls
working group for their ideas and the support they have given to this working group for their ideas and the support they have given to this
document, and in particular to Eric Rosen, Luca Martini, Markus Jork, document, and in particular to Eric Rosen, Luca Martini, Markus Jork,
Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan,
and Nick Weeds. Nick Weeds and Adrian Farrel.
9. References 9. References
9.1. Normative references 9.1. Normative references
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
skipping to change at page 97, line 21 skipping to change at page 97, line 21
. Downstream On Demand Independent Control, called . Downstream On Demand Independent Control, called
PulledUnconditional in [RFC3031]. PulledUnconditional in [RFC3031].
. Downstream On Demand Ordered Control, called . Downstream On Demand Ordered Control, called
PulledConditional in [RFC3031]. PulledConditional in [RFC3031].
- Label Withdrawal procedure, which is performed by a downstream - Label Withdrawal procedure, which is performed by a downstream
LSR to determine when to withdraw a FEC label mapping previ- LSR to determine when to withdraw a FEC label mapping previ-
ously distributed to LDP peers. The architecture defines a ously distributed to LDP peers. The architecture defines a
single Label Withdrawal procedure. Whenever an LSR breaks the single Label Withdrawal procedure. Whenever an LSR breaks the
binding between a label and a FEC, it must withdraw the FEC binding between a label and a FEC, it MUST withdraw the FEC
label mapping from all LDP peers to which it has previously label mapping from all LDP peers to which it has previously
sent the mapping. sent the mapping.
- Label Request procedure, which is performed by an upstream LSR - Label Request procedure, which is performed by an upstream LSR
to determine when to explicitly request that a downstream LSR to determine when to explicitly request that a downstream LSR
bind a label to a FEC and send it the corresponding label map- bind a label to a FEC and send it the corresponding label map-
ping. The architecture defines three Label Request procedures: ping. The architecture defines three Label Request procedures:
. Request Never. The LSR never requests a label. . Request Never. The LSR never requests a label.
skipping to change at page 102, line 25 skipping to change at page 102, line 25
distinguish such requests from a non-label merging MsgSource distinguish such requests from a non-label merging MsgSource
from duplicate label requests. from duplicate label requests.
The LSR uses the message ID of received Label Request messages The LSR uses the message ID of received Label Request messages
to detect duplicate requests. This means that an LSR (the to detect duplicate requests. This means that an LSR (the
upstream peer) may not reuse the message ID used for a Label upstream peer) may not reuse the message ID used for a Label
Request until the Label Request transaction has completed. Request until the Label Request transaction has completed.
2. When an LSR sends a label request to a peer it records that the 2. When an LSR sends a label request to a peer it records that the
request has been sent and marks it as outstanding. As long as request has been sent and marks it as outstanding. As long as
the request is marked outstanding the LSR should not send the request is marked outstanding the LSR SHOULD NOT send
another request for the same label to the peer. Such a second another request for the same label to the peer. Such a second
request would be a duplicate. The Send_Label_Request procedure request would be a duplicate. The Send_Label_Request procedure
described below obeys this rule. described below obeys this rule.
A duplicate label request is considered a protocol error and A duplicate label request is considered a protocol error and
should be dropped by the receiving LSR (perhaps with a suitable SHOULD be dropped by the receiving LSR (perhaps with a suitable
notification returned to MsgSource). notification returned to MsgSource).
3. If LSR is not merge-capable, this test will fail. 3. If LSR is not merge-capable, this test will fail.
4. The Send_Label procedure may fail due to lack of label 4. The Send_Label procedure may fail due to lack of label
resources, in which case the LSR should not perform the Label resources, in which case the LSR SHOULD NOT perform the Label
Use procedure. Use procedure.
A.1.2. Receive Label Mapping A.1.2. Receive Label Mapping
Summary: Summary:
The response by an LSR to receipt of a FEC label mapping from an The response by an LSR to receipt of a FEC label mapping from an
LDP peer may involve one or more of the following actions: LDP peer may involve one or more of the following actions:
- Transmission of a label release message for the FEC label to - Transmission of a label release message for the FEC label to
skipping to change at page 108, line 26 skipping to change at page 108, line 26
gate the Path Vector. gate the Path Vector.
10. LMp.22 through LMp.27 deal with a situation that can arise 10. LMp.22 through LMp.27 deal with a situation that can arise
when the LSR is using independent control and it receives a when the LSR is using independent control and it receives a
mapping from the downstream peer after it has sent a mapping mapping from the downstream peer after it has sent a mapping
to an upstream peer. In this situation the LSR needs to prop- to an upstream peer. In this situation the LSR needs to prop-
agate any changed attributes, such as Hop Count, upstream. If agate any changed attributes, such as Hop Count, upstream. If
Loop Detection is configured on, the propagated attributes Loop Detection is configured on, the propagated attributes
must include the Path Vector must include the Path Vector
11. An LSR operating in Downstream Unsolicited mode must process 11. An LSR operating in Downstream Unsolicited mode MUST process
any Label Request messages it receives. If there are pending any Label Request messages it receives. If there are pending
label requests, fall through into the Downstream on Demand label requests, fall through into the Downstream on Demand
procedures in order to satisfy the pending requests. procedures in order to satisfy the pending requests.
12. As determined by step LMp.1. 12. As determined by step LMp.1.
13. An LSR operating in ordered control mode may choose to skip at 13. An LSR operating in ordered control mode may choose to skip at
this stage the peer from which it received the advertisement this stage the peer from which it received the advertisement
that caused it to generate the label-map message. Doing so that caused it to generate the label-map message. Doing so
will in effect provide a form of split-horizon. will in effect provide a form of split-horizon.
skipping to change at page 111, line 38 skipping to change at page 111, line 38
LRl.12 Do any peers still hold Label for FEC? LRl.12 Do any peers still hold Label for FEC?
If so, goto LRl.14. If so, goto LRl.14.
LRl.13 Free the Label. LRl.13 Free the Label.
LRl.14 DONE. LRl.14 DONE.
Notes: Notes:
1. If LSR is using Downstream Unsolicited label distribution, it 1. If LSR is using Downstream Unsolicited label distribution, it
should not re-advertise a label mapping for FEC to MsgSource SHOULD NOT re-advertise a label mapping for FEC to MsgSource
until MsgSource requests it. until MsgSource requests it.
2. LRl.5 through LRl.9 deal with determining whether where the LSR 2. LRl.5 through LRl.9 deal with determining whether where the LSR
should propagate the label release to a downstream peer should propagate the label release to a downstream peer
(LRl.9). (LRl.9).
3. If LRl.9 is reached, no upstream LSR holds a label for the FEC, 3. If LRl.9 is reached, no upstream LSR holds a label for the FEC,
and the LSR holds a label for the FEC from the FEC Next Hop. and the LSR holds a label for the FEC from the FEC Next Hop.
The LSR could propagate the Label Release to the Next Hop. By The LSR could propagate the Label Release to the Next Hop. By
propagating the Label Release the LSR releases a potentially propagating the Label Release the LSR releases a potentially
skipping to change at page 118, line 50 skipping to change at page 118, line 50
Next Hop. Next Hop.
3. The purpose of the check on label retention mode is to avoid a 3. The purpose of the check on label retention mode is to avoid a
race with steps LMp.12-LMp.13 of the procedure for handling a race with steps LMp.12-LMp.13 of the procedure for handling a
Label Mapping message where the LSR operating in Conservative Label Mapping message where the LSR operating in Conservative
Label retention mode may have released a label mapping received Label retention mode may have released a label mapping received
from the New Next Hop before it detected the FEC next hop had from the New Next Hop before it detected the FEC next hop had
changed. changed.
4. Regardless of the Label Request procedure in use by the LSR, it 4. Regardless of the Label Request procedure in use by the LSR, it
must send a label request if the conditions in MUST send a label request if the conditions in
NH.13 hold. NH.13 hold.
Therefore it executes the Send_Label_Request procedure directly Therefore it executes the Send_Label_Request procedure directly
rather than perform LSR Label Request procedure. rather than perform LSR Label Request procedure.
A.1.8. Receive Notification / Label Request Aborted A.1.8. Receive Notification / Label Request Aborted
Summary: Summary:
When an LSR receives a Label Request Aborted notification from an When an LSR receives a Label Request Aborted notification from an
skipping to change at page 123, line 32 skipping to change at page 123, line 32
1. Iteration ResA.5 through ResA.8 handles the situation where the 1. Iteration ResA.5 through ResA.8 handles the situation where the
LSR is using Downstream Unsolicited label distribution and was LSR is using Downstream Unsolicited label distribution and was
previously unable to allocate a label for a FEC. previously unable to allocate a label for a FEC.
A.1.14. LSR decides to no longer label switch a FEC A.1.14. LSR decides to no longer label switch a FEC
Summary: Summary:
An LSR may unilaterally decide to no longer label switch a FEC for An LSR may unilaterally decide to no longer label switch a FEC for
an LDP peer. An LSR that does so must send a label withdraw message an LDP peer. An LSR that does so MUST send a label withdraw message
for the FEC to the peer. for the FEC to the peer.
Context: Context:
- Peer. The peer. - Peer. The peer.
- FEC. The FEC. - FEC. The FEC.
- PrevAdvLabel. The label for FEC previously advertised to Peer. - PrevAdvLabel. The label for FEC previously advertised to Peer.
skipping to change at page 124, line 11 skipping to change at page 124, line 11
PrevAdvLabel). (See Note 1.) PrevAdvLabel). (See Note 1.)
NoLS.2 DONE. NoLS.2 DONE.
Notes: Notes:
1. The LSR may remove the label from forwarding/switching use as 1. The LSR may remove the label from forwarding/switching use as
part of this event or as part of processing the label release part of this event or as part of processing the label release
from the peer in response to the label withdraw. If the LSR from the peer in response to the label withdraw. If the LSR
doesn't wait for the label reelase message from the peer it doesn't wait for the label reelase message from the peer it
should not reuse the label until it receives the label release. SHOULD NOT reuse the label until it receives the label release.
A.1.15. Timeout of deferred label request A.1.15. Timeout of deferred label request
Summary: Summary:
Label requests are deferred in response to No Route and Loop Label requests are deferred in response to No Route and Loop
Detected notifications. When a deferred FEC label request for a Detected notifications. When a deferred FEC label request for a
peer times out, the LSR sends the label request. peer times out, the LSR sends the label request.
Context: Context:
 End of changes. 93 change blocks. 
117 lines changed or deleted 120 lines changed or added

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