Hubbry Logo
Multiprotocol Label SwitchingMultiprotocol Label SwitchingMain
Open search
Multiprotocol Label Switching
Community hub
Multiprotocol Label Switching
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Multiprotocol Label Switching
Multiprotocol Label Switching
Multiprotocol Label Switching
View on Wikipedia
from Wikipedia

Multiprotocol Label Switching (MPLS) is a routing technique in telecommunications networks that directs data from one node to the next based on labels rather than network addresses.[1] Whereas network addresses identify endpoints, MPLS labels identify established paths between endpoints. MPLS can encapsulate packets of various network protocols and supports a range of access technologies, including T1/E1, ATM, Frame Relay, and DSL.

MPLS was originally developed to improve packet forwarding by reducing the reliance on complex routing table lookups. With the introduction of hardware-based forwarding engines, forwarding speed is no longer the main reason for deployment, and MPLS today is more often used for traffic engineering, Differentiated Services quality of service, and BGP/MPLS IP virtual private networks (VPNs).[2][3][4][5]


In an MPLS network, packet-forwarding decisions are made solely on the contents of labels, without the need to examine the packet itself. This allows for the creation of end-to-end connections across any type of transport medium, using any protocol. The primary benefit is to eliminate dependence on a particular OSI data link layer technology, and eliminate the need for multiple layer-2 networks to satisfy different types of traffic. Multiprotocol label switching belongs to the family of packet-switched networks.

MPLS operates at a layer between traditional definitions of OSI Layer 2 (data link layer) and Layer 3 (network layer), and is often referred to as a layer 2.5 protocol. It was designed to provide a unified data-carrying service for both circuit-based clients and packet-switching clients which provide a datagram service model. It can be used to carry many different kinds of traffic, including IP packets, as well as native Asynchronous Transfer Mode (ATM), Frame Relay, Synchronous Optical Networking (SONET) or Ethernet.

MPLS can exist in both an IPv4 and an IPv6 environment, using appropriate routing protocols. The major goal of MPLS development was the increase of routing speed. This goal is no longer relevant because of the usage of newer switching methods such as ASIC, TCAM and CAM-based switching able to forward plain IPv4 as fast as MPLS labeled packets. Now, therefore, the main benefit of MPLS is to implement limited traffic engineering and layer 3 or layer 2 service provider type VPNs over IPv4 networks.

MPLS is standardized by the IETF in RFC 3031. It is deployed to connect as few as two facilities to very large deployments. In practice, MPLS is mainly used to forward IP protocol data units and Virtual Private LAN Service (VPLS) Ethernet traffic. Major applications of MPLS are telecommunications traffic engineering and MPLS VPN. MPLS works in conjunction with the Internet Protocol (IP) and its routing protocols, usually interior gateway protocols (IGPs) and supports the creation of dynamic, transparent virtual networks with support for traffic engineering, the ability to transport layer VPNs with overlapping address spaces, and for layer-2 pseudowires that are capable of transporting a variety of transport payloads (IPv4, IPv6, ATM, Frame Relay, etc.).

History

[edit]

In 1996 a group from Ipsilon Networks proposed a flow management protocol.[6] Their IP Switching technology, which was defined only to work over ATM, did not achieve market dominance. Cisco Systems introduced a related proposal, not restricted to ATM transmission, called Tag Switching[7] with its Tag Distribution Protocol (TDP).[8] It was a Cisco proprietary proposal, and was renamed Label Switching. It was handed over to the Internet Engineering Task Force (IETF) for open standardization. The IETF formed the MPLS Working Group in 1997. Work involved proposals from other vendors, and development of a consensus protocol that combined features from several vendors' work.[9]

Some time later it was recognized that the work on threaded indices by Girish Chandranmenon and George Varghese had invented the idea of using labels to represent destination prefixes that was central to tag switching.[10]

One original motivation was to allow the creation of simple high-speed switches since for a significant length of time it was considered impractical to forward IP packets entirely in hardware. Advances in VLSI and in forwarding algorithms have made hardware forwarding of IP packets possible and common. The current advantages of MPLS primarily revolve around the ability to support multiple service models and perform traffic management. MPLS also offers a robust recovery framework[11] that goes beyond the simple protection rings of synchronous optical networking (SONET/SDH).

A number of different technologies were previously deployed with essentially identical goals, such as Frame Relay and ATM. Frame Relay and ATM use labels to move frames or cells through a network. The header of the Frame Relay frame and the ATM cell refers to the virtual circuit that the frame or cell resides on. The similarity between Frame Relay, ATM, and MPLS is that at each hop throughout the network, the label value in the header is changed. This is different from the forwarding of IP packets.[12]

MPLS technologies have evolved with the strengths and weaknesses of ATM in mind. MPLS is designed to have lower overhead than ATM while providing connection-oriented services for variable-length frames, and has replaced much use of ATM in the market.[13] MPLS dispenses with the cell-switching and signaling-protocol baggage of ATM. MPLS recognizes that small ATM cells are not needed in the core of modern networks, since modern optical networks are fast enough that even full-length 1500-byte packets do not incur significant real-time queuing delays.[a] At the same time, MPLS attempts to preserve the traffic engineering (TE) and out-of-band control that made Frame Relay and ATM attractive for deploying large-scale networks.

Dates

[edit]
  • 1994: Toshiba presented Cell Switch Router (CSR) ideas to IETF BOF
  • 1995: George Varghese and Girish Chandranmenon published paper on threaded indices, a form of label switching, at ACM SIGCOMM annual conference[14]
  • 1996: Ipsilon, Cisco and IBM announced label-switching plans
  • 1997: Formation of the IETF MPLS working group
  • 1999: First MPLS VPN (L3VPN) and TE deployments
  • 2000: MPLS Traffic Engineering
  • 2001: First MPLS Request for Comments (RFC) published[15]
  • 2002: AToM (L2VPN)
  • 2004: GMPLS; Large-scale L3VPN
  • 2006: Large-scale TE "Harsh"
  • 2007: Large-scale L2VPN
  • 2009: Label Switching Multicast
  • 2011: MPLS transport profile

Operation

[edit]

MPLS works by prefixing packets with an MPLS header, containing one or more labels. This is called a label stack.

MPLS packet structure
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 MPLS Label [1]
4 32 MPLS Label [2]
⋮ ⋮ ⋮
⋮ ⋮ MPLS Label [n]
4n 32n Packet
⋮ ⋮
⋮ ⋮

Each entry in the label stack contains four fields:

MPLS Label
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Label TC S Time to Live
Label: 20 bits
A label with the value of 1 represents the router alert label.
Traffic Class (TC): 3 bits
Field for QoS (quality of service) priority and ECN (Explicit Congestion Notification). Prior to 2009 this field was called EXP.[16]
Bottom of Stack (S): 1 bit
If this flag is set, it signifies that the current label is the last in the stack.
Time to Live (TTL): 8 bits
Time to live.

These MPLS-labeled packets are switched based on the label instead of a lookup in the IP routing table. When MPLS was conceived, label switching was faster than a routing table lookup because switching could take place directly within the switched fabric and avoided CPU and software involvement.

The presence of such a label has to be indicated to the switch. In the case of Ethernet frames this is done through the use of EtherType values 0x8847 and 0x8848, for unicast and multicast connections respectively.[17]

Equipment

[edit]
MPLS VPN network diagram with wikilinks

Label switch router

[edit]

An MPLS router that performs routing based only on the label is called a label switch router (LSR) or transit router. This is a type of router located in the middle of an MPLS network. It is responsible for switching the labels used to route packets.

When an LSR receives a packet, it uses the label included in the packet header as an index to determine the next hop on the label-switched path (LSP) and a corresponding label for the packet from a Label Information Base. The old label is then removed from the header and replaced with the new label before the packet is routed forward.

Label edge router

[edit]

A label edge router (LER, also edge LSR (which is "technically more correct")[18] or simply edge router[19]) is a router that operates at the edge of an MPLS network and acts as the entry and exit points for the network. LERs push an MPLS label onto an incoming packet[b] and pop it off an outgoing packet. Alternatively, under penultimate hop popping this function may instead be performed by the LSR directly connected to the LER.[c]

When forwarding an IP datagram into the MPLS domain, a LER uses routing information to determine the appropriate label to be affixed, labels the packet accordingly, and then forwards the labeled packet into the MPLS domain. Likewise, upon receiving a labeled packet that is destined to exit the MPLS domain, the LER strips off the label and forwards the resulting IP packet using normal IP forwarding rules.

