20.1 MPLS

Introduction

Multiprotocol Label Switching, usually called MPLS, is a technique used in many service provider and large enterprise networks to move traffic quickly and predictably. Instead of forwarding packets only by looking at IP addresses, MPLS attaches short labels and lets routers forward traffic based on those labels. This chapter focuses on what is specific to MPLS as an advanced enterprise technology, without repeating general routing or path selection topics that are handled elsewhere.

MPLS sits in between traditional Layer 2 switching and Layer 3 routing. It can carry many types of traffic, including IPv4, IPv6, and others, across a common core. This makes it very attractive for large networks that need predictable paths, VPN services, and traffic engineering features.

Label Switching Concept

At the heart of MPLS is the idea of label switching. In a normal IP network, each router looks up the destination IP address in a routing table, decides a next hop, and forwards the packet. Every hop repeats the same process. In MPLS, routers do not look at the IP header at every hop. Once traffic enters the MPLS cloud, a label is pushed onto the packet, and intermediate devices forward based only on that label.

A label is a short, fixed length identifier. It has local significance between two adjacent MPLS routers, which means the numeric value of a label only matters on a single link. The downstream router tells the upstream router which label to use for a particular Forwarding Equivalence Class, often abbreviated as FEC. A FEC is simply a group of packets that will be treated the same way in the MPLS network, for example all traffic going to a particular destination prefix.

Once a packet is associated with a FEC and has a label, each MPLS router in the core performs a label lookup, swaps the incoming label with an outgoing label, and forwards the packet. The IP header is usually not examined until the packet leaves the MPLS network.

MPLS Labels and Label Stack

An MPLS label is carried in a small header called the MPLS shim header. The label itself is 20 bits long. Along with the label value, there are a few other fields, including a field that marks the bottom of the label stack and an 8 bit Time To Live field, often written as TTL.

MPLS allows multiple labels to be stacked on a single packet. The concept of a label stack is very important for VPNs and for traffic engineering. Each label in the stack has a specific role. Typically, the top label in the stack is used for forwarding inside the provider core. Additional labels that sit below can identify services, VPNs, or specific tunnels.

The label at the bottom of the stack is marked with a special bit so that routers can tell which label is the last one. As a packet travels through the MPLS network, routers may push new labels, swap labels, or pop labels. These three basic operations are the foundation of MPLS forwarding:

1. Push, which means adding one or more labels on top of the existing stack.
2. Swap, which means replacing the top label with a different label.
3. Pop, which means removing the top label from the stack.

Basic MPLS Architecture

To understand MPLS in an enterprise or service provider environment, it is important to understand the roles that different routers play.

At the edge of the MPLS cloud sit the Provider Edge routers, also called PE routers. These routers connect to customer networks or to other parts of the enterprise. PEs perform both IP routing and MPLS functions. They receive ordinary IP packets from customer equipment, classify them into FECs, and push labels before sending traffic into the MPLS core.

Inside the MPLS core sit Provider routers, often called P routers. These devices do not connect directly to customers. They are pure label switching routers. They forward traffic based on MPLS labels alone, without examining customer IP headers. This simplifies the core and improves performance.

On the customer side, Customer Edge routers, or CE routers, connect to the PE devices. CEs are typically not aware that MPLS is used in the service provider core. They just run regular IP routing or static routes with the PE. In enterprise networks that use MPLS internally, the roles of CE and PE are still useful as conceptual boundaries between the MPLS core and ordinary routed domains.

A common pattern is that CEs exchange routes with PEs using routing protocols such as OSPF, EIGRP, or BGP. The PE then maps those routes into VPNs or FECs and assigns labels. Inside the provider core, P routers only need to know how to reach the PE loopback addresses using the interior routing protocol and the label information exchanged by the MPLS control plane.

Label Distribution and Control Plane

MPLS needs a control plane to distribute label bindings between routers. The exact details of protocols such as LDP or RSVP are covered elsewhere, but the idea is simple: for each FEC, the downstream MPLS router advertises a label that upstream routers should use when sending packets for that FEC.

In a typical MPLS deployment, the interior gateway protocol in the core, for example OSPF or IS-IS, builds the IP routing table. On top of that, a label distribution protocol runs between neighboring MPLS routers. The label distribution protocol maps IP routes to labels so that each router knows, for each FEC, what label to expect on incoming packets and what label to use on outgoing packets.

Each MPLS router maintains a Label Information Base, often abbreviated as LIB. This is similar to a routing table but for labels. It also keeps a Label Forwarding Information Base, or LFIB, which is the actual table used to forward traffic. The LFIB tells the router which incoming label should be swapped to which outgoing label and on which interface.

The separation of routing information from label information is a key architectural feature. Routing protocols decide which paths are available, and label distribution protocols assign labels to those paths. MPLS can be used with many different routing protocols, and that is one reason for the word multiprotocol in its name.

MPLS in Service Provider and Enterprise Use

In service provider networks, MPLS is widely used to deliver VPN services to multiple customers over a shared core. The core is independent of customer addressing, and each customer can even use overlapping IPv4 private address ranges without conflict. This is one of the strongest reasons for MPLS adoption.

In large enterprises, MPLS can run inside the corporate network or can be purchased as a managed service. When used internally, enterprises treat parts of their network as MPLS provider regions, with PEs and Ps implemented on their own routers. This provides scalability, separation between business units, and a consistent way to build VPNs and traffic engineered tunnels.

