Source-Routed Traffic Engineering · MPLS Data Plane

Segment Routing MPLS

Source-initiated traffic engineering on an MPLS data plane. No RSVP-TE state, no per-LSP signaling overhead: just a label stack computed at the head-end from a distributed topology database.

SR-MPLS Underlay with TI-LFA

Four routers in a ring. The primary path between R1 and R3 takes the upper hop; if R2 fails, TI-LFA pre-programs a repair label stack via R4 in under 50 ms.

SR-MPLS topology: four routers in a ring with a primary path R1 to R3 via R2 and a TI-LFA backup via R4
SR-MPLS: primary path R1 to R2 to R3 with a TI-LFA repair list via R4 (sub-50 ms reroute).

What SR-MPLS Is

Segment Routing (SR), defined in RFC 8402, distributes a set of topological instructions, segments, through standard IGP extensions (IS-IS: RFC 8667, OSPF: RFC 8665). Each segment is represented as an MPLS label. The head-end router imposes a label stack that encodes the complete explicit path; no per-LSP signaling state is maintained at midpoints.

The result is a simplified data plane: transit nodes perform standard MPLS forwarding with no RSVP adjacency databases, no LDP FECs per prefix, and no optical-style path setup latency. All traffic engineering intelligence moves to the source, enabling policies per flow class, per VPN, or per application without control-plane churn.

SR-MPLS coexists with and progressively replaces LDP in brownfield cores. RFC 8661 defines LDP-SR interworking so operators can migrate incrementally: SR-capable nodes advertise both SR SIDs and LDP labels, enabling end-to-end LSPs across mixed networks without a flag-day cutover.

Fast Reroute: TI-LFA

Topology-Independent Loop-Free Alternate (TI-LFA, RFC 9855; companion remote-LFA in RFC 8102) computes pre-programmed backup paths that are loop-free by construction, without the coverage gaps of classic LFA. Recovery is sub-50 ms on hardware that supports it. TI-LFA protects node, link, and SRLG failures: the backup path is encoded as a repair segment list pushed at the PLR before the primary path is removed from the forwarding table.

Flexible Algorithm (Flex-Algo)

IGP Flexible Algorithm (RFC 9350) lets one physical topology carry several logical planes. Each Flex-Algo definition sets a metric type, IGP cost, minimum unidirectional link delay, or TE metric, plus a set of link constraints, and the IGP computes shortest paths under those rules. OcNOS-SP advertises each algorithm through IS-IS SR, and every prefix-SID resolves per algorithm, so traffic follows the low-delay or affinity-limited plane natively. A latency-sensitive service and a best-effort service ride the same links on different planes with no SR-TE policy and no external controller.

Flex-Algo and TI-LFA work together. The fast-reroute backup for a prefix is computed inside the same algorithm as the primary path, so a delay-optimized flow reroutes onto another low-delay path rather than dropping back to the default shortest path. Each plane keeps its own sub-50 ms protection.

OcNOS-SP Implementation

OcNOS-SP implements SR-MPLS across the Broadcom Qumran and Jericho service-provider silicon families, from Qumran2a and Qumran2u compact edge platforms through Qumran2c and Qumran2c+ aggregation to Jericho2c+ core routers. The implementation covers the full SP edge and core feature set:

Control Plane: IS-IS SR

IS-IS with SR extensions (RFC 8667). Node SID, Adjacency SID, Anycast SID. Prefix-SID advertisement with N and P flags. Flexible Algorithms (RFC 9350) for topology-aware SID assignment.

Traffic Engineering: SR-TE

SR-TE policies with explicit segment lists. Head-end steering by color + endpoint. PCE-delegated path computation via PCEP (RFC 8231). ODN (On-Demand Next-hop) for automatic SLA-aware path selection.

Fast Reroute: TI-LFA

TI-LFA enabled per interface. Protects node and link failures. Backup path pre-installed in hardware forwarding table. Recovery below 50 ms on supported SP platforms.

ECMP & Load Balancing

SR ECMP over multiple next-hops with 5-tuple flow hashing. Equal-cost paths resolved per SID via MPLS forwarding table. Per-flow entropy label support for load-balance visibility.

LDP Interworking

RFC 8661 LDP-SR interworking for brownfield migration. Mapping server for prefix SID to LDP label binding. SR-LDP border node functionality: no flag-day core migration required.

BFD for SR

BFD for MPLS LSP (RFC 5884) with SR-TE policy binding. Sub-second fault detection feeding into TI-LFA switchover. Discriminator allocation per SR policy.

Telemetry

OpenConfig SR YANG models. gNMI streaming of SID utilization, ECMP distribution, and TE policy state. Prometheus-compatible via gRPC collector.

SRv6 Co-existence

SR-MPLS and SRv6 can be deployed on the same OcNOS-SP node. Per-VPN steering between MPLS and IPv6 data planes. Interworking function for cross-domain SRv6-SR-MPLS stitching.

OcNOS-Validated Hardware

For reference only. The platforms below are a representative subset of SR-MPLS-validated hardware. The complete, current list of qualified platforms, with ASIC, port density, and version coverage, is maintained in the OcNOS Hardware Compatibility List.

