Skip to main content

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.