MPLS – Multiprotocol Label Switching

1. What Is MPLS and Why Was It Created?

MPLS (Multiprotocol Label Switching) is a high-performance packet-forwarding technology used predominantly in service provider networks. Instead of forwarding packets by performing a routing table (IP longest-prefix match) lookup at every hop, MPLS forwards packets based on a short fixed-length label prepended to the packet. Label lookups are performed in a simple table and are far faster than recursive IP routing table lookups — particularly on older hardware.

MPLS was originally developed in the late 1990s to solve a speed problem: early IP routers performed software-based routing lookups that could not keep up with the rapidly growing Internet. MPLS moved forwarding decisions to hardware-based label switching. While modern routers use hardware ASICs for IP lookups (largely eliminating the speed advantage), MPLS remains essential in service provider networks for a different set of capabilities it uniquely enables: traffic engineering, VPN services, and service differentiation.

Related pages: WAN Technologies Overview | WAN Technologies | DMVPN | GRE Tunnels | IPsec VPN | BGP Overview | OSPF Configuration | MPLS Fundamentals Lab

2. The MPLS Label — Structure and Fields

The MPLS label is a 32-bit (4-byte) header inserted between the Layer 2 (Data Link) header and the Layer 3 (IP) header. This position — between Layer 2 and Layer 3 — is why MPLS is often called a "Layer 2.5" protocol. The label can be stacked: multiple labels can be placed one on top of another, forming a label stack, which is how MPLS VPNs work.

  MPLS label position in a frame:

  ┌─────────────────┬──────────────┬───────────────────────┬──────────────┐
  │  Layer 2 Header │  MPLS Label  │  Layer 3 (IP Header)  │   Payload    │
  │ (Ethernet, etc) │   32 bits    │    (IPv4 / IPv6)      │  (TCP/UDP…)  │
  └─────────────────┴──────────────┴───────────────────────┴──────────────┘
                         ▲
                    "Layer 2.5" — between L2 and L3

  MPLS label field breakdown (32 bits total):
  ┌───────────────────────────────┬─────────┬───┬────────────┐
  │        Label Value            │   EXP   │ S │    TTL     │
  │          20 bits              │  3 bits │1b │  8 bits    │
  └───────────────────────────────┴─────────┴───┴────────────┘

  Label Value (20 bits):
    The forwarding identifier — 0 to 1,048,575 possible values
    Used to look up the next action in the LFIB
    Values 0–15 are reserved (special labels)

  EXP / TC bits (3 bits):
    Originally called EXP (Experimental), now called TC (Traffic Class)
    Used for QoS — carries Class of Service (CoS) value 0–7
    Mapped to DSCP on ingress/egress for end-to-end QoS

  S — Bottom of Stack bit (1 bit):
    S = 1 → this label is the LAST (innermost) label in the stack
    S = 0 → more labels exist below this one in the stack
    The receiving router knows to look at the IP header when S = 1

  TTL (8 bits):
    Time-to-Live — decremented at each LSR hop (like IP TTL)
    Prevents infinite loops in the MPLS domain
    Typically initialised from the IP TTL at ingress

Reserved Label Values

3. MPLS Roles — LER and LSR

Routers in an MPLS network have different roles depending on their position in the network. The two fundamental roles are LER (Label Edge Router) and LSR (Label Switching Router).

3.1 LER — Label Edge Router

An LER sits at the edge of the MPLS domain — between the customer network and the service provider MPLS core. LERs are the routers that impose (push) labels onto packets entering the MPLS domain and remove (pop) labels from packets leaving the domain. There are two types:

3.2 LSR — Label Switching Router

An LSR is a router inside the MPLS core — it never touches unlabelled IP packets in normal operation. An LSR receives a labelled packet, looks up the incoming label in its LFIB (Label Forwarding Information Base), swaps the label for a new outgoing label, and forwards the packet. No IP routing table lookup is performed — the entire forwarding decision is based on the label alone.

  MPLS domain topology:

  [Customer A site 1] ─── [Ingress LER / PE1] ─── [LSR1] ─── [LSR2] ─── [Egress LER / PE2] ─── [Customer A site 2]

  Role at each hop:

  PE1 (Ingress LER):
  - Receives IP packet from Customer A
  - Classifies: destination 10.10.10.0/24 → FEC 1 → label 100
  - PUSHES label 100 onto packet
  - Forwards labelled packet to LSR1

  LSR1 (transit core router):
  - Receives packet with label 100
  - LFIB lookup: incoming label 100 → SWAP to label 200, forward to LSR2
  - Forwards packet to LSR2

  LSR2 (transit core router):
  - Receives packet with label 200
  - LFIB lookup: incoming label 200 → SWAP to label 300, forward to PE2
  (or: SWAP to label 3 implicit null → PHP → forward without label)

  PE2 (Egress LER):
  - Receives packet (label may already be popped by PHP)
  - POPS remaining labels
  - Forwards unlabelled IP packet to Customer A site 2

