By now, it is clear that the processes of label switching and distribution are shockingly similar to routing in a traditional sense. This is true with the significant exception that label switching and distribution do not have any need to analyze network layer information. When the edge LSR adds the label, the packet is predestined to arrive at its appropriate end. This greatly increases the efficiency of the routing process overall.
MPLS does add overhead in the form of additional communication between adjacent routers. Aside from routing prefix propagation, the added functions of maintaining the LIB and LFIB along with an adjacency table can use significant resources. In terms of memory utilization, for example, BGP uses approximately 72 MB of router memory for every 100,000 prefixes. With the Internet routing table at roughly 215,000 prefixes at the time of this writing, it is conceivable that the BGP table alone might use around 150 MB of memory. When CEF, LDP, and other processes are added to that, it is easy to see how a resource shortage might come into being for a given router. This also reflects a compelling case for being careful when enabling the propagation of Internet routes.
Label distribution is performed by a label distribution protocol. In fact, whether due to lack of originality or simply a love of the Keep It Simple Stupid (KISS) principal, the protocol is aptly named MPLS Label Distribution Protocol (MPLS-LDP). The assumption should be made from this point forward that the term "LDP" is meant to refer to MPLS-LDP. This clarification is necessary because a number of other methodologies of label propagation are being explored. For example, MP-BGP can piggyback labels on BGP routing updates due to standards extensions made to the BGP structure. With that in mind, it is important to mention that MPLS architecture does allow for two ways of propagating the needed additional information:
■ Extend functionality of existing protocols
■ Create a new protocol or protocols dedicated to the task of label exchange
Extending the functionality of an existing protocol requires a great deal of time and effort. This is especially true for protocols such as BGP and OSPF, both of which already have a multiprotocol version. However, the wide adoption of both protocols prior to the extensions would require that the new version be implemented throughout an internetwork in order to introduce label exchange. This would require a great deal of work and testing before, during, and after the upgrade.
The Internet Engineering Taskforce (IETF) has taken the second approach to the matter. LDP is implemented in the control plane and exchanges labels with neighbors, storing the results in the LIB.
In the MPLS architecture, the decision to assign a particular label to a particular FEC is made by the LSR at each hop along the way. The downstream LSR informs the upstream LSR of its decided label for that FEC. Essentially, this implies that labels are downstream-assigned as route entries come from the downstream side. So, traffic flow is a factor in the decision. It should be noted that upstream and downstream are subjective terms relating to the direction of traffic flow. Assuming that traffic flows bidirectionally, labels will be propagating in both directions. Also, the concept behind split horizon is in play as well because labels are distributed only in the downstream direction. This will have the effect of a label not being advertised to the neighbor from whom it was learned. The FIB is subject to split horizon from a pure routing perspective, therefore the LIB and LFIB will be subject to split horizon as well by default. The two LSRs that happen to be label distribution peers are said to have a label distribution adjacency between them.
Label distribution can occur in two basic manners: unsolicited downstream and downstream-on-demand. The names are essentially what they denote. An MPLS neighbor can receive an update due to a convergence event (unsolicited) or it can request an update from a neighbor. This might occur when a label is not present for a particular FEC. Advanced routing protocols, such as EIGRP, will request a route for a destination for which it does not have an entry when a packet arrives destined for said destination.
Was this article helpful?