2. Segment Routing Header (En-tête de routage de segment)
2. Segment Routing Header (En-tête de routage de segment)
Les en-têtes de routage sont définis dans [RFC8200]. Le Segment Routing Header (en-tête de routage de segment, SRH) a un nouveau Routing Type (type de routage) (4).
Le SRH est défini comme suit:
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) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
où:
Next Header: Défini dans [RFC8200], Section 4.4.
Hdr Ext Len: Défini dans [RFC8200], Section 4.4.
Routing Type: 4.
Segments Left: Défini dans [RFC8200], Section 4.4.
Last Entry: contient l'index (basé sur zéro), dans la Segment List (liste de segments), du dernier élément de la Segment List.
Flags: 8 bits de drapeaux. La Section 8.1 crée un registre IANA pour définir de nouveaux drapeaux. Les drapeaux suivants sont définis:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U U U U U U U U|
+-+-+-+-+-+-+-+-+
U: Non utilisé et réservé pour usage futur. DOIT être 0 à la transmission et ignoré à la réception.
Tag: Étiqueter un paquet comme faisant partie d'une classe ou d'un groupe de paquets -- par exemple, des paquets partageant le même ensemble de propriétés. Lorsque Tag n'est pas utilisé à la source, il DOIT être défini à zéro à la transmission. Lorsque Tag n'est pas utilisé pendant le traitement du SRH, il DEVRAIT être ignoré. Tag n'est pas utilisé lors du traitement du SID défini dans la Section 4.3.1. Il peut être utilisé lors du traitement d'autres SID qui ne sont pas définis dans ce document. L'allocation et l'utilisation du tag sont hors de la portée de ce document.
Segment List[0..n]: Adresses IPv6 de 128 bits représentant le nième segment dans la Segment List. La Segment List est encodée en commençant par le dernier segment de la SR Policy (politique SR). C'est-à-dire que le premier élément de la Segment List (Segment List[0]) contient le dernier segment de la SR Policy, le deuxième élément contient l'avant-dernier segment de la SR Policy, et ainsi de suite.
TLV: Type Length Value (type longueur valeur, TLV) est décrit dans la Section 2.1.
Dans le SRH, les champs Next Header, Hdr Ext Len, Routing Type et Segments Left sont définis dans la Section 4.4 de [RFC8200]. Sur la base des contraintes de cette section, Next Header, Header Ext Len et Routing Type ne sont pas mutables tandis que Segments Left est mutable.
La mutabilité de la valeur TLV est définie par le bit le plus significatif du type, comme spécifié dans la Section 2.1.
La Section 4.3 définit la mutabilité des champs restants du SRH (Flags, Tag, Segment List) dans le contexte du SID défini dans ce document.
Les nouveaux SID définis à l'avenir DOIVENT spécifier les propriétés de mutabilité des Flags, Tag et Segment List et indiquer comment fonctionne la vérification du Hashed Message Authentication Code (code d'authentification de message haché, HMAC) TLV (Section 2.1.2). Notez qu'en effet, ces champs sont mutables.
Conformément au modèle SR, la source du SRH sait toujours comment définir la Segment List, les Flags, le Tag et les TLV du SRH pour une utilisation dans le domaine SR. La manière dont elle y parvient est hors de la portée de ce document mais peut être basée sur la topologie, les SID disponibles et leurs propriétés de mutabilité, les exigences de mutabilité du SRH de la destination, ou toute autre information.
2.1. SRH TLVs
Cette section définit les TLV du Segment Routing Header.
Un TLV fournit des métadonnées pour le traitement des segments. Les seuls TLV définis dans ce document sont le HMAC (Section 2.1.2) et les TLV de remplissage (Section 2.1.1). Lors du traitement du SID défini dans la Section 4.3.1, tous les TLV sont ignorés sauf indication contraire de la configuration locale (Section 4.3.1.1.1). Ainsi, le support TLV et HMAC est optionnel pour toute implémentation; cependant, une implémentation ajoutant ou analysant des TLV DOIT supporter les TLV PAD. D'autres documents peuvent définir des TLV supplémentaires et des règles de traitement pour eux.
Les TLV sont présents lorsque le Hdr Ext Len est supérieur à (Last Entry+1)*2.
Lors du traitement des TLV à un point de terminaison de segment, les TLV DOIVENT être entièrement contenus dans le SRH tel que déterminé par le Hdr Ext Len. La détection de TLV dépassant la limite du SRH Hdr Ext Len entraîne un message ICMP Parameter Problem (problème de paramètre), Code 0, à l'adresse source, pointant vers le champ Hdr Ext Len du SRH, et le paquet est écarté.
Une implémentation PEUT limiter le nombre et/ou la longueur des TLV qu'elle traite en fonction de la configuration locale. Elle PEUT limiter:
-
le nombre d'options Pad1 (Section 2.1.1.1) consécutives à 1. Si un remplissage de plus d'un octet est requis, alors PadN (Section 2.1.1.2) devrait être utilisé.
-
La longueur dans PadN à 5.
-
Le nombre maximum de TLV non-Pad à traiter.
-
La longueur maximale de tous les TLV à traiter.
L'implémentation PEUT arrêter de traiter les TLV supplémentaires dans le SRH lorsque ces limites configurées sont dépassées.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
| Type | Length | Variable-length data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
Type: Un codepoint de 8 bits du "Segment Routing Header TLVs" [IANA-SRHTLV]. Les types non reconnus DOIVENT être ignorés à la réception.
Length: La longueur du champ de données de longueur variable en octets.
Variable-length data: données spécifiques au Type.
Les entrées Type Length Value (TLV) contiennent des informations OPTIONNELLES qui peuvent être utilisées par le nœud identifié dans l'adresse de destination (DA) du paquet.
Chaque TLV a sa propre longueur, format et sémantique. Le codepoint alloué (par IANA) à chaque Type TLV définit à la fois le format et la sémantique des informations transportées dans le TLV. Plusieurs TLV peuvent être encodés dans le même SRH.
Le bit de poids fort du type TLV (bit 0) spécifie si les données TLV de ce type peuvent changer en route vers la destination finale du paquet:
0: Les données TLV ne changent pas en route
1: Les données TLV changent en route
Tous les TLV spécifient leurs exigences d'alignement en utilisant un format xn+y. Le format xn+y est défini selon [RFC8200]. Les nœuds sources SR utilisent les exigences d'alignement xn+y des TLV et des TLV de remplissage lors de la construction d'un SRH.
Le champ Length du TLV est utilisé pour sauter le TLV lors de l'inspection du SRH au cas où le nœud ne supporte pas ou ne reconnaît pas le Type. La Length définit la longueur du TLV en octets, sans inclure les champs Type et Length.
Les TLV suivants sont définis dans ce document:
Padding TLVs (TLV de remplissage)
HMAC TLV
Des TLV supplémentaires peuvent être définis à l'avenir.