Label Distribution Protocol (LDP): Overview

LDP, defined in RFC 3035, contains a set of procedures and messages by which LSRs establish LSPs through a network by mapping Layer 3 routing information directly to Layer 2 1/2 switched paths. LDP associates a Forwarding Equivalence Class (FEC) with each LSP it creates. The FEC associated with an LSP specifies which packets are mapped to that LSP.

In essence, LDP is used to distribute <label, prefix> bindings. It runs in parallel with routing protocols. Other label-distribution mechanisms, such as TDP, Resource Reservation Protocol (RSVP), Protocol-Independent Multicast version 2 (PIMv2), and Border Gateway Protocol (BGPsee RFC 3107), can run in parallel with LDP. LDP descends from Cisco-proprietary TDP in such a way that LDP is a superset of TDP, using the same methods to achieve the same functions.

The four categories of LDP messages are as follows:

• Peer discovery messages These LDP hello messages are used to advertise and maintain the presence of an LSR in a network. LDP neighbor discovery uses UDP port 646 to send periodic hello packets. The neighbor responds with an LDP hello if it is an LSR or eLSR. The LSR with the highest IP address becomes active and establishes TCP connections for LDP on port 646. The LSR with the lowest IP address becomes passive and waits on the establishment of the TCP connection for the LDP session.

• Session management messages These establish, maintain, and terminate sessions between LDP peers. LDP session establishment allows negotiation of options over the TCP session established on port 646.

• Advertisement or label distribution messages These create, change, and delete label mappings for FECs. These messages deal with label binding advertisements, requests, withdrawal, and release.

• Notification messages These provide reporting information and signal error information and cause codes.

LDP Message Overview

LDP runs over TCP port 646 to provide reliable delivery of messages. The only exception is the discovery message, which uses UDP port 646.

LDP Message Structure

All LDP messages have a common structure that uses a type-length-value (TLV) encoding scheme to provide expandability. The value part of a TLV-encoded object (or TLV for short) can itself contain one or more TLVs. TLV encoding is very easy to deal with when it comes to adding a new capability because a new type is defined.

As described in RFC 3036, the LDP specification, all LDP messages have an LDP header followed by one or more TLVs. The LDP header format is shown in Figure 4-7.

Figure 4-7. LDP Message EncodingLDP Header

The fields in the LDP header are as follows:

• Version This is the current LDP version is 1.

• PDU Length This is the length of the protocol data unit (PDU) in octets, excluding the Version and PDU Length fields.

• LDP Identifier This uniquely identifies the label space network-wide.

Figure 4-8 shows the LDP TLV format.

Figure 4-8. LDP Message EncodingTLV Format

Figure 4-8 contains the following fields:

• U bit Unknown message bit. This specifies the procedures to follow upon receipt of an unknown TLV. If it is cleared, a notification must be sent. If it is set, the unknown message must be silently ignored.

• F bit Forward unknown TLV bit. Applies only when the U bit is set.

• Type The type of message.

• Length The length of the message in octets.

• Value The value of the message. For LDP messages, the value is composed of a 32-bit message ID that identifies the LDP message, a set of mandatory parameters, and a set of optional parameters.

LDP Identifier

The LDP ID is a 32-bit magnitude that uniquely identifies the label space network-wide. Figure 4-9 shows the format of the LDP ID.

Figure 4-9. LDP Identifier

Figure 4-9 has two fields:

• LSR ID The first four octets identify the LSR. It must be a globally unique value such as the router ID. It is generally derived from a router interface.

• Label Space ID The last two octets identify the label space within the LSR. For platform-wide label spaces, the label space ID must be 0.

The combination of these two fields forms an LDP identifier that uniquely identifies the label space network-wide.

Each LDP identifier has it own LDP session, and each LDP session uses a separate TCP connection, as discussed in the upcoming section "Establishing LDP Sessions."

Label Spaces

Frame-based MPLS interfaces use a per-platform label space. In other words, labels are assigned from a unique pool of labels in the LSR. However, given the nature of labels on LC-ATM interfaces, per-platform label space cannot be used for ATM interfaces. Two LC-ATM interfaces can use the same VPI/VCI pair as a label. Therefore, LC-ATM interfaces use per-interface label spaces and a non-null label space ID.

In summary, we have the following:

