IPv6 Source Routing · SRH Extension Header

Segment Routing über IPv6

SR angewandt auf die IPv6-Data-Plane – Segmentlisten werden als Sequenz von IPv6-Adressen in einem SRH-Extension-Header codiert und ermöglichen Source Routing ohne MPLS-Labels oder zusätzlichen Encapsulation-Overhead.

SRv6-SID-List-Forwarding

Ein Paket durchläuft drei SR-Endpoints. Die SID-Liste ist direkt in der IPv6-Zieladresse codiert: Jeder Hop poppt die aktive uSID und leitet auf der nächsten weiter.

SRv6-Paketfluss durch drei Endpunkte mit IPv6-SID-Liste fc00::1, fc00::2, fc00::3
SRv6: Paketdurchlauf durch drei Endpunkte, gesteuert durch eine IPv6-SID-Liste.

Was ist Segment Routing?

Segment Routing (RFC 8402) ist eine Source-Routing-Architektur. Der Head-End-Knoten kodiert den Pfad eines Pakets als geordnete Liste von Anweisungen, die als Segmente bezeichnet werden, und das Netzwerk leitet anhand dieser Liste weiter, ohne an jedem Hop einen Zustand pro Flow vorzuhalten. Sie arbeitet auf zwei Datenebenen: SR-MPLS überträgt die Segmentliste als MPLS-Label-Stack, und SRv6 überträgt sie als Liste von IPv6-Adressen. Diese Seite behandelt SRv6, und die SR-MPLS-Datenebene wird auf einer eigenen Seite dokumentiert.

Was SRv6 ist

SRv6 (RFC 8986) codiert einen quelleninitiierten Pfad als geordnete Liste von IPv6-Adressen, sogenannten SIDs – jede repräsentiert eine topologische Anweisung (Segment) an einem bestimmten Knoten. Der Segment Routing Header (SRH, RFC 8754) transportiert die SID-Liste im IPv6-Extension-Header-Stack. An jedem SR-Knoten wird die aktive SID verarbeitet, der SL-Pointer (Segments Left) dekrementiert und die IPv6-DA auf die nächste SID aktualisiert.

SRv6-SIDs sind routbare IPv6-Adressen, die aus einem Locator (topologisch signifikanter Präfix, typischerweise /48 oder /64) und einer Function (Verhaltenskennung) bestehen. Der SR-Forwarding-State ist somit in die IPv6-Routingtabelle eingebettet – kein separater Label-Space, kein LFIB, keine MPLS-spezifischen HW-Ressourcen. Transit-Knoten benötigen kein SRH-Bewusstsein, sofern sie keine SR-Endpoints sind.

SRv6 uSID (draft-ietf-spring-srv6-srh-compression) komprimiert die SID-Codierung deutlich: Mehrere Micro-SIDs werden in einer einzigen 128-Bit-IPv6-Adresse gepackt und reduzieren so Per-Hop-Verarbeitung und Header-Overhead auf Werte, die in typischen SP-Deployments mit SR-MPLS konkurrenzfähig sind.

SRv6 Network Programming

RFC 8986 definiert eine Reihe von SRv6-Endpoint-Verhalten – End (SR-Endpoint), End.X (Endpoint mit Cross-Connect), End.T (Endpoint mit Table Lookup), End.DT4/DT6/DT46 (Endpoint mit Decap und L3-Table-Lookup). Diese Verhalten implementieren die vollständige VPN-Forwarding-Funktion innerhalb der SID-Semantik und ermöglichen L3VPN- und L2VPN-Services über einen reinen IPv6-Core.

OcNOS-SP Implementation

IS-IS SRv6 Extensions

IS-IS mit SRv6-Erweiterungen (draft-ietf-lsr-isis-srv6-extensions). Locator-Ankündigung, SID-Sub-TLV pro Präfix. Flexible Algorithms für topologiebewusste SID-Zuweisung.

uSID-Komprimierung

uSID-Implementierung gemäß draft-ietf-spring-srv6-srh-compression. /32-Block, /48-Locator. Mehrere uSIDs werden pro 128-Bit-Adresse gepackt. Kompatibel mit bestehender IPv6-Forwarding-HW: keine SRH-Verarbeitung im Transit.

H.Encaps-Verhalten

Head-End-Encapsulation, die einen neuen äußeren IPv6-Header mit SRH einfügt. H.Encaps.Red für reduzierten SRH (Single SID). Unterstützt Policy-Based Steering anhand von Match-Kriterien.

SRv6-TE-Richtlinien

SRv6-Traffic-Engineering-Policies mit expliziten SID-Listen. Vom PCE berechnete Pfade via PCEP. BGP SR-TE für Cross-Domain-Policy-Verteilung.

L3VPN over SRv6

End.DT46-Behavior für Decap und VRF-Lookup. BGP-L3VPN mit SRv6-Transport gemäß RFC 9252 (BGP Overlay Services on SRv6). SID-Allokation pro VRF aus dem Locator-Block.

