LDP Overview

The LDP daemon is a standardised protocol that permits exchanging MPLS label information between MPLS capable devices (also called LSRs or LERs). The LDP protocol creates peering between devices, so as to exchange FEC information linking networks and labels together. This information is stored in MPLS binding tables. Then, based on available routing table, on the one hand, an MPLS label is appended to the routing table for locally generated packets; on the other hand, LFIB entry is created with that label information for incoming MPLS frames. By acting this way, data traffic is encapsulated in MPLS header, and on each LSR, the incoming label will determine which label has to be swapped, instead of the former one. MPLS permits carrying any transportation data through that MPLS backbone. It is possible to carry L3VPN traffic inside, thus permitting transporting overlapping data to different place. LDP often works in conjunction with IGP routing protocols like OSPF, thus facilitating the discovery of the backbone, and permitting to know for some traffic having to go through that backbone what is the best path to take.

The LDP is handled by FRR.

LDP packets and operations

LDP aims at sharing label information across devices. It tries to establish peering with remote LDP capable devices, first by discovering using UDP port 646 and multicast address 224.0.0.2 on the connected nodes, then by peering using TCP port 646. Once the TCP session is established, the following happens:

Note

This is the standard way for LDP sessions to peer together in a LSR. For that, LDP peers are directly connected, so that a label can be assigned to each IGP route. Let us remind that label switching of packets is hop per hop.

  • The list of IP addresses that each device owns is sent via an Address Message LDP message. Knowing local IP addresses permits to know that this address is reachable via an implicit-null message.

  • Then Label Mapping Messages are sent. Those messages stand for each known network associatet to a label. This is the so-called FEC information, where usually a destination IP prefix is bound to a label. It is worth to be noted that when a route is connected, the label associated is implicit-null, which is 3 in the case of IPv4. For the other routes, an arbitrary label value is communicated. A binding table is then forged on each device, and contains, for each route, the local label emitted for each network, and the remote label received from remote peer. This table is then used to apply labels to already present routes.

There are different methods to send label advertisement modes. The implementation actually supports the following : Liberal Label Retention + Downstream Unsolicited + Independent Control. The other advertising modes are depicted below, and compared with the current implementation.

  • Liberal label retention versus conservative mode: In liberal mode, every label sent by every LSR is stored in the MPLS table. In conservative mode, only the label that was sent by the best next hop (determined by the IGP metric) for that particular FEC is stored in the MPLS table.

  • Independent LSP Control versus ordered LSP Control MPLS has two ways of binding labels to FEC; either through ordered LSP control, or independent LSP control. Ordered LSP control only binds a label to a FEC if it is the egress LSR, or the router received a label binding for a FEC from the next hop router. In this mode, an MPLS router will create a label binding for each FEC and distribute it to its neighbors so long as he has a entry in the RIB for the destination. In the other mode, label bindings are made without any dependencies on another router advertising a label for a particular FEC. Each router makes it own independent decision to create a label for each FEC. By default IOS uses Independent LSP Control, while Juniper implements the Ordered Control. Both modes are interoperable, the difference is that Ordered Control prevent blackholing during the LDP convergence process, at cost of slowing down the convergence itself

  • unsolicited downstream versus downstream on demand Downstream on demand label distribution is where an LSR must explicitly request that a label be sent from its downstream router for a particular FEC. Unsolicited label distribution is where a label is sent from the downstream router without the original router requesting it.

LDP has by default the PHP functionality. That functionality stipulates that the outermost label of an MPLS tagged packet is removed by a LSR before the packet is passed to an adjacent LER. This behaviour permits sparing one cpu cycle on the LER, by not popping that last label. However, LDP provides the configuration mean to disable that feature, by using explicit-null labels.

RFC

RFC 5036:

LDP specification

RFC 5082:

The Generalized TTL Security Mechanism (GTSM)

RFC 6720:

The Generalized TTL Security Mechanism for the LDP

RFC 6667:

LDP ‘Typed Wildcard’ Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements

RFC 5919:

Signaling LDP Label Advertisement Completion

RFC 5561:

LDP capabilities

RFC 7552:

Updates to LDP for IPv6

See also

The command reference for details.