Passa al contenuto principale

2. Lo Stack di Etichette

  1. Lo Stack di Etichette

2.1. Codifica dello Stack di Etichette

Lo stack di etichette è rappresentato come una sequenza di "voci dello stack di etichette" (label stack entries). Ogni voce dello stack di etichette è rappresentata da 4 ottetti. Questo è mostrato nella Figura 1.

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Voce | Label | Exp |S| TTL | Stack +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Etichetta

                Label:  Valore dell'Etichetta, 20 bit
                Exp:    Uso Sperimentale, 3 bit
                S:      Fondo dello Stack (Bottom of Stack), 1 bit
                TTL:    Time to Live, 8 bit

                          Figura 1

Le voci dello stack di etichette appaiono DOPO le intestazioni del livello di collegamento dati, ma PRIMA di qualsiasi intestazione del livello di rete. La cima dello stack di etichette appare per prima nel pacchetto, e il fondo appare per ultimo. Il pacchetto del livello di rete segue immediatamente la voce dello stack di etichette che ha il bit S impostato.

Ogni voce dello stack di etichette è suddivisa nei seguenti campi:

  1. Fondo dello Stack (S)

     Questo bit è impostato a uno per l'ultima voce nello stack di etichette (cioè, per il fondo dello stack), e a zero per tutte le altre voci dello stack di etichette.

  2. Time to Live (TTL)

     Questo campo di otto bit è utilizzato per codificare un valore di time-to-live. L'elaborazione di questo campo è descritta nella sezione 2.4.

  3. Uso Sperimentale (Exp)

     Questo campo di tre bit è riservato per uso sperimentale.

  4. Valore dell'Etichetta (Label Value)

     Questo campo di 20 bit trasporta il valore effettivo dell'Etichetta.

     Quando viene ricevuto un pacchetto etichettato, viene cercato il valore dell'etichetta in cima allo stack. Come risultato di una ricerca riuscita si apprende:

     a) il prossimo hop verso il quale il pacchetto deve essere inoltrato;

     b) l'operazione da eseguire sullo stack di etichette prima dell'inoltro; questa operazione può essere sostituire la voce in cima allo stack di etichette con un'altra, o rimuovere (pop) una voce dallo stack di etichette, o sostituire la voce in cima allo stack di etichette e poi inserire (push) una o più voci aggiuntive sullo stack di etichette.

     Oltre ad apprendere il prossimo hop e l'operazione sullo stack di etichette, si può anche apprendere l'incapsulamento del collegamento dati in uscita, e possibilmente altre informazioni necessarie per inoltrare correttamente il pacchetto.

     Ci sono diversi valori di etichetta riservati:

       i. Un valore di 0 rappresenta l'"Etichetta NULL Esplicita IPv4" (IPv4 Explicit NULL Label). Questo valore di etichetta è legale solo in fondo allo stack di etichette. Indica che lo stack di etichette deve essere rimosso e l'inoltro del pacchetto deve quindi basarsi sull'intestazione IPv4.

      ii. Un valore di 1 rappresenta l'"Etichetta di Avviso Router" (Router Alert Label). Questo valore di etichetta è legale ovunque nello stack di etichette tranne che in fondo. Quando un pacchetto ricevuto contiene questo valore di etichetta in cima allo stack di etichette, viene consegnato a un modulo software locale per l'elaborazione. L'inoltro effettivo del pacchetto è determinato dall'etichetta sotto di essa nello stack. Tuttavia, se il pacchetto viene inoltrato ulteriormente, l'Etichetta di Avviso Router dovrebbe essere reinserita nello stack di etichette prima dell'inoltro. L'uso di questa etichetta è analogo all'uso dell'"Opzione di Avviso Router" nei pacchetti IP [5]. Poiché questa etichetta non può trovarsi in fondo allo stack, non è associata a un particolare protocollo del livello di rete.

     iii. Un valore di 2 rappresenta l'"Etichetta NULL Esplicita IPv6" (IPv6 Explicit NULL Label). Questo valore di etichetta è legale solo in fondo allo stack di etichette. Indica che lo stack di etichette deve essere rimosso e l'inoltro del pacchetto deve quindi basarsi sull'intestazione IPv6.

      iv. Un valore di 3 rappresenta l'"Etichetta NULL Implicita" (Implicit NULL Label). Questa è un'etichetta che un LSR può assegnare e distribuire, ma che non appare mai effettivamente nell'incapsulamento. Quando un LSR sostituirebbe altrimenti l'etichetta in cima allo stack con una nuova etichetta, ma la nuova etichetta è "NULL Implicita", l'LSR rimuoverà lo stack invece di effettuare la sostituzione. Sebbene questo valore possa non apparire mai nell'incapsulamento, deve essere specificato nel Protocollo di Distribuzione delle Etichette, quindi un valore è riservato.

       v. I valori 4-15 sono riservati.

