Segment Routing (SR-MPLS · SRv6)

1. Overview

Segment Routing (SR) is a source-routing-based path control architecture in which the ingress node of a packet inserts the path to the destination directly into the packet header as an ordered list of Segments, and intermediate nodes merely process that list in order. Because the path information is carried in the packet itself, core nodes need not maintain per-flow state. The IETF standardized it as RFC 8402 (Segment Routing Architecture), and the data plane is implemented in two ways: SR-MPLS, which reuses MPLS labels, and SRv6, which uses an IPv6 extension header.

The background for Segment Routing lies in the state explosion and operational complexity of the existing MPLS Traffic Engineering (TE) control plane. Traditional MPLS-TE uses a separate signaling protocol called RSVP-TE to set up explicit paths, and in this approach every node along every tunnel path must store and refresh reservation state for each LSP. If the number of tunnels is N and the nodes on a path number M, the state a core must manage grows roughly as N×M, so when running tens of thousands of tunnels on a large backbone the control plane bears a serious burden. Moreover, two protocols (LDP and RSVP-TE) must be run in parallel, and failure reconvergence/resignaling is slow, adding the extra complexity of pre-provisioning backup tunnels to achieve 50 ms recovery (FRR).

Here "soft state" refers to the way RSVP-TE maintains tunnel reservations with periodic refresh messages: if messages stop, the reservation expires, so nodes must continuously exchange state. On large backbones with hundreds of nodes and links, this refresh traffic and the state tables themselves eat into control-plane CPU and memory, and state restoration is delayed during software upgrades or node restarts — an operational weakness. Segment Routing eliminates this periodic state maintenance itself by moving path information into the packet, achieving a fundamental simplification.

The second background is the demand for alignment with SDN and network automation. As network operations shifted toward central controllers in the 2010s, the recognition spread that carrying the path in the packet header for stateless forwarding scales far better than having the controller push state into nodes. Segment Routing concentrates path intelligence at the edge (the ingress node) and the controller and simplifies the core, so it naturally combines with PCE (Path Computation Element) and BGP-LS based central control. The third background is the mainstreaming of IPv6: SRv6 uses the IPv6 address itself as a Segment Identifier (SID) without separate tunnel encapsulation, treating the network as a single programmable resource.

We can gauge these motivations with concrete numbers. For example, in a backbone of 100 nodes, running full-mesh TE tunnels between every node pair creates about 10,000 LSPs (100×99), and under RSVP-TE every intermediate node a given LSP traverses must periodically refresh Path/Resv state, so a single core node ends up maintaining and refreshing thousands of soft states. Segment Routing replaces this full mesh of tunnels with merely the advertisement of about 100 per-node Prefix SIDs, so the per-tunnel state a core must hold converges to essentially zero. Lowering state complexity from O(tunnels×hops) to O(nodes) in this way is the greatest mathematical advantage of Segment Routing.

The characteristics of Segment Routing are summarized as follows. They form the foundation on which the TE, FRR, VPN, and network programming discussed later are all built.

Stateless Core: Because path state is in the packet, intermediate nodes store no per-tunnel state. This is the source of scalability.
Reuse of existing IGP: Rather than inventing a new protocol for segment distribution, it advertises SIDs via extensions (TLVs) to IS-IS/OSPF. LDP and RSVP-TE can be removed.
Source routing: Because the ingress determines the path, TE policy is applied flexibly at a single point, the edge.
Two data planes: One can choose SR-MPLS, which uses MPLS labels (favorable for incremental migration), or SRv6, which uses IPv6 headers (favorable for network programming and service chaining).
ECMP friendliness: Prefix SIDs do not force a specific path but follow the IGP shortest path, so they naturally exploit Equal-Cost Multi-Path (ECMP) to distribute load. A strategy of specifying only as much as needed — forcing a specific path with an Adjacency SID only when required — is possible.

2. Segment Routing Architecture and Core Concepts

A Segment Routing domain consists of nodes connected by an IGP and a controller (PCE) that computes and injects paths. When the ingress node inserts a segment list, the packet is forwarded following that order, and each segment is consumed at its endpoint node. The overall structure is as follows.

graph LR
    CTRL["SDN controller / PCE (path computation)"] -. "BGP-LS / PCEP" .-> R1
    R1["R1 Ingress (push SID list)"] --> R2["R2 (process Node SID)"]
    R2 --> R3["R3 (Adjacency SID: force specific link)"]
    R3 --> R4["R4 (process Node SID)"]
    R4 --> R5["R5 Egress (pop last SID)"]
    subgraph SR_Domain["SR domain (IGP: advertise SIDs via IS-IS/OSPF)"]
        R1
        R2
        R3
        R4
        R5
    end