Provider router

[edit]

In the specific context of an MPLS-based virtual private network (VPN), LERs that function as ingress or egress routers to the VPN are often called provider edge (PE) routers. Devices that function only as transit routers are similarly called provider (P) routers.[20] The job of a P router is significantly easier than that of a PE router.

Label Distribution Protocol

[edit]

Labels may be distributed between LERs and LSRs using the Label Distribution Protocol (LDP)[21] or Resource Reservation Protocol (RSVP).[22] LSRs in an MPLS network regularly exchange label and reachability information with each other using standardized procedures in order to build a complete picture of the network so that they can then use that information to forward the packets.

Label-switched paths

[edit]

Label-switched paths (LSPs) are established by the network operator for a variety of purposes, such as to create network-based IP virtual private networks or to route traffic along specified paths through the network. In many respects, LSPs are not different from permanent virtual circuits (PVCs) in ATM or Frame Relay networks, except that they are not dependent on a particular layer-2 technology.

Routing

[edit]

When an unlabeled packet enters the ingress router and needs to be passed on to an MPLS tunnel, the router first determines the forwarding equivalence class (FEC) for the packet and then inserts one or more labels in the packet's newly created MPLS header. The packet is then passed on to the next hop router for this tunnel.

From an OSI model perspective, the MPLS Header is added between the network layer header and link layer header.[23]

When a labeled packet is received by an MPLS router, the topmost label is examined. Based on the contents of the label a swap, push[d] or pop[e] operation is performed on the packet's label stack. Routers can have prebuilt lookup tables that tell them which kind of operation to do based on the topmost label of the incoming packet so they can process the packet very quickly.

  • In a swap operation the label is swapped with a new label, and the packet is forwarded along the path associated with the new label.
  • In a push operation a new label is pushed on top of the existing label, effectively encapsulating the packet in another layer of MPLS. This allows hierarchical routing of MPLS packets. Notably, this is used by MPLS VPNs.
  • In a pop operation the label is removed from the packet, which may reveal an inner label below. This process is called decapsulation. If the popped label was the last on the label stack, the packet leaves the MPLS tunnel. This can be done by the egress router, or at the penultimate hop.

During these operations, the contents of the packet below the MPLS Label stack are not examined. Indeed, transit routers typically need only to examine the topmost label on the stack. The forwarding of the packet is done based on the contents of the labels, which allows protocol-independent packet forwarding that does not need to look at a protocol-dependent routing table and avoids the expensive IP longest prefix match at each hop.

At the egress router, when the last label has been popped, only the payload remains. This can be an IP packet or any type of packet. The egress router must, therefore, have routing information for the packet's payload since it must forward it without the help of label lookup tables. An MPLS transit router has no such requirement.

Usually[f], the last label is popped off at the penultimate hop (the hop before the egress router). This is called penultimate hop popping (PHP). This is useful in cases where the egress router has many packets leaving MPLS tunnels and thus spends significant CPU resources on these transitions. By using PHP, transit routers connected directly to this egress router effectively offload it, by popping the last label themselves. In the label distribution protocols, this PHP label pop action is advertised as label value 3 (implicit null) and is never found in a label, since it means that the label is to be popped.

Several MPLS services including end-to-end QoS management,[24] and 6PE,[25] require keeping a label even between the penultimate and the last MPLS router, with a label disposition always done on the last MPLS router, ultimate hop popping (UHP).[26][27] Some specific label values have been notably reserved[28][29] for this use. In this scenario the remaining label stack entry conveys information to the last hop (such as its Traffic Class field for QoS information), while also instructing the last hop to pop the label stack using one of the following reserved label values:

  • 0: Explicit-null for IPv4
  • 2: Explicit-null for IPv6

An MPLS header does not identify the type of data carried inside the MPLS path. To carry two different types of traffic between the same two routers, with different treatment by the core routers for each type, a separate MPLS path for each type of traffic is required.

Label-switched path

[edit]

A label-switched path (LSP) is a path through an MPLS network set up by the NMS or by a signaling protocol such as LDP, RSVP-TE, BGP (or the now deprecated CR-LDP). The path is set up based on criteria in the FEC.

The path begins at an LER, which makes a decision on which label to prefix to a packet based on the appropriate FEC. It then forwards the packet along to the next router in the path, which swaps the packet's outer label for another label, and forwards it to the next router. The last router in the path removes the label from the packet and forwards the packet based on the header of its next layer, for example IPv4. Due to the forwarding of packets through an LSP being opaque to higher network layers, an LSP is also sometimes referred to as an MPLS tunnel.

The router which first prefixes the MPLS header to a packet is an ingress router. The last router in an LSP, which pops the label from the packet, is called an egress router. Routers in between, which need only swap labels, are called transit routers or label switch routers (LSRs).

Note that LSPs are unidirectional; they enable a packet to be label switched through the MPLS network from one endpoint to another. Since bidirectional communication is typically desired, the aforementioned dynamic signaling protocols can automatically set up a separate LSP in the opposite direction.

When link protection is considered, LSPs can be categorized as primary (working), secondary (backup) and tertiary (LSP of last resort).

Installing and removing paths

[edit]

There are two standardized protocols for managing MPLS paths: the Label Distribution Protocol (LDP) and RSVP-TE, an extension of the Resource Reservation Protocol (RSVP) for traffic engineering.[30][31] Furthermore, there exist extensions of the Border Gateway Protocol (BGP) that can be used to manage an MPLS path.[20][32][33]

Multicast addressing

[edit]

Multicast was, for the most part, an afterthought in MPLS design. It was introduced by point-to-multipoint RSVP-TE.[34] It was driven by service provider requirements to transport broadband video over MPLS.

The hub and spoke multipoint LSP (HSMP LSP) was also introduced by IETF. HSMP LSP is mainly used for multicast, time synchronization, and other purposes.

Relationship to Internet Protocol

[edit]

MPLS works in conjunction with the Internet Protocol (IP) and its routing protocols, usually interior gateway protocols (IGPs). MPLS LSPs provide dynamic, transparent virtual networks with support for traffic engineering, the ability to transport layer-3 (IP) VPNs with overlapping address spaces, and support for layer-2 pseudowires using Pseudowire Emulation Edge-to-Edge (PWE3)[35] that are capable of transporting a variety of transport payloads (IPv4, IPv6, ATM, Frame Relay, etc.). MPLS-capable devices are referred to as LSRs. The paths an LSR knows can be defined using explicit hop-by-hop configuration, or are dynamically routed by the Constrained Shortest Path First (CSPF) algorithm, or are configured as a loose route that avoids a particular IP address or that is partly explicit and partly dynamic.

In a pure IP network, the shortest path to a destination is chosen even when the path becomes congested. Meanwhile, in an IP network with MPLS Traffic Engineering CSPF routing, constraints such as the RSVP bandwidth of the traversed links can also be considered, such that the shortest path with available bandwidth will be chosen. MPLS Traffic Engineering relies upon the use of TE extensions to Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS) and RSVP. In addition to the constraint of RSVP bandwidth, users can also define their own constraints by specifying link attributes and special requirements for tunnels to route (or not to route) over links with certain attributes.[36]

For end-users the use of MPLS is not visible directly, but can be assumed when doing a traceroute: only nodes that do full IP routing are shown as hops in the path, thus not the MPLS nodes used in between, therefore when you see that a packet hops between two very distant nodes and hardly any other hop is seen in that provider's network (or AS) it is very likely that network uses MPLS.

MPLS local protection

[edit]
Main article: MPLS local protection

In the event of a network element failure when recovery mechanisms are employed at the IP layer, restoration may take several seconds which may be unacceptable for real-time applications such as VoIP.[37][38][39] In contrast, MPLS local protection meets the requirements of real-time applications with recovery times comparable to those of shortest path bridging networks or SONET rings of less than 50 ms.[37][39][40]

Comparisons

[edit]

MPLS can make use of existing ATM network or Frame Relay infrastructure, as its labeled flows can be mapped to ATM or Frame Relay virtual-circuit identifiers, and vice versa.

Frame Relay

[edit]

Frame Relay aimed to make more efficient use of existing physical resources, which allow for the underprovisioning of data services by telecommunications companies (telcos) to their customers, as clients were unlikely to be utilizing a data service 100 percent of the time. Consequently, oversubscription of capacity by the telcos, while financially advantageous to the provider, can directly affect overall performance.

