Introduction
This article was adapted from Networkfuntimes and Juniper Networks.
A failed MPLS interview
About 13 years ago I worked in second-line support at an ISP. Every day I dealt with customer issues referred to as "MPLS circuits." At the time I did not fully understand what that meant, only that I was troubleshooting those issues daily. I decided to attend an interview for an MPLS-related role.
I still remember the first question: "How would you build a BGP-free core using MPLS?" I was completely lost. I had no idea how to answer, and then I was asked about traffic engineering, RSVP, and other topics. The whole interview left me confused. It turned out my understanding of "MPLS" was completely mistaken.
That interview made me realize that when people say "buying an MPLS circuit," they are often using the term to refer to a specific use case of MPLS rather than the broader technology itself. Based on my experience, you may be making this same mistake.
Common misconception
MPLS is essentially the technology that underpins almost all service provider networks. It is not a technology that will disappear soon; in fact, it continues to evolve every year.
Yet whenever MPLS is mentioned, some claim "SD-WAN will replace MPLS." In most of those cases, what people mean is MPLS VPN, specifically layer 3 MPLS VPN. Below I will explain this misunderstanding and the distinction between the concepts.
Because of this confusion, many do not study MPLS in depth. They hear that the technology will be "replaced by SD-WAN" and miss the broader technical meaning behind MPLS.
So, what is MPLS?
The short answer is that MPLS is a technology used by service providers to manage network traffic.
Normally, routers forward packets based on the destination IP address. In very large networks, especially service provider networks, that simple approach is not sufficient.
First, these networks must handle a large volume of routing information. Routers cannot always carry the full global routing table while meeting performance and scaling goals. Service providers also often want to direct different traffic onto different paths instead of always choosing the shortest path.
One way to achieve this is to create a tunnel between two routers at the edges of the network and send traffic through that tunnel. The tunnel can follow a specific path you choose or be computed according to routing constraints.
One method of sending packets through a tunnel is to add a label to the packet that instructs the next router how to forward it. The advantage of that label is that the receiving router does not need to inspect the IP destination; it forwards based only on the label.
For example, in the diagram below there are ten routers. There are two tunnels between R1 and R5: a blue tunnel following the shortest path for critical traffic, and a red tunnel following a longer path for best-effort traffic.
MPLS, short for multiprotocol label switching, is the technology that implements forwarding based on labels. It allows labels to be added to packets and for forwarding decisions to be made based on those labels instead of the destination IP. This enables more effective traffic management in large networks and the assignment of different paths for different traffic classes.
Why use tunnels?
There are many reasons to use tunnels. Some common MPLS tunnel use cases include:
- BGP-free core: Core routers do not need to store the full Internet routing table and forward packets based solely on labels.
- Priority tunnels: Create high-priority tunnels following the best path and lower-priority tunnels following longer paths, mapping traffic to these tunnels to separate high-priority from low-priority traffic.
- Dynamic path adjustment: Change paths dynamically when congestion or other network issues are detected.
- Resource optimization: Move low-priority tunnels to alternate paths so important tunnels can use the best resources.
- IPv4-to-IPv6 tunneling: Carry IPv6 traffic over an IPv4 core.
- Multicast tunnels: Run multicast tunnels in the core, for example to provide IPTV services to customers.
- VPN tunnels: Tunnel customer layer 3 or layer 2 VPN traffic through the core.
- Connecting provider sites: Larger providers can connect two sites of a smaller provider so the two sites appear as one, with the larger provider acting as an invisible tunnel between them.
These are just some basic use cases for MPLS in modern service provider networks.
Label-switched paths
Earlier we discussed "tunnels"; another name for tunnels in MPLS is label-switched paths (LSPs). There are multiple protocols to create LSPs.
One is the Label Distribution Protocol (LDP). LDP can create tunnels that follow best-path metrics and can also be used for IPv6 tunneling, customer VPN tunnels, and BGP-free core implementations.
Another protocol is RSVP-TE (Resource Reservation Protocol - Traffic Engineering), which is known for its traffic engineering capabilities.
A newer approach is segment routing, particularly SR-MPLS, which also provides many of the same capabilities mentioned above.
MPLS allows labels to be added to packets and forwarding to be based on those labels. The combination of MPLS and BGP enables many functions across the Internet, so MPLS will remain in use for a long time.
"Networks always change, and no one knows exactly what the future holds, but if an 18-year-old starts working in the service provider industry today and retires years later still using MPLS, that would be unsurprising. This highlights MPLS's importance to the modern Internet."
What do people mean by "MPLS"?
One common use of MPLS is to tunnel customer VPN traffic through the provider core.
Imagine a customer with dozens of sites nationwide. Each site has at least one LAN with private IP address space and needs connectivity to the LANs at other sites. Connectivity can be full mesh, selected sites, or hub-and-spoke from headquarters.
Because the service provider only looks at the labels inside its network rather than the IP addresses, the provider can offer VPN services using MPLS. Customer traffic can be tagged with a unique MPLS VPN label and tunneled through label-switched paths. The receiving provider-edge router maps that VPN label to the specific customer, keeping the customer's traffic logically separate from other customers, even if they use overlapping private IP address spaces.
In general, MPLS VPNs come in two "types."
One type is a layer 3 VPN (sometimes called L3VPN, IPVPN, or VPNv4). The provider learns the LAN prefixes for each site and advertises them within its network, marking them as belonging to a particular customer VPN. The provider's edge routers maintain a layer 3 routing table for that customer VPN, using BGP, OSPF, or static routes.
The other type is a layer 2 VPN, where the provider does not learn the customer IP ranges and instead does one of two things:
- Acts as a virtual circuit connecting two sites so frames entering at one end are tunneled to the other end. The provider does not need to learn MAC addresses because traffic entering at one end exits at the other.
- Acts as a virtual switch where the provider actually learns MAC addresses. For hosted WAN circuits, customer devices can learn MAC addresses at other sites directly. In practice, like a physical switch, the provider inspects traffic, learns MAC locations, and forwards or floods traffic accordingly. VPLS (virtual private LAN service) and EVPN (Ethernet VPN) are two approaches to achieve this.
"MPLS circuits"
At some point the term "MPLS circuits" began to be used to refer to MPLS VPNs.
Interestingly, packets sent over these so-called MPLS circuits do not carry any MPLS labels on the customer side. Labels only appear inside the service provider network. Customer-edge routers typically do not support MPLS. Instead, the provider's WAN interface takes traffic from the public internet and places it into the customer's private routing instance. The provider then uses MPLS inside its network to carry the VPN traffic.
Strictly speaking, MPLS circuits do not involve MPLS on the customer side.
This misuse leads many network engineers to think "MPLS" only means MPLS VPN and L3VPN. They may not understand labels, label-switched paths, LDP, or RSVP.
Is SD-WAN an MPLS killer?
Since the 2010s there has been recurring talk that "SD-WAN will kill MPLS."
Many people who only know MPLS as L3VPN claim MPLS is on its way out because they do not realize MPLS has a broader meaning.
I have written many articles on MPLS traffic engineering and BGP-free core, yet some still comment "I don't think MPLS has a future" or "I think SD-WAN will replace MPLS."
However, MPLS is not going away soon.
Value-wise, SD-WAN is unlikely to "kill" MPLS VPN. SD-WAN and MPLS VPN serve different use cases and each has strengths and weaknesses. Over time one approach may become more popular for certain deployments, but that does not mean MPLS will disappear.
