Segment Routing Explained: Why SR-MPLS Is Replacing LDP and RSVP-TE

Segment Routing (SR) has become the dominant MPLS evolution path for service providers. It eliminates the operational complexity of LDP and RSVP-TE, enables deterministic traffic engineering without per-flow state, and integrates natively with modern automation tools. This article explains how it works, why it matters, and how to configure it in OcNOS.

Why Segment Routing?

Traditional MPLS networks rely on two signaling protocols to distribute labels and engineer traffic paths:

  • LDP (Label Distribution Protocol) — distributes labels for destination-based forwarding, but creates tight coupling between IGP and label state, causing synchronization issues during convergence
  • RSVP-TE (Resource Reservation Protocol — Traffic Engineering) — enables explicit path control but requires per-flow signaling state on every transit router in the path, creating significant scalability and operational challenges

Segment Routing addresses both problems simultaneously. Labels (called “segments”) are distributed by the IGP itself — no separate signaling protocol required. Traffic engineering is achieved by inserting an ordered list of segments at the ingress router — no per-flow state on transit nodes.

How Segment Routing Works

In an SR network, each router assigns a globally unique numeric identifier called a Node SID (Segment Identifier) to its loopback address. These SIDs are flooded through the IS-IS or OSPF topology, giving every router a complete map of the network’s segment structure.

When a packet enters the network, the ingress router (PE) encodes a “segment stack” — an ordered list of SIDs representing the desired forwarding path — into the packet header. In SR-MPLS, this stack is implemented as a standard MPLS label stack. Transit routers swap labels and forward based on the top segment, requiring no knowledge of the end-to-end path.

PE1SID 101P1SID 102P2SID 103P3SID 104PE2SID 105Adj SID: 9001Adj SID: 9002Segment Stack (PE1)[16102] Node SID P1[16104] Node SID P3[16105] Node SID PE2
Segment Routing topology: each node advertises a Node SID via IS-IS. The ingress PE1 encodes an explicit path (P1 → P3 → PE2) as an MPLS label stack. No RSVP signaling is required on transit nodes.

Types of Segments

Prefix Segments (Node SIDs)

A Prefix Segment represents a destination prefix — typically a router’s loopback address — and instructs the network to forward toward that destination using the IGP shortest path. Node SIDs are globally unique within the SR domain and are allocated from the Segment Routing Global Block (SRGB).

Adjacency Segments (Adj SIDs)

An Adjacency Segment represents a specific link between two routers. Using an Adj SID in the segment stack forces the packet to traverse that exact link, regardless of the IGP shortest path. Adj SIDs are locally significant (only meaningful to the router that originates them) and enable precise, link-level traffic steering.

Segment Routing Global Block (SRGB)

The SRGB is the range of MPLS labels reserved for SR-assigned Node SIDs. All routers in an SR domain typically share the same SRGB range, so a Node SID of “index 5” always maps to the same MPLS label value (SRGB base + 5) on every router — greatly simplifying operations and troubleshooting.

OcNOS supports four SRGB configuration scenarios:

! OcNOS -- Scenario 1: Use the default SRGB [16000-23999]
! No manual configuration required. Enable SR under IS-IS:
!
router isis CORE
  segment-routing mpls
  address-family ipv4 unicast
    segment-routing mpls
  exit-address-family
!
! Verify default SRGB allocation:
show running-config segment-routing
show isis database detail | include SRGB
show mpls label-space 0

! OcNOS -- Scenario 2: Custom global SRGB
!
segment-routing
  global-block 30000 33999    ! SRGB range: 30000-33999 (4000 labels)
!
router isis CORE
  segment-routing mpls
  ! IGP inherits global SRGB unless overridden locally
!
! Verify:
show isis database detail | include SRGB
! Expected: SRGB Base: 30000, Range: 4000

! OcNOS -- Scenario 3: Per-IGP SRGB (subset of global)
!
segment-routing
  global-block 16000 23999    ! Global SRGB (default)
!
router isis CORE
  segment-routing mpls
  segment-routing global-block 17000 18999   ! Local override (within global)
!
! Verify local SRGB under IS-IS:
show running-config router isis | include srgb

! OcNOS -- Scenario 4: Global SRGB + per-IGP override
! When both are configured, IGP configuration takes precedence
!
segment-routing
  global-block 30000 33999
!
router isis CORE
  segment-routing mpls
  segment-routing global-block 31000 31999   ! This takes effect for IS-IS
!
! Key SRGB rules in OcNOS:
! - Maximum block size: 262143 labels (25% of label space)
! - Disable SR before changing SRGB range
! - Per-IGP SRGB must be a subset of global SRGB
! - No overlapping ranges across IGP instances

Assigning Node SIDs in OcNOS

! OcNOS -- Assign Node SID to router loopback
!
interface lo
  ip address 10.0.0.1/32
  ip router isis CORE
  isis segment-routing prefix-sid index 1
  ! Label value = SRGB base + index
  ! With default SRGB [16000]: label = 16001
!
! For Flex-Algo (multiple SIDs per node):
interface lo
  isis segment-routing prefix-sid index 1                  ! Default SPF (algo 0)
  isis segment-routing prefix-sid algorithm 128 index 1001 ! Delay algo
  isis segment-routing prefix-sid algorithm 129 index 2001 ! TE-metric algo
!
! Verify SID assignment and distribution:
show isis segment-routing prefix-sids
show isis database detail | include Prefix-SID
show mpls forwarding-table

Key Benefits of SR over LDP and RSVP-TE

Capability LDP RSVP-TE SR-MPLS
Signaling protocol Separate (LDP) Separate (RSVP) None — IGP distributes SIDs
Transit router state Per-destination Per-flow (RSVP state) None — stateless transit
Traffic engineering Not supported Complex RSVP tunnels Simple segment stacks at ingress
Fast reroute LFA only FRR with complex setup TI-LFA (topology-independent)
Network slicing Not supported Limited Flex-Algo (native)
SDN integration Limited Limited Native PCE and gNMI support

Related Reading


Suraj Kumar Singh is Senior Solution Lead at IP Infusion. Connect on LinkedIn.

Share