Beyond the textbook — what actually runs inside an operator’s MPLS core

1. What Is MPLS — The Operator’s View

MPLS — Multiprotocol Label Switching — is the backbone technology of virtually every major telecom network on the planet. Not because it is flashy or new (it is neither), but because it solves a set of real operational problems that pure IP routing cannot: traffic engineering, VPN isolation, fast reroute, and QoS at scale.

The core idea is simple: instead of making a forwarding decision at every router hop based on a full IP lookup, MPLS assigns a short fixed-length label to each packet at the network edge. Core routers switch packets using label lookups only — no IP header parsing, no routing table consultation. This is faster, more deterministic, and allows the operator to control exactly which path traffic takes through the network.

In a live operator network, MPLS is not just a speed optimisation. It is the mechanism that enables L3VPNs for enterprise customers, separates RAN traffic from corporate traffic, carries 5G N2/N3 interfaces with QoS guarantees, and provides sub-50ms failure recovery via Fast Reroute. Strip out MPLS and most operator networks would stop functioning within minutes.

2. Real Network Architecture — Roles and Segments

The Three Router Tiers

An operator MPLS network is typically organised into three layers, each with a distinct role:

Router Tier	Role in MPLS	Typical Hardware	Where It Sits
PE (Provider Edge)	Label imposition (push) and removal (pop). Connects customer/RAN sites. Runs BGP + LDP/RSVP.	Cisco ASR9k, Nokia 7750, Huawei NE40E	Aggregation hubs, regional DCs, major sites
P (Provider Core)	Label swap only. No IP routing decision. Pure MPLS forwarding.	Cisco NCS5500, Nokia 7950, Huawei NE9000	Core PoPs, national backbone nodes
CE (Customer Edge)	Sits on the customer/RAN side. Runs IP only — no MPLS awareness.	Any router or gNB/DU with IP interface	Tower sites, enterprise CPE, DU locations

The PE is where all the intelligence lives. It is responsible for understanding what VPN a packet belongs to, imposing the correct label stack, and enforcing QoS policy. The P routers in the core are deliberately kept simple — they do one thing: swap labels and forward at line rate.

LSP — The Label Switched Path

An LSP is a unidirectional pre-established path through the MPLS core from ingress PE to egress PE. Every packet belonging to a given flow follows the same LSP. There is no per-packet IP routing decision in the core — the label determines the path entirely.

LSPs are set up using one of two signalling protocols in operator networks:

LDP (Label Distribution Protocol) — distributes labels hop-by-hop, following the IGP (IS-IS or OSPF) shortest path. Simple to operate, no traffic engineering capability. Used for basic connectivity LSPs.
RSVP-TE (Resource Reservation Protocol — Traffic Engineering) — explicitly signals a specific path with bandwidth reservation. Used for traffic engineering, Fast Reroute, and QoS-guaranteed LSPs. More complex to operate but far more powerful.

Field Note: In a real GCC operator network, you will typically find LDP used for base connectivity between PE and P nodes, and RSVP-TE tunnels layered on top for specific traffic classes — VoNR, enterprise VPNs, and RAN N3 interfaces. Some operators are now replacing RSVP-TE with Segment Routing (covered in Article 3), but RSVP-TE is still dominant in production.

3. Step-by-Step Real Flow — Label Push, Swap, Pop

A 5G CU Packet Traversing the MPLS Core

Let us trace a real packet: a user plane GTP-U packet from a 5G CU-UP at Seeb hub (Muscat) destined for a UPF at the Muscat Central DC. The path traverses two P routers in the MPLS core.

Step 1 — Ingress PE: Label Push

The packet arrives at the PE router at Seeb hub as a plain IP packet (outer IP: CU-UP source, UPF destination, carrying GTP-U inside). The PE performs an IP lookup, identifies this packet belongs to the RAN L3VPN (VRF: RAN_N3). It imposes a two-label stack:

Inner label (VPN label / bottom of stack): identifies the specific VPN and egress PE interface. Generated by the egress PE and advertised via MP-BGP.
Outer label (transport label / top of stack): identifies the LSP to the egress PE. Generated by LDP or RSVP-TE.

Step 2 — P Router 1: Label Swap

The first P router receives the packet. It reads only the top label value. It performs a label swap: replaces the incoming outer label with a new outgoing label and forwards the packet out the correct interface toward the next hop. No IP lookup. No VPN awareness. Just a label table lookup and a forward. This happens at line rate — typically nanoseconds per packet.

Step 3 — P Router 2: Penultimate Hop Popping (PHP)