Telcos often sold Frame Relay to businesses looking for a cheaper alternative to dedicated lines; its use in different geographic areas depended greatly on governmental and telecommunication companies' policies.

Many customers migrated from Frame Relay to MPLS over IP or Ethernet, which in many cases reduced costs and improved manageability and performance of their wide area networks.[41]

Asynchronous Transfer Mode

[edit]

While the underlying protocols and technologies are different, both MPLS and ATM provide a connection-oriented service for transporting data across computer networks. In both technologies, connections are signaled between endpoints, the connection state is maintained at each node in the path, and encapsulation techniques are used to carry data across the connection. Excluding differences in the signaling protocols (RSVP/LDP for MPLS and PNNI for ATM) there still remain significant differences in the behavior of the technologies.

The most significant difference is in the transport and encapsulation methods. MPLS is able to work with variable-length packets while ATM uses fixed-length (53 bytes) cells. Packets must be segmented, transported and re-assembled over an ATM network using an adaptation layer, which adds significant complexity and overhead to the data stream. MPLS, on the other hand, simply adds a label to the head of each packet and transmits it on the network.

Differences exist, as well, in the nature of the connections. An MPLS connection (LSP) is unidirectional, allowing data to flow in only one direction between two endpoints. Establishing two-way communications between endpoints requires a pair of LSPs be established. Because two LSPs are used, data flowing in the forward direction may use a different path from data flowing in the reverse direction. ATM point-to-point connections (virtual circuits), on the other hand, are bidirectional, allowing data to flow in both directions over the same path.[g]

Both ATM and MPLS support tunneling of connections inside connections. MPLS uses label stacking to accomplish this while ATM uses virtual paths. MPLS can stack multiple labels to form tunnels within tunnels. The ATM virtual path indicator (VPI) and virtual circuit indicator (VCI) are both carried together in the cell header, limiting ATM to a single level of tunneling.

The biggest advantage that MPLS has over ATM is that it was designed from the start to be complementary to IP. Modern routers can support both MPLS and IP natively across a common interface allowing network operators great flexibility in network design and operation. ATM's incompatibilities with IP require complex adaptation, making it comparatively less suitable for today's predominantly IP networks.

Deployment

[edit]

MPLS is standardized by the IETF in RFC 3031. It is deployed to connect as few as two facilities to very large deployments. In practice, MPLS is mainly used to forward IP protocol data units (PDUs) and Virtual Private LAN Service (VPLS) Ethernet traffic. Major applications of MPLS are telecommunications traffic engineering and MPLS VPN.

Evolution

[edit]

MPLS was originally proposed to allow high-performance traffic forwarding and traffic engineering in IP networks. However, it evolved in Generalized MPLS (GMPLS) to also allow the creation of LSPs in non-native IP networks, such as SONET/SDH networks and wavelength switched optical networks.

Competing protocols

[edit]

MPLS can exist in both an IPv4 and an IPv6 environment, using appropriate routing protocols. The major goal of MPLS development was the increase of routing speed.[43] This goal is no longer relevant[44] because of the usage of newer switching methods such as ASIC, TCAM and CAM-based switching able to forward plain IPv4 as fast as MPLS labeled packets.[45] Now, therefore, the main benefit[46] of MPLS is to implement limited traffic engineering and layer 3 or layer 2 service provider type VPNs over IPv4 networks.[47]

Notes

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Multiprotocol Label Switching

View on Grokipedia
from Grokipedia
Multiprotocol Label Switching (MPLS) is a high-performance packet-forwarding technology that directs data packets through a using short, fixed-length labels rather than traditional network addresses, enabling faster forwarding decisions by avoiding repeated Layer 3 header analysis at each hop. This approach integrates the traffic management and performance characteristics of Layer 2 switching with the flexibility and scalability of Layer 3 , making it suitable for large-scale and networks. Standardized by the (IETF) in RFC 3031, MPLS supports multiple protocols, including IP, , and , by encapsulating them within labeled packets for efficient transport. In MPLS architecture, packets entering the network domain are classified into forwarding equivalence classes (FECs) at the label edge router (LER), where a label is assigned based on criteria such as destination IP address or quality of service requirements. These labels are then propagated along a label-switched path (LSP), a unidirectional path through the network defined by label switch routers (LSRs), which perform simple label lookups and swaps to forward the packet without examining the underlying protocol headers. Label distribution protocols, such as Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP), establish and maintain LSPs, allowing for dynamic path selection and traffic engineering to optimize bandwidth usage and reduce latency. MPLS offers several key benefits, including improved network efficiency through explicit path control, support for virtual private networks (VPNs) via label stacking, and enhanced scalability for core networks handling high volumes of traffic. It enables service providers to offer , such as guaranteed bandwidth or low-latency paths, while maintaining compatibility with existing IP infrastructure. Although originally developed in the late 1990s to address the shortcomings of in backbone networks, MPLS remains widely deployed in modern wide-area networks, often in conjunction with technologies like Segment Routing for simplified operations.

Introduction

Role in Networking

Multiprotocol Label Switching (MPLS) is a versatile, protocol-agnostic forwarding technology that directs data packets through a using short, fixed-length labels attached to packets, rather than relying on destination IP addresses for decisions. This label-based approach enables efficient across diverse network protocols, including IP, , and , by associating labels with forwarding equivalence classes (FECs) that group packets sharing the same forwarding treatment. In backbone networks, MPLS plays a central role in enhancing overall efficiency and enabling advanced services without altering the underlying infrastructure. A key function of MPLS is to accelerate packet forwarding by eliminating the need for complex, per-packet IP address lookups at intermediate routers, which instead perform simple label lookups and swaps for high-speed transit. This mechanism supports critical capabilities such as traffic engineering, allowing explicit control over path selection to optimize resource utilization and avoid congestion; virtual private networks (VPNs), which provide secure, isolated connectivity over shared infrastructure; and quality of service (QoS) enforcement, ensuring prioritized handling for latency-sensitive traffic like voice or video. These features make MPLS particularly valuable in large-scale carrier networks, where it facilitates the delivery of differentiated services while maintaining compatibility with existing Layer 3 routing protocols. MPLS offers significant benefits in terms of , as core routers maintain compact label forwarding tables instead of voluminous tables, reducing memory and processing demands in expansive networks. It integrates seamlessly with both Layer 2 switching and Layer 3 paradigms, supporting multiprotocol environments and enabling service providers to consolidate multiple legacy technologies into a unified . Additionally, label stacking—where multiple labels can be pushed onto a packet—allows for hierarchical structures that support nested services, such as tunneling VPN traffic within broader -engineered paths, thereby enhancing flexibility without increasing operational complexity. Label-switched paths (LSPs) form the basis for these operations, providing predetermined routes for labeled .

Basic Principles

Multiprotocol Label Switching (MPLS) employs short, fixed-length identifiers known as labels to facilitate in a network. These labels, typically 20 bits in length, are assigned to packets based on their (FEC), which groups packets with similar forwarding requirements. At the ingress to an MPLS domain, the first Label Switching Router (LSR) attaches one or more labels to the packet, encapsulating it for label-based forwarding rather than traditional lookups. The core forwarding process in MPLS relies on label swapping within the network domain. Upon receiving a labeled packet, an LSR consults its Label Information Base (LIB), a database that maps incoming labels to outgoing interfaces and replacement labels. The LSR then swaps the top on the stack with the new outgoing label and forwards the packet to the next hop, avoiding the computational overhead of analysis at each intermediate router. This swapping occurs efficiently across the core LSRs, enabling high-speed forwarding. At the egress LSR, the final label is removed (or "popped"), restoring the original packet for delivery to the destination or further non-MPLS processing. MPLS labels are carried in a "shim header" inserted between the Layer 2 () header and the Layer 3 (network) header of the packet. This shim, typically 32 bits per label entry (including the 20-bit label value, a 3-bit experimental field, a bottom-of-stack indicator, and an 8-bit time-to-live field), allows MPLS to operate independently of the underlying link-layer technology while maintaining compatibility with IP packets. The encapsulation supports label stacking, where multiple labels can be pushed onto the stack to enable hierarchical forwarding. Two primary models govern label encapsulation and processing in MPLS: the uniform model and the pipe model. In the uniform model, each LSR treats the packet as if it were destined for the immediate next hop, performing a label lookup that determines both the outgoing interface and the operation on the label stack (such as swap, push, or pop), while decrementing the TTL field in the outermost label at every hop. Conversely, the pipe model emulates end-to-end IP TTL behavior across the MPLS domain; at ingress, the IP TTL is copied into the MPLS label TTL, and intermediate LSRs decrement it per hop, but at egress, the TTL is copied back to the inner IP header only when the stack is fully popped, effectively hiding the domain's internal hops from the end-to-end TTL count. These models ensure flexibility in handling TTL propagation for security and loop prevention.