2.2. Determinazione del Protocollo del Livello di Rete

Quando l'ultima etichetta viene rimossa dallo stack di etichette di un pacchetto (risultando nello svuotamento dello stack), l'ulteriore elaborazione del pacchetto si basa sull'intestazione del livello di rete del pacchetto. L'LSR che rimuove l'ultima etichetta dallo stack deve quindi essere in grado di identificare il protocollo del livello di rete del pacchetto. Tuttavia, lo stack di etichette non contiene alcun campo che identifichi esplicitamente il protocollo del livello di rete. Ciò significa che l'identità del protocollo del livello di rete deve essere deducibile dal valore dell'etichetta che viene rimossa dal fondo dello stack, possibilmente insieme al contenuto dell'intestazione del livello di rete stessa.

Pertanto, quando la prima etichetta viene inserita su un pacchetto del livello di rete, l'etichetta deve essere una che viene utilizzata SOLO per pacchetti di un particolare livello di rete, oppure l'etichetta deve essere una che viene utilizzata SOLO per un insieme specificato di protocolli del livello di rete, dove i pacchetti dei livelli di rete specificati possono essere distinti ispezionando l'intestazione del livello di rete. Inoltre, ogni volta che quel valore di etichetta viene sostituito da un altro valore di etichetta durante il transito di un pacchetto, il nuovo valore deve essere anch'esso uno che soddisfa gli stessi criteri. Se queste condizioni non sono soddisfatte, l'LSR che rimuove l'ultima etichetta da un pacchetto non sarà in grado di identificare il protocollo del livello di rete del pacchetto.

L'adesione a queste condizioni non consente necessariamente ai nodi intermedi di identificare il protocollo del livello di rete di un pacchetto. In condizioni ordinarie, questo non è necessario, ma ci sono condizioni di errore in cui è desiderabile. Ad esempio, se un LSR intermedio determina che un pacchetto etichettato non è consegnabile, potrebbe essere desiderabile per quell'LSR generare messaggi di errore specifici per il livello di rete del pacchetto. L'unico mezzo che l'LSR intermedio ha per identificare il livello di rete è l'ispezione dell'etichetta superiore e dell'intestazione del livello di rete. Quindi, se i nodi intermedi devono essere in grado di generare messaggi di errore specifici del protocollo per i pacchetti etichettati, tutte le etichette nello stack devono soddisfare i criteri specificati sopra per le etichette che appaiono in fondo allo stack.