SR-MPLS Co-existence

SRv6 und SR-MPLS gleichzeitig aktiv auf demselben Knoten. Transport-Plane-Auswahl pro VPN. Interworking-Funktion für Cross-Domain-Stitching an Domain-Grenzen.

OcNOS-Validated Hardware

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

UfiSpace S9600-56DX
Qumran2c · 4×25G + 48×100G + 8×400G
UfiSpace S9600-28DX
Qumran2c · 4×25G + 24×100G + 4×400G
UfiSpace S9600-32X
Qumran2c · 32×100G
UfiSpace S9600-64X
Qumran2c · 64×100G
UfiSpace S9610-46DX
Qumran2c+ · 4×25G + 40×100G + 6×400G
UfiSpace S9510-28DC
Qumran2a · 24×25G + 2×100G + 2×400G
Edgecore AS7535-28XB
Qumran2a · 24×25G + 2×100G + 2×400G
UfiSpace S9510-30XC
Qumran2u · 28×25G + 2×100G

Vergleichen Sie SRv6-Support über alle OcNOS-validierten Plattformen hinweg

Open Feature Matrix →
FAQ

Häufig gestellte Fragen

Was ist SRv6?
SRv6 (Segment Routing over IPv6) ist Segment Routing, das die IPv6-Data-Plane direkt nutzt. Jedes Segment wird als 128-Bit-IPv6-Adresse, ein sogenanntes SID, kodiert, sodass das Netz den Datenverkehr entlang eines geplanten Pfads mittels nativem IPv6-Forwarding lenkt, ohne MPLS-Label-Stack.
Was ist der Unterschied zwischen SRv6 und SR-MPLS?
SRv6 kodiert Segmente als 128-Bit-IPv6-Adressen und leitet auf der IPv6-Data-Plane weiter, während SR-MPLS Segmente als MPLS-Labels kodiert und auf der MPLS-Data-Plane weiterleitet. SRv6 benötigt im Core nur IPv6, wohingegen SR-MPLS eine MPLS-Forwarding-Plane beibehält.
Was ist ein uSID in SRv6?
Ein uSID (micro-SID) fasst mehrere SRv6-Anweisungen in einer einzigen 128-Bit-IPv6-Adresse zusammen, sodass eine Adresse viele Segmente tragen kann. Das verkürzt die Segment-Liste, verringert den Paket-Overhead und ermöglicht, dass längere geplante Pfade in das standardmäßige IPv6-Forwarding passen.
Benötigt SRv6 MPLS?
Nein, SRv6 benötigt kein MPLS. Es läuft auf der nativen IPv6-Data-Plane und verwendet IPv6-Adressen als Segment-Identifier, sodass der Core allein über IPv6 weiterleitet. Dadurch können Netzbetreiber Traffic Engineering und Service-Routing ohne eine MPLS-Label-Switching-Plane betreiben.
Was ist der SRH in SRv6?
Der SRH (Segment Routing Header) ist ein IPv6-Erweiterungsheader, der die geordnete Liste der SIDs trägt, denen ein Paket folgen muss. Während das Paket den Pfad durchläuft, bestimmt das aktive Segment im SRH den nächsten Hop und codiert die konstruierte Route innerhalb des IPv6-Pakets selbst.
Sollte ich SRv6 oder SR-MPLS wählen?
Das hängt von der Datenebene des Core ab. SRv6 entfernt MPLS und führt Traffic Engineering und VPN-Dienste über natives IPv6 aus, was sich für IPv6-first- und Greenfield-Netzwerke eignet. SR-MPLS behält die MPLS-Weiterleitungsebene bei, was sich für Betreiber mit installierter MPLS-Basis eignet, die Segment Routing ohne Änderung der Datenebene wünschen. OcNOS-SP unterstützt beide, sodass ein Netzwerk Domäne für Domäne migrieren und an der Grenze zusammenarbeiten kann.
Unterstützt SRv6 L3VPN?
Ja. SRv6 überträgt L3VPN mithilfe der Endpunkt-Verhaltensweisen End.DT4, End.DT6 und End.DT46 aus RFC 8986, die ein Paket dekapseln und es im Ziel-VRF nachschlagen. BGP kündigt die SIDs pro VPN gemäß RFC 9252 als SRv6-Dienste an, sodass ein VPN über einen reinen IPv6-Core ohne MPLS-Service-Label läuft.
Welche Hardware unterstützt SRv6 in OcNOS?
OcNOS-SP führt SRv6 auf Broadcom-Qumran-Serviceprovider-Plattformen mit uSID-Kompression aus, sodass Transitknoten in Standard-IPv6 ohne SRH-Verarbeitung weiterleiten. Die aktuelle Liste der für SRv6 qualifizierten Plattformen, mit ASIC, Portdichte und Version, wird in der OcNOS Hardware Compatibility List gepflegt.