History

Origins and Development

In the mid-1990s, as the experienced rapid growth, IETF engineers including Paul Doolan and Eric Rosen began conceptualizing a technology to enhance IP network scalability by bridging traditional with efficient label-swapping mechanisms from circuit-switched technologies like and . The primary motivations stemmed from the computational overhead of IP's lookups in expanding backbone networks and the need to leverage hardware-accelerated forwarding from ATM switches without fully adopting their connection-oriented model. This led to several independent proposals in 1996. Cisco Systems introduced Tag Switching in September 1996, a method that assigned short fixed-length tags to packets at network edges for subsequent label-based forwarding, reducing per-packet routing decisions while preserving IP's flexibility; key contributors included Doolan, Rosen, and Yakov Rekhter. Concurrently, Ipsilon Networks proposed IP Switching, which used flow detection to establish shortcut virtual circuits over hardware, as detailed in their Ipsilon Flow Management Protocol specification from May 1996. IBM advanced Aggregate Route-Based IP Switching (ARIS) in November 1996, focusing on route aggregation to minimize virtual connections and integrate IP routing protocols like OSPF directly with switching fabrics. By 1997, these initiatives converged under the IETF's Multiprotocol Label Switching (MPLS) framework, with Rosen and others synthesizing label distribution and forwarding concepts from Tag Switching, IP Switching, and ARIS into a unified . This effort, formalized in early MPLS drafts, addressed the diverse needs of multiprotocol environments while paving the way for broader standardization.

Standardization and Key Milestones

The standardization of Multiprotocol Label Switching (MPLS) was spearheaded by the (IETF) through its MPLS Working Group, established in 1997 to develop a scalable forwarding mechanism that integrates label switching with , resulting in a series of (RFCs) that formalized the protocol's architecture and extensions. A pivotal document in this process is RFC 3031, published in January 2001 as a Proposed Standard, which defines the core MPLS architecture and emphasizes its multiprotocol capabilities, allowing labels to be used for forwarding packets of various protocols beyond just IP. Complementing this, RFC 3032, also from January 2001, specifies the MPLS label stack encoding, detailing how labels are structured and transmitted over various link-layer protocols such as PPP and Ethernet to ensure efficient packet handling in MPLS domains. Key operational protocols were further refined through subsequent RFCs; for instance, RFC 5036, released in October 2007, updates the Label Distribution Protocol (LDP) specification originally outlined in RFC 3036, providing procedures for label distribution among label switch routers to establish label-switched paths along routed paths. Initial commercial deployments of MPLS by Internet Service Providers (ISPs) began in 1999, shortly after early draft specifications emerged, enabling early adoption for traffic optimization in backbone networks. Significant milestones include the introduction of traffic engineering extensions in RFC 3209, published in December 2001, which extends RSVP to support explicit label-switched path setup for better resource utilization and bandwidth management in MPLS networks. The standardization of BGP-MPLS VPNs followed in RFC 4364, issued in February 2006, which outlines a peer-model approach for service providers to deliver scalable IP Virtual Private Networks over MPLS backbones, marking a major step in enterprise connectivity solutions. MPLS evolved to support legacy service emulation with RFC 3985 in February 2005, defining the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture for transporting emulated circuits like Frame Relay and ATM over MPLS PSNs. By September 2009, RFC 5654 established requirements for the MPLS Transport Profile (MPLS-TP), a variant tailored for transport networks with enhanced determinism and operations, administration, and maintenance features, reflecting joint IETF and ITU-T efforts to adapt MPLS for carrier-grade applications.

Architecture and Components

Label Edge Routers

Label Edge Routers (LERs) are specialized Label Switching Routers (LSRs) positioned at the boundaries of an MPLS domain, serving as the ingress and egress points for traffic entering and exiting the network. As ingress LERs, they perform label imposition by assigning one or more MPLS labels to incoming unlabeled packets based on the Forwarding (FEC) determined through lookups or policy decisions. Conversely, egress LERs execute label disposition, stripping MPLS labels from packets before forwarding them to non-MPLS networks, ensuring seamless integration with external domains. A core function of LERs is IP-to-label mapping, where they classify packets according to information and map them to appropriate labels for MPLS forwarding. This process supports multiprotocol capabilities, enabling LERs to handle diverse packet types such as IPv4, , and Layer 2 protocols like Ethernet, by encapsulating them with MPLS labels without altering the underlying protocol. LERs also interface with non-MPLS networks by performing necessary translations, such as converting IP-routed packets into labeled ones at the ingress and vice versa at the egress, thus bridging traditional with MPLS efficiency. In (VPN) deployments, LERs—often referred to as Provider Edge (PE) routers—play a critical role in isolating customer traffic by imposing VPN-specific labels alongside transport labels, ensuring secure and segregated paths across the provider's MPLS backbone. This dual-labeling mechanism allows multiple customers to share the same infrastructure while maintaining logical separation through label stacking. LERs interact with internal Label Switch Routers by injecting labeled packets into the MPLS core for swapping and transport.

Label Switch Routers

Label Switch Routers (LSRs) are core routers within a Multiprotocol Label Switching (MPLS) network that forward packets exclusively based on the labels carried in the packet headers, rather than performing traditional network layer header analysis. These routers operate in the interior of the MPLS domain and are responsible for switching labeled packets along predetermined paths without inspecting the underlying protocol information, such as IP headers. According to the MPLS architecture, an LSR supports the full set of MPLS functions required for label switching, including the ability to process and manipulate labels to maintain efficient packet traversal through the network. The primary function of an LSR is label swapping, where it examines the topmost label on an incoming packet, performs a lookup in its forwarding information base (FIB) to determine the corresponding forwarding equivalence class (FEC), and replaces the incoming label with one or more outgoing labels associated with the next hop. This process relies on pre-established label-to-next-hop mappings derived from label distribution protocols, enabling forwarding decisions via simple table lookups that bypass the computational overhead of IP routing table searches. LSRs also support label stacking, allowing multiple labels to be carried in a stack within the packet header; during forwarding, an LSR may pop the top label, swap it, or push additional labels to support nested label-switched paths (LSPs) for features like traffic engineering or VPNs. This label-based mechanism provides significant scalability advantages, as the use of short, fixed-length labels facilitates high-speed hardware-accelerated forwarding at layer 2 speeds, independent of the label type (e.g., whether it emulates VPI/VCI or uses a native MPLS shim header). Such operations are particularly beneficial in high-capacity core networks, where LSRs can handle terabit-per-second throughput by leveraging dedicated for label processing, reducing latency and increasing packet processing rates compared to conventional IP forwarding. For error handling and loop prevention, LSRs propagate the time-to-live (TTL) value from the original packet into the label stack and decrement it at each hop, expiring the packet if the TTL reaches zero to mimic IP TTL behavior and avoid infinite loops within the MPLS domain. This TTL mechanism ensures robust packet lifetime management without requiring additional protocol-specific checks at the core level.

Provider Routers

Provider routers in Multiprotocol Label Switching (MPLS) networks are specialized devices operated by service providers to enable efficient and service delivery across their infrastructure. They include Provider Edge (PE) routers, which directly attach to for ingress and egress points, and Provider (P) core routers, which interconnect PE routers and manage internal backbone transit. This structure allows service providers to segment customer traffic while optimizing core . PE routers perform critical functions at the network boundary, including establishing connectivity with Customer Edge (CE) routers, multiplexing multiple customer services onto shared infrastructure—such as through (VPLS) for emulating LAN environments—and enforcing (QoS) policies to prioritize traffic based on service level agreements. In contrast, P routers concentrate on labeled transit operations within the provider core, switching packets based on MPLS labels without direct involvement in customer-specific or services, thereby reducing processing overhead in high-volume environments. MPLS integration on provider routers is foundational to (ISP) backbones, where these devices enable label-based forwarding over large-scale IP networks. interfaces on both PE and P routers provide stable, loop-free IP addresses essential for label allocation and distribution, ensuring reliable protocol operations even during link failures. A key distinction from enterprise routers lies in the emphasis on ; provider routers are engineered to handle thousands of customers simultaneously through mechanisms like (VRF) instances on PE devices, supporting extensive VPN deployments without compromising performance. This contrasts with enterprise setups, which prioritize internal connectivity for fewer users and lack the same multi-tenant isolation requirements. PE and P routers align with broader MPLS subtypes, functioning as Label Edge Routers (LER) and Label Switch Routers (LSR), respectively.