Three MPLS Forwarding Operations

4. Forwarding Equivalence Class (FEC)

A Forwarding Equivalence Class (FEC) is a group of packets that will all be forwarded in the same way through the MPLS domain — same path, same treatment. At the ingress LER, each incoming packet is classified into exactly one FEC, and a label is assigned to that FEC. All packets in the same FEC receive the same label and follow the same Label Switched Path (LSP) through the network.

  FEC examples:

  FEC 1: All packets destined for 192.168.10.0/24  → label 100
  FEC 2: All packets destined for 10.0.0.0/8       → label 101
  FEC 3: BGP route 203.0.113.0/24 with community X → label 102
  FEC 4: Customer VPN (VRF) A traffic              → label 103

  Any criterion can define an FEC:
  - Destination IP prefix (most common)
  - BGP next-hop
  - VRF (VPN Routing and Forwarding instance)
  - Explicit path for traffic engineering

  All packets matching an FEC get the same label at ingress.
  All packets with the same label follow the same LSP through the core.
  The FEC-to-label binding is distributed by LDP or RSVP-TE.

5. Label Distribution — LDP and RSVP-TE

Labels are not statically configured — they are distributed dynamically between MPLS routers using a label distribution protocol. The two main protocols are LDP and RSVP-TE.

5.1 LDP — Label Distribution Protocol

LDP (Label Distribution Protocol) is the standard protocol for distributing labels in an MPLS network. Every LSR and LER running LDP advertises a label binding for each prefix in its routing table to all neighbouring MPLS routers. LDP follows the IGP topology — it creates LSPs that mirror the IGP shortest path.

  LDP operation:

  Step 1 — LDP discovery: routers send LDP Hello messages on UDP 646
           (multicast 224.0.0.2) to discover LDP neighbours on each link.

  Step 2 — LDP session: TCP session established on port 646 between
           LDP neighbours for reliable label advertisement.

  Step 3 — Label advertisement: each router advertises a label binding
           for every prefix in its IP routing table:
           "To reach 10.10.10.0/24 via me, use incoming label 200"

  Step 4 — LSP formed: neighbours chain these bindings to create a
           complete end-to-end Label Switched Path from ingress to egress.

  LDP characteristics:
  - Follows the IGP shortest path (OSPF/IS-IS determined)
  - No explicit path specification — cannot deviate from IGP topology
  - Simple to deploy — just enable LDP on interfaces
  - Used for basic MPLS forwarding and MPLS VPN services
  - Does not support bandwidth reservation or constraint-based routing

5.2 RSVP-TE — Resource Reservation Protocol with Traffic Engineering

RSVP-TE (Resource Reservation Protocol – Traffic Engineering) extends the original RSVP signalling protocol to establish explicit LSPs that can follow any path through the network — not just the IGP shortest path. RSVP-TE enables MPLS Traffic Engineering (MPLS-TE).

  RSVP-TE operation:

  Step 1 — Traffic Engineering Database (TED): the IGP (IS-IS or OSPF-TE)
           floods link-state information including bandwidth, delay, and
           administrative costs across the network.

  Step 2 — Path computation: CSPF (Constrained Shortest Path First) algorithm
           computes an explicit path that meets required constraints:
           - Available bandwidth ≥ requested bandwidth
           - Link attributes (colour/affinity) match policy
           - Explicit path specified by administrator (optional)

  Step 3 — RSVP PATH message: sent hop-by-hop along the computed path,
           reserving bandwidth at each router along the way.

  Step 4 — RSVP RESV message: sent back from egress to ingress, confirming
           bandwidth reservation and distributing labels along the path.

  Step 5 — LSP established: an explicit path LSP with guaranteed bandwidth
           is now active. Traffic mapped to this LSP follows the explicit path
           regardless of IGP shortest path.

  RSVP-TE enables:
  - Explicit path routing (bypass congested links)
  - Bandwidth reservation per LSP
  - Fast Reroute (FRR) — pre-computed backup paths for sub-50ms failover
  - Link/node protection — bypass tunnels around failed elements

LDP vs RSVP-TE Comparison

6. Label Switched Path (LSP) and LFIB