A. Segment and SID. A segment is "a single instruction the packet must follow," and the value identifying it is the SID (Segment Identifier). In SR-MPLS a SID is a 20-bit MPLS label; in SRv6 a SID is expressed in the form of a 128-bit IPv6 address. There are broadly two kinds of segment. First, a Prefix SID (a Node SID when it points to a specific node) is a global instruction meaning "go to that destination via the IGP shortest path" and is unique across the whole domain. Second, an Adjacency SID is a local instruction meaning "leave this node via that specific link (adjacency)," and is meaningful only at a specific node. Combining the two makes it possible to express a mix of loose and strict paths — such as "go via the shortest path to R4, then from R4 to R5 necessarily through a specific link" — greatly raising the expressive power of TE.

B. Segment List and Active Segment. The ingress node stacks multiple SIDs as an ordered list. The packet is always forwarded based on the Active Segment at the top of the list (or the one the pointer indicates), and when it reaches that segment's endpoint, that segment completes and the next one is activated. In SR-MPLS it proceeds by popping the top label of the label stack, and in SRv6 it proceeds by decrementing the Segments Left pointer of the SRH (Segment Routing Header). For example, if the list is ⟨R3-Adj, R5-Node⟩, it first traverses a specific link at R3 by force and then goes the rest of the way to R5 via the shortest path.

An important design principle here is that "an intermediate node processes only the segment for which it is the endpoint, and does not look at the rest." If R2 is not the endpoint of the active segment, R2 merely performs shortest-path forwarding toward that segment (e.g., R3-SID) and does not interpret the whole list. Thanks to this locality, processing at core nodes is simplified, and even if the list grows long the burden on each node stays constant. This is the structural reason Segment Routing does not lose core scalability even on long TE paths.

As a concrete example, suppose we want to avoid the congested R2-R4 direct link and route via R3. The ingress R1 need only stack two global SIDs, ⟨Node SID of R3, Node SID of R5⟩. The packet first goes to R3 via the IGP shortest path (R1→R2→R3), and after the R3-SID is consumed at R3 it again goes to R5 via the shortest path (R3→R4→R5). As a result, a detour that does not use the R2-R4 direct link is expressed with just two SIDs. If we want to further force a single specific parallel link at R3, we simply insert R3's Adjacency SID in that position. Freely adjusting the granularity of TE policy with nothing but combinations of global and local SIDs is the heart of Segment Routing's expressive power.

C. SRGB and SRLB (label blocks). In SR-MPLS a Prefix SID is advertised not as an actual label value but as an index, and each node computes the actual label by adding the index to the start of a reserved label range called the SRGB (SR Global Block) (e.g., 16000–23999). If the whole domain uses the same SRGB, SID indices are globally consistent and operation is simplified. For example, if the SRGB starts at 16000 and R5's Prefix SID index is 105, every node recognizes R5 identically as label 16105, so operators can track labels intuitively. Conversely, if the SRGB differs per node, labels for the same destination differ per node, making debugging cumbersome, so in practice a single domain-wide SRGB is strongly recommended. Local values such as Adjacency SIDs are allocated dynamically from the SRLB (SR Local Block).

D. Control plane — IGP extensions and PCE. Segment Routing, without a separate label-distribution protocol (LDP), extends IS-IS/OSPF with TLVs/sub-TLVs for advertising SIDs to propagate each node's Prefix/Adjacency SIDs across the whole domain. This point is very important operationally: whereas existing MPLS ran the IGP (shortest-path computation) and LDP (label distribution) as two separate control planes and suffered black holes when their states diverged, SR unifies routing and labeling into a single IGP state, structurally removing this inconsistency. When TE paths are complex and distributed computation is difficult, a PCE/controller that has collected the topology via BGP-LS computes an optimal segment list reflecting constraints (bandwidth, latency, affinity) and injects it into the ingress node via PCEP in the form of an SR Policy. That is, control intelligence is placed centrally (or at the edge) and forwarding at the core, separately. Thanks to this structure, the controller can perform global optimization while surveying the whole topology, yielding higher resource utilization than distributed TE in which each node judged with only local information.

3. SR-MPLS and SRv6 Data Plane Operation

From the data-plane perspective, the two approaches diverge in "whether the SID is expressed as a label or as an IPv6 address." What they share is that both follow the same abstract operations — push (insert the list), continue (shortest-path forwarding), next (proceed after completing a segment) — and the difference lies in whether those operations are implemented with MPLS label arithmetic or with IPv6 header arithmetic. The sequence below shows how an SRv6 packet is forwarded and consumed along the SRH.