Core Operation

Label Distribution Protocol

The (LDP) is a signaling protocol that enables label switch routers (LSRs) in an MPLS network to discover potential peers, establish session adjacencies, and distribute labels corresponding to Forwarding Equivalence Classes (FECs) to support efficient along label-switched paths. Defined in RFC 5036, LDP maps routing information, typically IP prefixes, to MPLS labels, allowing routers to forward packets based on short labels rather than IP lookups at each hop. LDP sessions are established reliably over TCP on port 646, ensuring ordered and error-checked exchange of label bindings between peers. Peer discovery in LDP occurs through Hello messages exchanged over UDP on port 646, either via for basic (link) discovery or for extended (targeted) discovery, enabling LSRs to form connections for subsequent signaling. Upon session establishment, LDP peers negotiate capabilities, such as distribution control modes and FEC types supported, to ensure compatibility. LDP operates in two primary distribution modes: downstream unsolicited (DU), where downstream LSRs proactively advertise mappings for FECs without upstream requests—commonly used for forwarding due to its and ; and downstream on-demand (DoD), where upstream LSRs explicitly request from downstream peers, providing more controlled distribution but potentially increasing signaling overhead. Label distribution procedures in LDP involve a set of message types to manage bindings dynamically in response to updates. An upstream LSR sends a Label Request to solicit a label for a specific FEC from a downstream peer in DoD mode, while in DU mode, downstream LSRs advertise Label Mapping containing the assigned label and FEC details without prompting. When changes occur, such as prefix withdrawals, LSRs issue Label Withdraw to revoke existing mappings, prompting peers to release associated labels via Label Release ; additionally, Label Abort Request allow cancellation of pending requests to avoid unnecessary . These procedures ensure that label information remains synchronized with the underlying () table, facilitating the setup of label-switched paths. To enhance scalability, LDP includes extensions such as the Typed Wildcard FEC element, specified in RFC 5918, which allows an LSR to request or advertise labels for all FECs of a particular type (e.g., pseudowires) in a single message, rather than handling each FEC individually. This extension addresses limitations in the original wildcard FEC mechanism by supporting typed FECs and associated procedures, including capability advertisement during session initialization to indicate support. The Typed Wildcard FEC is particularly useful in environments with numerous similar FECs, reducing signaling load while maintaining the protocol's flexibility for broader label distribution.

Label-Switched Paths

A Label-Switched Path (LSP) in Multiprotocol Label Switching (MPLS) is defined as a unidirectional path through a network of Label Switch Routers (LSRs), where packets belonging to a particular (FEC) are forwarded based on a sequence of labels assigned by each LSR along the path. This sequence effectively creates a virtual circuit-like structure from the ingress Label Edge Router (LER) to the egress LER, enabling explicit control over without relying on at every hop. LSPs are established through signaling protocols that distribute labels and define the path. The Label Distribution Protocol (LDP) enables dynamic LSP setup by associating labels with FECs derived from routing information, using loose path specification that follows IGP routes. Similarly, RSVP-TE extends the Resource Reservation Protocol to establish LSPs with traffic engineering capabilities, allowing explicit path control via Explicit Route Objects (EROs) for strict or loose routing, often used for bandwidth-guaranteed paths. For scalability in large networks, MPLS employs LSP hierarchy through mechanisms like merging and nesting. Label merging occurs when an LSR replaces multiple incoming labels from upstream LSPs with a single outgoing label, consolidating paths and minimizing label usage without altering the underlying FECs. Nesting, facilitated by label stacking, allows an LSP to be tunneled within another higher-level LSP, creating hierarchical tunnels that aggregate traffic and reduce overhead, as the inner LSP labels are only inspected at the tunnel endpoints. LSP integrity and performance are monitored using MPLS echo packets, which emulate data plane traffic to test connectivity. This mechanism supports LSP ping for failure detection and for path verification, enabling operators to identify issues like black-holing or misforwarding along the LSP.

Path Installation and Removal

In MPLS networks, path installation occurs after label mapping exchanges via protocols like LDP, where an LSR receives a binding from its downstream neighbor for a specific Forwarding Equivalence Class (FEC). The receiving LSR then allocates its own for the FEC and installs an entry in its Label Forwarding Information Base (LFIB), associating the incoming with the outgoing provided by the downstream LSR, along with the corresponding next-hop interface and forwarding operation (such as push, swap, or pop). This LFIB update enables efficient -based forwarding along the Label-Switched Path (LSP), replacing traditional IP lookups at intermediate nodes with simple lookups. To maintain consistency and prevent forwarding loops during installation, MPLS employs ordered label distribution control as defined in LDP. Under this mode, an LSR only advertises its label mapping for a FEC to upstream peers after it has received and installed a label from its immediate downstream next-hop toward the FEC's destination. This downstream-to-upstream sequencing ensures that LFIB entries are populated in a coordinated manner across the path, avoiding temporary loops that could arise from independent label allocations. In the context of LSPs, this ordered process dynamically builds the end-to-end forwarding state without requiring global synchronization. Path removal is initiated when an LSR detects a topology change, such as a link or node failure, or receives a withdrawal trigger, prompting it to send a Label Withdrawal message via LDP to all upstream LSRs that hold label bindings from it. Upon receiving the withdrawal, an upstream LSR removes the corresponding entry from its LFIB, ceasing use of the label for forwarding, and propagates the withdrawal message further upstream to cascade the removal along the path. To confirm resource release, the upstream LSR responds with a Label Release message, allowing the downstream LSR to deallocate the label and potentially reuse it for other bindings. This upstream propagation ensures efficient cleanup of stale forwarding state across the network. MPLS OAM mechanisms provide tools to verify the integrity of installed paths post-installation or after changes. Specifically, LSP Ping, which sends echo request packets labeled to traverse the LSP and analyzes the returned stack and reply, detects misconfigurations or inconsistencies in LFIB entries, such as incorrect next-hops or missing labels. This on-demand verification helps confirm loop-free operation and proper installation without disrupting traffic.

Routing and Addressing

MPLS Routing Mechanisms

Multiprotocol Label Switching (MPLS) integrates with underlying routing protocols to compute Forwarding Equivalence Classes (FECs) and maintain label bindings, enabling efficient packet forwarding across label-switched paths (LSPs). Within a single autonomous system, Interior Gateway Protocols (IGPs) such as (OSPF) and (IS-IS) are used to calculate the shortest paths and determine the FEC for each packet based on its IP destination prefix or other criteria derived from the . This integration allows MPLS to leverage the existing IGP topology information for FEC assignment without requiring modifications to the core routing algorithms. For inter-domain routing, (BGP) extends this capability by propagating labeled routes across autonomous systems, particularly for services like Layer 3 VPNs, where BGP carries both the routing information and associated MPLS labels to establish end-to-end connectivity. Label bindings in MPLS are dynamically created and advertised based on these routing updates to map FECs to specific labels. The (LDP) plays a central role in this process for IGP-derived routes, where downstream label switch routers (LSRs) assign labels to FECs and advertise these bindings upstream using LDP messages, ensuring that each LSR along the path has the necessary label information to forward packets toward the destination. This downstream-on-demand approach aligns label distribution with the IGP's convergence, allowing MPLS to adapt to topology changes as routing updates propagate through the network. For scenarios requiring more control over path selection, explicit routing mechanisms like Resource Reservation Protocol - Traffic Engineering (RSVP-TE) enable the establishment of traffic-engineered LSPs. RSVP-TE allows network operators to specify explicit paths that may deviate from the IGP's shortest path, incorporating bandwidth reservations and resource constraints to optimize traffic load balancing and quality of service. Path computation in RSVP-TE uses constrained shortest path first (CSPF) algorithms that consider link attributes advertised via IGPs, ensuring the selected paths meet the specified requirements while integrating seamlessly with the broader MPLS framework. To prevent forwarding loops, MPLS relies on the loop-free properties inherent in the underlying routing protocols, such as the shortest path calculations in OSPF and , which ensure acyclic paths based on link metrics. Additionally, label space management—where labels are allocated uniquely per interface or globally within an LSR—avoids inadvertent reuse that could create loops, while the MPLS label's Time-to-Live (TTL) field provides a mechanism to detect and mitigate any residual loops by decrementing the TTL at each hop, similar to IP TTL.