A Label Switched Path (LSP) is the end-to-end path through the MPLS domain that a specific FEC's traffic follows. An LSP is unidirectional — traffic in each direction follows a separate LSP. The LFIB (Label Forwarding Information Base) is the forwarding table each LSR uses to make label-switching decisions.

  LFIB structure on an LSR:

  Incoming Interface | Incoming Label | Operation | Outgoing Label | Outgoing Interface
  ─────────────────────────────────────────────────────────────────────────────────────
  Gi0/0             |      100       |   SWAP    |      200       |      Gi0/1
  Gi0/0             |      101       |   SWAP    |      201       |      Gi0/2
  Gi0/1             |      300       |   POP     |       -        |      Gi0/0   ← egress
  Gi0/2             |      400       |   PUSH    |   400 over 500 |      Gi0/1   ← VPN (2 labels)

  How the LFIB is built:
  1. IGP (OSPF/IS-IS) builds IP routing table
  2. LDP or RSVP-TE distributes label bindings
  3. LIB (Label Information Base) stores all received label bindings
  4. Best binding (from best next-hop) is selected for the LFIB
  5. LFIB entries are programmed into hardware for fast forwarding

  On an LSR, the IP routing table is NOT used for packet forwarding.
  Packets with labels are forwarded entirely from the LFIB.
  Only the ingress LER uses the IP routing table (to classify into FEC).

7. Penultimate Hop Popping (PHP)

Penultimate Hop Popping (PHP) is a standard MPLS optimisation. Without PHP, the egress LER (PE router) would need to perform two lookups for every arriving packet: first look up the label in the LFIB (to confirm it is the egress), then look up the destination IP in the routing table to forward the packet. PHP eliminates one of these lookups by having the second-to-last router (the penultimate hop) pop the label before forwarding to the egress LER.

  Without PHP (two lookups at egress LER):

  [LSR2] ──label 300──► [Egress LER / PE2]
                               │
                         Step 1: LFIB lookup (label 300 → pop, I am egress)
                         Step 2: IP routing table lookup (destination IP → forward)
                         Two table lookups per packet at the egress

  With PHP (one lookup at egress LER):

  [LSR2] receives packet with label 300
  LSR2's LFIB: incoming 300 → outgoing label = IMPLICIT NULL (label 3)
  LSR2 POPS the label before forwarding → sends UNLABELLED packet to PE2

  [Unlabelled IP packet] ──────────────────► [Egress LER / PE2]
                                                    │
                                        Step 1: IP routing table lookup only
                                        No LFIB lookup needed (no label present)

  PHP reduces CPU load on the egress LER.
  LDP signals PHP by advertising label 3 (Implicit NULL) to the penultimate hop.
  The penultimate hop pops the label — it does NOT forward label 3.

  In MPLS VPNs (label stack), PHP applies to the outer (transport) label only.
  The inner (VPN) label is still present when the packet arrives at the egress PE.

8. MPLS VPNs — Overview

MPLS VPNs are the most commercially significant application of MPLS. They allow a single shared service provider MPLS network to carry completely isolated traffic for multiple customers simultaneously — each customer sees a private network with no awareness of other customers' traffic. MPLS VPNs come in two major variants: Layer 3 VPN (L3VPN) and Layer 2 VPN (L2VPN).

9. MPLS L3VPN — How It Works

MPLS L3VPN (RFC 4364) is the most widely deployed MPLS VPN service. The service provider participates in customer routing: each PE router maintains a separate routing table per customer called a VRF (VPN Routing and Forwarding) instance. Customer routes are distributed between PE routers using MP-BGP (Multiprotocol BGP) with a special address family. A two-label stack carries traffic through the core.

Key Components

MPLS L3VPN Label Stack — Two Labels

  MPLS L3VPN uses a two-label stack on every packet:

  ┌──────────────────┬──────────────────┬────────────────────────┐
  │  Transport Label │    VPN Label     │   IP Packet (customer) │
  │ (outer / top)    │  (inner / bottom)│                        │
  │  Label = 200     │  Label = 500     │  src 10.1.1.1          │
  │  S = 0           │  S = 1           │  dst 10.2.2.2          │
  └──────────────────┴──────────────────┴────────────────────────┘

  Transport label (outer):
  - Pushed by ingress PE (LDP label from PE1 to PE2)
  - Swapped by P routers through the core
  - Identifies the path through the MPLS backbone to the egress PE
  - Popped by PHP at the penultimate P router

  VPN label (inner):
  - Pushed by ingress PE (MP-BGP VPN label advertised by egress PE)
  - NOT touched by P routers (they only see/swap the outer label)
  - Popped by egress PE to identify which VRF and CE to forward to
  - The VPN label alone tells the egress PE which customer this packet belongs to

  End-to-end flow:
  CE1 → PE1: plain IP packet arrives, PE1 classifies into VRF A
  PE1 → P1:  pushes VPN label (500) + transport label (200) → two-label stack
  P1 → P2:   swaps transport label 200 → 300 (VPN label 500 unchanged)
  P2 → PE2:  PHP: pops transport label → only VPN label 500 remains
  PE2 → CE2: pops VPN label 500 → looks up VRF A → forwards to CE2