MPLS is often preferred over simple IP routing in scenarios where many different logical networks must share one physical backbone. It provides a consistent way to label and separate traffic types. For example, voice, video, and data VPNs can be carried over the same links but kept logically separate using different labels.

MPLS VPNs

One of the most important applications of MPLS is the creation of Layer 3 VPNs. In this model, each customer or each logical network has its own virtual routing table on the PE routers. These are often called Virtual Routing and Forwarding instances, or VRFs.

When a packet from a customer enters a PE interface associated with a particular VRF, the PE performs a route lookup inside the correct VRF. It then assigns the appropriate labels to send the packet through the MPLS core to the correct remote PE that also holds that VRF. Inside the core P routers, forwarding is done only on labels. The core does not need to know the customer prefixes or VRF details.

To carry VPN traffic across the core, MPLS commonly uses more than one label. Typically, the top label identifies the path across the provider core. A second label below it, sometimes called the VPN label, identifies the VRF and the specific next hop on the destination PE. The PE at the far end pops the VPN label, looks up the destination inside the VRF routing table, and delivers the packet to the correct CE.

This two label model is very flexible. It lets providers change the core topology or internal routing without affecting VPN separation. It also enables overlapping customer address spaces, because the VPN label and VRF membership distinguish different customers that might be using the same IP subnets.

MPLS Traffic Engineering

MPLS is also well known for its traffic engineering capabilities. Instead of always using the shortest path from the routing protocol, MPLS can create label switched paths, often called LSPs, that follow explicitly chosen routes. This is helpful when some links are congested, when specific applications need guaranteed bandwidth, or when some paths must be preferred or avoided.

With MPLS traffic engineering, a head end router can establish a tunnel to a tail end router that passes through specific intermediate nodes. The tunnel is represented by a label stack that ordinary P routers use to forward packets without knowing the higher level policy. The traffic inside that tunnel can be IP packets from many different flows, and the head end can decide which traffic to place into which LSP.

Traffic engineering can also use resource information from the network, such as available bandwidth, delay, or link attributes, so that tunnels avoid congested or unsuitable links. This allows more efficient use of the overall network and can support service level agreements for latency sensitive or high priority applications.

Because LSPs can be unidirectional, traffic engineering often sets up separate LSPs for forward and return paths. This lets engineers control asymmetry and fine tune load distribution even when interior routing metrics would otherwise produce less ideal results.

Quality of Service and MPLS

MPLS integrates naturally with Quality of Service policies. Each packet can carry a small field in the MPLS header that indicates the class of service. Core routers can use this to apply different queuing, dropping, or scheduling behavior to various traffic classes.

In many service provider designs, customer QoS markings, such as IP precedence or DSCP, are mapped into MPLS class of service bits at the ingress PE. Inside the MPLS core, routers act on the MPLS class bits, and at the egress PE, markings can be mapped back into IP QoS values for delivery into the customer network.

This mapping allows end to end QoS behavior while keeping the core devices focused on fast label switching and simple class handling. It also supports offerings such as different service tiers, voice optimized transport, or premium data paths over the same physical infrastructure.

MPLS and Network Convergence

MPLS has helped networks converge different types of services onto a single IP and MPLS based backbone. Historically, organizations might have run separate networks for data, voice, and private line services. With MPLS VPNs and traffic engineering, these services can share one converged core.

For example, Layer 3 VPNs can replace traditional leased lines between sites. MPLS traffic engineering can give voice and video paths predictable latency. MPLS auto discovery and signaling mechanisms can support dynamic addition of new sites and services without reengineering the entire network.

In many large designs, MPLS is also a foundation for more advanced technologies covered in later chapters, including overlays and SD-WAN interactions. MPLS often acts as a stable, predictable transport layer across which newer virtualized or software defined overlays are built.

Design Considerations for MPLS Deployments

Using MPLS in an enterprise or service provider network introduces specific design questions. One of the main ones is the decision on where to place MPLS boundaries. PEs must have enough capacity for both control plane and forwarding functions, because they hold VRFs, participate in customer routing protocols, and handle label operations.

Core P routers can be simpler in function but must be very reliable and fast. The interior routing protocol must provide a solid base for label distribution. Redundancy at both PE and P layers is essential, because a failure can affect many VPNs or services at once.

Another important consideration is the scaling of VRFs and labels. Each additional VPN and each additional LSP consumes memory and control plane resources. Designs must estimate how many customers, sites, and traffic classes will be supported so that devices and protocols are chosen appropriately.

Operationally, MPLS also affects troubleshooting. Engineers need visibility into both the IP routing domain and the label domain. Tools that can display LIB and LFIB entries, trace MPLS paths, and verify VPN membership become part of daily operations. Detailed operational topics belong in troubleshooting and monitoring chapters, but it is important to realize that MPLS adds a layer of abstraction that must be understood for stable operations.

Summary

MPLS introduces label based forwarding into enterprise and service provider networks. Packets are associated with FECs, labels are exchanged between routers, and the core forwards on labels rather than IP headers. By using label stacks, MPLS supports powerful services such as Layer 3 VPNs and traffic engineering. It allows multiple logical networks and service classes to share a single high performance core while keeping customer addressing, policies, and traffic types logically separated.