Multicast Addressing in MPLS

Multicast addressing in MPLS addresses the limitations of using Label-Switched Paths (LSPs) for traffic, where packets must be replicated at branch points or the ingress router, resulting in inefficient bandwidth usage and increased processing overhead on core routers. To overcome this, MPLS introduces point-to-multipoint (P2MP) LSPs, which enable a single copy of a packet to traverse the network while branching efficiently at replication points, reducing duplication and optimizing resource utilization in provider backbones. The primary mechanism for multicast addressing is the Multicast Label Distribution Protocol (mLDP), defined in RFC 6388, which extends the standard (LDP) to support label mappings for multicast Forwarding Equivalence Classes (FECs). In mLDP, a multicast FEC is identified by elements such as the root node address, opaque value (for protocols like PIM), and tree type, allowing the ingress label edge router (LER) to signal P2MP LSPs downstream. These LSPs form a tree topology where labels are assigned per branch, ensuring packets are forwarded natively as without per-packet replication in the core. This approach decouples multicast signaling from , enabling scalable tree construction independent of underlying paths. mLDP integrates closely with Protocol Independent Multicast (PIM) to handle (SSM) scenarios, where Provider Multicast Service Interfaces (PMSIs) are instantiated as P2MP LSPs aligned with PIM sparse mode trees. Inclusive trees carry traffic for multiple sources to a shared group, while exclusive trees are dedicated to specific source-group pairs, allowing dynamic activation for high-bandwidth streams to avoid flooding the default tree. This integration supports both any-source and SSM models by mapping customer routes to core LSPs, ensuring efficient delivery across MPLS domains. In provider networks, these mechanisms enable applications such as IPTV delivery, where a single video stream is efficiently to thousands of subscribers without redundant transmissions, and video conferencing, supporting real-time group communications with low latency and bandwidth conservation.

Integration with IP

MPLS over IP

Multiprotocol Label Switching (MPLS) operates atop the IP layer by encapsulating IP packets with MPLS labels, positioning the label stack directly between the and the underlying link-layer header. This structure enables efficient label-based forwarding while preserving the integrity of the original IP packet. The encoding for this encapsulation is specified in RFC 3032, which defines the 20-bit label, 3-bit experimental bits (often used for traffic class), 8-bit , and the bottom-of-stack indicator, ensuring compatibility with both IPv4 and packets as MPLS is designed as a multiprotocol mechanism. In IP/MPLS hybrid networks, where not all segments support native MPLS, additional encapsulation techniques allow MPLS packets to traverse IP-only portions. RFC 4023 outlines MPLS-in-IP and MPLS-in-GRE methods, where an outer IP header (IPv4 or ) wraps the MPLS label stack and payload, using 0x8847 for MPLS or 0x8848 for multicast. This approach replaces the topmost MPLS label temporarily with for transit, enabling seamless interworking without requiring full MPLS deployment across the entire path. For compatibility, the encapsulation follows extension header guidelines, supporting MPLS transport over cores. The primary benefits of MPLS over IP stem from separating the control and data planes: standard IP routing protocols such as OSPF, , or BGP handle label distribution and path computation in the , while the data plane leverages label swapping for high-speed forwarding, bypassing per-packet IP lookups in the core routers. This hybrid model improves and in large networks by offloading forwarding decisions to simple label operations, reducing processing overhead compared to pure . MPLS over IP facilitates Layer 3 Virtual Private Networks (VPNs) through BGP/MPLS mechanisms, as detailed in RFC 4364, where customer IP routes are exchanged via BGP with attached MPLS labels to establish end-to-end paths. To address overlapping IP addresses across multiple VPNs, route distinguishers—a 64-bit prefix added to IPv4 routes—are used to create unique VPN route identifiers, ensuring isolation and proper within the shared IP/MPLS backbone. This enables service providers to offer secure, segmented IP connectivity over a common infrastructure without native IP forwarding in the MPLS core. For interworking, ingress edge routers in the MPLS domain label incoming IP packets based on forwarding equivalence classes derived from IP destinations, allowing core label switch routers to forward solely via labels without inspecting IP headers. Upon reaching the egress, the label stack is removed, restoring the original IP packet for delivery to the destination network, thus supporting transparent transit of IP traffic through MPLS domains even in hybrid environments.

Local Protection Techniques

Local protection techniques in Multiprotocol Label Switching (MPLS) enable rapid recovery from link or node failures by locally rerouting traffic around affected label-switched paths (LSPs), reducing to near zero. These methods pre-establish paths at the point of local repair (PLR), allowing traffic redirection in under 50 milliseconds upon failure detection via mechanisms like (BFD). This sub-50 ms convergence is vital for delay-sensitive applications, including (VoIP) services and financial trading systems that demand carrier-grade reliability. MPLS Fast Reroute (FRR), defined in RFC 4090, extends the with Traffic Engineering (RSVP-TE) to establish backup LSP tunnels for local repair of primary LSPs. FRR operates on a make-before-break principle, where backup paths are signaled and activated before the protected segment is disrupted, ensuring seamless transitions. Upon failure, the PLR immediately switches traffic to the backup, protecting against both link and node outages without relying on global reconvergence. The protocol introduces new RSVP objects, such as the FAST_REROUTE object for specifying protection attributes and the object for identifying backup paths. FRR supports two primary modes: one-to-one backup and facility backup. In one-to-one backup (also called detour backup), the PLR establishes a dedicated detour LSP for each protected LSP segment, tunneling traffic around the failure point until it rejoins the original path. This approach offers granular control and full isolation but requires more signaling overhead and resources per LSP. Conversely, facility backup employs a shared bypass tunnel to protect an entire facility (link or node), allowing multiple LSPs to share the same backup path through MPLS label stacking. The PLR pushes additional labels onto packets to forward them via the bypass, merging them back at the merge point (MP); this mode is more bandwidth-efficient for dense topologies. Another key local protection method is Loop-Free Alternates (LFA), which leverages (IGP) computations like OSPF or to identify loop-free backup next-hops without additional reservation protocols. LFA pre-installs these alternates in the forwarding plane based on shortest-path metrics, ensuring the backup path avoids the failed component and does not loop back to the PLR. Applicable to both IP and MPLS/LDP environments, LFA provides immediate for traffic, typically achieving sub-50 ms protection for link failures in point-to-point interfaces. It complements FRR by offering lightweight, topology-agnostic repair in scenarios without RSVP-TE deployment.

Comparisons

With Frame Relay

Multiprotocol Label Switching (MPLS) and share conceptual similarities in their use of virtual circuits to provide traffic isolation and connection-oriented services across wide-area networks. In , Permanent Virtual Circuits (PVCs) establish predefined paths between endpoints, ensuring dedicated logical connections without dedicated physical lines. Similarly, MPLS employs Label-Switched Paths (LSPs) to create unidirectional tunnels that segregate traffic flows, mimicking the model by forwarding packets based on labels rather than destination addresses alone. This approach in both technologies enables efficient multiplexing of multiple virtual connections over a shared physical , reducing costs compared to leased lines while maintaining logical separation. Despite these parallels, MPLS and differ fundamentally in their architectural layers, , and adaptability to modern traffic. operates strictly at Layer 2 of the , using Data Link Connection Identifier (DLCI) addressing to switch variable-length frames with fixed committed information rates (CIR) for bandwidth allocation, which limits its efficiency for bursty IP traffic and requires static provisioning. In contrast, MPLS functions as a Layer 2.5 technology, integrating label switching with protocols to handle packet-based forwarding, offering greater for large-scale IP networks through dynamic path computation and support for variable packet sizes without the rigidity of DLCI limits. These differences make MPLS more suitable for integrating with IP cores, whereas 's Layer 2 focus and fixed bandwidth constraints hinder its performance in diverse, high-volume environments. To facilitate migration from legacy Frame Relay networks to MPLS infrastructures, the Any Transport over MPLS (AToM) framework enables the emulation of Frame Relay services via pseudowires, which are point-to-point tunnels that transparently carry Frame Relay Protocol Data Units (PDUs) over an MPLS core. Defined in the Pseudowire Emulation Edge-to-Edge (PWE3) architecture, pseudowires map Frame Relay DLCIs to MPLS labels, preserving the original frame format, including headers and error checking, while leveraging MPLS LSPs for transport. Specific encapsulation methods, such as those outlined for Frame Relay over MPLS, insert a pseudowire control word to handle sequencing and error detection, allowing service providers to consolidate Frame Relay PVCs onto a single MPLS backbone without disrupting customer edge devices. This approach supports both N-to-one and one-to-one modes for Frame Relay traffic, enabling seamless backhauling of existing services. MPLS offers several advantages over Frame Relay, particularly in dynamic routing capabilities and operational efficiency. Unlike Frame Relay's static PVC configuration, which demands manual provisioning and lacks adaptability to network changes, MPLS uses protocols like Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP) for automatic LSP establishment and adjustment, enabling traffic engineering and rapid rerouting. Additionally, MPLS incurs lower protocol overhead by avoiding Frame Relay's extensive header fields and fixed-rate commitments, resulting in more efficient bandwidth utilization for IP-dominant traffic patterns. These features enhance scalability and reduce management complexity, positioning MPLS as a modern evolution for connection-oriented services.