10. MPLS L2VPN — VPLS and VPWS

MPLS L2VPN services carry Layer 2 frames across the MPLS core — the service provider transports Ethernet, Frame Relay, ATM, or other Layer 2 frames transparently between customer sites. The customer retains full control of routing; the SP is simply a transparent wire. Two primary L2VPN technologies are VPLS and VPWS.

VPWS — Virtual Private Wire Service (Point-to-Point)

  VPWS (also called Pseudowire or AToM — Any Transport over MPLS):
  Provides a point-to-point Layer 2 circuit between two customer sites.

  [Customer Site A] ──Ethernet──► [PE1] ─── MPLS core ─── [PE2] ──Ethernet──► [Customer Site B]

  From the customer's perspective: a direct Layer 2 link between sites.
  Frames injected at Site A emerge unchanged at Site B.

  Use cases:
  - Replace leased lines or Frame Relay point-to-point circuits
  - Connect two customer Ethernet sites as if directly patched
  - Extend a Layer 2 segment across a WAN (e.g., stretch a VLAN)

  Label stack: [Transport label | Pseudowire label | L2 frame]
  The pseudowire label identifies which L2 circuit the frame belongs to.

VPLS — Virtual Private LAN Service (Multipoint)

  VPLS: provides multipoint-to-multipoint Layer 2 connectivity.
  All customer sites appear to be on the same Ethernet LAN (same broadcast domain).

  Customer Site A ──► [PE1] ─┐
  Customer Site B ──► [PE2] ─┤─── MPLS core ─── Virtual Ethernet "switch" (VPLS)
  Customer Site C ──► [PE3] ─┘

  Frames from Site A can reach Sites B and C.
  Broadcast frames from Site A are replicated to Sites B and C.
  Each PE acts as a virtual Ethernet switch for the VPLS domain.

  Use cases:
  - Connect multiple enterprise sites as a single Layer 2 domain
  - Metro Ethernet services
  - Data centre interconnect (DCI) — stretch VLANs between data centres

  Customer controls: routing, IP addressing — SP provides the Layer 2 fabric only.

  Limitation vs L3VPN: VPLS must handle broadcast storms and MAC table flooding
  across the MPLS core — scalability challenges in large deployments.

11. MPLS Traffic Engineering (MPLS-TE)

MPLS Traffic Engineering uses RSVP-TE to create explicit LSPs that route traffic along paths that are not necessarily the IGP shortest path. This allows service providers to distribute load across their network and ensure certain traffic classes get guaranteed bandwidth — capabilities that plain IP routing cannot provide.

Why Traffic Engineering Is Needed

  Problem with IGP-only routing:

  Network topology:
                    ─── Link A (10 Gbps, short path) ───
  [Ingress PE] ─┤                                          ├─ [Egress PE]
                    ─── Link B (10 Gbps, longer path) ──

  IGP selects Link A (shortest path) for ALL traffic.
  Link A: utilisation 95% → congested → packet drops, latency spikes
  Link B: utilisation 5%  → idle → wasted capacity

  With MPLS-TE:
  Flow 1 (best-effort):  → Link A (IGP shortest path)
  Flow 2 (critical app): → Link B (explicit path via RSVP-TE)
                           bandwidth 2 Gbps reserved for this LSP

  Result: critical traffic avoids the congested link;
          Link B capacity is utilised; overall network efficiency improves.

MPLS-TE Key Features

MPLS-TE vs Plain IP Routing

  Plain IP routing: all paths follow IGP metric. Traffic distributes only along
  equal-cost paths. No bandwidth reservation. Failover relies on IGP reconvergence
  (typically 1–30 seconds for large networks).

  MPLS-TE: paths explicitly routed anywhere. Bandwidth reserved per tunnel.
  Fast Reroute provides sub-50 ms failover. Network operator has full control
  over how traffic is distributed across all available capacity.

  Who uses MPLS-TE:
  - Tier 1 and Tier 2 service providers with complex backbone topologies
  - Enterprises with critical real-time applications (trading, voice, video)
  - Data centre operators requiring predictable inter-DC bandwidth

12. Why Service Providers Use MPLS — Commercial Value

MPLS is the backbone technology for the majority of global service provider networks. Its commercial appeal comes from the ability to deliver multiple services — Internet transit, enterprise VPNs, voice, and video — all on the same shared physical infrastructure with strong isolation and quality guarantees.

13. MPLS Summary — Key Facts

14. MPLS Quiz