• Interface label space The label space is specific to an interface. It is used with LC-ATM and LC-Frame Relay. The label forwarding information base (LFIB), which is used to forward labeled packets, contains an incoming interface. This is because the same numerical label (with a different meaning) can be assigned on multiple interfaces.

• Platform label space The label space is router-wide. It is generally used in frame-based MPLSthat is, POS, Ethernet, and Fast Ethernet interfaces. The label can be used on any interface. The LFIB does not contain an incoming interface.

From another angle, one label space is used per LDP session. When two LSRs are connected through three frame-based interfaces, as shown in Figure 4-10, you have only one LDP session and one label space.

Figure 4-10. Link Topology and LDP Sessions, Part I

However, as shown in Figure 4-11, each LC-ATM interface has its own LDP session and label space.

Figure 4-11. Link Topology and LDP Sessions, Part II

So an LSR has essentially two scenarios in which it needs to announce multiple label spaces to a peer and therefore use different LDP identifiers. One is when the LSR has two LC-ATM links to the peer, and the other is when the LSR has one LC-ATM link to the peer and one or more Ethernet links to the peer using per-platform label spaces.

In summary, the number of LDP sessions is determined by the number of different label spaces.

LDP Discovery

LSRs learn of LSR neighbors using LDP discovery and LDP link hellos. Figure 4-12 shows an example of LDP hello messages.

Figure 4-12. LDP Discovery Using Hellos

LDP discovery simplifies operational aspects of explicitly configuring peer LSRs.

LDP link hellos are sent out of MPLS-enabled interfaces as UDP packets to the well-known UDP port 646 for LDP discovery and for an "all routers on this subnet" group multicast address (they are sent to 224.0.0.2:646 UDP). The willingness to label-switch on a specific link is signaled by the LDP link hello messages.

Figure 4-13 shows a complete example of LDP discovery.

Figure 4-13. LDP Discovery Example

LDP sessions for nondirectly connected LSRs use an extended discovery process and require explicit configuration and the use of targeted hellos. There are two main differences between targeted hellos (or directed hellos) and normal hellos:

• Targeted hellos are sent to a specific IP address.

• The initiator solicits targeted hellos from the target (it is asymmetric).

Establishing LDP Sessions

LDP discovery triggers LDP session establishment. Session establishment is a two-step process:

• Transport connection establishment The active LSR that has the highest transport address initiates the establishment of the LDP TCP connection by connecting to the well-known TCP port 646 at the neighbor LSR address. LDP uses TCP as a reliable transport for sessions. Each TCP connection has only one LDP session.
  
  
• Session initialization After establishing the TCP transport connection, the active LSR sends the Init message to negotiate LDP session parameters exchanging LDP messages. The parameters negotiated include LDP protocol version, label distribution method, timer values, loop detection status, and maximum PDU length. Optional TLVs are also used to negotiate VPI/VCI ranges for label-controlled ATM, DLCI ranges for label-controlled Frame Relay, VC-merge capability, and VC directionality. Successful negotiation establishes an LDP session between LSRs. The session is ready to exchange label mappings after receiving the first keepalive.
  
  

An example of LDP session establishment is shown in Figure 4-14.

Figure 4-14. LDP Session Establishment

If multiple links connect two LSRs and use the same label space and LDP ID, there will be multiple link or hello adjacencies but only one transport adjacency.

Maintaining LDP Sessions

Two methods are used to maintain LDP sessions:

• Continued transmission of discovery hello messages as link keepalives, to monitor the willingness to label-switch on a specific interface. LSR keeps hello adjacency holddown timers.

• LDP session keepalives are used to monitor the health and integrity of the sessions and underlying TCP connection and to restart a session when keepalives are lost. An LSR maintains individual TCP session holdtime and keepalive intervals.

Label Distribution Methods

To help you understand the label distribution methods, I will first define the terms downstream and upstream, which are relative to an IP destination or FEC in general. Figure 4-15 shows upstream and downstream routers.

Figure 4-15. Upstream and Downstream Routers

In Figure 4-15, Router C is the downstream neighbor of Router B for destination 10.1.2/24, and Router B is the downstream neighbor of Router A for destination 10.1.2/24. Likewise, Router A is the upstream neighbor of Router B for destination 10.1.2/24.

