Source-Routed Traffic Engineering · MPLS-Data-Plane

Segment Routing MPLS

Quelleninitiiertes Traffic Engineering auf einer MPLS-Data-Plane. Kein RSVP-TE-State, kein Signaling-Overhead pro LSP – lediglich ein Label-Stack, der am Head-End aus einer verteilten Topologiedatenbank berechnet wird.

SR-MPLS-Underlay mit TI-LFA

Vier Router in einem Ring. Der primäre Pfad zwischen R1 und R3 nimmt den oberen Hop; fällt R2 aus, programmiert TI-LFA in unter 50 ms einen Repair-Label-Stack über R4 vor.

SR-MPLS-Topologie: vier Router in einem Ring mit einem primären Pfad R1 zu R3 über R2 und einem TI-LFA-Backup über R4
SR-MPLS: primärer Pfad R1 zu R2 zu R3 mit einer TI-LFA-Repair-List über R4 (sub-50 ms Reroute).

Was SR-MPLS ist

Segment Routing (SR), definiert in RFC 8402, verteilt eine Reihe topologischer Anweisungen – Segmente – über Standard-IGP-Erweiterungen (IS-IS: RFC 8667, OSPF: RFC 8665). Jedes Segment wird als MPLS-Label dargestellt. Der Head-End-Router legt einen Label-Stack auf, der den vollständigen expliziten Pfad codiert; an Zwischenpunkten wird kein LSP-spezifischer Signaling-State vorgehalten.

Das Ergebnis ist eine vereinfachte Data Plane: Transit-Knoten führen Standard-MPLS-Forwarding aus, ohne RSVP-Adjacency-Datenbanken, ohne LDP-FECs pro Präfix und ohne die Pfad-Setup-Latenz im optischen Stil. Die gesamte Traffic-Engineering-Intelligenz wird zur Quelle verlagert und ermöglicht Richtlinien pro Flow-Klasse, pro VPN oder pro Anwendung, ohne die Control Plane zu belasten.

SR-MPLS koexistiert mit LDP in Brownfield-Cores und ersetzt es schrittweise. RFC 8661 definiert LDP-SR-Interworking, sodass Betreiber inkrementell migrieren können: SR-fähige Knoten kündigen sowohl SR-SIDs als auch LDP-Labels an und ermöglichen End-to-End-LSPs über gemischte Netzwerke ohne Flag-Day-Cutover.

Fast Reroute: TI-LFA

Topology-Independent Loop-Free Alternate (TI-LFA, draft-ietf-rtgwg-segment-routing-ti-lfa; das ergänzende remote-LFA in RFC 8102) berechnet vorprogrammierte Backup-Pfade, die per Konstruktion schleifenfrei sind, ohne die Coverage-Lücken des klassischen LFA. Die Wiederherstellung erfolgt auf entsprechend ausgestatteter Hardware in unter 50 ms. TI-LFA schützt vor Node-, Link- und SRLG-Ausfällen – der Backup-Pfad wird als Repair-Segment-Liste codiert und am PLR aufgeschoben, bevor der primäre Pfad aus der Forwarding-Tabelle entfernt wird.

OcNOS-SP Implementation

OcNOS-SP implementiert SR-MPLS auf Broadcom Qumran MX-, Qumran AX- und Jericho2-ASICs. Die Implementierung deckt den vollständigen Funktionsumfang für SP-Edge und -Core ab:

Control Plane: IS-IS SR

IS-IS mit SR-Erweiterungen (RFC 8667). Node SID, Adjacency SID, Anycast SID. Prefix-SID-Ankündigung mit N- und P-Flags. Flexible Algorithms (RFC 9350) für topologiebewusste SID-Zuweisung.

Traffic Engineering: SR-TE

SR-TE-Policies mit expliziten Segmentlisten. Head-End-Steering nach Color + Endpoint. An PCE delegierte Pfadberechnung via PCEP (RFC 8231). ODN (On-Demand Next-hop) für automatische SLA-bewusste Pfadauswahl.

Fast Reroute: TI-LFA

TI-LFA pro Interface aktivierbar. Schützt vor Node- und Link-Ausfällen. Backup-Pfad in der Hardware-Forwarding-Tabelle vorinstalliert. Wiederherstellung in unter 50 ms auf ASICs der Qumran-Klasse.

ECMP & Load Balancing

SR ECMP über mehrere Next-Hops mit 5-Tupel-Flow-Hashing. Equal-Cost-Pfade werden pro SID über die MPLS-Forwarding-Tabelle aufgelöst. Per-Flow-Entropy-Label-Unterstützung für Load-Balance-Sichtbarkeit.

LDP-Interworking

RFC 8661 LDP-SR-Interworking für Brownfield-Migration. Mapping-Server für Prefix-SID-zu-LDP-Label-Binding. SR-LDP-Border-Node-Funktionalität – keine Flag-Day-Core-Migration erforderlich.

BFD für SR

