ScholarGate
Get started
Process / pipelineTelecommunicationsRouting/forwardingPipeline

Multiprotocol Label Switching (MPLS)

Also known as: label switching, traffic engineering

OriginatorIETF MPLS Working GroupYear2001Sources2Related methods8

Multiprotocol Label Switching (MPLS) is a forwarding paradigm that prepends a short label to packets, enabling routers to make forwarding decisions based on the label rather than IP destination address. Introduced by IETF (2001), MPLS was designed to enable traffic engineering, VPN creation, and fast rerouting in IP networks. While MPLS complexity is high, it remains foundational in service provider backbones for traffic engineering and Quality of Service (QoS) provisioning.

Key highlights

  • Traffic engineering: explicit path control enables load balancing and congestion avoidance
  • Fast rerouting: precomputed backup LSPs enable sub-50 ms failover
  • VPN support: MPLS LDP/BGP enables provider-provisioned VPNs (MPLS/BGP VPN)
  • Protocol independence: label-based forwarding works with any IP version or protocol
  • Fast lookup: label-based lookup is O(1), faster than IP prefix matching
  • QoS integration: label values can encode QoS class, enabling per-class prioritization

Intuition

This section is available to Pro members. Upgrade to Pro

How it works

This section is available to Pro members. Upgrade to Pro

When to use it

Use MPLS in service provider networks for traffic engineering and VPN provisioning. MPLS is valuable when LSP-based routing (engineering paths explicit paths) offers advantages over dynamic IP routing. Avoid MPLS in small networks; operational complexity is high. For SDN-based traffic engineering, MPLS combined with controller-driven LSP setup (segment routing) is effective.

Strengths & limitations

Strengths
  • Traffic engineering: explicit path control enables load balancing and congestion avoidance
  • Fast rerouting: precomputed backup LSPs enable sub-50 ms failover
  • VPN support: MPLS LDP/BGP enables provider-provisioned VPNs (MPLS/BGP VPN)
  • Protocol independence: label-based forwarding works with any IP version or protocol
  • Fast lookup: label-based lookup is O(1), faster than IP prefix matching
  • QoS integration: label values can encode QoS class, enabling per-class prioritization
Limitations
  • Operational complexity: MPLS configuration and troubleshooting require expertise
  • Packet overhead: MPLS header adds 4+ bytes to every packet
  • Scalability: managing thousands of LSPs becomes complex; state explosion risk
  • Limited visibility: packet labels obscure content from monitoring and security tools
  • Deployment maturity: MPLS is mature in service provider networks but uncommon in enterprises

Common pitfalls

This section is available to Pro members. Upgrade to Pro

Applications

This section is available to Pro members. Upgrade to Pro

Frequently asked

What is a forwarding equivalence class (FEC)?

An FEC is a set of packets receiving the same treatment (routing, QoS) and thus sharing the same LSP. An FEC is defined by match criteria (IP destination prefix, IP protocol, port) or more granularly (per-flow FEC).

How is an LSP established?

LSPs are established using label distribution protocols (LDP, RSVP-TE). LDP uses hop-by-hop routing to build LSPs. RSVP-TE allows ingress routers to explicitly specify the path, enabling traffic engineering.

What is segment routing (SR)?

Segment routing simplifies MPLS by encoding paths in packet headers without requiring per-LSP state at every hop. Ingress router pushes segment IDs (labels) onto the stack; each hop pops the top label and forwards. This reduces operational complexity significantly.

Why is MPLS less common in data centers than ISP networks?

Data centers prioritize simplicity and speed of deployment. MPLS adds complexity without clear benefit in data center environments. SDN and segment routing offer similar capabilities with less overhead. However, MPLS-based VPNs are still used for connecting geographically distributed data centers.

Sources

  1. 1.
    Rosen, E. C., Viswanathan, A., & Callon, R. (2001). Multiprotocol Label Switching Architecture. RFC 3031.
    https://www.ietf.org
  2. 2.
    Awduche, D. O., Malcolm, J., Agogbua, J., et al. (2002). Requirements for Traffic Engineering over MPLS. RFC 2702.
    https://www.ietf.org

You have read it. What now?

Ask about this methodSimilar methods

Cite this page

ScholarGate. (2026, June 3). MPLS. ScholarGate. https://scholargate.app/telecommunications/mpls