sequenceDiagram
    participant R1 as R1 Ingress
    participant R2 as R2 (Endpoint SID-A)
    participant R4 as R4 (Endpoint SID-B)
    participant R5 as R5 Egress
    R1->>R2: "IPv6(DA=SID-A) + SRH[SID-B, SID-A], SL=1"
    Note over R2: "DA matches own SID-A -> End behavior, SL 1->0, DA=SID-B"
    R2->>R4: "IPv6(DA=SID-B) + SRH, SL=0"
    Note over R4: "DA matches SID-B -> perform terminal behavior such as End.DX6"
    R4->>R5: "forward original payload (decapsulated)"

A. SR-MPLS forwarding. SR-MPLS uses existing MPLS forwarding hardware as is. The ingress pushes the segment list as a label stack, and each node looks at the top label, popping it (or popping at the penultimate hop via PHP) if it is the endpoint, otherwise swapping and forwarding along the shortest path. The key advantage is the removal of LDP and RSVP-TE: label distribution is integrated into the IGP, greatly simplifying the control plane, and it can be introduced incrementally into existing MPLS networks. However, a deep segment list makes the label stack deep and may hit the push-depth limit of some older ASICs (e.g., 5–6 levels).

Another advantage of SR-MPLS is its coexistence with existing MPLS services (L3VPN, L2VPN, EVPN). Only the transport label can be swapped from LDP/RSVP-TE to SR while the service label (MP-BGP) is kept as is, so one can modernize only the core control plane without service interruption. This property of "keep the service, change only the transport" is the decisive reason carriers choose SR-MPLS as their first step.

B. SRv6 forwarding and the SRH. SRv6 adds an SRH (Segment Routing Header, IPv6 routing extension header Type 4, RFC 8754) to an IPv6 packet and carries the segment list as an array of IPv6 addresses. The packet's destination address (DA) always holds the current active SID, and when the DA matches its local SID an endpoint node decrements the Segments Left (SL) pointer by one and copies the next SID into the DA to forward it. SRv6's innovation lies in SID structure. Dividing a 128-bit SID into Locator (routable high-order bits) + Function (the behavior the node is to perform) + Argument, a single address instructs not only "to where" but also "what to do."

C. Network Programming (RFC 8986). SRv6 programs the network by defining standard behaviors in the Function field. Representative ones are End (proceed to the next SID), End.X (L3 cross-connect to a specific adjacency), End.DT4/DT6 (VPN table lookup then decapsulation), and End.DX2 (L2 cross-connect). This makes it possible to express VPN, service chaining, and TE with a single SID list and no separate protocol. For example, stringing together "firewall (SID1) → DPI (SID2) → destination VPN (SID3)" as a list yields Service Function Chaining (SFC) directly. Compared with how existing MPLS had to assemble L3VPN/L2VPN/TE/FRR with distinct control planes (MP-BGP, RSVP-TE, LDP), SRv6 reduces all these services to a single unified SID semantics, a qualitative difference. This is a shift in perspective that sees the network as "a distributed computer that executes instructions carried in packets," and is the basis for defining SRv6 not as a mere forwarding technology but as a foundation of the programmable network.

D. TI-LFA fast reroute. Segment Routing provides TI-LFA (Topology-Independent Loop-Free Alternate) for failure recovery. Each node precomputes a backup path for failures in the form of a segment list, and when it detects a link or node failure it immediately pushes the backup segments to reroute within 50 ms. Classic LFA had "coverage holes" where, depending on the topology, no loop-free alternate path existed, but TI-LFA forces the post-convergence shortest path as segments, guaranteeing loop-free 100% coverage on all topologies. Unlike RSVP-TE FRR, there is no need to pre-signal and hold backup tunnels as state, so the same level of protection is achieved without core state burden — a decisive difference.

E. Choosing between SR-MPLS and SRv6. The two data planes are chosen by purpose, not superiority. SR-MPLS reuses existing MPLS forwarding chips and operational know-how, so it is advantageous for investment protection and incremental migration, but service identification still depends on the label stack and separate control. SRv6, being IPv6-native, integrates network programming, SFC, and VPN into a single SID without tunnel encapsulation, but requires the premises of header overhead and full IPv6 adoption. The following table compares the design points of the two.

Category	SR-MPLS	SRv6
SID representation	20-bit MPLS label	128-bit IPv6 address (Locator+Function+Arg)
Data plane	reuses existing MPLS forwarding	IPv6 + SRH extension header
Overhead	small (4-byte label)	large (16 bytes per SID, eased by uSID)
Service expression	label stack + separate control	native VPN/SFC via Function
Ease of migration	high (incremental into existing MPLS)	premised on full IPv6 and hardware replacement
Main application	carrier backbone TE modernization	5G, cloud native, SFC

