Label Distribution Protocol

From Hill2dot0
(Redirected from LDP)
Jump to: navigation, search

The Label Distribution Protocol (LDP) was the first label distribution protocol to be standardized by the IETF. LDP is defined in RFC 3036, LDP Specification, and RFC 3037, LDP Applicability.

LDP supports forwarding along normally routed paths as determined by destination-based routing protocols, such as RIP, EIGRP, OSPF, and IS-IS. This forwarding is sometimes called MPLS hop-by-hop forwarding.

LDP can support the following.

Downstream-on-demand distribution with ordered control and conservative label retention is recommended in situations where labels are a relatively scarce resource that must be conserved (e.g., in large backbones or on virtual path switched ATM links where the label space is reduced). Unsolicited downstream distribution with independent control and liberal label retention is recommended where labels are plentiful and need not be conserved carefully. However, LDP permits other combinations of distribution methods (e.g., label retention mode and control mode), including hybrid variations.

LDP is also used when an MPLS LSP is required to be set up with minimal administrative intervention between nodes (e.g., between PE routers running BGP that require an LSP to forward VPN data (RFC 2547, BGP/MPLS VPNs).

LDP uses TCP for communication, which ensures that label messages are delivered reliably and paced out (i.e., flow control) and that distributed labels and state information associated with LSPs need not be refreshed periodically.

Basic LDP Messages

The LDP specification defines four major message types.

  • Discovery messages are used in LDP to announce and maintain the presence of an LSR within the MPLS domain. Not all devices in an MPLS domain need be full MPLS devices or even routers. The LSRs must find and identify themselves to one another, as well as periodically assure one another that they are operational.
  • Session messages are used to establish, maintain, and terminate sessions between LDP peers. LDP peers are MPLS devices that run compatible versions of LDP. Two LSRs running CR-LDP are peers, but they are not peers with LSRs running only basic LDP. Sessions are used to keep a “history” or log file of the interaction between LDP peers so lost information can be recovered when links fail.
  • Advertisement messages are used to create, change, and delete label mappings for FECs (bindings between label and FEC). Similar in function to traditional routing protocol updates, these messages serve the same purpose in LDP. Advertisement messages are usually the content of the session between LSR peers.
  • Notification messages are used for advisory information and to signal error conditions between LSRs. Their use is fairly self-explanatory, such as when one LSR tells another LSR to delete a label that does not exist in the forwarding table at the other LSR.

All of the message types, with the important exception of discovery messages, use TCP. Discovery messages use UDP. TCP will establish connections for the LDP sessions to ride more effectively (it is very difficult to support “connectionless sessions”) using TCP sequence numbers and end-to-end flow control. In addition, TCP always resends missing segments. LDP can use these TCP features without having to reinvent them.

LDP is designed to be extensible so other message types and individual messages can be added.

LDP Session Establishment

LDP Session Establishment

The LSRs running LDP use the following procedure to establish a session over which to perform label distribution.

Session establishment begins with each LSR advertising a periodic Hello message containing the LSR ID and Label Space ID. When an LSR sees a Hello message from a peer LSR, it keeps track of that peer (i.e., an adjacency). Hello messages are encapsulated in UDP and are only used for initial neighbor discovery. The peer with the highest LSR ID becomes active; the other becomes passive. The active LSR initiates a TCP session, which is a three-way handshake establishing the TCP session.

Once a TCP session is established, the active LSR sends an initialization message, which contains the parameters for the LDP session. Relevant information in this message includes the LDP version, label distribution method, timer values, VPI/VCI ranges for label-controlled ATM, DLCI ranges for label-controlled frame relay, etc. This information is then acknowledged by the passive LSR, which then responds with its own initialization message. This message is also acknowledged by the active LSR.

Any error or incompatibility resulting from the initialization process will cause the session to fail and the TCP session to be torn down. Once initialization is complete, KeepAlive messages are sent to confirm the session is still active, even when no real data is being sent.

Normally, LDP peers are directly attached, but nondirectly attached LSRs can establish an LDP session via the extended discovery process. This method can be useful to advertise the existence of many LSPs over an aggregate LSP. An aggregate LSP can carry many LSPs transparently over a core network or even another provider, reducing the number of LSPs required in the core. This helps MPLS scale in the core of the network by reducing the number of defined LSPs.

All communication between LSRs occurs via UDP and TCP port number 646 as defined by IANA.

LDP Label Assignment

LDP Label Assignment

The visual shows the LDP binding a label to an FEC in independent, unsolicited downstream label distribution with liberal label retention.

When any LSR detects a new FEC (i.e., a new entry in the routing table or BGP next hop), it assigns a label to the FEC and sends a label mapping message telling its upstream neighbor LSRs to use the label to forward traffic to the FEC.

An upstream LSR might receive many labels to use for a particular FEC from potential downstream LSRs. With liberal label retention, all these labels will be retained; however, only one—the label from the LSR identified as the next hop by the routing protocol—is used to push or swap on a packet.

The label used between each LSR is a local issue. The ultimate path defined by the resulting LSP is unidirectional and defined by the shortest path according to the IGP used by the LSRs.

The full set of LDP-defined messages follows.

  • Notification
  • Hello
  • Initialization
  • Keep Alive
  • Address
  • Address Withdraw
  • Label Mapping
  • Label Request
  • Label Abort Request
  • Label Withdraw
  • Label Release

Draft enhancements also propose additional messages to facilitate management and to find out which LSRs carry an LSP.

  • Query
  • Query-Reply
  • Partial Query-Reply

An LDP Tree

An LDP Tree

The following is an example of an LDP tree.

Consider a network where the egress router is the basis of defining an FEC. Within an AS, the BGP next hop address is the egress router (assume the NEXT_HOP attribute is set to NEXT_HOP_SELF). LSRs that are defining a label per FEC will only define a label per egress router. Thus, if an LSR receives a request from multiple upstream LSRs for a label for the same FEC (assuming downstream-on-demand or even if it advertises a label for an FEC in unsolicited downstream mode), then both can be mapped to the same label downstream.

The example above illustrates the concept of merging an LSP. However, not all hardware supports this multipoint-to-point LSP (e.g., ATM hardware has issues because of AAL5). But if this LSP is supported, the need to have an LSP between every ingress and egress LSR is reduced. As LSPs are aggregated in such a topology, visibility of individual data flows is lost, and as a result, it is no longer possible to support TE or QoS applications.