2. Segment Routing Header (Segmentroutingkopfzeile)
2. Segment Routing Header (Segmentroutingkopfzeile)
Routingkopfzeilen sind in [RFC8200] definiert. Der Segment Routing Header (Segmentroutingkopfzeile, SRH) hat einen neuen Routing Type (Routingtyp) (4).
Der SRH ist wie folgt definiert:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[0] (128-bit IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
...
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[n] (128-bit IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
wobei:
Next Header: Definiert in [RFC8200], Abschnitt 4.4.
Hdr Ext Len: Definiert in [RFC8200], Abschnitt 4.4.
Routing Type: 4.
Segments Left: Definiert in [RFC8200], Abschnitt 4.4.
Last Entry: enthält den Index (nullbasiert) des letzten Elements der Segment List (Segmentliste) in der Segment List.
Flags: 8 Bits von Flags. Abschnitt 8.1 erstellt ein IANA-Register zur Definition neuer Flags. Die folgenden Flags sind definiert:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U U U U U U U U|
+-+-+-+-+-+-+-+-+
U: Nicht verwendet und für zukünftige Verwendung reserviert. MUSS bei der Übertragung 0 sein und beim Empfang ignoriert werden.
Tag: Markiert ein Paket als Teil einer Klasse oder Gruppe von Paketen -- z.B. Pakete, die denselben Satz von Eigenschaften teilen. Wenn Tag an der Quelle nicht verwendet wird, MUSS es bei der Übertragung auf Null gesetzt werden. Wenn Tag während der SRH-Verarbeitung nicht verwendet wird, SOLLTE es ignoriert werden. Tag wird nicht verwendet, wenn der in Abschnitt 4.3.1 definierte SID verarbeitet wird. Es kann verwendet werden, wenn andere SIDs verarbeitet werden, die in diesem Dokument nicht definiert sind. Die Zuweisung und Verwendung von Tag liegt außerhalb des Umfangs dieses Dokuments.
Segment List[0..n]: 128-Bit-IPv6-Adressen, die das n-te Segment in der Segment List darstellen. Die Segment List wird beginnend mit dem letzten Segment der SR Policy (SR-Richtlinie) codiert. Das heißt, das erste Element der Segment List (Segment List[0]) enthält das letzte Segment der SR Policy, das zweite Element enthält das vorletzte Segment der SR Policy, und so weiter.
TLV: Type Length Value (Typ Länge Wert, TLV) wird in Abschnitt 2.1 beschrieben.
Im SRH sind die Felder Next Header, Hdr Ext Len, Routing Type und Segments Left in Abschnitt 4.4 von [RFC8200] definiert. Basierend auf den Einschränkungen in diesem Abschnitt sind Next Header, Header Ext Len und Routing Type nicht veränderbar, während Segments Left veränderbar ist.
Die Veränderbarkeit des TLV-Werts wird durch das höchstwertige Bit im Typ definiert, wie in Abschnitt 2.1 spezifiziert.
Abschnitt 4.3 definiert die Veränderbarkeit der verbleibenden Felder im SRH (Flags, Tag, Segment List) im Kontext des in diesem Dokument definierten SID.
Neue SIDs, die in Zukunft definiert werden, MÜSSEN die Veränderbarkeitseigenschaften von Flags, Tag und Segment List spezifizieren und angeben, wie die Hashed Message Authentication Code (gehashter Nachrichtenauthentifizierungscode, HMAC) TLV (Abschnitt 2.1.2) Verifizierung funktioniert. Beachten Sie, dass diese Felder tatsächlich veränderbar sind.
Konsistent mit dem SR-Modell weiß die Quelle des SRH immer, wie die Segment List, Flags, Tag und TLVs des SRH für die Verwendung innerhalb der SR-Domäne einzustellen sind. Wie dies erreicht wird, liegt außerhalb des Umfangs dieses Dokuments, kann aber auf Topologie, verfügbaren SIDs und deren Veränderbarkeitseigenschaften, den SRH-Veränderbarkeitsanforderungen des Ziels oder anderen Informationen basieren.
2.1. SRH TLVs
Dieser Abschnitt definiert TLVs des Segment Routing Header.
Ein TLV liefert Metadaten für die Segmentverarbeitung. Die einzigen in diesem Dokument definierten TLVs sind der HMAC (Abschnitt 2.1.2) und Padding-TLVs (Abschnitt 2.1.1). Bei der Verarbeitung des in Abschnitt 4.3.1 definierten SID werden alle TLVs ignoriert, es sei denn, die lokale Konfiguration gibt etwas anderes an (Abschnitt 4.3.1.1.1). Daher ist die TLV- und HMAC-Unterstützung für jede Implementierung optional; eine Implementierung, die TLVs hinzufügt oder analysiert, MUSS jedoch PAD-TLVs unterstützen. Andere Dokumente können zusätzliche TLVs und Verarbeitungsregeln für sie definieren.
TLVs sind vorhanden, wenn der Hdr Ext Len größer als (Last Entry+1)*2 ist.
Bei der Verarbeitung von TLVs an einem Segmentendpunkt MÜSSEN TLVs vollständig im SRH enthalten sein, wie durch den Hdr Ext Len bestimmt. Die Erkennung von TLVs, die die Grenze des SRH Hdr Ext Len überschreiten, führt zu einer ICMP Parameter Problem (Parameterproblem), Code 0, Nachricht an die Quelladresse, die auf das Hdr Ext Len Feld des SRH zeigt, und das Paket wird verworfen.
Eine Implementierung KANN die Anzahl und/oder Länge der von ihr verarbeiteten TLVs basierend auf der lokalen Konfiguration begrenzen. Sie KANN begrenzen:
-
die Anzahl aufeinanderfolgender Pad1 (Abschnitt 2.1.1.1) Optionen auf 1. Wenn Padding von mehr als einem Byte erforderlich ist, sollte PadN (Abschnitt 2.1.1.2) verwendet werden.
-
Die Länge in PadN auf 5.
-
Die maximale Anzahl zu verarbeitender Nicht-Pad-TLVs.
-
Die maximale Länge aller zu verarbeitenden TLVs.
Die Implementierung KANN die Verarbeitung zusätzlicher TLVs im SRH stoppen, wenn diese konfigurierten Grenzen überschritten werden.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
| Type | Length | Variable-length data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
Type: Ein 8-Bit-Codepunkt aus "Segment Routing Header TLVs" [IANA-SRHTLV]. Nicht erkannte Typen MÜSSEN beim Empfang ignoriert werden.
Length: Die Länge des Feldes mit variabler Länge in Bytes.
Variable-length data: Daten, die spezifisch für den Typ sind.
Type Length Value (TLV) Einträge enthalten OPTIONALE Informationen, die vom Knoten verwendet werden können, der in der Destination Address (Zieladresse, DA) des Pakets identifiziert wird.
Jedes TLV hat seine eigene Länge, sein Format und seine Semantik. Der (von IANA) zugewiesene Codepunkt für jeden TLV-Typ definiert sowohl das Format als auch die Semantik der im TLV übertragenen Informationen. Mehrere TLVs können im selben SRH codiert werden.
Das höchstwertige Bit des TLV-Typs (Bit 0) gibt an, ob die TLV-Daten dieses Typs sich auf dem Weg zum endgültigen Ziel des Pakets ändern können oder nicht:
0: TLV-Daten ändern sich nicht unterwegs
1: TLV-Daten ändern sich unterwegs
Alle TLVs geben ihre Ausrichtungsanforderungen im xn+y-Format an. Das xn+y-Format ist gemäß [RFC8200] definiert. Die SR-Quellknoten verwenden die xn+y-Ausrichtungsanforderungen von TLVs und Padding-TLVs beim Konstruieren eines SRH.
Das Length-Feld des TLV wird verwendet, um das TLV beim Überprüfen des SRH zu überspringen, falls der Knoten den Typ nicht unterstützt oder erkennt. Die Length definiert die TLV-Länge in Oktetten, ohne die Type- und Length-Felder.
Die folgenden TLVs sind in diesem Dokument definiert:
Padding TLVs (Padding-TLVs)
HMAC TLV
Zusätzliche TLVs können in Zukunft definiert werden.