F. Binding SID and SR-Policy. As the segment list grows longer, the push burden on edge nodes and the header overhead increase. The device that eases this is the Binding SID (BSID), which binds a single SID to represent "another predefined segment list (or SR Policy)." The ingress pushes only one BSID instead of the long path, and the BSID's anchor node expands the actual list internally. This allows paths to be hierarchized and modularized, so one can abstract each domain's detailed path with a BSID at inter-domain boundaries, or have the controller swap policy per BSID to perform hitless path changes. A representative practice is to stitch an end-to-end path across a multi-domain (access-aggregation-core) backbone with BSIDs.

4. Comparison of Key Features — vs. MPLS-TE

The difference between Segment Routing and traditional MPLS (LDP+RSVP-TE) is not a mere protocol swap but stems from a difference in design philosophy over where to put state. RSVP-TE stores path state distributed across the entire core, so state explodes in proportion to the number of tunnels and reconvergence is slow, whereas SR moves state into the packet and the edge to make the core stateless. This difference leads to gaps in scalability, operability, and automation suitability.

Category	MPLS LDP+RSVP-TE	Segment Routing (SR-MPLS/SRv6)
Path state	per-tunnel state stored at each core node	path in the packet header, core stateless
Label/SID distribution	separate protocols LDP, RSVP-TE	integrated via IGP (IS-IS/OSPF) extensions
TE method	RSVP-TE explicit signaling	SID-list source routing + PCE
Failure recovery	FRR (needs pre-stated backup tunnels)	TI-LFA (100% coverage without state)
SDN fit	low (distributed state)	high (central computation, stateless forwarding)
VPN/SFC	label stack + separate control	natively expressed via SRv6 Function

This difference also shows in failure convergence speed. RSVP-TE, when a path breaks, requires the head-end to build a new tunnel via resignaling, so convergence is slow on large networks and state may be inconsistent in the meantime, whereas with SR, once the IGP reconverges each node automatically switches to the new shortest path and the Prefix SID meaning is preserved, so no separate resignaling is needed. Also, when provisioning a new service, RSVP-TE must provision tunnels on every node along the path, but SR only needs the SID list specified at the edge, so the provisioning touchpoint shrinks to a single point, the edge. This leads to a real effect of lowering operating cost (OPEX) and provisioning lead time.

Looking at overhead numerically, in SRv6 a three-segment path adds 56 bytes of extra header — the base SRH of 8 bytes plus 3×16 bytes of SIDs. In a 1,500-byte MTU environment this is about 3.7% bandwidth overhead and a size that can trigger fragmentation in edge cases. By contrast, using 16-bit uSIDs allows the same three hops to be held within a single 128-bit address, expressed without an extra SRH, so the overhead drops sharply. For this reason, new SRv6 backbone designs often adopt uSID by default on the premise of jumbo frames (9,000 bytes).

In practice, large carriers and cloud backbones are migrating to SR because of the state burden of RSVP-TE. For example, there are reports of global content/telecom operators replacing tens of thousands of TE tunnels with SR-Policy to drastically reduce control-plane state. However, SRv6 incurs larger packet overhead due to the SRH (16 bytes per SID). With three segments the SRH exceeds 40 bytes, causing MTU/fragmentation issues, so a design is needed that raises backbone MTU above 1,500 bytes (jumbo frames) or compresses with the uSID discussed later. Understanding this trade-off between the gain of "state reduction" and the cost of "header overhead" is key.

5. Deep Dive — Latest Trends and Standards Evolution

Segment Routing is an area where standardization and commercial deployment are actively advancing, and from a professional engineer's perspective the following trends deserve attention.

A. Overcoming overhead with SRv6 uSID (micro-SID). SRv6's greatest weakness is that the 128-bit SID is long, so the header grows sharply as segments increase. To reduce this, the uSID (micro-segment) technique emerged. Multiple 16-bit or 32-bit micro-SIDs are arranged like a container within a single 128-bit IPv6 address, so one address expresses multiple hops. For example, with 16-bit uSIDs a single address can hold up to six segments, expressing long paths without an SRH (or with a short SRH), so overhead/MTU problems are greatly eased and compatibility with older hardware improves. As many vendors support uSID on commercial line cards, the practical barrier to SRv6 adoption has lowered.