UfiSpace S9610-36D
Jericho2c+ · 36×400G
Edgecore AS9947-36XKB
Jericho2c+ · 24×100G + 12×400G
UfiSpace S9600-56DX
Qumran2c · 48×100G + 8×400G
UfiSpace S9610-46DX
Qumran2c+ · 40×100G + 6×400G
UfiSpace S9600-32X
Qumran2c · 32×100G
UfiSpace S9600-64X
Qumran2c · 64×100G
UfiSpace S9510-28DC
Qumran2a · 24×25G + 2×100G + 2×400G
UfiSpace S9510-30XC
Qumran2u · 28×25G + 2×100G
See all platforms in Qualified Hardware → SR-MPLS Feature Matrix →

Related Technologies & Solutions

EVPN-VXLAN → SRv6 → BGP → Open IP Core SR-MPLS design → SP Networks Solution → IP-over-DWDM Solution → Broadband Access Solution → OcNOS Feature Matrix → IS-IS SR with TI-LFA → MPLS Traffic Engineering (RSVP-TE) → Segment Routing explained: SR-MPLS →

Compare SR-MPLS support across all OcNOS-validated platforms

Open Feature Matrix →
FAQ

Frequently asked questions

What is SR-MPLS?
SR-MPLS (Segment Routing on the MPLS data plane) is segment routing that uses MPLS labels for forwarding, with labels distributed by the IGP instead of a separate label protocol. It steers traffic along engineered paths while reusing the existing MPLS forwarding plane.
How does SR-MPLS use IS-IS or OSPF?
SR-MPLS extends IS-IS or OSPF to advertise segment identifiers as MPLS labels, so the IGP itself distributes the labels. This removes the need for LDP to assign labels and lets every node build label-switched paths from the routing information it already floods.
What is the SRGB in SR-MPLS?
The SRGB (Segment Routing Global Block) is the range of MPLS labels reserved for global prefix segments. A prefix-SID is an index into this block, so a node computes the local label for a destination by adding the index to the SRGB base, giving consistent label assignment.
What is the difference between SR-MPLS and SRv6?
SR-MPLS forwards using MPLS labels and keeps an MPLS data plane, while SRv6 forwards on the native IPv6 data plane using IPv6 addresses as segments. SR-MPLS suits networks that already run MPLS, where SRv6 removes MPLS in favor of IPv6-only forwarding.
Does SR-MPLS still need LDP?
No, SR-MPLS does not need LDP or RSVP-TE. The IGP distributes labels through prefix-SIDs and adjacency-SIDs, and TI-LFA provides fast reroute, so a single IGP handles label distribution, traffic engineering, and protection that previously required separate protocols.
How is SR-MPLS different from traditional MPLS with LDP or RSVP-TE?
Traditional MPLS relies on LDP or RSVP-TE to signal and hold per-LSP state at every hop. SR-MPLS keeps the same MPLS forwarding plane, but the IGP distributes labels as segment IDs, so the head-end sets the path with no separate signaling protocol. RFC 8660 defines this. OcNOS-SP can run SR-MPLS and RSVP-TE together on one router.
What is IS-IS segment routing?
IS-IS segment routing extends the IS-IS link-state protocol to advertise segment identifiers as MPLS labels, defined in RFC 8667. Each router floods prefix-SID and adjacency-SID sub-TLVs, so the IGP alone builds label-switched paths without LDP. OcNOS-SP implements IS-IS SR with node and adjacency SIDs, plus Flexible Algorithm for topology-aware path selection.
What is TI-LFA in SR-MPLS?
TI-LFA (Topology Independent Loop-Free Alternate), specified in RFC 9855, uses segment routing to pre-compute a loop-free backup path for every destination. On a link, node, or SRLG failure the point of local repair pushes a repair label stack and restores traffic in under 50 ms. OcNOS-SP enables TI-LFA per interface, with the backup pre-installed in the hardware forwarding table.
What is Flex-Algo (IGP Flexible Algorithm)?
Flex-Algo, or IGP Flexible Algorithm (RFC 9350), lets the IGP compute constraint-based paths using a metric and constraints other than the default shortest path, for example lowest delay or an affinity-limited topology. Each algorithm maps to a prefix-SID, so traffic follows the custom path natively. OcNOS-SP supports Flexible Algorithm with IS-IS SR for topology-aware SID assignment.
Can EVPN run over SR-MPLS?
Yes. EVPN (RFC 7432) is a BGP control plane for Ethernet services that forwards over an MPLS data plane, so its service labels ride SR-MPLS label-switched paths the same way they would over LDP or RSVP-TE. Running EVPN over SR-MPLS gives Ethernet services the segment-routing benefits of source-based path selection and TI-LFA protection.
Datasheet and Solution Briefs

Go deeper. Take it with you.

The product datasheet plus short, technical downloads that go further than this page.

Datasheet

OcNOS-SP Datasheet

Full OcNOS-SP specification: the access, cell site and aggregation feature set, software SKUs, supported hardware platforms, and the solution ordering guide.

Get the datasheet
Solution Brief

SR-MPLS Upgrade with OcNOS

Migrate SR-MPLS onto OcNOS on open hardware: Flex-Algo, TI-LFA, and a proven Cisco-alternative cutover path.

Get the brief
Solution Brief

Cloud & Service Provider WAN Transport

Cloud and service-provider WAN transport on open hardware: SR-MPLS, EVPN, and scale-tested forwarding.

Get the brief