RFC 4379 - 4. Theory of Operation

4. Teoria di funzionamento (Theory of Operation)

Un MPLS echo request serve per testare uno specifico LSP. L'LSP testato è identificato da una "pila FEC"; ad esempio, se l'LSP è stabilito tramite LDP verso l'indirizzo IP di uscita 10.1.1.1, la pila FEC contiene un singolo elemento, il sub-TLV prefisso LDP IPv4 di valore 10.1.1.1/32. Se l'LSP testato è un LSP RSVP, la pila FEC consiste in un singolo elemento che identifica unicamente tale LSP tramite sessione RSVP e template mittente.

La pila FEC può essere più complessa. Ad esempio, si vuole testare il prefisso VPN IPv4 10.1/8 tramite un tunnel LSP LDP con uscita 10.10.1.1. Allora la pila FEC contiene due sub-TLV, in fondo il prefisso VPN IPv4, in cima il prefisso LDP IPv4. Se il tunnel sottostante (LDP) è sconosciuto o ritenuto irrilevante, la pila FEC può essere un singolo elemento contenente solo il sub-TLV prefisso VPN IPv4.

Alla ricezione di un MPLS echo request, ci si aspetta che il ricevitore verifichi che il piano di controllo e il piano dati siano entrambi integri (per la pila FEC sottoposta a ping) e che i due piani siano sincronizzati. La procedura è nella sezione 4.4.

4.1. Gestione dellEqual-Cost Multi-Path (ECMP) (Dealing with Equal-Cost Multi-Path)

Un LSP non è necessariamente un semplice tunnel punto-punto. Un singolo LSP inizia spesso in più ingressi e termina in più uscite (frequente per gli LSP LDP). Un LSP per un dato FEC può anche avere più "next hop" presso un LSR di transito. All'ingresso, possono essere scelti diversi LSP per raggiungere l'endpoint desiderato. Infine, un LSP può avere percorsi di backup, percorsi di deviazione ed altri percorsi alternativi.

I due ultimi casi prima: si suppone che l'LSR che avvia l'echo request possa forzare tale richiesta in un qualsiasi LSP desiderato, quindi la scelta di più LSP all'ingresso non è un problema. Il sondeggio dei vari percorsi di backup (generalmente non usati per l'inoltro dei dati finché l'LSP principale è attivo) non è trattato qui.

Poiché l'LSP e il percorso effettivamente presi da un dato pacchetto possono essere sconosciuti in anticipo, sarebbe utile che un MPLS echo request potesse attraversare tutti i percorsi possibili. Ma ciò, sebbene ideale, può essere poco realistico poiché l'algoritmo usato da ciascun LSR per distribuire i pacchetti su percorsi diversi può essere proprietario.

Per coprire in parte i percorsi alternativi, vi è una certa libertà nella scelta dell'indirizzo IP di destinazione e della porta UDP sorgente dell'echo request. Ciò da solo è chiaramente insufficiente; nel caso del traceroute, le informazioni di multipath del TLV di mappatura a valle offrono maggiore libertà. Uso: l'LSR di ingresso invia periodicamente messaggi MPLS traceroute per determinare se un dato LSP ha un multipath. In tal caso, ciascun hop fornisce informazioni su come pilotare i suoi percorsi a valle. L'ingresso può allora inviare MPLS echo request che attraversano tali percorsi. Se più LSR hanno ECMP, l'ingresso MAY tentare combinazioni per attraversare tutti i percorsi possibili. Ma una copertura completa può essere irrealizzabile.

4.2. Test degli LSP usati per trasportare carichi MPLS (Testing LSPs That Are Used to Carry MPLS Payloads)

Per rilevare alcune interruzioni di LSP, può essere necessario (MAY) incapsulare l'MPLS echo request con almeno un'etichetta aggiuntiva quando si testano gli LSP usati per trasportare carichi MPLS (come gli LSP che trasportano traffico L2VPN e L3VPN). Ad esempio, testare un LSP LDP o RSVP-TE inviando semplicemente un MPLS echo request può non rilevare che un router immediatamente a monte della destinazione LSP ping ha inoltrato con successo l'MPLS echo request tramite un'interfaccia non configurata per trasportare carichi MPLS, a causa del penultimate hop popping. Poiché il router ricevente non può distinguere se un pacchetto IP è stato inviato senza etichetta o con etichetta Implicit Null, inserire un'etichetta shim Nil FEC sopra l'MPLS echo request impedisce che tali pacchetti siano inoltrati tramite un'interfaccia non etichettata.