Se un pacchetto non può essere inoltrato per qualche motivo (ad es., supera l'MTU del collegamento dati), e il suo protocollo del livello di rete non può essere identificato, o non ci sono regole specifiche del protocollo specificate per gestire la condizione di errore, allora il pacchetto DEVE essere scartato silenziosamente.

2.3. Generazione di Messaggi ICMP per Pacchetti IP Etichettati

La sezione 2.4 e la sezione 3 discutono le situazioni in cui è desiderabile generare messaggi ICMP per pacchetti IP etichettati. Affinché un particolare LSR sia in grado di generare un pacchetto ICMP e far inviare quel pacchetto alla sorgente del pacchetto IP, devono valere due condizioni:

  1. deve essere possibile per quell'LSR determinare che un particolare pacchetto etichettato è un pacchetto IP;

  2. deve essere possibile per quell'LSR instradare verso l'indirizzo IP sorgente del pacchetto.

La condizione 1 è discussa nella sezione 2.2. Le seguenti due sottosezioni discutono la condizione 2. Tuttavia, ci saranno alcuni casi in cui la condizione 2 non vale affatto, e in questi casi non sarà possibile generare il messaggio ICMP.

2.3.1. Tunneling attraverso un Dominio di Routing di Transito

Supponiamo di utilizzare MPLS per fare "tunneling" attraverso un dominio di routing di transito, dove le rotte esterne non vengono divulgate nei router interni del dominio. Ad esempio, i router interni potrebbero eseguire OSPF e potrebbero sapere solo come raggiungere destinazioni all'interno di quel dominio OSPF. Il dominio potrebbe contenere diversi Autonomous System Border Routers (ASBR), che parlano BGP tra loro. Tuttavia, in questo esempio le rotte da BGP non sono distribuite in OSPF e gli LSR che non sono ASBR non eseguono BGP.

In questo esempio, solo un ASBR saprà come instradare verso la sorgente di un pacchetto arbitrario. Se un router interno deve inviare un messaggio ICMP alla sorgente di un pacchetto IP, non saprà come instradare il messaggio ICMP.

Una soluzione è far iniettare da uno o più ASBR il "default" nell'IGP. (N.B.: questo NON richiede che ci sia un "default" trasportato da BGP.) Ciò garantirebbe quindi che qualsiasi pacchetto non etichettato che deve lasciare il dominio (come un pacchetto ICMP) venga inviato a un router che dispone di informazioni di routing complete. I router con informazioni di routing complete etichetteranno i pacchetti prima di rimandarli attraverso il dominio di transito, in modo che l'uso del routing predefinito all'interno del dominio di transito non causi loop.

Questa soluzione funziona solo per i pacchetti che hanno indirizzi globalmente unici e per le reti in cui tutti gli ASBR hanno informazioni di routing complete. La prossima sottosezione descrive una soluzione che funziona quando queste condizioni non sono soddisfatte.

2.3.2. Tunneling di Indirizzi Privati attraverso una Dorsale Pubblica

In alcuni casi in cui MPLS viene utilizzato per fare tunneling attraverso un dominio di routing, potrebbe non essere affatto possibile instradare verso l'indirizzo sorgente di un pacchetto frammentato. Questo sarebbe il caso, ad esempio, se gli indirizzi IP trasportati nel pacchetto fossero indirizzi privati (cioè, non globalmente unici) e MPLS venisse utilizzato per fare tunneling di quei pacchetti attraverso una dorsale pubblica. Il routing predefinito verso un ASBR non funzionerà in questo ambiente.

In questo ambiente, per inviare un messaggio ICMP alla sorgente di un pacchetto, si può copiare lo stack di etichette dal pacchetto originale al messaggio ICMP, e poi commutare l'etichetta del messaggio ICMP. Ciò farà procedere il messaggio nella direzione della destinazione del pacchetto originale, piuttosto che verso la sua sorgente. A meno che il messaggio non venga commutato con etichetta fino all'host di destinazione, finirà, non etichettato, in un router che sa come instradare verso la sorgente del pacchetto originale, punto in cui il messaggio verrà inviato nella direzione corretta.

Questa tecnica può essere molto utile se il messaggio ICMP è un messaggio "Time Exceeded" o un messaggio "Destination Unreachable because fragmentation needed and DF set".

Quando si copia lo stack di etichette dal pacchetto originale al messaggio ICMP, i valori delle etichette devono essere copiati esattamente, ma i valori TTL nello stack di etichette dovrebbero essere impostati sul valore TTL che viene inserito nell'intestazione IP del messaggio ICMP. Questo valore TTL dovrebbe essere abbastanza lungo da consentire il percorso tortuoso che il messaggio ICMP dovrà seguire.

Si noti che se la scadenza del TTL di un pacchetto è dovuta alla presenza di un loop di routing, allora se viene utilizzata questa tecnica, anche il messaggio ICMP potrebbe andare in loop. Poiché un messaggio ICMP non viene mai inviato come risultato della ricezione di un messaggio ICMP, e poiché molte implementazioni limitano la velocità con cui i messaggi ICMP possono essere generati, non si prevede che ciò ponga un problema.

2.4. Elaborazione del Campo Time to Live (TTL)

2.4.1. Definizioni

Il "TTL in ingresso" di un pacchetto etichettato è definito come il valore del campo TTL della voce in cima allo stack di etichette quando il pacchetto viene ricevuto.

Il "TTL in uscita" di un pacchetto etichettato è definito come il maggiore tra:

  a) uno meno il TTL in ingresso,
  b) zero.

