The previous tech tips have focused primarily on the enterprise side of MPLS migration. I will now shift focus to the functionality and features of MPLS architectures. This tip focuses on MPLS Label Switched Paths (LSPs).
MPLS developers needed to solve a problem and that problem was the creation of virtual circuits over an IP backbone. By combining ATM and Frame-relay like virtual circuits via IP, MPLS could provide a solution that was both cost effective and provided a richer feature set than either Frame or ATM. The solution that the developers came up with was Label Switched Paths (LSPs).
The creation of an LSP builds a virtual circuit mesh over an MPLS backbone. In the past, service providers utilized their IP backbones for Internet and remote access IP VPN services across the best effort Internet. The Frame and ATM services were purchased to provide secure, reliable interconnections for a mesh of remote sites. With the advent of MPLS LSPs the providers can offer IP backbones that mimic the virtual circuit mesh provided by Frame and ATM.
So what constitutes a LSP? As we have discussed previously, CE routers connect to PE routers to interface with the MPLS cloud. The PE routers utilize label switching to switch packets across the backbone. The LSP is a specific path between PE routers on the MPLS core that the traffic will traverse. Traffic labeled in a specific way is forwarded along a specific LSPs. All packets with the same label use the same path. Unlike Frame and ATM backbones where the DLCI or VPI/VCI indicates endpoints, MPLS labels indicate the paths. This allows packets destined for the same end node to traverse different LSPs. This is important as one or more of the LSPs may be carrying traffic requiring QoS.
If that seems ambiguous it's because it is. The LSP is actually just a link between incoming and outgoing interfaces on a router. A router basically has two forwarding tables, the IP forwarding table and the label forwarding table. For label switching, the router looks at a packet's label and then forwards the label out of a specific interface. The destination of that label is determined by the IP forwarding table. We have already said that LSPs are indicated by the label on the packet, so how does this work? Let's say for example that you have a backbone that has multiple sites attached to it. Let's assume that the routed path through the backbone from one end site to the other is static for the time being (e.g. it is the path calculated by an interior gateway protocol such as OSPF, BGP etc.). All IP traffic between the two end routers will traverse the same path over the same routers. Now assume that the endpoints are utilizing MPLS. The traffic will be switched across the backbone utilizing information found in each routers label forwarding table. The routers build the label forwarding table based on information from the routing table. Therefore since label forwarding is based on the IP forwarding, the LSP will be created across the same path. MPLS backbone providers have established complex traffic engineered backbones where LSPs can take multiple paths to and from endpoints based on their MPLS label. In order to provide different paths to the same endpoint the providers have to establish separate LSPs that are built upon layer 3 information. Now traffic coming from one destination to another can be differentiated by which LSP it is in. One LSP may get QoS treatment and the other may be best effort.
If this is a confusing concept, just remember that Frame and ATM networks build PVCs across a bunch of ATM network elements for the virtual mesh. There are routing and signaling protocols that are used to establish PVCs and forward cells. It is no different in an MPLS environment, except that the signaling and routing protocols are our old friend IP and label distribution protocol know as LDP. We will discuss LDP in the next tip.
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.