B. Standards framework. The architecture stabilized with RFC 8402 (2018), the SRv6 SRH with RFC 8754 (2020), and SRv6 Network Programming with RFC 8986 (2021), and the TE policy model was established with SR Policy (RFC 9256). uSID, G-SRv6, and the like are still at the IETF draft stage and continue to evolve, so it is safer to describe them as "under standardization" rather than asserting. Controller integration via BGP-LS/PCEP extensions is also standardized.

C. Extension into the data center and host. Segment Routing traditionally started as a carrier backbone technology, but recently it is extending into the data center fabric (leaf-spine) and the host (Linux kernel). The Linux kernel natively supports SRv6 encap and End behaviors, enabling host networking in which containers/VMs directly participate in SRv6 paths. This makes real a configuration enforcing end-to-end policy on a single SRv6 plane from the server NIC to the backbone, which, combined with eBPF-based data planes and CNI, forms one pillar of cloud-native networking.

D. Linkage with past and similar exam topics. Segment Routing is a topic well suited to appear in professional-engineer exams bundled with MPLS, SDN, network slicing, IPv6, and traffic engineering. In particular, "the limits of MPLS and the emergence of SR," "comparison of SR-MPLS and SRv6," "SRv6 network programming and SFC," and "TI-LFA vs. RSVP-TE FRR" are easily varied into comparative/explanatory questions. In composing an answer, one should always take the state-complexity perspective (stateless core) as the central axis and add the selection criteria for SR-MPLS/SRv6 and the latest complementary technologies such as uSID for a deep development.

6. Considerations and Implications

Because adopting Segment Routing is not a mere protocol swap but a transition in the backbone operating model, from a professional engineer's perspective the following should be considered comprehensively.

Adoption strategy (incremental migration): Carriers with large existing MPLS assets should first migrate to SR-MPLS, which reuses the hardware as is, to strip away LDP/RSVP-TE, and then phase into SRv6 (uSID) once full IPv6 adoption and network-programming demand mature — a realistic two-stage roadmap. This spreads the risk of hitting hardware/MTU constraints if one tries to go straight to SRv6.
Trade-off (state vs. overhead): SR removes core state at the cost of packet header overhead (especially SRv6). One must design and verify in advance the segment-list length, MTU policy, uSID compression, and the ASIC's push/SID-processing limits. Judge via traffic patterns whether this is a regime where the gain of "statelessness" exceeds the header cost.
Operations and security: Since source routing lets the ingress specify the path, one must filter the SRH of external packets at the domain boundary (seal the SR domain) to prevent path-manipulation/bypass attacks. Also, because a SID is a routable address, address planning (Locator design) and access control become the core of security.
Interoperability and multi-vendor: SR is based on standard IGP extensions, so multi-vendor interoperability is relatively good, but SRv6 Function sets and uSID formats may differ in detail by vendor/draft. Before large-scale adoption, one should run inter-vendor SID-format/behavior interoperability tests (PoC) and take a prudent approach that distinguishes finalized standard features from draft features when adopting.
Outlook and related technologies: SR evolves toward intent-based automatic path optimization by combining with SDN controllers (PCE), BGP-LS, and telemetry. Architecture design must consider linkage with 5G slicing, cloud SFC, and SD-WAN underlay, and in the medium-to-long term it is highly likely to become the de facto standard for backbone TE. Organizations should proactively secure an IPv6 addressing scheme and operational capabilities (automation tools, observability).

Taken together, Segment Routing is an architecture that answers the question "where to put state" with "in the packet and at the edge," and this simple idea simultaneously raised scalability, operability, and automation suitability. When advising on design as a professional engineer, it is desirable to synthesize existing assets, IPv6 maturity, and service requirements (SFC, slicing) to propose the right mix of SR-MPLS and SRv6, and to recommend complementary designs such as uSID, observability, and security sealing together.

References

RFC 8402, Segment Routing Architecture, IETF, https://www.rfc-editor.org/rfc/rfc8402
RFC 8754, IPv6 Segment Routing Header (SRH), IETF, https://www.rfc-editor.org/rfc/rfc8754
RFC 8986, SRv6 Network Programming, IETF, https://www.rfc-editor.org/rfc/rfc8986
RFC 9256, Segment Routing Policy Architecture, IETF, https://www.rfc-editor.org/rfc/rfc9256

In one line: Segment Routing is a source-routing architecture that carries the path in the packet as a SID list to make the core stateless; implemented as SR-MPLS (incremental migration) and SRv6 (IPv6, network programming), it dissolves the state explosion of MPLS-TE through IGP integration, TI-LFA, and uSID, and is evolving into the transport foundation for 5G slicing, SFC, and SDN automation.