With Asynchronous Transfer Mode

Multiprotocol Label Switching (MPLS) shares conceptual similarities with (ATM) in its use of label-based forwarding to establish efficient paths through the network. In ATM, virtual path identifier (VPI) and virtual channel identifier (VCI) fields in the cell header serve as labels that enable hardware-accelerated switching without examining higher-layer addresses, supporting (QoS) guarantees and circuit-like emulation for voice and data traffic. Similarly, MPLS employs short labels attached to packets to forward traffic along label-switched paths (LSPs), mimicking ATM's connection-oriented behavior while integrating with protocols. This label mechanism in both technologies reduces per-packet processing overhead compared to traditional , facilitating scalable traffic engineering and virtualization. Despite these parallels, MPLS and ATM differ fundamentally in their data handling and implementation. ATM operates on fixed-size 53-byte cells—comprising a 5-byte header and 48-byte payload—optimized for dedicated hardware switches that perform cell segmentation and reassembly (SAR), which ensures predictable latency but introduces segmentation overhead known as the "cell tax" of approximately 10%. In contrast, MPLS processes variable-length packets natively, leveraging a mix of software-based label distribution (via protocols like LDP) and hardware forwarding in modern routers, allowing seamless integration with IP without mandatory cell conversion. These differences make MPLS more adaptable to packet-switched environments, avoiding ATM's rigid cell structure while retaining support for QoS through label stacking and traffic class mappings. MPLS facilitates the transition from infrastructures by enabling emulation, particularly through Virtual Private Wire Service (VPWS), which transports ATM cells or services over MPLS networks without altering the underlying ATM semantics. This approach, defined in standards like RFC 4717, allows service providers to emulate ATM connectivity—such as AAL5 PDU transport—across an IP/MPLS core, effectively bridging legacy ATM edges to modern backbones. By eliminating the cell tax and supporting native IP traffic, MPLS reduces operational complexity and costs associated with ATM's hardware dependencies. Historically, MPLS emerged in the late as an IP-centric evolution to address 's limitations in core networks, with widespread adoption by the early leading to the gradual phase-out of for backbone transport in favor of more flexible, scalable alternatives. Developed by the IETF, MPLS was explicitly designed to replicate 's traffic engineering benefits—like explicit path control—while operating over packet-based infrastructures, accelerating the shift from cell-relay to label-switched IP domains. This evolution enabled carriers to consolidate services without full infrastructure overhauls, solidifying MPLS's role in replacing -dominated cores.

Deployment and Evolution

Historical and Current Deployment

Multiprotocol Label Switching (MPLS) saw its initial commercial deployments in the late 1990s, with the first implementations of MPLS-based Layer 3 VPNs (L3VPNs) and traffic engineering (TE) occurring around 1999. By the early 2000s, adoption accelerated among Tier 1 Internet service providers (ISPs), driven by the need for efficient VPN services and optimized traffic management in growing backbone networks. For instance, AT&T launched its MPLS-based IP VPN service in 2004, extending connectivity over its MPLS infrastructure to support enterprise customers. Similarly, Verizon began emphasizing MPLS for network-based VPNs starting in 2000, integrating it into its wireline offerings to handle increasing data demands. As of 2025, MPLS remains a dominant technology in telecommunications networks, underpinning service providers' infrastructures for core routing and service delivery. It plays a central role in 4G Evolved Packet Core (EPC) and 5G Core (5GC) networks, enabling efficient packet forwarding and network slicing via IP/MPLS technologies. MPLS also facilitates cloud interconnects, such as those between data centers and hybrid environments, and serves as a foundational layer for SD-WAN overlays, providing reliable underlay transport for enterprise applications. The BGP/MPLS VPN framework, in particular, supports enterprise connectivity by allowing scalable, secure virtual networks across global providers, with the IP-MPLS VPN services market valued at approximately $60 billion in 2023 and projected to exceed $100 billion by 2032. Despite its prevalence, MPLS deployment in 2025 faces challenges related to legacy hardware phase-out and scaling. Many providers are transitioning from older MPLS-capable routers that lack support for modern features like Segment Routing, necessitating costly upgrades to maintain performance in high-bandwidth environments. Additionally, while MPLS supports through mechanisms like 6PE and 6VPE, scaling these across large dual-stack networks poses complexities in label management and inter-domain routing, particularly as adoption grows to address address exhaustion.

Evolutions and Modern Enhancements

Since its standardization in the early 2000s, Multiprotocol Label Switching (MPLS) has undergone significant evolutions to address the demands of modern transport networks, particularly post-2010 advancements focusing on enhanced reliability, , and integration with . One key development is the MPLS Transport Profile (), outlined in RFC 5654, which defines requirements for a subset of MPLS tailored for packet transport networks, emphasizing deterministic performance characteristics suitable for metro and aggregation environments. introduces enhancements such as improved Operations, Administration, and Maintenance (OAM) capabilities, including in-band OAM packets for fault detection and performance monitoring without relying on IP connectivity, enabling static provisioning of label-switched paths (LSPs) while supporting unidirectional and bidirectional connectivity models. This profile aligns MPLS more closely with traditional transport technologies like Synchronous Digital Hierarchy (SDH), providing features like 50 ms protection switching for high-availability services in rings and linear topologies up to 1,200 km. A major simplification in MPLS control plane operations came with Segment Routing over MPLS (SR-MPLS), specified in RFC 8660 published in 2019, which leverages the MPLS data plane for source-based routing without the need for intermediate nodes to maintain per-flow state or complex signaling protocols like LDP or RSVP-TE. In SR-MPLS, segment identifiers (SIDs) are encoded as MPLS labels in a stack, allowing the ingress node to steer traffic along explicit paths while reducing network state by eliminating the distribution of forwarding entries across the domain. This approach enhances scalability in large-scale networks by minimizing protocol overhead and enabling traffic engineering through simple label stacking, with forwarding behaviors that process the top label for next-hop decisions and pop the label upon reaching the designated segment endpoint. In the era of and beyond, MPLS has been adapted to support network slicing in transport networks, as described in IETF drafts for realizing end-to-end slices using IP/MPLS technologies, where MPLS LSPs provide isolated, resource-guaranteed paths for diverse services across the transport stratum. This integration facilitates by enabling dynamic allocation of sliced resources for low-latency applications, such as ultra-reliable low-latency communications (URLLC), through MPLS-based virtual networks that map 3GPP-defined slices to transport connectivity services. Complementing this, (EVPN) with MPLS has emerged as a standard for fabrics, as detailed in RFC 8365, offering a overlay that uses MPLS labels for underlay transport to provide scalable, multi-tenant Layer 2 and Layer 3 services across distributed s. EVPN-MPLS employs BGP for signaling to advertise reachability and MAC/IP routes, ensuring efficient any-to-any connectivity in fabrics while supporting features like fast convergence and load balancing via equal-cost multipath (ECMP). Addressing escalating cyber threats in the 2020s, MPLS security has been bolstered through integration with protocols, as framed in the MPLS security framework of RFC 5920, which identifies vulnerabilities in label distribution and recommends layered protections including encryption for payload confidentiality. RFC 6071 further specifies mechanisms, such as Authentication Header (AH) and Encapsulating Security Payload (ESP) in both tunnel and transport modes, to secure MPLS-in-IP tunnels by protecting against , replay attacks, and unauthorized label modifications, particularly in provider-edge to provider-edge (PE-PE) interconnections. These enhancements enable over MPLS without altering the core label-switching fabric, ensuring compliance with modern security standards for sensitive traffic in sliced and virtualized environments.

