LDP and CR-LDP

The article presents the principles of label switching, and more specifically the MPLS (MultiProtocol Label Switching) protocol. In an MPLS core network, IP packets in transit are encapsulated in MPLS packets and relayed on the basis of the label in the MPLS header. To do this, the LSRs (Label Switching Routers) in an MPLS cloud have to agree on the meaning of the labels - this is known as label distribution. There are several ways to populate MPLS switching tables. The first is to do it manually, which is only realistic for a very limited number of Forwarding Equivalence Classes (FECs). It is also possible to use a fully automatic protocol that builds MPLS paths (LSP Label Switched Paths) for each of the equivalence classes recognized in the routing tables, based on the information contained in the IP routing tables. With this approach, paths are constructed on a hop-by-hop basis, similar to that of IP routing protocols. The use of the new Label Distribution Protocol (LDP) is an example of this approach, as is the addition of label distribution information in Border Gateway Protocol 4 (BGP4). Finally, there are solutions based on centralized control. These offer tools for establishing LSPs by explicitly providing the path they must take and the quality of service they must ensure. These solutions are based on two protocols: the first, CR-LDP (Constraint Routing – Label Distribution Protocol) is an extension of LDP, whose presence in the network is required, while the second, RSVP-TE (ReSerVation Protocol – Tunnel Extension) is a modification of RSVP already present in many manufacturers' routers. There is some debate between CR-LDP and RSVP-TE proponents as to which protocol should be used to explicitly establish paths. We won't get into the controversy, especially as they offer essentially the same functions. And, if we have chosen to deal with CR-LDP here, it's only because we're already dealing with LDP.

First, we'll look at the principles of LDP, then at how it works by giving a number of examples. Finally, we describe the possibilities of CR-LDP, before concluding by outlining the state of the market and the proposals for evolving and extending LDP that have already been submitted to the IETF (Internet Engineering Task Force).