2.4.2. Regole indipendenti dal protocollo

Se il TTL in uscita di un pacchetto etichettato è 0, allora il pacchetto etichettato NON DEVE essere inoltrato ulteriormente; né lo stack di etichette può essere rimosso e il pacchetto inoltrato come pacchetto non etichettato. La vita del pacchetto nella rete è considerata scaduta.

A seconda del valore dell'etichetta nella voce dello stack di etichette, il pacchetto PUÒ essere semplicemente scartato, o può essere passato al livello di rete "ordinario" appropriato per l'elaborazione degli errori (ad es., per la generazione di un messaggio di errore ICMP, vedere la sezione 2.3).

Quando un pacchetto etichettato viene inoltrato, il campo TTL della voce dello stack di etichette in cima allo stack di etichette DEVE essere impostato sul valore TTL in uscita.

Si noti che il valore TTL in uscita è funzione esclusivamente del valore TTL in ingresso, ed è indipendente dal fatto che eventuali etichette vengano inserite o rimosse prima dell'inoltro. Non c'è alcun significato per il valore del campo TTL in qualsiasi voce dello stack di etichette che non sia in cima allo stack.

2.4.3. Regole dipendenti da IP

Definiamo il campo "IP TTL" come il valore del campo TTL IPv4, o il valore del campo Hop Limit IPv6, a seconda di quale sia applicabile.

Quando un pacchetto IP viene etichettato per la prima volta, il campo TTL della voce dello stack di etichette DEVE ESSERE impostato sul valore del campo IP TTL. (Se il campo IP TTL deve essere decrementato, come parte dell'elaborazione IP, si assume che ciò sia già stato fatto.)

Quando un'etichetta viene rimossa e lo stack di etichette risultante è vuoto, allora il valore del campo IP TTL DOVREBBE ESSERE sostituito con il valore TTL in uscita, come definito sopra. In IPv4 ciò richiede anche la modifica del checksum dell'intestazione IP.

Si riconosce che potrebbero esserci situazioni in cui un'amministrazione di rete preferisce decrementare il TTL IPv4 di uno mentre attraversa un dominio MPLS, invece di decrementare il TTL IPv4 del numero di hop LSP all'interno del dominio.

2.4.4. Traduzione tra Diversi Incapsulamenti

A volte un LSR può ricevere un pacchetto etichettato su, ad es., un'interfaccia ATM controllata da label switching (LC-ATM) [9], e potrebbe doverlo inviare su un collegamento PPP o LAN. Allora il pacchetto in ingresso non sarà ricevuto utilizzando l'incapsulamento specificato in questo documento, ma il pacchetto in uscita sarà inviato utilizzando l'incapsulamento specificato in questo documento.

In questo caso, il valore del "TTL in ingresso" è determinato dalle procedure utilizzate per trasportare pacchetti etichettati su, ad es., interfacce LC-ATM. L'elaborazione del TTL procede quindi come descritto sopra.

A volte un LSR può ricevere un pacchetto etichettato su un collegamento PPP o LAN, e potrebbe doverlo inviare su, diciamo, un'interfaccia LC-ATM. Allora il pacchetto in ingresso sarà ricevuto utilizzando l'incapsulamento specificato in questo documento, ma il pacchetto in uscita non sarà inviato utilizzando l'incapsulamento specificato in questo documento. In questo caso, la procedura per trasportare il valore del "TTL in uscita" è determinata dalle procedure utilizzate per trasportare pacchetti etichettati su, ad es., interfacce LC-ATM.

Ultimo aggiornamento il