RFC 4379 - 3. Packet Format
3. Formato dei pacchetti (Packet Format)
Questa sezione definisce i tipi di messaggio, le modalità di risposta, i codici di ritorno e i TLV utilizzati dai messaggi MPLS echo.
Un MPLS echo request è un pacchetto UDP IPv4 o IPv6 (eventualmente con etichette); il contenuto del pacchetto UDP ha il formato seguente:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Il Version Number è attualmente 1. (Nota: il numero di versione deve essere incrementato ogni volta che viene apportata una modifica che incide sulla capacità di un'implementazione di analizzare o elaborare correttamente un MPLS echo request/reply. Tali modifiche comprendono qualsiasi cambiamento sintattico o semantico apportato a uno qualsiasi dei campi fissi, oppure all'assegnazione o al formato di un qualsiasi Type-Length-Value (TLV) o sub-TLV definito a un certo numero di versione. Il numero di versione potrebbe non dover essere modificato se viene aggiunto un TLV o sub-TLV opzionale.)
Il campo Global Flags è un vettore di bit con il formato seguente:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Per ora è definito un solo flag, il bit V; gli altri bit devono essere posti a zero durante l'invio e ignorati alla ricezione (MUST).
Il flag V (Validate FEC Stack) è posto a 1 se il mittente vuole che il destinatario esegua la verifica della pila FEC (FEC Stack validation); se V è 0, la scelta è lasciata al destinatario.
Il Message Type è uno dei seguenti:
| Valore | Significato |
|---|---|
| 1 | MPLS echo request (richiesta echo MPLS) |
| 2 | MPLS echo reply (risposta echo MPLS) |
Il Reply Mode può assumere uno dei valori seguenti:
| Valore | Significato |
|---|---|
| 1 | Do not reply (non rispondere) |
| 2 | Reply via an IPv4/IPv6 UDP packet (rispondere con un pacchetto UDP IPv4/IPv6) |
| 3 | Reply via an IPv4/IPv6 UDP packet with Router Alert (rispondere con un pacchetto UDP IPv4/IPv6 con Router Alert) |
| 4 | Reply via application level control channel (rispondere tramite un canale di controllo a livello di applicazione) |
Un MPLS echo request con 1 (non rispondere) nel campo Reply Mode può essere usato per test di connettività unidirezionale; il router ricevente può registrare le lacune nei Sequence Number e/o mantenere statistiche di ritardo e jitter. Un MPLS echo request avrà normalmente 2 (rispondere con un pacchetto UDP IPv4/IPv6) nel campo Reply Mode. Se il normale percorso di ritorno IP è ritenuto inaffidabile, si può usare 3 (rispondere con un pacchetto UDP IPv4/IPv6 con Router Alert). Si noti che ciò richiede che tutti i router intermedi comprendano gli MPLS echo reply e sappiano come inoltrarli. L'echo reply usa lo stesso numero di versione IP dell'echo request ricevuto, cioè un echo reply incapsulato in IPv4 viene inviato in risposta a un echo request incapsulato in IPv4.
Alcune applicazioni supportano un canale di controllo IP. Un esempio è il canale di controllo associato (associated control channel) definito in Virtual Circuit Connectivity Verification (VCCV) [VCCV]. Qualsiasi applicazione che supporti un canale di controllo IP tra le proprie entità di controllo può impostare il Reply Mode a 4 (rispondere tramite un canale di controllo a livello di applicazione) per garantire che le risposte usino lo stesso canale. Un'ulteriore definizione di questo codepoint è specifica dell'applicazione e quindi al di fuori dello scopo di questo documento.
I codici e i sottocodici di ritorno sono descritti nella sezione successiva.
Il Sender's Handle è compilato dal mittente e restituito invariato dal destinatario nell'echo reply (se presente). Non vi è alcuna semantica associata a questo handle, sebbene un mittente possa trovarlo utile per associare le richieste alle risposte.
Il Sequence Number è assegnato dal mittente dell'MPLS echo request e può essere usato (per esempio) per rilevare le risposte mancanti.
Il TimeStamp Sent è l'ora del giorno (in secondi e microsecondi, secondo l'orologio del mittente) in formato NTP [NTP] in cui viene inviato l'MPLS echo request. Il TimeStamp Received in un echo reply è l'ora del giorno (secondo l'orologio del destinatario) in formato NTP in cui è stato ricevuto il corrispondente echo request.
I TLV (tuple Type-Length-Value) hanno il formato seguente:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I tipi sono definiti di seguito; Length è la lunghezza del campo Value in ottetti. Il campo Value dipende dal Type; viene riempito con zeri per allinearlo a un confine di 4 ottetti. I TLV possono essere annidati all'interno di altri TLV, nel qual caso i TLV annidati sono chiamati sub-TLV. I sub-TLV hanno tipi indipendenti e devono anch'essi essere allineati a 4 ottetti (MUST).
Seguono due esempi. Il sub-TLV LDP IPv4 FEC del Label Distribution Protocol (LDP) ha il formato seguente:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La Length di questo TLV è 5. Un TLV pila FEC di destinazione che contiene un sub-TLV LDP IPv4 FEC e un sub-TLV prefisso IPv4 VPN ha il formato seguente:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (FEC TLV) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Di seguito è riportata una descrizione dei tipi e dei valori (Types and Values) dei TLV di primo livello per LSP ping:
| Tipo n. (Type #) | Campo valore (Value Field) |
|---|---|
| 1 | Target FEC Stack (pila FEC di destinazione) |
| 2 | Downstream Mapping (mappatura a valle) |
| 3 | Pad (riempimento) |
| 4 | Not Assigned (non assegnato) |
| 5 | Vendor Enterprise Number (numero enterprise del fornitore) |
| 6 | Not Assigned (non assegnato) |
| 7 | Interface and Label Stack (pila interfaccia ed etichette) |
| 8 | Not Assigned (non assegnato) |
| 9 | Errored TLVs (TLV errati) |
| 10 | Reply TOS Byte (byte TOS di risposta) |
I tipi inferiori a 32768 (cioè con il bit di ordine superiore uguale a 0) sono TLV obbligatori (mandatory) che devono essere supportati da un'implementazione oppure comportare l'invio, nella risposta echo, del codice di ritorno 2 ("uno o più dei TLV non sono stati compresi") (MUST).
I tipi maggiori o uguali a 32768 (cioè con il bit di ordine superiore uguale a 1) sono TLV opzionali (optional) che dovrebbero essere ignorati se l'implementazione non li comprende o non li supporta (SHOULD).
3.1. Codici di ritorno (Return Codes)
Il codice di ritorno è impostato a zero dal mittente. Il destinatario può impostarlo a uno dei valori elencati di seguito. La notazione
| Valore | Significato |
|---|---|
| 0 | No return code (Nessun codice di ritorno) |
| 1 | Malformed echo request received (Ricevuto un echo request malformato) |
| 2 | One or more of the TLVs was not understood (Uno o più TLV non sono stati compresi) |
| 3 | Replying router is an egress for the FEC at stack-depth |
| 4 | Replying router has no mapping for the FEC at stack-depth |
| 5 | Downstream Mapping Mismatch (Mancata corrispondenza della mappatura a valle) (vedere la Nota 1) |
| 6 | Upstream Interface Index Unknown (Indice di interfaccia a monte sconosciuto) (vedere la Nota 1) |
| 7 | Reserved (Riservato) |
| 8 | Label switched at stack-depth |
| 9 | Label switched but no MPLS forwarding at stack-depth |
| 10 | Mapping for this FEC is not the given label at stack-depth |
| 11 | No label entry at stack-depth |
| 12 | Protocol not associated with interface at FEC stack-depth |
| 13 | Premature termination of ping due to label stack shrinking to a single label (Terminazione anticipata del ping per la riduzione della pila di etichette a una sola etichetta) |
Nota 1
Il sottocodice di ritorno contiene il punto della pila di etichette in cui l'elaborazione è stata terminata. Se l'RSC è 0, nessuna etichetta è stata elaborata. In caso contrario, il pacchetto sarebbe stato commutato su etichetta alla profondità RSC.
3.2. Pila FEC di destinazione (Target FEC Stack)
Una pila FEC di destinazione (Target FEC Stack) è una lista di sub-TLV. Il numero di elementi si determina esaminando i campi di lunghezza (Length) dei sub-TLV.
| Sottotipo (Sub-Type) | Lunghezza (Length) | Campo valore (Value Field) |
|---|---|---|
| 1 | 5 | LDP IPv4 prefix (prefisso IPv4 LDP) |
| 2 | 17 | LDP IPv6 prefix (prefisso IPv6 LDP) |
| 3 | 20 | RSVP IPv4 LSP (LSP IPv4 RSVP) |
| 4 | 56 | RSVP IPv6 LSP (LSP IPv6 RSVP) |
| 5 | Not Assigned (non assegnato) | |
| 6 | 13 | VPN IPv4 prefix (prefisso IPv4 VPN) |
| 7 | 25 | VPN IPv6 prefix (prefisso IPv6 VPN) |
| 8 | 14 | L2 VPN endpoint (endpoint L2 VPN) |
| 9 | 10 | "FEC 128" Pseudowire ("FEC 128" pseudowire, deprecato) |
| 10 | 14 | "FEC 128" Pseudowire ("FEC 128" pseudowire) |
| 11 | 16+ | "FEC 129" Pseudowire ("FEC 129" pseudowire) |
| 12 | 5 | BGP labeled IPv4 prefix (prefisso IPv4 con etichetta BGP) |
| 13 | 17 | BGP labeled IPv6 prefix (prefisso IPv6 con etichetta BGP) |
| 14 | 5 | Generic IPv4 prefix (prefisso IPv4 generico) |
| 15 | 17 | Generic IPv6 prefix (prefisso IPv6 generico) |
| 16 | 4 | Nil FEC (Nil FEC) |
Altri tipi di FEC saranno definiti secondo necessità.
Si noti che questo TLV definisce una pila di FEC: il primo elemento FEC corrisponde alla cima (top) della pila di etichette, e così via.
Un MPLS echo request deve avere una pila FEC di destinazione che descrive la pila FEC in prova (MUST). Per esempio, se un LSR X ha una mappatura LDP [LDP] per 192.168.1.1 (per esempio l'etichetta 1001), per verificare che l'etichetta 1001 raggiunga effettivamente un LSR di uscita che ha annunciato questo prefisso tramite LDP, X può inviare un MPLS echo request con un TLV di pila FEC contenente un solo FEC, di tipo LDP IPv4 prefix, con prefisso 192.168.1.1/32, e inviare l'echo request con l'etichetta 1001.
Supponiamo ora che l'LSR X voglia verificare che la pila di etichette <1001, 23456> sia la pila di etichette corretta da usare per raggiungere un prefisso IPv4 VPN (vedere la sezione 3.2.5) 10/8 nella VPN foo. Supponiamo inoltre che l'LSR Y, con indirizzo di loopback 192.168.1.1, abbia annunciato il prefisso 10/8 con Route Distinguisher RD-foo-Y (che in generale può essere diverso dal Route Distinguisher che l'LSR X usa nei propri annunci per la VPN foo), etichetta 23456 e next hop BGP 192.168.1.1 [BGP]. Supponiamo infine che l'LSR X riceva via LDP un binding di etichetta 1001 per 192.168.1.1. X ha due possibilità nell'inviare un MPLS echo request: X può inviare un MPLS echo request con un TLV di pila FEC contenente un solo FEC di tipo VPN IPv4 prefix, con prefisso 10/8 e Route Distinguisher RD-foo-Y. In alternativa, X può inviare un TLV di pila FEC con due FEC: il primo di tipo LDP IPv4 con prefisso 192.168.1.1/32, il secondo di tipo IP VPN con prefisso 10/8 e Route Distinguisher RD-foo-Y. In entrambi i casi, l'MPLS echo request avrebbe una pila di etichette <1001, 23456>. (Nota: in questo esempio, 1001 è l'etichetta "esterna" e 23456 è l'etichetta "interna".)
3.2.1. Prefisso IPv4 LDP (LDP IPv4 Prefix)
Il FEC prefisso IPv4 è definito in [LDP]. Quando un prefisso IPv4 LDP viene codificato in una pila di etichette, si usa il formato seguente. Il valore è composto da 4 ottetti di prefisso IPv4 seguiti da 1 ottetto di lunghezza del prefisso in bit; il formato è riportato di seguito. Il prefisso IPv4 è in ordine di byte di rete; se il prefisso è più corto di 32 bit, i bit finali dovrebbero essere posti a zero (SHOULD). Per un esempio di mappatura per un FEC IPv4, vedere [LDP].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.2. Prefisso IPv6 LDP (LDP IPv6 Prefix)
Il FEC prefisso IPv6 è definito in [LDP]. Quando un prefisso IPv6 LDP viene codificato in una pila di etichette, si usa il formato seguente. Il valore è composto da 16 ottetti di prefisso IPv6 seguiti da 1 ottetto di lunghezza del prefisso in bit; il formato è riportato di seguito. Il prefisso IPv6 è in ordine di byte di rete; se il prefisso è più corto di 128 bit, i bit finali dovrebbero essere posti a zero (SHOULD). Per un esempio di mappatura per un FEC IPv6, vedere [LDP].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3. LSP IPv4 RSVP (RSVP IPv4 LSP)
Il valore ha il formato riportato di seguito. I campi valore sono tratti dalla RFC 3209, sezioni 4.6.1.1 e 4.6.2.1. Vedere [RSVP-TE].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.4. LSP IPv6 RSVP (RSVP IPv6 LSP)
Il valore ha il formato riportato di seguito. I campi valore sono tratti dalla RFC 3209, sezioni 4.6.1.2 e 4.6.2.2. Vedere [RSVP-TE].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.5. Prefisso IPv4 VPN (VPN IPv4 Prefix)
Le informazioni di instradamento del livello di rete VPN-IPv4 (NLRI) sono definite in [RFC4365]. Questo documento usa il termine VPN IPv4 prefix per un NLRI VPN-IPv4 che è stato annunciato con un'etichetta MPLS in BGP. Vedere [BGP-LABEL].
Quando un prefisso IPv4 VPN viene codificato in una pila di etichette, si usa il formato seguente. Il campo valore è composto dal Route Distinguisher annunciato con il prefisso IPv4 VPN, dal prefisso IPv4 (con bit finali a 0 per arrivare in tutto a 32 bit) e da una lunghezza del prefisso, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Il Route Distinguisher (RD) è un identificatore di 8 ottetti; non contiene alcuna informazione intrinseca. Lo scopo dell'RD è unicamente quello di permettere di creare rotte distinte verso un prefisso di indirizzo IPv4 comune. La codifica dell'RD non è importante in questa sede. Quando si confronta questo campo con le informazioni FEC locali, esso viene trattato come un valore opaco.
3.2.6. Prefisso IPv6 VPN (VPN IPv6 Prefix)
Le informazioni di instradamento del livello di rete VPN-IPv6 (NLRI) sono definite in [RFC4365]. Questo documento usa il termine VPN IPv6 prefix per un NLRI VPN-IPv6 che è stato annunciato con un'etichetta MPLS in BGP. Vedere [BGP-LABEL].
Quando un prefisso IPv6 VPN viene codificato in una pila di etichette, si usa il formato seguente. Il campo valore è composto dal Route Distinguisher annunciato con il prefisso IPv6 VPN, dal prefisso IPv6 (con bit finali a 0 per arrivare in tutto a 128 bit) e da una lunghezza del prefisso, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Il Route Distinguisher è identico all'RD del prefisso IPv4 VPN, salvo che qui esso serve a permettere la creazione di rotte distinte verso prefissi IPv6. Vedere la sezione 3.2.5. Quando si confronta questo campo con le informazioni FEC locali, esso viene trattato come un valore opaco.
3.2.7. Endpoint L2 VPN (L2 VPN Endpoint)
VPLS sta per Virtual Private LAN Service. I termini VPLS BGP NLRI e VE ID (VPLS Edge Identifier) sono definiti in [VPLS-BGP]. Questo documento usa il termine più semplice L2 VPN endpoint per riferirsi a un NLRI VPLS BGP. Il Route Distinguisher è un identificatore di 8 ottetti usato per distinguere le informazioni sulle varie L2 VPN annunciate da un nodo. Il VE ID è un identificatore di 2 ottetti usato per identificare un particolare nodo che funge da punto di attacco del servizio all'interno di una VPLS. La struttura di questi due identificatori non è importante in questa sede; quando si confrontano questi campi con le informazioni FEC locali, essi vengono trattati come valori opachi. Il tipo di incapsulamento è identico al PW Type della sezione 3.2.8 seguente.
Quando un endpoint L2 VPN viene codificato in una pila di etichette, si usa il formato seguente. Il campo valore è composto da un Route Distinguisher (8 ottetti), dal VE ID del mittente (del ping) (2 ottetti), dal VE ID del destinatario (2 ottetti) e da un tipo di incapsulamento (2 ottetti), formattati 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.8. Pseudowire FEC 128 (deprecato) (FEC 128 Pseudowire (Deprecated))
FEC 128 (0x80) è definito in [PW-CONTROL], come pure i termini PW ID (Pseudowire ID) e PW Type (Pseudowire Type). Un PW ID è un identificatore di connessione di 32 bit non nullo. Il PW Type è un numero di 15 bit che indica il tipo di incapsulamento. Esso è trasportato allineato a destra nel campo denominato qui sotto tipo di incapsulamento (encapsulation type), con il bit di ordine superiore posto a zero. Entrambi questi campi sono trattati in questo protocollo come valori opachi.
Quando un FEC 128 viene codificato in una pila di etichette, si usa il formato seguente. Il campo valore è composto dall'indirizzo del PE remoto (l'indirizzo di destinazione della sessione LDP mirata), dal PW ID e dal tipo di incapsulamento, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Questo FEC è deprecato ed è mantenuto solo per compatibilità all'indietro. Le implementazioni di LSP ping dovrebbero accettare ed elaborare questo TLV (SHOULD), ma dovrebbero inviare le richieste echo di LSP ping con il nuovo TLV (vedere la sezione successiva), a meno che non siano configurate esplicitamente per usare il vecchio TLV (SHOULD).
Un LSR che riceve questo TLV dovrebbe usare l'indirizzo IP di origine dell'LSP echo request per dedurre l'indirizzo del PE del mittente (SHOULD).
3.2.9. Pseudowire FEC 128 (corrente) (FEC 128 Pseudowire (Current))
FEC 128 (0x80) è definito in [PW-CONTROL], come pure i termini PW ID (Pseudowire ID) e PW Type (Pseudowire Type). Un PW ID è un identificatore di connessione di 32 bit non nullo. Il PW Type è un numero di 15 bit che indica il tipo di incapsulamento. Esso è trasportato allineato a destra nel campo denominato qui sotto tipo di incapsulamento (encapsulation type), con il bit di ordine superiore posto a zero.
Entrambi questi campi sono trattati in questo protocollo come valori opachi. Nel confrontare questi campi con le informazioni FEC locali, la corrispondenza deve essere esatta (MUST).
Quando un FEC 128 viene codificato in una pila di etichette, si usa il formato seguente. Il campo valore è composto dall'indirizzo del PE del mittente (l'indirizzo di origine della sessione LDP mirata), dall'indirizzo del PE remoto (l'indirizzo di destinazione della sessione LDP mirata), dal PW ID e dal tipo di incapsulamento, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10. Pseudowire FEC 129 (FEC 129 Pseudowire)
FEC 129 (0x81) e i termini PW Type, Attachment Group Identifier (AGI), Attachment Group Identifier Type (AGI Type), Attachment Individual Identifier Type (AII Type), Source Attachment Individual Identifier (SAII) e Target Attachment Individual Identifier (TAII) sono definiti in [PW-CONTROL]. Il PW Type è un numero di 15 bit che indica il tipo di incapsulamento. Esso è trasportato allineato a destra nel campo PW Type riportato di seguito, con il bit di ordine superiore posto a zero. Tutti gli altri campi sono trattati come valori opachi e copiati direttamente dal formato FEC 129. Tutti questi valori insieme definiscono in modo univoco il FEC nell'ambito della sessione LDP identificata dagli indirizzi del PE di origine e del PE remoto.
Quando un FEC 129 viene codificato in una pila di etichette, si usa il formato seguente. La Length di questo TLV è 16 + lunghezza AGI + lunghezza SAII + lunghezza TAII. Si usa il riempimento (padding) per rendere la lunghezza totale un multiplo di 4; la lunghezza del riempimento non è inclusa nel campo Length.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.11. Prefisso IPv4 con etichetta BGP (BGP Labeled IPv4 Prefix)
I prefissi IPv4 con etichetta BGP sono definiti in [BGP-LABEL]. Quando un prefisso IPv4 con etichetta BGP viene codificato in una pila di etichette, si usa il formato seguente. Il campo valore è composto dal prefisso IPv4 (con bit finali a 0 per arrivare in tutto a 32 bit) e dalla lunghezza del prefisso, come segue.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.12. Prefisso IPv6 con etichetta BGP (BGP Labeled IPv6 Prefix)
I prefissi IPv6 con etichetta BGP sono definiti in [BGP-LABEL]. Quando un prefisso IPv6 con etichetta BGP viene codificato in una pila di etichette, si usa il formato seguente. Il valore è composto da 16 ottetti di prefisso IPv6 seguiti da 1 ottetto di lunghezza del prefisso in bit; il formato è riportato di seguito. Il prefisso IPv6 è in ordine di byte di rete; se il prefisso è più corto di 128 bit, i bit finali dovrebbero essere posti a zero (SHOULD).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.13. Prefisso IPv4 generico (Generic IPv4 Prefix)
Il valore è composto da 4 ottetti di prefisso IPv4 seguiti da 1 ottetto di lunghezza del prefisso in bit; il formato è riportato di seguito. Il prefisso IPv4 è in ordine di byte di rete; se il prefisso è più corto di 32 bit, i bit finali dovrebbero essere posti a zero (SHOULD). Questo FEC si usa quando il protocollo che annuncia l'etichetta è sconosciuto o può cambiare nel corso dell'LSP. Un esempio è un LSP inter-AS che può essere segnalato da LDP in un sistema autonomo (AS), da RSVP-TE [RSVP-TE] in un altro AS e da BGP tra gli AS, come è comune per le VPN inter-AS.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.14. Prefisso IPv6 generico (Generic IPv6 Prefix)
Il valore è composto da 16 ottetti di prefisso IPv6 seguiti da 1 ottetto di lunghezza del prefisso in bit; il formato è riportato di seguito. Il prefisso IPv6 è in ordine di byte di rete; se il prefisso è più corto di 128 bit, i bit finali dovrebbero essere posti a zero (SHOULD).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.15. Nil FEC (Nil FEC)
Talvolta etichette dell'intervallo riservato, come Router Alert ed Explicit-null, possono essere aggiunte alla pila di etichette per varie finalità diagnostiche, quali influenzare il bilanciamento del carico. Queste etichette possono non avere alcun FEC esplicitamente associato. La pila Nil FEC è definita per permettere di aggiungere alla pila FEC di destinazione un sub-TLV che tenga conto di tali etichette, così che si possa comunque eseguire una validazione corretta.
La Length è 4. Le etichette sono valori di 20 bit trattati come numeri.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label è il valore effettivo dell'etichetta inserita nella pila di etichette; i campi MBZ devono essere zero all'invio (MUST) e sono ignorati alla ricezione.
3.3. Mappatura a valle (Downstream Mapping)
L'oggetto mappatura a valle (Downstream Mapping) è un TLV che può essere incluso in un messaggio echo request (MAY). In un echo request può comparire un solo oggetto mappatura a valle. La presenza di un oggetto mappatura a valle è una richiesta che oggetti mappatura a valle siano inclusi nell'echo reply. Se il router che risponde è la destinazione del FEC, allora un TLV mappatura a valle non dovrebbe essere incluso nell'echo reply (SHOULD NOT). In caso contrario, il router che risponde dovrebbe includere un oggetto mappatura a valle per ogni interfaccia sulla quale questo FEC potrebbe essere inoltrato (SHOULD). Per una definizione più precisa della nozione di "a valle", vedere la sezione 3.3.2, "Router e interfaccia a valle (Downstream Router and Interface)".
La Length è K + M + 4*N ottetti, dove M è la lunghezza multipath (Multipath Length) e N è il numero di etichette a valle (Downstream Label). I valori di K si trovano nella descrizione del tipo di indirizzo (Address Type) riportata di seguito. Il campo Value di una mappatura a valle ha il formato seguente.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unità massima di trasmissione (Maximum Transmission Unit, MTU)
L'MTU è la dimensione in ottetti del più grande frame MPLS (pila di etichette inclusa) che entra nell'interfaccia verso l'LSR a valle.
Tipo di indirizzo (Address Type)
Il tipo di indirizzo indica se l'interfaccia è numerata (numbered) o non numerata (unnumbered). Esso determina inoltre la lunghezza dei campi Downstream IP Address e Downstream Interface. Il totale risultante per la parte iniziale del TLV è elencato nella tabella seguente come "K Octets". Il tipo di indirizzo è impostato a uno dei valori seguenti.
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28
DS Flags (flag di downstream)
Il campo DS Flags è un vettore di bit con il formato seguente.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+
Attualmente sono definiti due flag, I e N. I flag rimanenti devono essere posti a zero all'invio (MUST) e sono ignorati alla ricezione.
| Flag | Nome e significato |
|---|---|
| I | Interface and Label Stack Object Request (richiesta dell'oggetto interfaccia e pila di etichette): quando questo flag è impostato, indica che il router che risponde dovrebbe includere un oggetto Interface and Label Stack nel messaggio echo reply (SHOULD). |
| N | Treat as a Non-IP Packet (trattare come pacchetto non IP): i messaggi echo request saranno usati per diagnosticare flussi non IP. Tuttavia, questi messaggi sono trasportati in pacchetti IP. Per un router che modifica il proprio algoritmo ECMP in base al FEC o all'esame approfondito del pacchetto, questo flag richiede che il router lo tratti come farebbe se la determinazione di un payload IP fosse fallita. |
Downstream IP Address e Downstream Interface Address
Gli indirizzi IPv4 e gli indici di interfaccia sono codificati su 4 ottetti; gli indirizzi IPv6 sono codificati su 16 ottetti.
Se l'interfaccia verso l'LSR a valle è numerata, il tipo di indirizzo deve essere impostato a IPv4 o IPv6 (MUST), il Downstream IP Address deve essere impostato al Router ID dell'LSR a valle oppure all'indirizzo dell'interfaccia dell'LSR a valle (MUST) e il Downstream Interface Address deve essere impostato all'indirizzo dell'interfaccia dell'LSR a valle (MUST).
Se l'interfaccia verso l'LSR a valle è non numerata, il tipo di indirizzo deve essere IPv4 Unnumbered o IPv6 Unnumbered (MUST), il Downstream IP Address deve essere il Router ID dell'LSR a valle (MUST) e il Downstream Interface Address deve essere impostato all'indice assegnato dall'LSR a monte all'interfaccia (MUST).
Se un LSR non conosce l'indirizzo IP del proprio vicino, deve impostare il tipo di indirizzo a IPv4 Unnumbered o IPv6 Unnumbered (MUST). Per IPv4, deve impostare il Downstream IP Address a 127.0.0.1; per IPv6 l'indirizzo è impostato a 0::1. In entrambi i casi, l'indice di interfaccia deve essere impostato a 0 (MUST). Se un LSR riceve un pacchetto Echo Request con uno di questi indirizzi nel campo Downstream IP Address, ciò indica che deve saltare la verifica dell'interfaccia (MUST) ma proseguire con la validazione delle etichette.
Se l'originatore di un pacchetto Echo Request desidera ottenere informazioni di mappatura a valle ma non conosce la pila di etichette attesa, dovrebbe impostare il tipo di indirizzo a IPv4 Unnumbered o IPv6 Unnumbered (SHOULD). Per IPv4, deve impostare il Downstream IP Address a 224.0.0.2 (MUST); per IPv6 l'indirizzo deve essere impostato a FF02::2 (MUST). In entrambi i casi, l'indice di interfaccia deve essere impostato a 0 (MUST). Se un LSR riceve un pacchetto Echo Request con l'indirizzo multicast all-routers, ciò indica che deve saltare sia la validazione dell'interfaccia sia quella della pila di etichette (MUST), ma restituire i TLV di mappatura a valle usando le informazioni fornite.
Tipo di multipath (Multipath Type)
Sono definiti i seguenti tipi di multipath.
| Chiave | Tipo | Informazioni multipath |
|---|---|---|
| 0 | no multipath (nessun multipath) | Vuoto (Multipath Length = 0) |
| 2 | IP address (indirizzo IP) | Indirizzi IP |
| 4 | IP address range (intervallo di indirizzi IP) | Coppie di indirizzi basso/alto |
| 8 | Bit-masked IP address set (insieme di indirizzi IP con maschera di bit) | Prefisso di indirizzo IP e maschera di bit |
| 9 | Bit-masked label set (insieme di etichette con maschera di bit) | Prefisso di etichetta e maschera di bit |
Il tipo 0 indica che tutti i pacchetti saranno inoltrati da questa unica interfaccia.
I tipi 2, 4, 8 e 9 specificano che le informazioni multipath fornite serviranno a esercitare (exercise) questo percorso.
Limite di profondità (Depth Limit)
Il limite di profondità si applica solo a una pila di etichette ed è il numero massimo di etichette considerate nell'hash; dovrebbe essere posto a zero se non specificato o illimitato (SHOULD).
Lunghezza multipath (Multipath Length)
La lunghezza in ottetti delle informazioni multipath.
Informazioni multipath (Multipath Information)
Valori di indirizzo o di etichetta codificati secondo il tipo di multipath. Per i dettagli di codifica vedere la sezione successiva.
Etichette a valle (Downstream Label(s))
L'insieme di etichette nella pila di etichette così come sarebbe apparso se questo router avesse inoltrato il pacchetto attraverso questa interfaccia. Le eventuali etichette Implicit Null sono esplicitamente incluse. Le etichette sono trattate come numeri, cioè sono allineate a destra nel campo.
Una etichetta a valle (Downstream Label) è di 24 bit, nello stesso formato di un'etichetta MPLS meno il campo TTL, cioè il MSBit dell'etichetta è il bit 0, il LSBit è il bit 19, i bit EXP sono i bit 20-22 e il bit 23 è il bit S. Il router che risponde dovrebbe riempire i bit EXP e S (SHOULD); l'LSR che riceve l'echo reply può scegliere di ignorare questi bit (MAY).
Protocollo (Protocol)
Il protocollo è tratto dalla tabella seguente.
| Protocol # | Protocollo di segnalazione |
|---|---|
| 0 | Unknown (sconosciuto) |
| 1 | Static (statico) |
| 2 | BGP |
| 3 | LDP |
| 4 | RSVP-TE |
3.3.1. Codifica delle informazioni multipath (Multipath Information Encoding)
Le informazioni multipath (Multipath Information) codificano le etichette o gli indirizzi che eserciteranno questo percorso. Le informazioni multipath dipendono dal tipo di multipath. Il contenuto del campo è mostrato nella tabella precedente. Gli indirizzi IPv4 sono presi dall'intervallo 127/8; gli indirizzi IPv6 sono presi dall'intervallo 0:0:0:0:0:FFFF:127/104. Le etichette sono trattate come numeri, cioè sono allineate a destra nel campo. Per il tipo 4, gli intervalli indicati dalle coppie di indirizzi non devono sovrapporsi (MUST NOT) e devono essere in sequenza crescente (MUST).
Il tipo 8 permette una codifica più densa degli indirizzi IP. Il prefisso IP è formattato come un indirizzo IP di base con i bit di ordine inferiore non appartenenti al prefisso posti a zero. La lunghezza massima del prefisso è 27. Al prefisso segue una maschera di lunghezza 2^(32-lunghezza del prefisso) bit per IPv4 e 2^(128-lunghezza del prefisso) bit per IPv6. Ogni bit posto a 1 rappresenta un indirizzo valido. L'indirizzo è l'indirizzo IPv4 di base più la posizione del bit nella maschera, dove i bit sono numerati da sinistra a destra a partire da zero. Per esempio, gli indirizzi IPv4 127.2.1.0, 127.2.1.5-127.2.1.15 e 127.2.1.20-127.2.1.29 sarebbero codificati 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Quegli stessi indirizzi incorporati in IPv6 sarebbero codificati 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Il tipo 9 permette una codifica più densa delle etichette. Il prefisso di etichetta è formattato come un valore di etichetta di base con i bit di ordine inferiore non appartenenti al prefisso posti a zero. La lunghezza massima del prefisso (compresi gli zeri iniziali dovuti alla codifica) è 27. Al prefisso segue una maschera di lunghezza 2^(32-lunghezza del prefisso) bit. Ogni bit posto a uno rappresenta un'etichetta valida. L'etichetta è quella di base più la posizione del bit nella maschera, dove i bit sono numerati da sinistra a destra a partire da zero. I valori di etichetta di tutti i numeri dispari tra 1152 e 1279 sarebbero codificati 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 +-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nota: nell'originale inglese (RFC 4379) la bitmap di questo esempio è spezzata in corrispondenza di un a capo di composizione tipografica. Qui è riprodotta letteralmente come nell'originale inglese. Il suo significato è che la parte iniziale è il prefisso dell'etichetta di base 1152 (= 0b10010000000) e la parte successiva è la maschera delle etichette dispari con bit alternati.
Se le informazioni multipath ricevute non sono nulle, le etichette e gli indirizzi IP devono essere scelti dall'insieme fornito (MUST). Se nessuna di queste etichette o indirizzi corrisponde a una particolare interfaccia a valle, allora per quell'interfaccia il tipo deve essere posto a 0 (MUST). Se le informazioni multipath ricevute sono nulle (cioè Multipath Length = 0, oppure, per i tipi 8 e 9, una maschera di tutti zeri), il tipo deve essere posto a 0 (MUST).
Per esempio, si supponga che l'LSR X all'hop 10 abbia due LSR a valle, Y e Z, per il FEC in questione. L'X che riceve potrebbe restituire il tipo di multipath 4, con indirizzi IP basso/alto 127.1.1.1->127.1.1.255 per l'LSR a valle Y e 127.2.1.1->127.2.1.255 per l'LSR a valle Z. L'head end riflette questa informazione all'LSR Y. Y, che ha tre LSR a valle, U, V e W, calcola che 127.1.1.1->127.1.1.127 andrebbe a U e 127.1.1.128->127.1.1.255 andrebbe a V. Y risponderebbe quindi con 3 mappature a valle: verso U, con tipo di multipath 4 (127.1.1.1->127.1.1.127); verso V, con tipo di multipath 4 (127.1.1.127->127.1.1.255); e verso W, con tipo di multipath 0.
Si noti che calcolare le informazioni multipath può imporre un carico di elaborazione significativo al destinatario. Un destinatario può quindi scegliere di elaborare un sottoinsieme dei prefissi ricevuti (MAY). Il mittente, nel ricevere una risposta a una mappatura a valle con informazioni parziali, dovrebbe presumere che i prefissi mancanti nella risposta siano stati saltati dal destinatario (SHOULD) e può richiedere nuovamente informazioni su di essi in un nuovo echo request (MAY).
3.3.2. Router e interfaccia a valle (Downstream Router and Interface)
La nozione di "router a valle" e di "interfaccia a valle" merita una spiegazione. Si consideri un LSR X. Se un pacchetto originato con TTL n>1 arrivasse all'LSR X con etichetta più esterna L e TTL=1, X deve essere in grado di calcolare quali LSR potrebbero ricevere il pacchetto se fosse originato con TTL=n+1, su quale interfaccia la richiesta arriverebbe e quale pila di etichette vedrebbero quegli LSR. (Stabilire come si effettui questo calcolo è al di fuori dello scopo di questo documento.) L'insieme di questi LSR/interfacce costituisce i router/interfacce a valle (e le relative etichette) per X rispetto a L. Ogni coppia di router e interfaccia a valle richiede l'aggiunta di una mappatura a valle separata nella risposta.
Il caso in cui X è l'LSR che origina l'echo request è un caso speciale. X deve stabilire quali LSR riceverebbero l'MPLS echo request per una data pila FEC che X origina con TTL=1.
L'insieme dei router a valle in X può essere costituito da percorsi alternativi (vedere la discussione su ECMP più sotto) o da percorsi simultanei (per esempio per il multicast MPLS). Nel primo caso, le informazioni multipath sono usate come suggerimento al mittente su come può influenzare la scelta tra queste alternative.
3.4. TLV di riempimento (Pad TLV)
La parte valore del Pad TLV contiene un numero variabile (>= 1) di ottetti. Il primo ottetto assume i valori della tabella seguente; tutti gli altri ottetti (se presenti) sono ignorati. Il destinatario dovrebbe verificare che il TLV sia ricevuto nella sua interezza (SHOULD), ma per il resto ignora il contenuto di questo TLV, a parte il primo ottetto.
| Valore | Significato |
|---|---|
| 1 | Drop Pad TLV from reply (elimina il Pad TLV dalla risposta) |
| 2 | Copy Pad TLV to reply (copia il Pad TLV nella risposta) |
| 3-255 | Riservato per usi futuri |
3.5. Numero enterprise del fornitore (Vendor Enterprise Number)
Gli SMI Private Enterprise Numbers sono mantenuti da IANA. La Length è sempre 4; il valore è il codice enterprise privato SMI del fornitore, in ordine di ottetti di rete, che ha un'estensione privata del fornitore (Vendor Private) su uno qualsiasi dei campi della parte fissa del messaggio; in tal caso questo TLV deve essere presente (MUST). Se nessuno dei campi della parte fissa del messaggio ha estensioni private del fornitore, l'inclusione di questo TLV è opzionale (OPTIONAL). Sono stati definiti intervalli privati del fornitore per tipi di messaggio, modalità di risposta e codici di ritorno. Quando si usa uno qualsiasi di questi, il TLV numero enterprise del fornitore deve essere incluso nel messaggio (MUST).
3.6. Pila interfaccia ed etichette (Interface and Label Stack)
Il TLV Interface and Label Stack può essere incluso in un messaggio di risposta per segnalare l'interfaccia sulla quale è stato ricevuto il messaggio di richiesta e la pila di etichette che era sul pacchetto al momento della ricezione (MAY). Può comparire un solo oggetto di questo tipo. Lo scopo dell'oggetto è permettere al router a monte di ottenere le informazioni esatte di interfaccia e pila di etichette così come appaiono presso l'LSR che risponde.
La Length è K + 4*N ottetti; N è il numero di etichette nella pila di etichette. I valori di K si trovano nella descrizione del tipo di indirizzo (Address Type) riportata di seguito. Il campo Value di una mappatura a valle ha il formato seguente.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Label Stack .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tipo di indirizzo (Address Type)
Il tipo di indirizzo indica se l'interfaccia è numerata o non numerata. Esso determina inoltre la lunghezza dei campi IP Address e Interface. Il totale risultante per la parte iniziale del TLV è elencato nella tabella seguente come "K Octets". Il tipo di indirizzo è impostato a uno dei valori seguenti.
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24
IP Address e Interface
Gli indirizzi IPv4 e gli indici di interfaccia sono codificati su 4 ottetti; gli indirizzi IPv6 sono codificati su 16 ottetti.
Se l'interfaccia sulla quale è stato ricevuto il messaggio echo request è numerata, il tipo di indirizzo deve essere impostato a IPv4 o IPv6 (MUST), l'IP Address deve essere impostato al Router ID dell'LSR oppure all'indirizzo dell'interfaccia (MUST) e l'Interface deve essere impostata all'indirizzo dell'interfaccia (MUST).
Se l'interfaccia è non numerata, il tipo di indirizzo deve essere IPv4 Unnumbered o IPv6 Unnumbered (MUST), l'IP Address deve essere il Router ID dell'LSR (MUST) e l'Interface deve essere impostata all'indice assegnato all'interfaccia (MUST).
Pila di etichette (Label Stack)
La pila di etichette del messaggio echo request ricevuto. Se questo router ha modificato dei valori TTL, essi dovrebbero essere ripristinati (SHOULD).
3.7. TLV errati (Errored TLVs)
Il TLV seguente è un TLV che può essere incluso in un echo reply per informare il mittente di un echo request dei TLV obbligatori (mandatory) non supportati da un'implementazione oppure analizzati e trovati in errore (MAY).
Il campo Value contiene i TLV che non sono stati compresi, codificati come sub-TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. TLV byte TOS di risposta (Reply TOS Byte TLV)
Questo TLV può essere usato dall'originatore dell'echo request per richiedere che un echo reply sia inviato con il byte TOS dell'intestazione IP impostato al valore specificato nel TLV (MAY). Questo TLV ha lunghezza 4 con il seguente campo valore.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply-TOS Byte| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+