4.3. Invio di un MPLS Echo Request (Sending an MPLS Echo Request)

Un MPLS echo request è un pacchetto UDP. L'intestazione IP è impostata come segue: l'indirizzo IP sorgente è un indirizzo instradabile del mittente; l'indirizzo IP di destinazione è un indirizzo (scelto casualmente) tratto da 127/8 (IPv4) o 0:0:0:0:0:FFFF:127/104 (IPv6). L'IP TTL è 1. La porta UDP sorgente è scelta dal mittente; la porta UDP di destinazione è 3503 (assegnata dall'IANA per MPLS echo request). L'intestazione IP MUST contenere l'opzione Router Alert.

L'MPLS echo request è inviato con la pila di etichette corrispondente al FEC testato. Notare che (ad esempio) se l'instradamento normale verso il FEC in cima alla pila passa tramite un tunnel di traffic engineering [RSVP-TE], possono essere applicate ulteriori etichette. Se tutti i FEC nella pila corrispondono a etichette Implicit Null, l'MPLS echo request è considerato senza etichetta anche se un'etichetta aggiuntiva è applicata in invio.

Se l'echo request ha un'etichetta, (a seconda dell'oggetto del ping) si può impostare il TTL dell'etichetta più interna a 1 per evitare che la richiesta di ping vada troppo oltre. Esempi in cui ciò SHOULD essere fatto includono il ping di un prefisso VPN IPv4 o IPv6, di un endpoint L2 VPN o di un pseudowire. Evitare che la richiesta vada troppo oltre può anche essere ottenuto inserendo un'etichetta Router Alert sull'etichetta; ma ciò ha l'effetto collaterale indesiderato che l'MPLS echo request può prendere un percorso dati diverso da quello dei dati reali. Per l'uso di questi meccanismi nella verifica di connettività dei pseudowire, vedere [VCCV].

In modalità "ping" (verifica di connettività end-to-end), il TTL dell'etichetta più esterna è 255. In modalità "traceroute" (modalità di isolamento dei guasti), il TTL è impostato successivamente a 1, 2, ecc.

Il mittente sceglie Sender's Handle e Sequence Number. All'invio di ulteriori MPLS echo request, SHOULD incrementare Sequence Number di 1. Ma il mittente MAY inviare un gruppo di echo request con lo stesso Sequence Number per aumentare la probabilità che almeno un pacchetto con tale Sequence Number arrivi.

TimeStamp Sent è impostato all'ora di invio (secondi e microsecondi). TimeStamp Received è posto a zero.

Un MPLS echo request MUST avere un TLV FEC Stack. Inoltre, la modalità di risposta MUST essere quella desiderata; il codice e il sottocodice di ritorno sono posti a zero. In modalità "traceroute", l'echo request SHOULD contenere un TLV Downstream Mapping.

4.4. Ricezione di un MPLS Echo Request (Receiving an MPLS Echo Request)

L'invio di un MPLS echo request al piano di controllo è innescato da una delle seguenti eccezioni di trattamento del pacchetto: opzione Router Alert, scadenza dell'IP TTL, scadenza del MPLS TTL, etichetta MPLS Router Alert, o indirizzo di destinazione nell'intervallo 127/8. Il piano di controllo identifica inoltre il messaggio tramite la porta UDP di destinazione 3503.

Ai fini della segnalazione, il fondo della pila è considerato profondità di pila 1. Ciò stabilisce un riferimento assoluto per il caso in cui la pila reale possa contenere più etichette dei FEC nella pila FEC di destinazione.

Inoltre, in tutti i codici di errore elencati, la profondità di pila 0 significa "valore non specificato", per compatibilità con le implementazioni esistenti che non usano il campo del sottocodice di ritorno.

L'LSR X che riceve un MPLS echo request procede come segue:

1. Verificare la validità complessiva del pacchetto. Se il pacchetto è mal formato, l'LSR X SHOULD inviare un MPLS Echo Reply con codice di ritorno "Malformed echo request received", sottocodice 0. Se vi è un TLV non marcato "Ignore" e non compreso da X, X SHOULD inviare un opportuno "TLV not understood" MPLS, sottocodice 0; in quest'ultimo caso, includere tali TLV non compresi solo come sub-TLV nel TLV Errored TLVs della risposta. I campi di intestazione Sender's Handle, Sequence Number e Timestamp Sent non sono verificati ma sono inclusi nel messaggio echo reply.

L'algoritmo usa le seguenti variabili e identificatori:

• Interface-I: interfaccia che ha ricevuto l'MPLS echo request.
• Stack-R: pila di etichette alla ricezione.
• Stack-D: pila di etichette trasportata dal TLV Downstream Mapping (non necessariamente presente).
• Label-L: etichetta attualmente in verifica dalla pila reale. Non inizializzato.
• Label-stack-depth: profondità di etichetta in verifica. Inizializzata al numero di etichette nella pila ricevuta S.
• FEC-stack-depth: profondità del FEC nella pila FEC di destinazione applicata alla verifica dell'etichetta reale corrente. Non inizializzato.
• Best-return-code: il miglior codice di ritorno echo reply attualmente noto. Può cambiare con ulteriori verifiche.
• Best-rtn-subcode: come Best-return-code ma per il sottocodice echo reply.
• FEC-status: il valore restituito dall'algoritmo di verifica FEC della sezione 4.4.1.

2. Se l'echo request è valido, X memorizza l'interfaccia in Interface-I e la pila in Stack-R.

3. Verifica delle etichette (Label Validation):

   Se Label-stack-depth è 0: impostare FEC-stack-depth a 1, Label-L a 3 (Implicit Null); impostare Best-return-code a 3 ("Replying router is an egress for the FEC at stack depth"), Best-rtn-subcode al valore FEC-stack-depth (1), andare al passo 5.

   Altrimenti, estrarre Label-L da Stack-R alla profondità Label-stack-depth, cercare nell'ILM se l'etichetta è allocata e associata a un'operazione. Se non vi è alcuna voce per L: impostare Best-return-code a 11 ("No label entry at stack-depth"), Best-rtn-subcode a Label-stack-depth, andare al passo 7. Altrimenti, recuperare l'operazione di etichetta associata e andare al passo 4.

4. Verifica dell'operazione di etichetta (Label Operation Check):

   Se l'operazione è "Pop and Continue Processing" (inclusi i label Explicit Null e Router Alert): decrementare Label-stack-depth e iterare alla etichetta successiva, ritorno al passo 3.

   Se l'operazione è "Swap or Pop and Switch based on Popped Label": impostare Best-return-code a 8 ("Label switched at stack-depth"), Best-rtn-subcode a Label-stack-depth per segnalare lo scambio di transito. Se l'echo request ricevuto contiene un TLV Downstream Mapping: se l'indirizzo IP nel TLV è 127.0.0.1 o 0::1, impostare Best-return-code a 6 ("Upstream Interface Index Unknown"), la risposta SHOULD contenere un TLV Interface and Label Stack con Interface-I e Stack-R. Altrimenti, verificare che l'indirizzo IP, l'indirizzo di interfaccia e la pila di etichette nel TLV corrispondano a Interface-I e Stack-R; in caso di mancata corrispondenza, impostare Best-return-code a 5 ("Downstream Mapping Mismatch"), la risposta SHOULD contenere un TLV Interface and Label Stack basato su Interface-I e Stack-R, andare al passo 7. Per ciascun percorso ECMP a valle disponibile: recuperare l'interfaccia di uscita dalla voce NHLFE; se l'interfaccia di uscita non ha MPLS abilitato, impostare Best-return-code a 9 ("Label switched but no MPLS forwarding at stack-depth"), Best-rtn-subcode a Label-stack-depth, andare a Send_Reply_Packet. Se è presente un TLV Downstream Mapping, la risposta SHOULD contenere un TLV compilato con le informazioni del percorso ECMP corrente. Se non vi è alcun TLV Downstream Mapping, o l'indirizzo IP a valle è l'indirizzo multicast ALLROUTERS, andare al passo 7. Se il flag "Validate FEC Stack" non è impostato e l'LSR non è configurato per eseguire la verifica FEC per impostazione predefinita, andare al passo 7.

   Determinare FEC-stack-depth: attraversare Stack-D del TLV dal fondo verso l'alto, decrementando il numero di etichette per ogni etichetta non Implicit Null, e incrementando FEC-stack-depth per ogni etichetta; se contiene una o più etichette Implicit Null, FEC-stack-depth può essere maggiore di Label-stack-depth. Impostare FEC-stack-depth a 0, i a Label-stack-depth; finché i>0: ++FEC-stack-depth; se Stack-D[FEC-stack-depth]!=3 (Implicit Null) allora --i. Se il numero di etichette nella pila FEC >= FEC-stack-depth, eseguire la procedura di verifica FEC 4.4.1; se FEC-status è 2, impostare Best-return-code a 10; se il codice di ritorno è 1, impostare Best-return-code a FEC-return-code, Best-rtn-subcode a FEC-stack-depth. Andare al passo 7.

5. Elaborazione di uscita (Egress Processing): se l'echo request ricevuto non contiene un TLV Downstream Mapping, o l'indirizzo IP a valle è 127.0.0.1 o 0::1, andare al passo 6. Verificare che l'indirizzo IP, l'indirizzo di interfaccia e la pila di etichette nel TLV corrispondano a Interface-I e Stack-R; in caso di mancata corrispondenza, impostare Best-return-code a 5, la risposta SHOULD creare un TLV Received Interface and Label Stack, andare al passo 7.

6. Verifica FEC di uscita (Egress FEC Validation): ciclo su tutti gli elementi della pila FEC di destinazione a partire da FEC-stack-depth. Eseguire la verifica FEC della sezione 4.4.1 su Label-L e il FEC a FEC-stack-depth; impostare Best-return-code a FEC-code, Best-rtn-subcode al valore FEC-stack-depth. Se FEC-status è 1, andare al passo 7. ++FEC-stack-depth; se FEC-stack-depth > numero di FEC nella pila, andare al passo 7. Se FEC-status è 0: ++Label-stack-depth; se Label-stack-depth > numero di etichette in Stack-R, andare al passo 7; Label-L = etichetta estratta da Stack-R alla profondità Label-stack-depth; ritorno al passo 6.

7. Invio del pacchetto di risposta (Send Reply Packet): inviare un MPLS echo reply con codice di ritorno Best-return-code e sottocodice di ritorno Best-rtn-subcode, includendo tutti i TLV creati. La procedura di invio è nella sezione 4.4.1.

4.4.1. Convalida FEC (FEC Validation)

Questa sezione descrive la verifica di un elemento FEC della pila FEC di destinazione, accettando FEC, Label-L e Interface-I. Passi:

1. Inizializzare a 0 i due valori restituiti FEC-status e FEC-return-code.
2. Se il FEC è Nil FEC: se Label-L è Explicit_Null o Router_Alert, ritorna. Altrimenti, impostare FEC-return-code a 10, FEC-status a 1, ritorna.
3. Verificare la mappatura di etichette FEC che descrive come il traffico ricevuto sull'LSP è ulteriormente scambiato o associato a quale applicazione. Se non vi è alcuna mappatura, impostare FEC-return-code a 4 ("Replying router has no mapping for the FEC at stack-depth"), FEC-status a 1, ritorna.
4. Se la mappatura di etichette del FEC è Implicit Null, impostare FEC-status a 2 e andare al passo 5. Altrimenti, se la mappatura di etichette del FEC è Label-L, andare al passo 5. Altrimenti, impostare FEC-return-code a 10, FEC-status a 1, ritorna.
5. Verifica del protocollo: verificare il protocollo usato per annunciare il FEC. Se si può determinare che il protocollo associato a Interface-I non annuncerà tale tipo di FEC, impostare FEC-return-code a 12 ("Protocol not associated with interface at FEC stack-depth"), FEC-status a 1.
6. Ritorna.

4.5. Invio di un MPLS Echo Reply (Sending an MPLS Echo Reply)

Un MPLS echo reply è un pacchetto UDP. Deve essere inviato solo in risposta a un MPLS echo request (MUST). L'indirizzo IP sorgente è un indirizzo instradabile del rispondente; la porta sorgente è la porta UDP ben nota di LSP ping. L'indirizzo IP e la porta UDP di destinazione sono copiati dalla sorgente dell'echo request. L'IP TTL è 255. Se la modalità di risposta della richiesta è "Reply via an IPv4 UDP packet with Router Alert", l'intestazione IP MUST contenere l'opzione Router Alert IP; se la risposta è inviata tramite un LSP, l'etichetta più esterna MUST essere l'etichetta Router Alert (1) [LABEL-STACK].

Il formato dell'echo reply è identico a quello dell'echo request. Sender's Handle, Sequence Number e TimeStamp Sent sono copiati dalla richiesta; TimeStamp Received è impostato all'ora di ricezione (utile se gli orologi sono sincronizzati). Il TLV FEC Stack della richiesta MAY essere copiato nella risposta.

Il rispondente MUST compilare il codice e il sottocodice di ritorno determinati in precedenza.

Se la richiesta contiene un TLV Pad, il rispondente MUST interpretare il primo byte circa come rispondere.

Se il router rispondente è la destinazione del FEC, la risposta SHOULD NOT contenere un TLV Downstream Mapping.

Se la richiesta contiene un TLV Downstream Mapping e il rispondente non è la destinazione del FEC, SHOULD calcolare i suoi router a valle e le relative etichette di ingresso, e aggiungere alla echo reply restituita un TLV Downstream Mapping per ciascun router a valle.

Se l'elaborazione delle informazioni di multipath del TLV Downstream Mapping supera quanto il router ricevente è disposto a eseguire, MAY rispondere solo con un sottoinsieme dei multipath della richiesta. (Nota: l'iniziatore MAY inviare un'altra echo request con le informazioni di multipath assenti dalla risposta.)

Salvo la modalità di risposta 4 ("Reply via application level control channel"), l'echo reply è sempre inviato nel contesto della rete IP/MPLS.

4.6. Ricezione di un MPLS Echo Reply (Receiving an MPLS Echo Reply)

L'LSR X SHOULD ricevere solo risposte ai propri MPLS echo request inviati. Pertanto, alla ricezione di un echo reply, X analizza il pacchetto, ne verifica la validità e tenta di abbinarlo a un echo request inviato in precedenza tramite la porta UDP di destinazione e il Sender's Handle. Se non trova corrispondenza, X scarta la risposta; altrimenti verifica il Sequence Number.

Se la risposta contiene una mappatura a valle e X desidera proseguire il traceroute, SHOULD copiare tale mappatura a valle nel suo prossimo echo request (TTL incrementato di 1).

4.7. Problema dei prefissi VPN IPv4 e IPv6 (Issue with VPN IPv4 and IPv6 Prefixes)

Di norma, il ping LSP di un prefisso VPN IPv4 o IPv6 è inviato con una pila di etichette di profondità > 1, con il TTL dell'etichetta più interna a 1, per terminare al PE di uscita prima di raggiungere l'apparecchiatura del cliente. Ma in alcuni casi la pila di etichette può ridursi a una singola etichetta prima di colpire il PE di uscita; ciò termina il ping prematuramente. Un esempio è il VPN Carrier's Carrier su più AS.

Per aggirare ciò, un metodo è che l'LSR che riceve tale ping si accorga della terminazione prematura e restituisca il codice di errore 13. L'iniziatore può allora ritentare il ping incrementando il TTL dell'etichetta VPN. Così l'LSR di ingresso proverà successivamente i valori di TTL finché non trova quello che permette al ping VPN di raggiungere il PE di uscita.

4.8. Router non conformi (Non-compliant Routers)

Se l'uscita della pila FEC sottoposta a ping non supporta MPLS ping, non viene inviata alcuna risposta, il che può dare un "falso negativo". In modalità "traceroute", se un LSR di transito non supporta LSP ping, non risponde per alcuni TTL (diciamo n). L'LSR che ha inviato l'echo request SHOULD inviare echo request con TTL=n+1, n+2, ..., n+k per sondare gli LSR più a valle. In questo caso, per gli echo request con TTL>n, fino al ricevimento di una risposta contenente un TLV Downstream Mapping, SHOULD inviare il campo "Downstream IP Address" del TLV impostato all'indirizzo multicast ALLROUTERS. La pila di etichette MAY essere omessa dal TLV. Inoltre, fino al ricevimento di un echo reply contenente un TLV Downstream Mapping, SHOULD NOT impostare il flag "Validate FEC Stack".