BFD für MPLS LSP (RFC 5884) mit SR-TE-Policy-Bindung. Fehlererkennung im Sub-Sekunden-Bereich, die ein TI-LFA-Switchover auslöst. Discriminator-Allokation pro SR-Policy.

Telemetrie

OpenConfig SR YANG-Modelle. gNMI-Streaming von SID-Auslastung, ECMP-Verteilung und TE-Policy-Zustand. Prometheus-kompatibel über gRPC-Collector.

SRv6-Koexistenz

SR-MPLS und SRv6 können auf demselben OcNOS-SP-Knoten betrieben werden. Steering pro VPN zwischen MPLS- und IPv6-Data-Plane. Interworking-Funktion für Cross-Domain-SRv6–SR-MPLS-Stitching.

OcNOS-Validated Hardware

Nur zur Referenz. Die folgenden Plattformen sind eine repräsentative Teilmenge der SR-MPLS-validierten Hardware. Die vollständige, aktuelle Liste qualifizierter Plattformen, mit ASIC, Portdichte und Versionsabdeckung, wird in der OcNOS Hardware Compatibility List gepflegt.

UfiSpace S9600-32X
Qumran MX · 32×100G
UfiSpace S9600-64X
Qumran MX · 64×100G
UfiSpace S9610-36D
Qumran AX · 36×400G
UfiSpace S9610-46DX
Qumran AX · 36×400G + 10×100G
Celestica E1031
Qumran MX · 32×100G
UfiSpace S9321-64E
Jericho2 · 64×400G
UfiSpace S9510-28DC
Qumran AX · IPoDWDM
Edgecore AS9726-32DB
Trident 4 · 32×400G
Alle Plattformen in Qualified Hardware ansehen → SR-MPLS Feature Matrix →

Verwandte Technologien und Lösungen

EVPN-VXLAN → SRv6 → BGP → SP Networks Solution → IP-over-DWDM-Lösung → Broadband-Access-Lösung → OcNOS Feature Matrix → IS-IS SR mit TI-LFA →

Vergleichen Sie SR-MPLS-Support über alle OcNOS-validierten Plattformen hinweg

Open Feature Matrix →
FAQ

Häufig gestellte Fragen

Was ist SR-MPLS?
SR-MPLS (Segment Routing auf der MPLS-Datenebene) ist Segment Routing, das MPLS-Labels für die Weiterleitung nutzt, wobei die Labels vom IGP anstelle eines separaten Label-Protokolls verteilt werden. Es lenkt den Verkehr entlang engineerter Pfade und nutzt dabei die vorhandene MPLS-Weiterleitungsebene weiter.
Wie nutzt SR-MPLS IS-IS oder OSPF?
SR-MPLS erweitert IS-IS oder OSPF, um Segment-Identifier als MPLS-Labels anzukündigen, sodass das IGP selbst die Labels verteilt. Damit entfällt die Notwendigkeit, dass LDP Labels zuweist, und jeder Knoten kann Label-switched Paths aus den Routing-Informationen aufbauen, die er ohnehin bereits flutet.
Was ist der SRGB in SR-MPLS?
Der SRGB (Segment Routing Global Block) ist der für globale Präfix-Segmente reservierte Bereich von MPLS-Labels. Eine Prefix-SID ist ein Index in diesen Block, sodass ein Knoten das lokale Label für ein Ziel berechnet, indem er den Index zur SRGB-Basis addiert, was eine konsistente Label-Zuweisung ergibt.
Worin besteht der Unterschied zwischen SR-MPLS und SRv6?
SR-MPLS leitet mithilfe von MPLS-Labels weiter und behält eine MPLS-Datenebene bei, während SRv6 auf der nativen IPv6-Datenebene weiterleitet und IPv6-Adressen als Segmente verwendet. SR-MPLS eignet sich für Netze, die bereits MPLS betreiben, wohingegen SRv6 MPLS zugunsten einer reinen IPv6-Weiterleitung ablöst.
Benötigt SR-MPLS weiterhin LDP?
Nein, SR-MPLS benötigt weder LDP noch RSVP-TE. Der IGP verteilt die Labels über Prefix-SIDs und Adjacency-SIDs, und TI-LFA sorgt für Fast Reroute, sodass ein einziger IGP die Labelverteilung, das Traffic Engineering und den Schutz übernimmt, die zuvor separate Protokolle erforderten.
Solution Briefs

Gehen Sie tiefer. Nehmen Sie es mit.

Zwei kurze, technische Downloads, die über diese Seite hinausgehen: das SR-MPLS-Upgrade-Briefing und das Cloud-&-SP-WAN-Transport-Briefing.

Solution Brief

SR-MPLS-Upgrade mit OcNOS

Migrieren Sie SR-MPLS auf OcNOS auf offener Hardware: Flex-Algo, TI-LFA und ein bewährter Umstellungspfad als Cisco-Alternative.

Brief anfordern
Solution Brief

Cloud- & Service-Provider-WAN-Transport

Cloud- und Service-Provider-WAN-Transport auf offener Hardware: SR-MPLS, EVPN und im Maßstab getestetes Forwarding.

Brief anfordern