MPLS & Segment Routing Overhead Calculator

1. The Evolution of Carrier Transport: From LDP/RSVP-TE to Segment Routing

In traditional Multi-Protocol Label Switching networks defined by RFC 3031, core transport relies on distributed, dynamic signaling protocols to establish end-to-end Label Switched Paths (LSPs). Label Distribution Protocol (LDP) advertises shortest-path labels mapped directly to Interior Gateway Protocol (IGP) topology metrics. While resilient, LDP lacks native Traffic Engineering (TE) capabilities. To steer traffic across sub-optimal, low-latency, or disjoint geographical corridors, telecommunication carriers deployed Resource Reservation Protocol with Traffic Engineering (RSVP-TE).

However, RSVP-TE requires every transit Provider (P) router along an LSP to maintain per-tunnel soft-state refresh messages. In modern 5G mobile backhaul and multi-tier data center backbones interconnecting tens of thousands of edge endpoints, maintaining hundreds of thousands of dynamic RSVP-TE state reservations induces critical control-plane CPU bottlenecks, slow convergence times, and state explosion.

Segment Routing (RFC 8402) revolutionizes carrier transport by applying the paradigm of source routing. The ingress Provider Edge (PE) router encodes the entire explicit end-to-end forwarding policy directly into the packet header as an ordered stack of instructions called Segment Identifiers (SIDs). Transit core routers maintain zero per-flow state; they simply inspect the active segment at the top of the stack, execute the instruction (such as forwarding along an IGP shortest path or across an explicit optical adjacency), pop or decrement the segment, and forward the packet at line rate.

2. SR-MPLS vs. SRv6: Mathematical Overhead Comparison

Segment Routing can be instantiated over two distinct data planes: SR-MPLS (reusing the mature MPLS shim header) and SRv6 (implementing native IPv6 extension headers). While both execute the same source-routing logic, their physical wire overheads diverge dramatically:

• SR-MPLS Encapsulation (RFC 3032): Reuses the fixed 32-bit (4-byte) MPLS label format consisting of a 20-bit Label/SID value, a 3-bit Traffic Class (TC / EXP) field for QoS, a 1-bit Bottom-of-Stack (S) flag, and an 8-bit Time-to-Live (TTL) field. Each additional segment adds exactly 4 Bytes. A 4-segment policy (e.g., Node SID + Adjacency SID + Service Label + TI-LFA backup) introduces merely 16 Bytes of transport tax.
• SRv6 Encapsulation (RFC 8754 - Segment Routing Header): In SRv6, every SID is a full 128-bit (16-byte) IPv6 address. When a policy requires two or more segments, the ingress router encapsulates the packet with an outer 40-byte IPv6 header followed by an 8-byte Segment Routing Header (SRH) and an array of 16-byte SIDs:
  Overhead_SRv6 = 40B (IPv6 Base) + 8B (SRH Base) + (N × 16B)
  For an identical 4-segment policy, standard SRv6 introduces 112 Bytes of header overhead (40 + 8 + 64). On a standard 1500-byte Ethernet link, this consumes 7.47% of total link capacity purely in encapsulation overhead, drastically reducing customer usable MTU and requiring strict TCP MSS clamping.

3. Micro-SIDs (uSID / NEXT-C-SID RFC 8986) & Compression Mechanics

To eliminate the severe bandwidth penalty of 128-bit SRv6 headers while preserving the universal routing capabilities of native IPv6, network equipment manufacturers and the IETF standardized the Compressed SID (C-SID) framework (RFC 8986), most prominently realized as micro-SIDs (uSID).

Under the NEXT-C-SID flavor, a standard 128-bit IPv6 address is partitioned into a shared carrier Locator Block (e.g., 32 bits) followed by a sequence of 16-bit compressed micro-SIDs packed into the remaining 96 bits of the address field. Each transit node shifts the address register by 16 bits to expose the next micro-SID in line:

[ 32-bit Block: fc00:0001 ] : [ uSID1: 0010 ] : [ uSID2: 0020 ] : [ uSID3: 0030 ] : [ uSID4: 0040 ] : [ uSID5: 0050 ] : [ uSID6: 0060 ]

Consequently, a path of up to six micro-SIDs can be completely accommodated inside the single outer 128-bit IPv6 destination address, completely eliminating the need for an 8-byte SRH or extra 16-byte segment list entries. Overhead drops from 144 Bytes down to the standard 40-byte IPv6 header, recovering 104 Bytes per packet and achieving wire efficiency parity with SR-MPLS.

4. Hardware Constraints: Maximum SID Depth (MSD) & Parser Limitations

While network architects can logically construct deep, multi-constrained traffic engineering paths involving dozens of SIDs, physical routing hardware imposes strict mechanical limits defined by Maximum SID Depth (MSD, RFC 8491 / RFC 8476):

• Imposition MSD (Node MSD): The maximum number of labels or SIDs an ingress router's forwarding pipeline can push onto a packet in a single clock cycle at line rate without dropping packets.
• Transit Read Depth & Parser Window: Merchant silicon ASICs (such as Broadcom Tomahawk, Trident, or Jericho architectures) inspect packets using a hardware parser with a fixed window (typically 128 to 256 Bytes from the start of the Layer 2 header). If an extensive label stack (e.g., 8 labels + Entropy + Control Word) or a large SRv6 SRH pushes the customer Layer 4 TCP/UDP header beyond the parser's window, the switch cannot read the port numbers.
• Operational Consequence: The ASIC becomes incapable of performing 5-tuple Equal-Cost Multi-Path (ECMP) hashing, resulting in severe link polarization. Furthermore, Access Control Lists (ACLs) inspecting Layer 4 ports fail to match, and some switches are forced into internal recirculation (looping the packet through the switching fabric twice), cutting port throughput by 50% and introducing jitter.