The previous tech tip focused on label switched paths and their functionality in an MPLS environment. This article will focus on the label distribution protocol (LDP) and how MPLS routers build and utilize label forwarding tables. I will not focus too much energy on the actual protocol itself but will instead discuss the label forwarding mechanisms.
LDP is defined in RFC 3036 and is used to provide mechanisms for MPLS routers to process and route labeled traffic across an MPLS network. In the last article, we discussed the path that the labels take (label switched path) and how the LSP is actually a virtual circuit much in the same way as a Frame and ATM virtual circuit. Again similar to ATM and Frame, the MPLS nodes forward and route traffic based on the label found in the packet. Frame and ATM use cell and frame headers, MPLS uses labeled headers. The MPLS routers will forward packets with a certain labeled header across a specific LSP. This set of labels and the corresponding ingress and egress MPLS routers in the MPLS domain make up the LSP.
MPLS routers build a Label Information Base (LIB) and a Label Forwarding Information Base (LFIB) on each router and exchange information via LDP to determine which path to forward labeled traffic across.
A LIB is a collection of destinations that have been assigned a local label and the subsequent mapping of these labels to the labels it received from its neighbors. The LFIB is the forwarding element of these labeled packets.
When a packet initially enters an MPLS router, the MPLS router will assign a label to the packet. This label is randomly assigned by the router but it is tied to a specific forward equivalency class (FEC). A FEC is basically an IP destination found in the routers IP routing table. So, for instance, a router may get a packet destined for 10.10.10.0 on an MPLS interface. The routers could randomly assign label 10 to this packet. All packets destined for the same destination prefixes are put in the same FEC and assigned the same label (although they don't have to be). At this point the router must make a routing decision. In the IP world the router would look in its IP forwarding table that it has built via a routing protocol to determine next hop and interface in which to forward the packet. However in the MPLS world the router must look in its LFIB. The LFIB is analogous to the IP forwarding table.
MPLS routers utilize LDP to exchange information regarding label assignments and this information is used to build the LFIB used to process and forward labeled packets.
In a manner similar to IP routing protocols, MPLS utilizes LDP to discover MPLS neighbors that are directly connected, establish peer relationships with them and advertise label assignments.
The way that this works is that each router advertises the labels it has assigned to each destination/FEC to each of its neighbors. The routers in turn build the LFIB that is made up of incoming label, outgoing label, next hop and outgoing interface for each FEC. You may be wondering why the LFIB would need an outgoing label. It would seem that if you have a labeled packet, a next hop address and an outgoing interface that you have all you need to make a forwarding decision. The answer lies in the assignment of labels individually by each MPLS router. Going back to the earlier discussion, if you have multiple routers that have destinations for network 10.10.10.0, they are all going to assign their own random label to that destination/FEC. When the MPLS routers form their adjacencies they advertise these label bindings to each other. When one router receives the packet from another router, it comes as a labeled packet. So if I receive a packet from my upstream neighbor for destination/FEC 10.10.10.0 it may have a label of 20 that was randomly assigned. Rather than trying to coordinate label assignment, my MPLS router will simply pop off the 10 label previously assigned and put on the 20 label. That way when the upstream router looks in its LIB, it will know label 20 corresponds to destination/FEC 10. There are many ways that LDP can go about establishing this routing and forwarding schema as is evident with other routing protocols. However, the basic premise of building the LFIB via LDP is the message I want to convey.
Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for SBC Communications. He has over 10 years of experience providing strategic, business, and technical consulting services to clients. Robbie resides in Atlanta, and is a graduate of Clemson University. His background includes positions as a Principal Architect at International Network Services, Lucent, Frontway and Callisma.