RFC 5036
LDP Specification
Pages: 135
Draft Standard
→ Errata
Obsoletes: 3036
Updated by: 6720 6790 7358 7552
Draft Standard
→ Errata
Obsoletes: 3036
Updated by: 6720 6790 7358 7552
Part 3 of 5 – Pages 44 to 78
3.5. LDP Messages
All LDP messages have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Mandatory Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit
Unknown message bit. Upon receipt of an unknown message, if U is
clear (=0), a notification is returned to the message originator;
if U is set (=1), the unknown message is silently ignored. The
sections following that define messages specify a value for the
U-bit.
Message Type
Identifies the type of message.
Message Length
Specifies the cumulative length in octets of the Message ID,
Mandatory Parameters, and Optional Parameters.
Message ID
32-bit value used to identify this message. Used by the sending
LSR to facilitate identifying Notification messages that may apply
to this message. An LSR sending a Notification message in
response to this message SHOULD include this Message ID in the
Status TLV carried by the Notification message; see Section
"Notification Message".
Mandatory Parameters
Variable length set of required message parameters. Some messages
have no required parameters.
For messages that have required parameters, the required
parameters MUST appear in the order specified by the individual
message specifications in the sections that follow.
Optional Parameters
Variable length set of optional message parameters. Many messages
have no optional parameters.
For messages that have optional parameters, the optional
parameters may appear in any order.
Note that there is no alignment requirement for the first octet of an
LDP message and that there is no padding at the end of a message;
that is, parameters can end at odd-byte boundaries.
The following message types are defined in this version of LDP:
Message Name Section Title
Notification "Notification Message"
Hello "Hello Message"
Initialization "Initialization Message"
KeepAlive "KeepAlive Message"
Address "Address Message"
Address Withdraw "Address Withdraw Message"
Label Mapping "Label Mapping Message"
Label Request "Label Request Message"
Label Abort Request "Label Abort Request Message"
Label Withdraw "Label Withdraw Message"
Label Release "Label Release Message"
The sections that follow specify the encodings and procedures for
these messages.
Some of the above messages are related to one another, for example
the Label Mapping, Label Request, Label Withdraw, and Label Release
messages.
While it is possible to think about messages related in this way in
terms of a message type that specifies a message class and a message
subtype that specifies a particular kind of message within that
class, this specification does not formalize the notion of a message
subtype.
The specification assigns type values for related messages, such as
the Label messages, from of a contiguous block in the 16-bit message
type number space.
3.5.1. Notification Message
An LSR sends a Notification message to inform an LDP peer of a
significant event. A Notification message signals a fatal error or
provides advisory information such as the outcome of processing an
LDP message or the state of the LDP session.
The encoding for the Notification message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
Status TLV
Indicates the event being signaled. The encoding for the Status
TLV is specified in Section "Status TLV".
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV. The following Optional Parameters are generic
and may appear in any Notification message:
Optional Parameter Type Length Value
Extended Status 0x0301 4 See below
Returned PDU 0x0302 var See below
Returned Message 0x0303 var See below
Other Optional Parameters, specific to the particular event being
signaled by the Notification messages, may appear. These are
described elsewhere.
Extended Status
The 4 octet value is an Extended Status Code that encodes
additional information that supplements the status information
contained in the Notification Status Code.
Returned PDU
An LSR uses this parameter to return part of an LDP PDU to the LSR
that sent it. The value of this TLV is the PDU header and as much
PDU data following the header as appropriate for the condition
being signaled by the Notification message.
Returned Message
An LSR uses this parameter to return part of an LDP message to the
LSR that sent it. The value of this TLV is the message type and
length fields and as much message data following the type and
length fields as appropriate for the condition being signaled by
the Notification message.
3.5.1.1. Notification Message Procedures
If an LSR encounters a condition requiring it to notify its peer with
advisory or error information, it sends the peer a Notification
message containing a Status TLV that encodes the information and
optionally additional TLVs that provide more information about the
condition.
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 the Notification message the LSR SHOULD terminate the LDP
session by closing the session TCP connection and discard all state
associated with the session, including all label-FEC bindings learned
via the session.
When an LSR receives a Notification message that carries a Status
Code that indicates a fatal error, it SHOULD terminate the LDP
session immediately by closing the session TCP connection and discard
all state associated with the session, including all label-FEC
bindings learned via the session.
The above statement does not apply to the processing of the Shutdown
message in the session initialization procedure. When an LSR
receives a Shutdown message during session initialization, it SHOULD
transmit a Shutdown message and then close the transport connection.
3.5.1.2. Events Signaled by Notification Messages
It is useful for descriptive purpose to classify events signaled by
Notification messages into the following categories.
3.5.1.2.1. Malformed PDU or Message
Malformed LDP PDUs or messages that are part of the LDP Discovery
mechanism are handled by silently discarding them.
An LDP PDU received on a TCP connection for an LDP session is
malformed if:
- The LDP Identifier in the PDU header is unknown to the
receiver, or it is known but is not the LDP Identifier
associated by the receiver with the LDP peer for this LDP
session. This is a fatal error signaled by the Bad LDP
Identifier Status Code.
- The LDP protocol version is not supported by the receiver, d or
it is supported but is not the version negotiated for the
session during session establishment. This is a fatal error
signaled by the Bad Protocol Version Status Code.
- The PDU Length field is too small (< 14) or too large (>
maximum PDU length). This is a fatal error signaled by the Bad
PDU Length Status Code. Section "Initialization Message"
describes how the maximum PDU length for a session is
determined.
An LDP message is malformed if:
- The Message Type is unknown.
If the Message Type is < 0x8000 (high order bit = 0), it is an
error signaled by the Unknown Message Type Status Code.
If the Message Type is >= 0x8000 (high order bit = 1), it is
silently discarded.
- The Message Length is too large, that is, indicates that the
message extends beyond the end of the containing LDP PDU. This
is a fatal error signaled by the Bad Message Length Status
Code.
- The Message Length is too small, that is, smaller than the
smallest possible value component. This is a fatal error
signaled by the Bad Message Length Status Code.
- The message is missing one or more Mandatory Parameters. This
is a non-fatal error signaled by the Missing Message Parameters
Status Code.
3.5.1.2.2. Unknown or Malformed TLV
Malformed TLVs contained in LDP messages that are part of the LDP
Discovery mechanism are handled by silently discarding the containing
message.
A TLV contained in an LDP message received on a TCP connection of an
LDP is malformed if:
- The TLV Length is too large, that is, indicates that the TLV
extends beyond the end of the containing message. This is a
fatal error signaled by the Bad TLV Length Status Code.
- The TLV type is unknown.
If the TLV type is < 0x8000 (high order bit = 0), it is an
error signaled by the Unknown TLV Status Code.
If the TLV type is >= 0x8000 (high order bit = 1), the TLV is
silently dropped.
- The TLV Value is malformed. This occurs when the receiver
handles the TLV but cannot decode the TLV Value. This is
interpreted as indicative of a bug in either the sending or
receiving LSR. It is a fatal error signaled by the Malformed
TLV Value Status Code.
3.5.1.2.3. Session KeepAlive Timer Expiration
This is a fatal error signaled by the KeepAlive Timer Expired Status
Code.
3.5.1.2.4. Unilateral Session Shutdown
This is a fatal event signaled by the Shutdown Status Code. The
Notification message may optionally include an Extended Status TLV to
provide a reason for the Shutdown. The sending LSR terminates the
session immediately after sending the Notification.
3.5.1.2.5. Initialization Message Events
The session initialization negotiation (see Section "Session
Initialization") may fail if the session parameters received in the
Initialization message are unacceptable. This is a fatal error. The
specific Status Code depends on the parameter deemed unacceptable,
and is defined in Sections "Initialization Message".
3.5.1.2.6. Events Resulting from Other Messages
Messages other than the Initialization message may result in events
that must be signaled to LDP peers via Notification messages. These
events and the Status Codes used in the Notification messages to
signal them are described in the sections that describe these
messages.
3.5.1.2.7. Internal Errors
An LDP implementation may be capable of detecting problem conditions specific to its implementation. When such a condition prevents an implementation from interacting correctly with a peer, the implementation should, when capable of doing so, use the Internal Error Status Code to signal the peer. This is a fatal error.3.5.1.2.8. Miscellaneous Events
These are events that fall into none of the categories above. There are no miscellaneous events defined in this version of the protocol.3.5.2. Hello Message
LDP Hello messages are exchanged as part of the LDP Discovery Mechanism; see Section "LDP Discovery". The encoding for the Hello message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Hello (0x0100) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Hello Parameters TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. Common Hello Parameters TLV Specifies parameters common to all Hello messages. The encoding for the Common Hello Parameters TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Common Hello Parms(0x0400)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time |T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hold Time
Hello hold time in seconds. An LSR maintains a record of
Hellos received from potential peers (see Section "Hello
Message Procedures"). Hello Hold Time specifies the time the
sending LSR will maintain its record of Hellos from the
receiving LSR without receipt of another Hello.
A pair of LSRs negotiates the hold times they use for Hellos
from each other. Each proposes a hold time. The hold time
used is the minimum of the hold times proposed in their Hellos.
A value of 0 means use the default, which is 15 seconds for
Link Hellos and 45 seconds for Targeted Hellos. A value of
0xffff means infinite.
T, Targeted Hello
A value of 1 specifies that this Hello is a Targeted Hello. A
value of 0 specifies that this Hello is a Link Hello.
R, Request Send Targeted Hellos
A value of 1 requests the receiver to send periodic Targeted
Hellos to the source of this Hello. A value of 0 makes no
request.
An LSR initiating Extended Discovery sets R to 1. If R is 1,
the receiving LSR checks whether it has been configured to send
Targeted Hellos to the Hello source in response to Hellos with
this request. If not, it ignores the request. If so, it
initiates periodic transmission of Targeted Hellos to the Hello
source.
Reserved
This field is reserved. It MUST be set to zero on transmission
and ignored on receipt.
Optional Parameters
This variable length field of the Hello message contains 0 or more
parameters, each encoded as a TLV. The optional parameters
defined by this version of the protocol are
Optional Parameter Type Length Value
IPv4 Transport Address 0x0401 4 See below
Configuration 0x0402 4 See below
Sequence Number
IPv6 Transport Address 0x0403 16 See below
IPv4 Transport Address
Specifies the IPv4 address to be used for the sending LSR when
opening the LDP session TCP connection. If this optional TLV
is not present, the IPv4 source address for the UDP packet
carrying the Hello SHOULD be used.
Configuration Sequence Number
Specifies a 4 octet unsigned configuration sequence number that
identifies the configuration state of the sending LSR. Used by
the receiving LSR to detect configuration changes on the
sending LSR.
IPv6 Transport Address
Specifies the IPv6 address to be used for the sending LSR when
opening the LDP session TCP connection. If this optional TLV
is not present the IPv6 source address for the UDP packet
carrying the Hello SHOULD be used.
3.5.2.1. Hello Message Procedures
An LSR receiving Hellos from another LSR maintains a Hello adjacency
corresponding to the Hellos. The LSR maintains a hold timer with the
Hello adjacency, which it restarts whenever it receives a Hello that
matches the Hello adjacency. If the hold timer for a Hello adjacency
expires the LSR discards the Hello adjacency: see Sections
"Maintaining Hello Adjacencies" and "Maintaining LDP Sessions".
We recommend that the interval between Hello transmissions be at most
one third of the Hello hold time.
An LSR processes a received LDP Hello as follows:
1. The LSR checks whether the Hello is acceptable. The criteria
for determining whether a Hello is acceptable are
implementation dependent (see below for example criteria).
2. If the Hello is not acceptable, the LSR ignores it.
3. If the Hello is acceptable, the LSR checks whether it has a
Hello adjacency for the Hello source. If so, it restarts the
hold timer for the Hello adjacency. If not, it creates a Hello
adjacency for the Hello source and starts its hold timer.
4. If the Hello carries any optional TLVs, the LSR processes them
(see below).
5. Finally, if the LSR has no LDP session for the label space
specified by the LDP Identifier in the PDU header for the
Hello, it follows the procedures of Section "LDP Session
Establishment".
The following are examples of acceptability criteria for Link and
Targeted Hellos:
A Link Hello is acceptable if the interface on which it was
received has been configured for label switching.
A Targeted Hello from source address A is acceptable if either:
- The LSR has been configured to accept Targeted Hellos, or
- The LSR has been configured to send Targeted Hellos to A.
The following describes how an LSR processes Hello optional TLVs:
Transport Address
The LSR associates the specified transport address with the
Hello adjacency.
Configuration Sequence Number
The Configuration Sequence Number optional parameter is used by
the sending LSR to signal configuration changes to the
receiving LSR. When a receiving LSR playing the active role in
LDP session establishment detects a change in the sending LSR
configuration, it may clear the session setup backoff delay, if
any, associated with the sending LSR (see Section "Session
Initialization").
A sending LSR using this optional parameter is responsible for
maintaining the configuration sequence number it transmits in
Hello messages. Whenever there is a configuration change on
the sending LSR, it increments the configuration sequence
number.
3.5.3. Initialization Message
The LDP Initialization message is exchanged as part of the LDP
session establishment procedure; see Section "LDP Session
Establishment".
The encoding for the Initialization message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Initialization (0x0200) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Session Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
Common Session Parameters TLV
Specifies values proposed by the sending LSR for parameters that
must be negotiated for every LDP session.
The encoding for the Common Session Parameters TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Sess Parms (0x0500)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | KeepAlive Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Reserved | PVLim | Max PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
Protocol Version
Two octet unsigned integer containing the version number of the
protocol. This version of the specification specifies LDP
protocol version 1.
KeepAlive Time
Two octet unsigned non zero integer that indicates the number
of seconds that the sending LSR proposes for the value of the
KeepAlive Time. The receiving LSR MUST calculate the value of
the KeepAlive Timer by using the smaller of its proposed
KeepAlive Time and the KeepAlive Time received in the PDU. The
value chosen for KeepAlive Time indicates the maximum number of
seconds that may elapse between the receipt of successive PDUs
from the LDP peer on the session TCP connection. The KeepAlive
Timer is reset each time a PDU arrives.
A, Label Advertisement Discipline
Indicates the type of Label advertisement. A value of 0 means
Downstream Unsolicited advertisement; a value of 1 means
Downstream On Demand.
If one LSR proposes Downstream Unsolicited and the other
proposes Downstream on Demand, the rules for resolving this
difference is:
- If the session is for a label-controlled ATM link or a
label-controlled Frame Relay link, then Downstream on Demand
MUST be used.
- Otherwise, Downstream Unsolicited MUST be used.
If the label advertisement discipline determined in this way
is unacceptable to an LSR, it MUST send a Session
Rejected/Parameters Advertisement Mode Notification message
in response to the Initialization message and not establish
the session.
D, Loop Detection
Indicates whether Loop Detection based on Path Vectors is
enabled. A value of 0 means that Loop Detection is disabled; a
value of 1 means that Loop Detection is enabled.
PVLim, Path Vector Limit
The configured maximum Path Vector length. MUST be 0 if Loop
Detection is disabled (D = 0). If the Loop Detection
procedures would require the LSR to send a Path Vector that
exceeds this limit, the LSR will behave as if a loop had been
detected for the FEC in question.
When Loop Detection is enabled in a portion of a network, it is
recommended that all LSRs in that portion of the network be
configured with the same Path Vector limit. Although knowledge
of a peer's Path Vector limit will not change an LSR's
behavior, it does enable the LSR to alert an operator to a
possible misconfiguration.
Reserved
This field is reserved. It MUST be set to zero on transmission
and ignored on receipt.
Max PDU Length
Two octet unsigned integer that proposes the maximum allowable
length for LDP PDUs for the session. A value of 255 or less
specifies the default maximum length of 4096 octets.
The receiving LSR MUST calculate the maximum PDU length for the
session by using the smaller of its and its peer's proposals
for Max PDU Length. The default maximum PDU length applies
before session initialization completes.
If the maximum PDU length determined this way is unacceptable
to an LSR, it MUST send a Session Rejected/Parameters Max PDU
Length Notification message in response to the Initialization
message and not establish the session.
Receiver LDP Identifier
Identifies the receiver's label space. This LDP Identifier,
together with the sender's LDP Identifier in the PDU header,
enables the receiver to match the Initialization message with
one of its Hello adjacencies; see Section "Hello Message
Procedures".
If there is no matching Hello adjacency, the LSR MUST send a
Session Rejected/No Hello Notification message in response to
the Initialization message and not establish the session.
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters are:
Optional Parameter Type Length Value
ATM Session Parameters 0x0501 var See below
Frame Relay Session 0x0502 var See below
Parameters
ATM Session Parameters
Used when an LDP session manages label exchange for an ATM link
to specify ATM-specific session parameters.
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|0| ATM Sess Parms (0x0501) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Label Range Component N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M, ATM Merge Capabilities
Specifies the merge capabilities of an ATM switch. The
following values are supported in this version of the
specification:
Value Meaning
0 Merge not supported
1 VP Merge supported
2 VC Merge supported
3 VP & VC Merge supported
If the merge capabilities of the LSRs differ, then:
- Non-merge and VC-merge LSRs may freely interoperate.
- The interoperability of VP-merge-capable switches with non-
VP-merge-capable switches is a subject for future study.
When the LSRs differ on the use of VP merge, the session is
established, but VP merge is not used.
Note that if VP merge is used, it is the responsibility of the
ingress node to ensure that the chosen VCI is unique within the
LSR domain.
N, Number of label range components
Specifies the number of ATM Label Range Components included in
the TLV.
D, VC Directionality
A value of 0 specifies bidirectional VC capability, meaning the
LSR can (within a given VPI) support the use of a given VCI as
a label for both link directions independently. A value of 1
specifies unidirectional VC capability, meaning (within a given
VPI) a given VCI may appear in a label mapping for one
direction on the link only. When either or both of the peers
specifies unidirectional VC capability, both LSRs use
unidirectional VC label assignment for the link as follows.
The LSRs compare their LDP Identifiers as unsigned integers.
The LSR with the larger LDP Identifier may assign only odd-
numbered VCIs in the VPI/VCI range as labels. The system with
the smaller LDP Identifier may assign only even-numbered VCIs
in the VPI/VCI range as labels.
Reserved
This field is reserved. It MUST be set to zero on transmission
and ignored on receipt.
One or more ATM Label Range Components
A list of ATM Label Range Components that together specify the
Label range supported by the transmitting LSR.
A receiving LSR MUST calculate the intersection between the
received range and its own supported label range. The
intersection is the range in which the LSR may allocate and
accept labels. LSRs MUST NOT establish a session with
neighbors for which the intersection of ranges is NULL. In
this case, the LSR MUST send a Session Rejected/Parameters
Label Range Notification message in response to the
Initialization message and not establish the session.
The encoding for an ATM Label Range Component is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res
This field is reserved. It MUST be set to zero on
transmission and MUST be ignored on receipt.
Minimum VPI (12 bits)
This 12-bit field specifies the lower bound of a block of
Virtual Path Identifiers that is supported on the
originating switch. If the VPI is less than 12 bits, it
SHOULD be right justified in this field and preceding bits
SHOULD be set to 0.
Minimum VCI (16 bits)
This 16-bit field specifies the lower bound of a block of
Virtual Channel Identifiers that is supported on the
originating switch. If the VCI is less than 16 bits, it
SHOULD be right justified in this field and preceding bits
SHOULD be set to 0.
Maximum VPI (12 bits)
This 12-bit field specifies the upper bound of a block of
Virtual Path Identifiers that is supported on the
originating switch. If the VPI is less than 12 bits, it
SHOULD be right justified in this field and preceding bits
SHOULD be set to 0.
Maximum VCI (16 bits)
This 16-bit field specifies the upper bound of a block of
Virtual Connection Identifiers that is supported on the
originating switch. If the VCI is less than 16 bits, it
SHOULD be right justified in this field and preceding bits
SHOULD be set to 0.
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,
and the receiving LSR MUST ignore the Minimum and Maximum VPI
fields.
Frame Relay Session Parameters
Used when an LDP session manages label exchange for a Frame
Relay link to specify Frame Relay-specific session parameters.
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|0| FR Sess Parms (0x0502) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay Label Range Component N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M, Frame Relay Merge Capabilities
Specifies the merge capabilities of a Frame Relay switch. The
following values are supported in this version of the
specification:
Value Meaning
0 Merge not supported
1 Merge supported
Non-merge and merge Frame Relay LSRs may freely interoperate.
N, Number of label range components
Specifies the number of Frame Relay Label Range Components
included in the TLV.
D, VC Directionality
A value of 0 specifies bidirectional VC capability, meaning the
LSR can support the use of a given DLCI as a label for both
link directions independently. A value of 1 specifies
unidirectional VC capability, meaning a given DLCI may appear
in a label mapping for one direction on the link only. When
either or both of the peers specifies unidirectional VC
capability, both LSRs use unidirectional VC label assignment
for the link as follows. The LSRs compare their LDP
Identifiers as unsigned integers. The LSR with the larger LDP
Identifier may assign only odd-numbered DLCIs in the range as
labels. The system with the smaller LDP Identifier may assign
only even-numbered DLCIs in the range as labels.
Reserved
This field is reserved. It MUST be set to zero on transmission
and ignored on receipt.
One or more Frame Relay Label Range Components
A list of Frame Relay Label Range Components that together
specify the Label range supported by the transmitting LSR.
A receiving LSR MUST calculate the intersection between the
received range and its own supported label range. The
intersection is the range in which the LSR may allocate and
accept labels. LSRs MUST NOT establish a session with
neighbors for which the intersection of ranges is NULL. In
this case, the LSR MUST send a Session Rejected/Parameters
Label Range Notification message in response to the
Initialization message and not establish the session.
The encoding for a Frame Relay Label Range Component is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved. It MUST be set to zero on transmission
and ignored on receipt.
Len
This field specifies the number of bits of the DLCI. The
following values are supported:
Len DLCI Bits
0 10
2 23
Len values 1 and 3 are reserved.
Minimum DLCI
This 23-bit field specifies the lower bound of a block of Data
Link Connection Identifiers (DLCIs) that is supported on the
originating switch. The DLCI SHOULD be right justified in this
field and unused bits SHOULD be set to 0.
Maximum DLCI
This 23-bit field specifies the upper bound of a block of Data
Link Connection Identifiers (DLCIs) that is supported on the
originating switch. The DLCI SHOULD be right justified in this
field and unused bits SHOULD be set to 0.
Note that there is no Generic Session Parameters TLV for sessions
that advertise Generic Labels.
3.5.3.1. Initialization Message Procedures
See Section "LDP Session Establishment" and particularly Section
"Session Initialization" for general procedures for handling the
Initialization message.
3.5.4. KeepAlive Message
An LSR sends KeepAlive messages as part of a mechanism that monitors
the integrity of the LDP session transport connection.
The encoding for the KeepAlive message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| KeepAlive (0x0201) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
Optional Parameters
No optional parameters are defined for the KeepAlive message.
3.5.4.1. KeepAlive Message Procedures
The KeepAlive Timer mechanism described in Section "Maintaining LDP
Sessions" resets a session KeepAlive Timer every time an LDP PDU is
received on the session TCP connection. The KeepAlive message is
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 MUST arrange that its peer receive an LDP message from it at
least every KeepAlive Time period. Any LDP protocol message will do
but, in circumstances where no other LDP protocol messages have been sent within the period, a KeepAlive message MUST be sent.3.5.5. Address Message
An LSR sends the Address message to an LDP peer to advertise its interface addresses. The encoding for the Address message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Address (0x0300) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address List TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. Address List TLV The list of interface addresses being advertised by the sending LSR. The encoding for the Address List TLV is specified in Section "Address List TLV". Optional Parameters No optional parameters are defined for the Address message.3.5.5.1. Address Message Procedures
An LSR that receives an Address message uses the addresses it learns to maintain a database for mapping between peer LDP Identifiers and next hop addresses; see Section "LDP Identifiers and Next Hop Addresses". When a new LDP session is initialized and before sending Label Mapping or Label Request messages, an LSR SHOULD advertise its interface addresses with one or more Address messages. Whenever an LSR "activates" a new interface address, it SHOULD advertise the new address with an Address message.
Whenever an LSR "de-activates" a previously advertised address, it SHOULD withdraw the address with an Address Withdraw message; see Section "Address Withdraw Message". If an LSR does not support the Address Family specified in the Address List TLV, it SHOULD send an Unsupported Address Family Notification to its LDP signaling an error and abort processing the message. An LSR may re-advertise an address (A) that it has previously advertised without explicitly withdrawing the address. If the receiver already has address binding (LSR, A), it SHOULD take no further action. An LSR may withdraw an address (A) without having previously advertised it. If the receiver has no address binding (LSR, A), it SHOULD take no further action.3.5.6. Address Withdraw Message
An LSR sends the Address Withdraw message to an LDP peer to withdraw previously advertised interface addresses. The encoding for the Address Withdraw message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Address Withdraw (0x0301) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address List TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. Address List TLV The list of interface addresses being withdrawn by the sending LSR. The encoding for the Address List TLV is specified in Section "Address List TLV".
Optional Parameters
No optional parameters are defined for the Address Withdraw
message.
3.5.6.1. Address Withdraw Message Procedures
See Section "Address Message Procedures".
3.5.7. Label Mapping Message
An LSR sends a Label Mapping message to an LDP peer to advertise
FEC-label bindings to the peer.
The encoding for the Label Mapping message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
FEC TLV
Specifies the FEC component of the FEC-Label mapping being
advertised. See Section "FEC TLVs" for encoding.
Label TLV
Specifies the Label component of the FEC-Label mapping. See
Section "Label TLV" for encoding.
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters are:
Optional Parameter Length Value
Label Request 4 See below
Message ID TLV
Hop Count TLV 1 See below
Path Vector TLV variable See below
The encodings for the Hop Count and Path Vector TLVs can be found
in Section "TLV Encodings for Commonly Used Parameters".
Label Request Message ID
If this Label Mapping message is a response to a Label Request
message, it MUST include the Label Request Message ID optional
parameter. The value of this optional parameter is the Message
ID of the corresponding Label Request message.
Hop Count
Specifies the running total of the number of LSR hops along the
LSP being set up by the Label message. Section "Hop Count
Procedures" describes how to handle this TLV.
Path Vector
Specifies the LSRs along the LSP being set up by the Label
message. Section "Path Vector Procedures" describes how to
handle this TLV.
3.5.7.1. Label Mapping Message Procedures
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
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
whether it uses a different mapping for each of its peers.
An LSR is responsible for the consistency of the label mappings it
has distributed and that its peers have these mappings.
An LSR receiving a Label Mapping message from a downstream LSR for a
Prefix SHOULD NOT use the label for forwarding unless its routing
table contains an entry that exactly matches the FEC Element.
See Appendix A, "LDP Label Distribution Procedures", for more
details.
3.5.7.1.1. Independent Control Mapping
If an LSR is configured for independent control, a mapping message is
transmitted by the LSR upon any of the following conditions:
1. The LSR recognizes a new FEC via the forwarding table, and the
label advertisement mode is Downstream Unsolicited
advertisement.
2. The LSR receives a Request message from an upstream peer for a
FEC present in the LSR's forwarding table.
3. The next hop for a FEC changes to another LDP peer, and Loop
detection is configured.
4. The attributes of a mapping change.
5. The receipt of a mapping from the downstream next hop AND
a) no upstream mapping has been created OR
b) loop detection is configured OR
c) the attributes of the mapping have changed.
3.5.7.1.2. Ordered Control Mapping
If an LSR is doing Ordered Control, a Mapping message is transmitted
by downstream LSRs upon any of the following conditions:
1. The LSR recognizes a new FEC via the forwarding table and is
the egress for that FEC.
2. The LSR receives a Request message from an upstream peer for a
FEC present in the LSR's forwarding table, and the LSR is the
egress for that FEC OR has a downstream mapping for that FEC.
3. The next hop for a FEC changes to another LDP peer, and Loop
Detection is configured.
4. The attributes of a mapping change.
5. The receipt of a mapping from the downstream next hop AND
a) no upstream mapping has been created OR
b) Loop Detection is configured OR
c) the attributes of the mapping have changed.
3.5.7.1.3. Downstream on Demand Label Advertisement
In general, the upstream LSR is responsible for requesting label
mappings when operating in Downstream on Demand mode. However,
unless some rules are followed, it is possible for neighboring LSRs
with different advertisement modes to get into a livelock situation
where everything is functioning properly, but no labels are
distributed. 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, Ru is using Downstream Unsolicited advertisement mode and Rd is using 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 will advertise a label if it wants Ru to use one. If Rd and Ru operate as suggested, no labels will be distributed from Rd to Ru. This livelock situation can be avoided if the following rule is observed: an LSR operating in Downstream on Demand mode SHOULD NOT be expected to send unsolicited mapping advertisements. Therefore, if the downstream LSR is operating in Downstream on Demand mode, the upstream LSR is responsible for requesting label mappings as needed.3.5.7.1.4. Downstream Unsolicited Label Advertisement
In general, the downstream LSR is responsible for advertising a label mapping when it wants an upstream LSR to use the label. An upstream LSR may issue a mapping request if it so desires. The combination of Downstream Unsolicited mode and Conservative Label retention can lead to a situation where an LSR releases the label for a FEC that it later needs. For example, if LSR Rd advertises to LSR Ru the label for a FEC for which it is not Ru's next hop, Ru will release the label. If Ru's next hop for the FEC later changes to Rd, it needs the previously released label. To deal with this situation, either Ru can explicitly request the label when it needs it, or Rd can periodically re-advertise it to Ru. In many situations Ru will know when it needs the label from Rd. For example, when its next hop for the FEC changes to Rd. However, there could be situations when Ru does not. For example, Rd may be attempting to establish an LSP with non-standard properties. Forcing Ru to explicitly request the label in this situation would require it to maintain state about a potential LSP with non-standard properties. In situations where Ru knows it needs the label, it is responsible for explicitly requesting the label by means of a Label Request message. In situations where Ru may not know that it needs the label, Rd is responsible for periodically re-advertising the label to Ru. For this version of LDP, the only situation where Ru knows it needs a label for a FEC from Rd is when Rd is its next hop for the FEC, Ru does not have a label from Rd, and the LSP for the FEC is one that can be established with TLVs defined in this document.
3.5.8. Label Request Message
An LSR sends the Label Request message to an LDP peer to request a binding (mapping) for a FEC. The encoding for the Label Request message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. FEC TLV The FEC for which a label is being requested. See Section "FEC TLV" for encoding. Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are: Optional Parameter Length Value Hop Count TLV 1 See below Path Vector TLV variable See below The encodings for the Hop Count and Path Vector TLVs can be found in Section "TLV Encodings for Commonly Used Parameters". Hop Count Specifies the running total of the number of LSR hops along the LSP being set up by the Label Request message. Section "Hop Count Procedures" describes how to handle this TLV. Path Vector Specifies the LSRs along the LSR being set up by the Label Request message. Section "Path Vector Procedures" describes how to handle this TLV.
3.5.8.1. Label Request Message Procedures
The Request message is used by an upstream LSR to explicitly request that the downstream LSR assign and advertise a label for a FEC. An LSR may transmit a Request message under any of the following conditions: 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 mapping from the next hop for the given FEC. 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. Note that if the LSR already has a pending Label Request message for the new next hop, it SHOULD NOT issue an additional Label Request in response to the next hop change. 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 already have a mapping from the next hop. Note that since a non-merge LSR must set up a separate LSP for each upstream peer requesting a label, it must send a separate Label Request for each such peer. A consequence of this is that a non-merge LSR may have multiple Label Request messages for a given FEC outstanding at the same time. The receiving LSR SHOULD respond to a Label Request message with a Label Mapping for the requested label or with a Notification message indicating why it cannot satisfy the request. 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. Unless its routing table includes an entry that exactly matches the requested Prefix, the LSR MUST respond with a No Route Notification message. The message ID of the Label Request message serves as an identifier for the Label Request transaction. When the receiving LSR responds with a Label Mapping message, the mapping message MUST include a Label Request/Returned Message ID TLV optional parameter that includes the message ID of the Label Request message. Note that since LSRs use Label Request message IDs as transaction identifiers, an LSR SHOULD NOT reuse the message ID of a Label Request message until the corresponding transaction completes.
This version of the protocol defines the following Status Codes for
the Notification message that signals a request cannot be satisfied:
No Route
The FEC for which a label was requested includes a FEC Element
for which the LSR does not have a route.
No Label Resources
The LSR cannot provide a label because of resource limitations.
When resources become available, the LSR MUST notify the
requesting LSR by sending a Notification message with the Label
Resources Available Status Code.
An LSR that receives a No Label Resources response to a Label
Request message MUST NOT issue further Label Request messages
until it receives a Notification message with the Label
Resources Available Status Code.
Loop Detected
The LSR has detected a looping Label Request message.
See Appendix A, "LDP Label Distribution Procedures", for more
details.
3.5.9. Label Abort Request Message
The Label Abort Request message may be used to abort an outstanding
Label Request message.
The encoding for the Label Abort Request message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Abort Req (0x0404) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
FEC TLV
Identifies the FEC for which the Label Request is being aborted.
Label Request Message ID TLV
Specifies the message ID of the Label Request message to be
aborted.
Optional Parameters
No optional parameters are defined for the Label Abort Req
message.
3.5.9.1. Label Abort Request Message Procedures
An LSR Ru may send a Label Abort Request message to abort an
outstanding Label Request message for a FEC sent to an LSR Rd in the
following circumstances:
1. Ru's next hop for the FEC has changed from LSR Rd to LSR X; or
2. Ru is a non-merge, non-ingress LSR and has received a Label
Abort Request for the FEC from an upstream peer Y.
3. Ru is a merge, non-ingress LSR and has received a Label Abort
Request for the FEC from an upstream peer Y and Y is the only
(last) upstream LSR requesting a label for the FEC.
There may be other situations where an LSR may choose to abort an
outstanding Label Request message in order to reclaim resource
associated with the pending LSP. However, specification of general
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
previously responded to the Label Request being aborted with a Label
Mapping message or some other Notification message, it MUST
acknowledge the abort by responding with a Label Request Aborted
Notification message. The Notification MUST include a Label Request
Message ID TLV that carries the message ID of the aborted Label
Request message.
If an LSR receives a Label Abort Request Message after it has
responded to the Label Request in question with a Label Mapping
message or a Notification message, it ignores the abort request.
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
abort the Label Request, the label in the Label Mapping message is
valid. The LSR may choose to use the label or to release it with a
Label Release message.
An LSR aborting a Label Request message may not reuse the Message ID
for the Label Request message until it receives one of the following
from its peer:
- A Label Request Aborted Notification message acknowledging the
abort;
- A Label Mapping message in response to the Label Request
message being aborted;
- A Notification message in response to the Label Request message
being aborted (e.g., Loop Detected, No Label Resources, etc.).
To protect itself against tardy peers or faulty peer implementations
an LSR may choose to time out receipt of the above. The timeout
period should be relatively long (several minutes). If the timeout
period elapses with no reply from the peer, the LSR may reuse the
Message ID of the Label Request message; if it does so, it should
also discard any record of the outstanding Label Request and Label
Abort messages.
Note that the response to a Label Abort Request message is never
"ordered". That is, the response does not depend on the downstream
state of the LSP setup being aborted. An LSR receiving a Label Abort
Request message MUST process it immediately, regardless of the
downstream state of the LSP, responding with a Label Request Aborted
Notification or ignoring it, as appropriate.
3.5.10. Label Withdraw Message
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
mappings the LSR had previously advertised. This breaks the mapping
between the FECs and the labels.
The encoding for the Label Withdraw Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Withdraw (0x0402) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
FEC TLV
Identifies the FEC for which the FEC-label mapping is being
withdrawn.
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters are:
Optional Parameter Length Value
Label TLV variable See below
The encoding for Label TLVs are found in Section "Label TLVs".
Label
If present, specifies the label being withdrawn (see procedures
below).
3.5.10.1. Label Withdraw Message Procedures
An LSR transmits a Label Withdraw message under the following
conditions:
1. The LSR no longer recognizes a previously known FEC for which
it has advertised a label.
2. The LSR has decided unilaterally (e.g., via configuration) to
no longer label switch a FEC (or FECs) with the label mapping
being withdrawn.
The FEC TLV specifies the FEC for which labels are to be withdrawn. If no Label TLV follows the FEC, all labels associated with the FEC are to be withdrawn; otherwise, only the label specified in the optional Label TLV is to be withdrawn. The FEC TLV may contain the Wildcard FEC Element; if so, it may contain no other FEC Elements. In this case, if the Label Withdraw message contains an optional Label TLV, then the label is to be withdrawn from all FECs to which it is bound. If there is not an optional Label TLV in the Label Withdraw message, then the sending LSR is withdrawing all label mappings previously advertised to the receiving LSR. An LSR that receives a Label Withdraw message MUST respond with a Label Release message. See Appendix A, "LDP Label Distribution Procedures", for more details.3.5.11. Label Release Message
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 previously requested of and/or advertised by the peer. The encoding for the Label Release Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Release (0x0403) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. FEC TLV Identifies the FEC for which the FEC-label mapping is being released.
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters are:
Optional Parameter Length Value
Label TLV variable See below
The encodings for Label TLVs are found in Section "Label TLVs".
Label
If present, the label being released (see procedures below).
3.5.11.1. Label Release Message Procedures
An LSR transmits a Label Release message to a peer when it no longer
needs a label previously received from or requested of that peer.
An LSR MUST transmit a Label Release message under any of the
following conditions:
1. The LSR that sent the label mapping is no longer the next hop
for the mapped FEC, and the LSR is configured for conservative
operation.
2. The LSR receives a label mapping from an LSR that is not the
next hop for the FEC, and the LSR is configured for
conservative operation.
3. The LSR receives a Label Withdraw message.
Note that if an LSR is configured for "liberal mode", a release
message will never be transmitted in the case of conditions (1) and
(2) as specified above. In this case, the upstream LSR keeps each
unused label, so that it can immediately be used later if the
downstream peer becomes the next hop for the FEC.
The FEC TLV specifies the FEC for which labels are to be released.
If no Label TLV follows the FEC, all labels associated with the FEC
are to be released; otherwise, only the label specified in the
optional Label TLV is to be released.
The FEC TLV may contain the Wildcard FEC Element; if so, it may
contain no other FEC Elements. In this case, if the Label Release
message contains an optional Label TLV, then the label is to be
released for all FECs to which it is bound. If there is not an
optional Label TLV in the Label Release message, then the sending LSR
is releasing all label mappings previously learned from the receiving LSR. See Appendix A, "LDP Label Distribution Procedures", for more details.
(page 78 continued on part 4)