The second P router, one hop before the egress PE, performs PHP. It pops the outer transport label entirely. The packet now has only the inner VPN label on top. This is handed to the egress PE with the inner label exposed — saving the egress PE one lookup cycle. PHP is the default behaviour in most operator deployments.

Step 4 — Egress PE: Label Pop and IP Forward

The egress PE (at Muscat DC, facing the UPF) receives the packet with only the inner VPN label. It looks up this label in the VPN forwarding table, identifies the outgoing VRF and interface, pops the remaining label, and forwards the original IP packet to the UPF. The UPF receives a plain IP packet — it has no idea MPLS was involved.

Key insight: The UPF, the CU-UP, and everything at the RAN side are completely MPLS-unaware. They send and receive plain IP. All MPLS processing happens transparently at the PE and P layer. This is why MPLS is called a ‘shim layer’ — it lives between Layer 2 and Layer 3 in the stack, invisible to endpoints.

4. Practical Example — RAN Traffic in an Oman Operator Network

Consider a 5G SA backhaul network using IP/MPLS to carry all RAN interfaces. PE routers sit at each aggregation hub (Seeb, Ruwi, Barka, Salalah) and P routers interconnect them in the national backbone. Each gNB connects via a CE router or a Layer 2 handoff to the nearest PE.

Traffic Type	MPLS VRF	LSP Type	QoS Class
5G N2 (AMF signalling)	RAN_CTRL_VRF	RSVP-TE dedicated tunnel	EF / CS6
5G N3 (UPF user plane)	RAN_USER_VRF	RSVP-TE with bandwidth reservation	AF41 / EF per bearer
OAM / Element Management	MGMT_VRF	LDP best-effort LSP	CS2
Enterprise VPN (roaming)	ENT_VRF_x	LDP + BGP VPN label	AF31

All four traffic types ride the same physical infrastructure. VRF separation ensures complete Layer 3 isolation — an enterprise packet cannot reach the RAN control plane VRF. RSVP-TE tunnels for N2 and N3 guarantee bandwidth and path determinism. If the core link between Seeb and Ruwi fails, RSVP-TE Fast Reroute triggers in under 50ms and traffic reroutes via Barka — automatically, without any RAN-side awareness.

5. How VPNs Isolate Traffic — L3VPN Mechanics

MP-BGP and the VPN Label

MPLS L3VPN (RFC 4364) uses MP-BGP to distribute VPN routing information between PE routers. Each VPN has a VRF on each PE where it is present. Routes within a VRF are tagged with a Route Distinguisher (RD) to make them globally unique, and a Route Target (RT) to control import/export between VRFs.

Concept	What It Does	Real Example
VRF	Separate routing table per VPN on PE	RAN_N3_VRF holds only UPF and CU-UP routes
Route Distinguisher (RD)	Makes VPN routes globally unique in BGP	65001:100 for RAN VPN, 65001:200 for Enterprise VPN
Route Target (RT)	Controls which VRFs import which routes	RT export 65001:100 on Seeb PE, import same on Muscat DC PE
VPN Label	Inner MPLS label — identifies egress VRF+interface	Allocated by egress PE, advertised via MP-BGP update

6. How Failures Reroute Traffic — Fast Reroute

Sub-50ms Recovery Without RAN Awareness

MPLS Fast Reroute (FRR) is one of the most critical features for RAN transport. When a core link or node fails, FRR triggers a pre-computed backup path in under 50ms — well within the threshold that RAN protocols can tolerate without resetting sessions.

FRR works by pre-establishing a bypass tunnel around each protected link or node. The protecting P router detects failure via BFD (Bidirectional Forwarding Detection) — typically 300ms interval / 3x multiplier. But the actual reroute happens the moment an interface goes down — the router does not wait for BFD. Interface-down events trigger local repair immediately.

Link protection — bypass tunnel routes around a single failed link. Traffic arrives at the same downstream P router via an alternate path.
Node protection — bypass tunnel routes around the next-hop P router entirely, reaching the hop after it. More resilient, requires more pre-computation.
BFD on every PE-to-PE and P-to-P link — provides fast detection for remote failures not visible as interface-down events.

Field Note: In a real GCC operator network, we have seen FRR configured but bypass tunnels not pre-established due to RSVP-TE misconfiguration. The network appeared healthy in steady state but failed over in 3-5 seconds instead of sub-50ms during a fibre cut. RAN teams reported mass call drops. Always verify FRR bypass tunnel state in steady-state, not just during commissioning.

7. Common Issues in the Field