Competing and Successor Protocols

Segment Routing (SR) emerged as a successor to traditional MPLS by introducing source routing capabilities that encode packet paths using segments, either as MPLS labels (SR-MPLS) or IPv6 addresses, thereby reducing the need for per-flow state in transit nodes and simplifying control plane operations. In SR-MPLS, the forwarding plane remains unchanged from MPLS, allowing seamless integration while eliminating protocols like LDP and RSVP-TE for label distribution, which minimizes network state and enhances scalability. This approach has been widely adopted by service providers, with the global SR market reaching USD 1.72 billion in 2024 and projected to grow at a CAGR of 19.8% through 2033, driven by its efficiency in traffic engineering and network simplification. VXLAN, combined with (EVPN), serves as an overlay alternative to MPLS in environments, enabling multi-tenancy through virtualized Layer 2/3 networks without relying on an MPLS underlay. EVPN provides a BGP-based for VXLAN, supporting features like MAC/ IP mobility and load balancing that address MPLS limitations in patterns common in cloud-scale s. These technologies compete with MPLS by offering greater flexibility for virtualized workloads, as VXLAN's 24-bit segment ID allows up to 16 million isolated networks, far exceeding MPLS label constraints in multi-tenant scenarios. SRv6 extends Segment Routing into an IPv6-native framework, using addresses as segments to program network behaviors, positioning it as a potential replacement for MPLS in future infrastructures like networks. By leveraging the 128-bit header extension, SRv6 eliminates the need for MPLS labels entirely, enabling service embedding directly in packet headers for simplified operations and enhanced programmability. This evolution supports migration from MPLS without full overhauls, as operators can coexist SRv6 with existing MPLS domains during transitions. While MPLS persists for legacy compatibility and proven reliability in wide-area networks, successors like SR and SRv6 offer trade-offs favoring reduced operational complexity and state, though they require IPv6 readiness that MPLS does not. In data centers, VXLAN/EVPN trades MPLS's underlay control for overlay agility, better suiting dynamic, tenant-isolated environments but potentially increasing encapsulation overhead. Overall, these protocols extend MPLS principles while addressing its scalability challenges in modern, distributed architectures.

References

  1. https://datatracker.ietf.org/doc/html/rfc3031
  2. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_basic/configuration/15-sy/mp-basic-15-sy-book/mp-mpls-overview.html
  3. https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/4649-mpls-faq-4649.html
  4. https://www.cisco.com/site/us/en/learn/topics/networking/what-is-multiprotocol-label-switching-mpls.html
  5. https://datatracker.ietf.org/doc/html/rfc2702
  6. https://datatracker.ietf.org/doc/html/rfc4364
  7. https://datatracker.ietf.org/doc/html/rfc3032
  8. https://www.rfc-editor.org/rfc/rfc2105.html
  9. https://datatracker.ietf.org/doc/html/draft-ietf-mpls-arch-00
  10. https://www.cs.princeton.edu/~jrex/teaching/spring2005/reading/rekhter97.pdf
  11. https://newsroom.cisco.com/c/r/newsroom/en/us/a/y1996/m09/cisco-s-new-tag-switching-technology-fuses-routing-and-switching-for-scalable-high-performance-networks.html
  12. https://www.rfc-editor.org/rfc/rfc1954.html
  13. https://datatracker.ietf.org/doc/html/draft-woundy-aris-ipswitching-00
  14. https://datatracker.ietf.org/doc/html/rfc5036
  15. https://www.cisco.com/c/dam/en_us/solutions/industries/docs/energy/mpls_wp_v2.pdf
  16. https://datatracker.ietf.org/doc/html/rfc3209
  17. https://datatracker.ietf.org/doc/html/rfc3985
  18. https://datatracker.ietf.org/doc/html/rfc5654
  19. https://datatracker.ietf.org/doc/html/rfc4216
  20. https://datatracker.ietf.org/doc/html/rfc4761
  21. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_ldp/configuration/xe-2/mp-ldp-xe-2-book/mp-ldp-overview.html
  22. https://www.cisco.com/c/en/us/td/docs/ios/mpls/configuration/guide/mp_mpls_cisco_rtrs.html
  23. https://datatracker.ietf.org/doc/html/rfc5439
  24. https://datatracker.ietf.org/doc/html/rfc5918
  25. https://datatracker.ietf.org/doc/html/rfc4379
  26. https://datatracker.ietf.org/doc/html/rfc3031#section-3
  27. https://datatracker.ietf.org/doc/html/rfc3031#section-3.4.2
  28. https://www.researchgate.net/publication/3200064_Multicast_traffic_aggregation_in_MPLS-based_VPN_networks
  29. https://datatracker.ietf.org/doc/html/rfc6388
  30. https://documentation.nokia.com/acg/24-7-2/books/mpls-classic/c105-multicast-label-distribution-protocol.html
  31. https://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/sbb_mvpn.html
  32. https://www.juniper.net/documentation/us/en/software/junos/subscriber-mgmt-services/topics/concept/subscriber-management-subscriber-secure-policy-multicast.html
  33. https://datatracker.ietf.org/doc/html/rfc4023
  34. https://datatracker.ietf.org/doc/html/rfc4090
  35. https://www.broadband-forum.org/pdfs/mr-305-1-0-0.pdf
  36. https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5xx/routing/66x/b-routing-cg-66x-ncs540/b-routing-cg-63x-ncs540_chapter_01000.pdf
  37. https://datatracker.ietf.org/doc/html/rfc4906
  38. https://datatracker.ietf.org/doc/html/rfc4619
  39. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l2_vpns/configuration/xe-16/mp-l2-vpns-xe-16-book/any_transport_over_mpls.html
  40. https://datatracker.ietf.org/doc/html/rfc4447
  41. https://www.sciencedirect.com/topics/engineering/multi-protocol-label-switching
  42. https://www.rfc-editor.org/rfc/rfc3031.html
  43. https://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-7/mpls/configuration/guide/gc37te.html
  44. https://datatracker.ietf.org/doc/rfc3035
  45. https://datatracker.ietf.org/doc/html/rfc4717
  46. https://datatracker.ietf.org/doc/rfc4717
  47. https://learningnetwork.cisco.com/s/article/MPLS-History-and-building-blocks
  48. https://www.techtarget.com/searchnetworking/definition/Multiprotocol-Label-Switching-MPLS
  49. https://www.crn.com/news/security/18841957/att-launches-mpls-based-ip-vpn-service
  50. https://www.verizon.com/business/resources/articles/making-the-case-for-mpls-vpns-in-the-modern-enterprise/
  51. https://www.ietf.org/archive/id/draft-ietf-teas-5g-ns-ip-mpls-13.html
  52. https://www.globenewswire.com/news-release/2025/03/13/3042307/0/en/MPLS-IP-VPN-Market-to-Reach-USD-110-92-Billion-by-2032-as-Enterprises-Embrace-Secure-and-Scalable-Connectivity-for-Cloud-and-Remote-Work-SNS-Insider.html
  53. https://www.hfcl.com/blog/mpls-still-worth-it-2025
  54. https://nanog.org/events/nanog-76/content/1921/
  55. https://datatracker.ietf.org/doc/html/rfc8660
  56. https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/
  57. https://datatracker.ietf.org/doc/html/rfc8365
  58. https://datatracker.ietf.org/doc/html/rfc6071
  59. https://www.rfc-editor.org/rfc/rfc8402.html
  60. https://growthmarketreports.com/report/segment-routing-market
  61. https://www.link-pp.com/knowledge/mpls-vs-vxlan-comparison.html
  62. https://www.wwt.com/article/segment-routing-the-future-of-mpls
  63. https://www.ciena.com/insights/blog/2025/scaling-transport-networks-the-transition-to-segment-routing
  64. https://orhanergun.net/comparing-mpls-and-segment-routing-which-is-better-for-your-network
Add your contribution
Related Hubs
User Avatar
No comments yet.