2. Segment Routing Header (Intestazione di Segment Routing)
2. Segment Routing Header (Intestazione di Segment Routing)
Le intestazioni di routing sono definite in [RFC8200]. Il Segment Routing Header (intestazione di instradamento di segmento, SRH) ha un nuovo Routing Type (tipo di routing) (4).
Il SRH è definito come segue:
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) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
dove:
Next Header: Definito in [RFC8200], Sezione 4.4.
Hdr Ext Len: Definito in [RFC8200], Sezione 4.4.
Routing Type: 4.
Segments Left: Definito in [RFC8200], Sezione 4.4.
Last Entry: contiene l'indice (a base zero), nella Segment List (lista di segmenti), dell'ultimo elemento della Segment List.
Flags: 8 bit di flag. La Sezione 8.1 crea un registro IANA per definire nuovi flag. I seguenti flag sono definiti:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U U U U U U U U|
+-+-+-+-+-+-+-+-+
U: Non utilizzato e riservato per uso futuro. DEVE essere 0 in trasmissione e ignorato alla ricezione.
Tag: Etichetta un pacchetto come parte di una classe o gruppo di pacchetti -- ad esempio, pacchetti che condividono lo stesso insieme di proprietà. Quando Tag non viene utilizzato alla sorgente, DEVE essere impostato a zero in trasmissione. Quando Tag non viene utilizzato durante l'elaborazione SRH, DOVREBBE essere ignorato. Tag non viene utilizzato quando si elabora il SID definito nella Sezione 4.3.1. Può essere utilizzato quando si elaborano altri SID che non sono definiti in questo documento. L'allocazione e l'uso del tag sono al di fuori dell'ambito di questo documento.
Segment List[0..n]: Indirizzi IPv6 a 128 bit che rappresentano l'ennesimo segmento nella Segment List. La Segment List è codificata a partire dall'ultimo segmento della SR Policy (politica SR). Cioè, il primo elemento della Segment List (Segment List[0]) contiene l'ultimo segmento della SR Policy, il secondo elemento contiene il penultimo segmento della SR Policy, e così via.
TLV: Type Length Value (tipo lunghezza valore, TLV) è descritto nella Sezione 2.1.
Nel SRH, i campi Next Header, Hdr Ext Len, Routing Type e Segments Left sono definiti nella Sezione 4.4 di [RFC8200]. Sulla base dei vincoli in quella sezione, Next Header, Header Ext Len e Routing Type non sono mutabili mentre Segments Left è mutabile.
La mutabilità del valore TLV è definita dal bit più significativo nel tipo, come specificato nella Sezione 2.1.
La Sezione 4.3 definisce la mutabilità dei campi rimanenti nel SRH (Flags, Tag, Segment List) nel contesto del SID definito in questo documento.
I nuovi SID definiti in futuro DEVONO specificare le proprietà di mutabilità dei Flags, Tag e Segment List e indicare come funziona la verifica del Hashed Message Authentication Code (codice di autenticazione dei messaggi con hash, HMAC) TLV (Sezione 2.1.2). Si noti che, in effetti, questi campi sono mutabili.
Coerentemente con il modello SR, la sorgente del SRH sa sempre come impostare la Segment List, i Flags, il Tag e i TLV del SRH per l'uso all'interno del dominio SR. Come ci riesce è al di fuori dell'ambito di questo documento ma può essere basato sulla topologia, sui SID disponibili e le loro proprietà di mutabilità, sui requisiti di mutabilità del SRH della destinazione, o qualsiasi altra informazione.
2.1. SRH TLVs
Questa sezione definisce i TLV del Segment Routing Header.
Un TLV fornisce metadati per l'elaborazione dei segmenti. Gli unici TLV definiti in questo documento sono il HMAC (Sezione 2.1.2) e i TLV di padding (Sezione 2.1.1). Durante l'elaborazione del SID definito nella Sezione 4.3.1, tutti i TLV sono ignorati a meno che la configurazione locale non indichi diversamente (Sezione 4.3.1.1.1). Pertanto, il supporto TLV e HMAC è opzionale per qualsiasi implementazione; tuttavia, un'implementazione che aggiunge o analizza TLV DEVE supportare i TLV PAD. Altri documenti possono definire TLV aggiuntivi e regole di elaborazione per essi.
I TLV sono presenti quando il Hdr Ext Len è maggiore di (Last Entry+1)*2.
Durante l'elaborazione dei TLV a un endpoint di segmento, i TLV DEVONO essere completamente contenuti all'interno del SRH come determinato dal Hdr Ext Len. Il rilevamento di TLV che superano il limite del SRH Hdr Ext Len comporta un messaggio ICMP Parameter Problem (problema di parametro), Code 0, all'indirizzo sorgente, puntando al campo Hdr Ext Len del SRH, e il pacchetto viene scartato.
Un'implementazione PUÒ limitare il numero e/o la lunghezza dei TLV che elabora in base alla configurazione locale. PUÒ limitare:
-
il numero di opzioni Pad1 (Sezione 2.1.1.1) consecutive a 1. Se è richiesto un padding di più di un byte, allora dovrebbe essere utilizzato PadN (Sezione 2.1.1.2).
-
La lunghezza in PadN a 5.
-
Il numero massimo di TLV non-Pad da elaborare.
-
La lunghezza massima di tutti i TLV da elaborare.
L'implementazione PUÒ interrompere l'elaborazione di TLV aggiuntivi nel SRH quando questi limiti configurati vengono superati.
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 a 8 bit da "Segment Routing Header TLVs" [IANA-SRHTLV]. I tipi non riconosciuti DEVONO essere ignorati alla ricezione.
Length: La lunghezza del campo dati a lunghezza variabile in byte.
Variable-length data: dati specifici del Type.
Le voci Type Length Value (TLV) contengono informazioni OPZIONALI che possono essere utilizzate dal nodo identificato nell'indirizzo di destinazione (DA) del pacchetto.
Ogni TLV ha la propria lunghezza, formato e semantica. Il codepoint allocato (da IANA) a ciascun Type TLV definisce sia il formato che la semantica delle informazioni trasportate nel TLV. Più TLV possono essere codificati nello stesso SRH.
Il bit più significativo del tipo TLV (bit 0) specifica se i dati TLV di quel tipo possono cambiare durante il percorso verso la destinazione finale del pacchetto:
0: I dati TLV non cambiano durante il percorso
1: I dati TLV cambiano durante il percorso
Tutti i TLV specificano i loro requisiti di allineamento utilizzando un formato xn+y. Il formato xn+y è definito secondo [RFC8200]. I nodi sorgente SR utilizzano i requisiti di allineamento xn+y dei TLV e dei TLV di padding durante la costruzione di un SRH.
Il campo Length del TLV viene utilizzato per saltare il TLV durante l'ispezione del SRH nel caso in cui il nodo non supporti o non riconosca il Type. La Length definisce la lunghezza del TLV in ottetti, senza includere i campi Type e Length.
I seguenti TLV sono definiti in questo documento:
Padding TLVs (TLV di padding)
HMAC TLV
TLV aggiuntivi possono essere definiti in futuro.