Every interface on an LSR uses one of two methods for label distribution:

• Downstream Unsolicited The label distribution is downstream-controlled. The LSR downstream initiates and advertises the label mapping. Per-platform label space is distributed. Using this method, an LSR can distribute the same label to different neighbors.

• Downstream on Demand The label distribution is upstream-controlled. The LSR upstream initiates the mapping request. It distributes per-interface (such as LC-ATM) labels. In a Downstream on Demand label assignment, the LVC is built from the headend platform to the tailend platform.

The advertisement mode is exchanged between peer LSRs during the initialization phase. Neighbor LSRs must agree on the distribution method used.

The label-mapping LDP message uses two TLVs to perform the mappingthe FEC TLV and the Label TLV. Different types of labels use different Label TLVs. In particular, you can have a Generic Label TLV (type 0x0200), an ATM Label TLV (type 0x0201), and a Frame Relay Label TLV (type 0x0202).

Two methods of label distribution control can be used:

• Independent label control An LSR can assign a label for a FEC even if it does not have a downstream LSR. Upon receiving a label request message, the LSR can respond with a binding without waiting for a label mapping from the next-hop LSR.

• Ordered label control An LSR can assign a label for a FEC only if it has already received a label from the downstream LSR. Upon receiving a label request message, the LSR must perform its own label request downstream.

One last concept has to do with whether an LSR maintains or requests a label binding from or to a neighbor that is not the next hop according to the routing table. This is called label retention mode, and it has two alternatives:

• Conservative label retention mode An LSR operating in Downstream on Demand order requests label mappings only from the next-hop LSR. This saves valuable labels and therefore is preferred for LC-ATM interfaces.

• Liberal label retention mode An LSR operating in Downstream Unsolicited order can accept label-to-FEC mappings from all LDP peers. An LSR operating in Downstream on Demand order might request label-to-FEC mappings from all LDP peers. This mode is useful only in Downstream Unsolicited mode because labels will already be assigned upon a next-hop change in a prefix's routing information base.

As a summary, Table 4-1 lists the different recommendations for label distribution modes.

Table 4-1. Recommended Modes for Label Distribution

	Per-Platform Labels	Per-Interface Labels
Order	Downstream Unsolicited	Downstream on Demand
Control	Independent	Ordered
Retention	Liberal	Conservative

Loop Detection

LDP implements three mechanisms to prevent looping LSPs beyond the loop detection mechanisms built into the IGP:

• Time to Live The TTL field in the shim header is used to prevent looping labeled packets. Its use is equivalent to IP TTL, decrementing the TTL field at every hop as a packet travels through the network. This method can be used only in data link layers that use the shim header for label switching. It cannot be used for LC-ATM interfaces because the ATM cell header does not contain a TTL field. MPLS considers ATM a non-TTL segment.

• Hop count TLV This additional TLV is used to count the number of hops in an LVC during LVC setup. The TTL field in the IP header is decremented by this hop count at ingress, and the IP packet is dropped if the new calculated TTL value is equal to or smaller than 0. A maximum TTL value can be configured. This method is required in RFC 3035, but it might be insufficient to prevent loops in all cases.

• Path vector TLV This additional TLV was designed specifically to prevent loops. During an LVC setup, the path vector TLV records all the LSR IDs (the first 4 bytes of the Label ID) in the path, when the LSR adds its own router ID before sending the label request. If an LSR receives an LDP message containing its own router ID in the path vector TLV, the message is ignored, and a notification message is transmitted to signal the loop detected. LDP also supports a maximum path vector TLV length.

Figure 4-16 shows an example of the usage of the path vector TLV.

Figure 4-16. Loop Prevention with the Path Vector TLV

If loop detection is desired in an MPLS domain, it should be turned on in all LSRs and eLSRs.

Security Considerations

LDP runs on top of TCP, and it provides a TCP MD5 configurable signature option based on the one specified in RFC 2385 and used by BGP. The MD5 hash function is specified in RFC 1321. A shared secret is configured on the LDP peers, and the MD5 digest is computed from the shared password and the TCP segment.

ATM MPLS provides extra security capabilities. With per-interface label space, an LSR using Downstream on Demand label allocation mode discards labeled packets from upstream neighbors if the label was not previously advertised to that neighbor. This inherent capability prevents label spoofing.