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 und ersetzt es in Brownfield-Cores schrittweise. RFC 8661 definiert das 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 so durchgängige LSPs über gemischte Netze hinweg, ohne einen Flag-Day-Wechsel.

Fast Reroute: TI-LFA

Topology-Independent Loop-Free Alternate (TI-LFA, RFC 9855; ergänzendes remote-LFA in RFC 8102) berechnet vorprogrammierte Ausweichpfade, die konstruktionsbedingt schleifenfrei sind, ohne die Abdeckungslücken des klassischen LFA. Die Wiederherstellung liegt auf unterstützender Hardware unter 50 ms. TI-LFA schützt vor Knoten-, Link- und SRLG-Ausfällen: Der Ausweichpfad wird als Reparatur-Segmentliste kodiert, die am PLR eingefügt wird, bevor der primäre Pfad aus der Weiterleitungstabelle entfernt wird.

Flexible Algorithm (Flex-Algo)

IGP Flexible Algorithm (RFC 9350) ermöglicht es, dass eine einzige physische Topologie mehrere logische Ebenen trägt. Jede Flex-Algo-Definition legt einen Metriktyp, IGP-Kosten, minimale unidirektionale Link-Verzögerung oder TE metric fest, dazu eine Reihe von Link-Constraints, und das IGP berechnet die kürzesten Pfade nach diesen Regeln. OcNOS-SP kündigt jeden Algorithmus über IS-IS SR an, und jede prefix-SID wird pro Algorithmus aufgelöst, sodass der Verkehr nativ der Ebene mit geringer Verzögerung oder eingeschränkter Affinität folgt. Ein latenzempfindlicher Dienst und ein Best-Effort-Dienst nutzen dieselben Links auf unterschiedlichen Ebenen, ohne SR-TE-Policy und ohne externen Controller.

Flex-Algo und TI-LFA arbeiten zusammen. Der Fast-Reroute-Backup für ein Präfix wird innerhalb desselben Algorithmus wie der primäre Pfad berechnet, sodass ein verzögerungsoptimierter Flow auf einen anderen Pfad mit geringer Verzögerung umgeleitet wird, statt auf den standardmäßigen kürzesten Pfad zurückzufallen. Jede Ebene behält ihren eigenen Schutz von unter 50 ms.

OcNOS-SP Implementation

OcNOS-SP implementiert SR-MPLS über die Service-Provider-Silizium-Familien Broadcom Qumran und Jericho hinweg, von den kompakten Edge-Plattformen Qumran2a und Qumran2u über die Aggregation Qumran2c und Qumran2c+ bis zu den Core-Routern Jericho2c+. Die Implementierung deckt den vollständigen Funktionsumfang von 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 Schnittstelle aktiviert. Schützt vor Knoten- und Link-Ausfällen. Ausweichpfad in der Hardware-Weiterleitungstabelle vorinstalliert. Wiederherstellung in unter 50 ms auf unterstützten SP-Plattformen.

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

LDP-SR-Interworking gemäß RFC 8661 für die Brownfield-Migration. Mapping-Server für die Bindung von prefix SID an LDP-Label. SR-LDP-Grenzknotenfunktionalitä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 bereitgestellt werden. Per-VPN-Steering zwischen den MPLS- und IPv6-Datenebenen. Interworking-Funktion für domänenübergreifendes 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 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
Alle Plattformen in Qualified Hardware ansehen → SR-MPLS Feature-Matrix →

Verwandte Technologien und Lösungen

EVPN-VXLAN → SRv6 → BGP → Offenes IP Core SR-MPLS Design → SP Networks Solution → IP-over-DWDM-Lösung → Broadband-Access-Lösung → OcNOS Feature Matrix → IS-IS SR mit TI-LFA → MPLS Traffic Engineering (RSVP-TE) → Segment Routing erklärt: SR-MPLS →

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.
Worin unterscheidet sich SR-MPLS von herkömmlichem MPLS mit LDP oder RSVP-TE?
Herkömmliches MPLS ist auf LDP oder RSVP-TE angewiesen, um an jedem Hop einen Zustand pro LSP zu signalisieren und vorzuhalten. SR-MPLS behält dieselbe MPLS-Weiterleitungsebene bei, doch das IGP verteilt Labels als Segment-IDs, sodass der Head-End den Pfad ohne separates Signalisierungsprotokoll festlegt. RFC 8660 definiert dies. OcNOS-SP kann SR-MPLS und RSVP-TE gemeinsam auf einem Router betreiben.
Was ist IS-IS Segment Routing?
IS-IS Segment Routing erweitert das IS-IS-Link-State-Protokoll, um Segment-Identifier als MPLS-Labels anzukündigen, definiert in RFC 8667. Jeder Router flutet prefix-SID- und adjacency-SID-Sub-TLVs, sodass allein das IGP labelvermittelte Pfade ohne LDP aufbaut. OcNOS-SP implementiert IS-IS SR mit Knoten- und Adjazenz-SIDs sowie Flexible Algorithm für eine topologiebewusste Pfadauswahl.
Was ist TI-LFA in SR-MPLS?
TI-LFA (Topology Independent Loop-Free Alternate), spezifiziert in RFC 9855, nutzt Segment Routing, um für jedes Ziel im Voraus einen schleifenfreien Ausweichpfad zu berechnen. Bei einem Link-, Knoten- oder SRLG-Ausfall fügt der Point of Local Repair einen Reparatur-Label-Stack ein und stellt den Verkehr in unter 50 ms wieder her. OcNOS-SP aktiviert TI-LFA pro Schnittstelle, wobei der Ausweichpfad in der Hardware-Weiterleitungstabelle vorinstalliert ist.
Was ist Flex-Algo (IGP Flexible Algorithm)?
Flex-Algo, bzw. IGP Flexible Algorithm (RFC 9350), ermöglicht es dem IGP, beschränkungsbasierte Pfade anhand einer Metrik und anderer Beschränkungen als des standardmäßigen kürzesten Pfads zu berechnen, etwa geringste Verzögerung oder eine affinitätsbegrenzte Topologie. Jeder Algorithmus wird einer prefix-SID zugeordnet, sodass der Verkehr den benutzerdefinierten Pfad nativ nutzt. OcNOS-SP unterstützt Flexible Algorithm mit IS-IS SR für eine topologiebewusste SID-Zuweisung.
Kann EVPN über SR-MPLS laufen?
Ja. EVPN (RFC 7432) ist eine BGP-Steuerebene für Ethernet-Dienste, die über eine MPLS-Datenebene weiterleitet; seine Service-Labels nutzen daher SR-MPLS-labelvermittelte Pfade auf dieselbe Weise wie über LDP oder RSVP-TE. Der Betrieb von EVPN über SR-MPLS verschafft Ethernet-Diensten die Segment-Routing-Vorteile der quellbasierten Pfadauswahl und des TI-LFA-Schutzes.
Datenblatt und Solution Briefs

Gehen Sie tiefer. Nehmen Sie es mit.

Das Produktdatenblatt und kurze, technische Downloads, die über diese Seite hinausgehen.

Datenblatt

OcNOS-SP Datenblatt

Vollständige OcNOS-SP Spezifikation: Funktionsumfang für Access, Cell Site und Aggregation, Software-SKUs, unterstützte Hardware-Plattformen und der Solution Ordering Guide.

Datasheet abrufen
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