1. Introduction (Einführung)

Segment Routing (SR) nutzt das Source-Routing-Paradigma. Ein Knoten steuert ein Paket durch eine SR-Richtlinie (SR Policy), die als geordnete Liste von Anweisungen, den sogenannten "Segmenten", instanziiert ist. Ein Segment kann jede Anweisung repräsentieren, topologiebasiert oder dienstbasiert. Ein Segment kann eine lokale Semantik für einen SR-Knoten oder eine globale Semantik innerhalb einer SR-Domäne haben. SR unterstützt explizites Routing pro Fluss, während der Zustand pro Fluss nur an den Eingangsknoten zur SR-Domäne aufrechterhalten wird.

Ein Segment wird häufig durch seine Segment-Kennung (Segment Identifier, SID) referenziert.

Ein Segment kann mit einer topologischen Anweisung verknüpft sein. Ein lokales topologisches Segment kann einen Knoten anweisen, das Paket über eine bestimmte ausgehende Schnittstelle weiterzuleiten. Ein globales topologisches Segment kann eine SR-Domäne anweisen, das Paket über einen bestimmten Pfad zu einem Ziel weiterzuleiten. Für dasselbe Ziel können unterschiedliche Segmente existieren, jedes mit unterschiedlichen Pfadzielen (z.B. welche Metrik minimiert wird, welche Einschränkungen spezifiziert sind).

Ein Segment kann mit einer Dienstanweisung verknüpft sein (z.B. das Paket sollte von einem Container oder einer virtuellen Maschine (Virtual Machine, VM) verarbeitet werden, die mit dem Segment verknüpft ist). Ein Segment kann mit einer QoS-Behandlung verknüpft sein (z.B. die mit diesem Segment empfangenen Pakete bei x Mbps formen).

Die SR-Architektur unterstützt jede Art von Anweisung, die mit einem Segment verknüpft ist.

Die SR-Architektur unterstützt jede Art von Kontrollebene: verteilt, zentralisiert oder hybrid.

In einem verteilten Szenario werden die Segmente von IS-IS, OSPF oder BGP zugewiesen und signalisiert. Ein Knoten entscheidet individuell, Pakete auf eine SR-Richtlinie zu steuern (z.B. vorberechneter lokaler Schutz [RFC8355]). Ein Knoten berechnet die SR-Richtlinie individuell.

In einem zentralisierten Szenario werden die Segmente von einem SR-Controller zugewiesen und instanziiert. Der SR-Controller entscheidet, welche Knoten welche Pakete auf welchen source-gerouteten Richtlinien steuern müssen. Der SR-Controller berechnet die source-gerouteten Richtlinien. Die SR-Architektur schränkt nicht ein, wie der Controller das Netzwerk programmiert. Wahrscheinliche Optionen sind das Netzwerkkonfigurationsprotokoll (Network Configuration Protocol, NETCONF), das Pfadberechnungselement-Kommunikationsprotokoll (Path Computation Element Communication Protocol, PCEP) und BGP. Die SR-Architektur schränkt die Anzahl der SR-Controller nicht ein. Insbesondere können mehrere SR-Controller dieselbe SR-Domäne programmieren. Die SR-Architektur ermöglicht es diesen SR-Controllern zu entdecken, welche SIDs an welchen Knoten instanziiert sind und welche Sätze von lokalen (SRLB) und globalen (SRGB) Labels an welchem Knoten verfügbar sind.

Ein Hybridszenario ergänzt eine verteilte Basis-Kontrollebene mit einem zentralisierten Controller. Wenn sich beispielsweise das Ziel außerhalb der IGP-Domäne befindet, kann der SR-Controller eine SR-Richtlinie im Namen eines IGP-Knotens berechnen. Die SR-Architektur schränkt nicht ein, wie die Knoten, die Teil der verteilten Kontrollebene sind, mit dem SR-Controller interagieren. Wahrscheinliche Optionen sind PCEP und BGP.

Hosts KÖNNEN Teil einer SR-Domäne sein. Ein zentralisierter Controller kann Hosts über Richtlinien informieren, indem er diese Richtlinien an Hosts pusht oder auf Anfragen von Hosts antwortet.

Die SR-Architektur kann auf verschiedenen Datenebenen instanziiert werden. Dieses Dokument stellt zwei Datenebenen-Instanziierungen von SR vor: SR über MPLS (SR over MPLS, SR-MPLS) und SR über IPv6 (SR over IPv6, SRv6).

SR kann direkt auf die MPLS-Architektur angewendet werden, ohne die Weiterleitungsebene zu ändern [SR-MPLS]. Ein Segment wird als MPLS-Label kodiert. Eine SR-Richtlinie wird als Stapel von Labels instanziiert. Das zu verarbeitende Segment (das aktive Segment) befindet sich oben auf dem Stapel. Nach Abschluss eines Segments wird das zugehörige Label vom Stapel entfernt.

SR kann auf die IPv6-Architektur mit einem neuen Typ von Routing-Header, dem SR-Header (SRH) [IPv6-SRH], angewendet werden. Eine Anweisung ist mit einem Segment verknüpft und als IPv6-Adresse kodiert. Ein SRv6-Segment wird auch als SRv6 SID bezeichnet. Eine SR-Richtlinie wird als geordnete Liste von SRv6 SIDs im Routing-Header instanziiert. Das aktive Segment wird durch die Zieladresse (Destination Address, DA) des Pakets angezeigt. Das nächste aktive Segment wird durch den SegmentsLeft (SL) Zeiger im SRH angezeigt. Wenn ein SRv6 SID abgeschlossen ist, wird SL dekrementiert und das nächste Segment wird in die DA kopiert. Wenn ein Paket auf eine SR-Richtlinie gesteuert wird, wird der zugehörige SRH dem Paket hinzugefügt.

Im Kontext einer IGP-basierten verteilten Kontrollebene werden zwei topologische Segmente definiert: das IGP-Adjacency-Segment und das IGP-Präfix-Segment.

Im Kontext einer BGP-basierten verteilten Kontrollebene werden zwei topologische Segmente definiert: das BGP-Peering-Segment und das BGP-Präfix-Segment.

Das Headend einer SR-Richtlinie bindet eine SID (Binding-Segment oder BSID genannt) an seine Richtlinie. Wenn das Headend ein Paket mit einem aktiven Segment erhält, das mit der BSID einer lokalen SR-Richtlinie übereinstimmt, steuert das Headend das Paket in die zugehörige SR-Richtlinie.

Dieses Dokument definiert die IGP-, BGP- und Binding-Segmente für die SR-MPLS- und SRv6-Datenebenen.

Hinweis: Dieses Dokument definiert die Architektur für Segment Routing, einschließlich Definitionen grundlegender Objekte und Funktionen sowie einer Beschreibung des Gesamtdesigns. Es definiert NICHT die Mittel zur Implementierung der Architektur -- dies ist in zahlreichen referenzierten Dokumenten enthalten, von denen einige in diesem Dokument der Bequemlichkeit des Lesers wegen erwähnt werden.