RSVP-TE tunnel not coming up — typically caused by bandwidth over-subscription. If the requested bandwidth exceeds what RSVP has available on the path, admission control rejects it and the tunnel stays down. Check RSVP bandwidth allocation per interface vs. tunnel requests.
LDP-RSVP interaction issues — when both protocols run together, traffic can fall back to LDP-switched paths if RSVP tunnels go down. The fallback path may lack QoS properties. Operators sometimes find VoNR traffic on best-effort LDP paths after maintenance.
MP-BGP session flap between PEs — if the BGP session between two PEs resets, all VPN routes are withdrawn and reinstalled. For RAN VPNs this causes a brief outage on all N2/N3 interfaces between those sites. Tune BGP timers: keepalive 3s, hold-time 9s minimum.
VRF route leakage — incorrect Route Target configuration causes routes from one VPN to leak into another. In RAN networks, enterprise traffic can accidentally enter the RAN control plane VRF. Usually caught in testing, but misconfigurations during operational changes are a real risk.
MPLS EXP / TC bit overwriting — some transit devices reset MPLS EXP bits, destroying QoS markings set at PE ingress. Traffic arrives at egress PE as best effort. Validate EXP bit preservation at every hop during acceptance testing.

8. Troubleshooting Approach

Start at the Control Plane, Not the Data Plane

Most MPLS issues are control plane problems that manifest as data plane failures. Follow this sequence:

Verify LDP/RSVP adjacencies — check that sessions are up between all expected neighbours. A missing adjacency means LSPs through that node are not established.
Trace the LSP — use MPLS ping and MPLS traceroute (LSP ping) to verify end-to-end LSP continuity. This tells you exactly which router is forwarding incorrectly without touching the IP layer.
Check label bindings — on the ingress PE, verify the correct label is being pushed for the destination prefix and compare with what the egress PE advertised via BGP.
Verify FRR bypass tunnel state — on all P routers, every protected LSP should show a pre-established bypass. If bypass is missing, recovery during failure will be seconds, not milliseconds.
Check VRF routing table — on the PE, verify the correct routes exist in the VRF. Missing routes mean MP-BGP is not advertising them correctly — check BGP route policies and RT import/export config.

9. Design Recommendations — Consultant Level

Separate RAN VRFs by interface type — do not lump N2 and N3 in the same VRF. Control plane and user plane have different QoS and bandwidth profiles. Separate VRFs give cleaner policy application and easier troubleshooting.
Use RSVP-TE for all RAN-facing LSPs — LDP follows IGP shortest path and has no bandwidth awareness. RSVP-TE gives deterministic paths, bandwidth reservation, and FRR. For RAN transport, the operational overhead is worth it.
Tune BFD aggressively on PE-CE links — PE-to-gNB or PE-to-DU links should use 300ms/3x timers. This detects access link failures fast enough for FRR to engage before RAN protocols time out.
Document your label stack end-to-end — for every RAN interface (N2, N3, F1), document the expected outer and inner label values per PE. This saves hours during outage troubleshooting.
Plan for MPLS-to-SR migration — most GCC operators are planning to move toward Segment Routing over the next 2-3 years. Design your current MPLS network to be SR-ready: IS-IS with SR extensions enabled, consistent Loopback addressing — these map directly to SR Node SIDs.
Never allocate 100% of interface bandwidth to RSVP — keep 20-30% in reserve for unplanned bursts. Overcommitted RSVP bandwidth causes new LSPs to be rejected and forces traffic to fall back to LDP.

10. Summary — Practical Takeaways

MPLS is not a theoretical construct — it is the operational backbone of every serious telecom transport network. Understanding label push/swap/pop, VRF isolation, and FRR behaviour is not optional for a 5G transport engineer. It is table stakes.

The most common mistakes are: mixing RAN and enterprise traffic in the same VRF, running LDP for RAN LSPs instead of RSVP-TE, not verifying FRR bypass tunnels in steady state, and failing to enforce MPLS EXP bit preservation across transit segments.

Takeaway	Action
PE is where all intelligence lives	Audit all VRF, RT, and QoS policy configs at each PE during commissioning
FRR must be verified in steady state	Check bypass tunnel pre-establishment monthly, not just after failures
RAN VRFs must be separated by function	N2 and N3 in separate VRFs — different QoS, different bandwidth profiles
RSVP-TE over LDP for RAN LSPs	LDP has no bandwidth awareness — RSVP-TE gives determinism and FRR
MPLS EXP bits must survive all hops	Include EXP preservation in transport acceptance test plan

Muhammad Tahir Riaz | trmtelcocloudai.com | Telecom Transport Series — Article 2 of 10

How IP/MPLS Really Works in a Live Telecom Network