Passa al contenuto principale

RFC 3031 - Componenti centrali dell'architettura MPLS (Detailed MPLS Architecture)

3. Componenti centrali dell'architettura MPLS (Detailed MPLS Architecture)​

3.1 Classe di equivalenza di inoltro (FEC)​

Una «Forwarding Equivalence Class» è un insieme di pacchetti inoltrati allo stesso modo, lungo lo stesso percorso. Il criterio di appartenenza può essere un prefisso di indirizzo di rete, un routing esplicito, una classe di servizio (CoS), un indirizzo sorgente o un identificatore di applicazione. La granularità della FEC è decisa localmente.

3.2 Etichetta (Label)​

Un'etichetta è un identificatore corto, a lunghezza fissa, con significato puramente locale. È univoco solo nello «spazio di etichette» in cui viene distribuita. Può essere codificata nell'header «shim» proprio di MPLS, oppure direttamente nei campi VPI/VCI di ATM o DLCI di Frame Relay.

3.3 Router a commutazione di etichetta (LSR)​

Un LSR esegue: ricerca dell'ILM tramite l'etichetta in ingresso, operazioni sullo stack (sostituzione, push, pop) secondo il risultato, inoltro al next-hop. Il LER è un LSR posto al margine del dominio MPLS e converte tra pacchetti non etichettati ed etichettati.

3.4 Associazione di etichette e distribuzione​

Un'«associazione di etichette» si ha quando un LSR a valle (Rd) lega un'etichetta L a una FEC F e comunica tale associazione al suo peer (Ru) tramite il protocollo di distribuzione. Ru, ricevendola, sa che per inviare a Rd i pacchetti della FEC F userà l'etichetta L.

3.5 Modalità di distribuzione (Label Distribution Mode)​

  • Downstream on Demand: Ru richiede esplicitamente a Rd l'etichetta di una FEC.
  • Downstream Unsolicited: Rd annuncia spontaneamente le proprie associazioni, senza richiesta.

3.6 Modalità di controllo (Label Control Mode)​

  • Independent: ogni LSR lega e distribuisce un'etichetta non appena riconosce una FEC (simile alla convergenza IP classica).
  • Ordered: un LSR lega e distribuisce un'etichetta per una FEC solo se ne è l'uscita del LSP, o se ha già ricevuto un'associazione per quella FEC dal next-hop. L'Ordered Control garantisce che il LSP sia completo prima di farvi transitare traffico, utile quando il percorso deve avere proprietà specifiche (prenotazione risorse, routing esplicito, assenza di nodi duplicati).

3.7 Modalità di ritenzione (Label Retention Mode)​

  • Liberal: Ru conserva le associazioni ricevute da Rd anche se Rd non è il suo next-hop, per un riutilizzo rapido dopo un cambio di rotta (costo: più etichette da gestire).
  • Conservative: Ru scarta le associazioni provenienti da un Rd non next-hop e le riottiene se necessario (costo: ripristino, ma minor occupazione di etichette).

3.8 Stack di etichette (Label Stack)​

MPLS supporta uno stack di etichette (LIFO). Possono essere impilate più etichette. L'inoltro si basa sempre sull'etichetta in cima, indipendentemente dal livello gerarchico. Per uno stack di profondità m si parla di etichette di livello 1…m. Lo stack abilita i «tunnel LSP» e la «gerarchia MPLS» (§3.27).

3.9 NHLFE (Next-Hop Label Forwarding Entry)​

La NHLFE serve per l'inoltro dei pacchetti etichettati e contiene:

  1. il next-hop del pacchetto;
  2. l'operazione sullo stack: sostituire l'etichetta in cima / pop / sostituire e push di una o più nuove etichette;
  3. eventualmente: incapsulamento di link, codifica dello stack e altre informazioni necessarie.

Se il next-hop è lo stesso LSR, deve eseguire il pop e poi una nuova decisione di inoltro sul resto (un'altra etichetta o IP nativo).

3.10 ILM (Incoming Label Map)​

L'ILM mappa ogni etichetta in ingresso in un insieme di NHLFE. Se ce ne sono più, prima dell'inoltro se ne deve scegliere una (es. bilanciamento su percorsi multipli equivalenti). La scelta è fuori dall'architettura.

3.11 FTN (FEC-to-NHLFE)​

La FTN serve ai pacchetti che arrivano non etichettati ma vanno etichettati prima dell'inoltro. L'LSR analizza l'header di rete per dedurre la FEC, poi mappa tramite FTN a una NHLFE. Anche qui può servire una scelta.

3.12 Label Swapping​

Pacchetto etichettato: LSR cerca l'etichetta in cima → ILM → NHLFE → decide il next-hop e opera sullo stack → codifica e inoltra. Pacchetto non etichettato: LSR analizza l'header → FEC → FTN → NHLFE → etichetta e inoltra.

Importante: con il label switching, il next-hop proviene sempre dalla NHLFE e può talvolta differire dal next-hop «senza MPLS».

3.13 Ambito e unicità delle etichette​

Rd può legare L1 alla FEC F per Ru1 e L2 alla stessa FEC F per Ru2; L1==L2 è deciso localmente. Se Rd può distinguere se l'etichetta L in cima è stata pushata da Ru1 o Ru2, allora F1==F2 non è richiesto e Rd è visto come utente di «spazi di etichette» diversi.

Uno spazio «per-interface» è ammesso solo se Ru1 e Ru2 sono i suoi unici peer di distribuzione e ciascuno è collegato point-to-point. Altrimenti l'etichetta deve essere univoca sull'intero dispositivo (per-platform). Se Rd è collegato a Ru con due link point-to-point, può legare lo stesso valore a FEC diverse, ma solo se la legatura vale per quella precisa interfaccia. Fuori da ciò, Rd non deve mai legare uno stesso valore a due FEC diverse (nemmeno su livelli diversi — MPLS non ha nozione di «spazio di etichette per livello»).

3.14 Label Switched Path (LSP), ingresso e uscita​

Un «LSP di livello m» è una sequenza <R1, ..., Rn> dove R1 (ingresso) pusha un'etichetta ottenendo profondità m; ogni Ri inoltra secondo l'etichetta di livello m (via ILM); da R1 a R[n-1] la profondità resta ≥ m; gli switch L2 attraversati non decidono né sull'etichetta di livello m né sull'header di rete.

Un «LSP per una FEC F» è, per un pacchetto P, l'LSP di livello m la cui etichetta di livello m corrisponde a F. L'albero che unisce più LSP di ingresso su un'unica uscita è l'«LSP tree» (multipoint-to-point) della FEC.

3.15 Penultimate Hop Popping​

Secondo §3.14, R[n-1] può inviare P a Rn con profondità m-1, cioè fare il pop al penultimo hop invece che all'uscita. È architetturalmente valido: l'etichetta di livello m serve solo a portare P a Rn, e da quando R[n-1] decide di inviarla a Rn essa non serve più.

Vantaggio: l'uscita fa una sola ricerca (invece di due), e anche il penultimo hop; semplifica il «fast path» hardware. L'uscita del LSP può allora non essere un LSR. Ma alcuni hardware non sanno fare il pop, quindi non è imposto: il penultimo hop fa il pop solo se l'uscita lo «richiede esplicitamente» o se il LSP next-hop non supporta MPLS. Un LSR capace di pop deve farlo se il peer a valle lo richiede. La negoziazione iniziale deve stabilire se il vicino sa fare il pop; a chi non sa farlo non si deve chiedere.

3.16 LSP Next Hop​

L'«LSP next-hop» di un pacchetto etichettato in un LSR è il next-hop indicato dalla NHLFE usata per l'inoltro. Per una FEC, è il next-hop indicato dalla NHLFE indicizzata dall'etichetta corrispondente. Può differire dal next-hop scelto dall'algoritmo di routing di rete (L3 next-hop).

3.17 Etichette in ingresso non valide​

Se un LSR riceve un pacchetto etichettato la cui etichetta in ingresso non ha alcuna associazione, non deve semplicemente rimuoverla e inoltrarlo come IP non etichettato — ciò può creare un loop (l'upstream crede a un routing esplicito, il downstream non vede associazione e il routing IP hop-by-hop può rispedire il pacchetto all'upstream). Tali pacchetti vanno quindi scartati, a meno di non poter accertare che l'inoltro non etichettato sia innocuo.

3.18 Controllo del LSP: Ordered vs Independent​

Vedi §3.6. Independent decide localmente (come la convergenza IP classica). Ordered lega l'etichetta solo all'uscita o dopo aver ricevuto un'associazione dal next-hop. Se il traffico deve seguire un percorso con proprietà specifiche (nodi non duplicati, risorse garantite, percorso esplicito), serve Ordered. Un LSP Ordered può essere avviato dall'ingresso o dall'uscita. Le due modalità sono pienamente interoperabili; ma un nodo non-Ordered nel LSP rende il comportamento globale simile a Independent. L'architettura lascia la scelta come questione locale.

3.19 Aggregazione (Aggregation)​

Creare una FEC per ogni prefisso della tabella di routing può produrre molte FEC che nello stesso dominio MPLS prendono la stessa via. Si può allora aggregare l'unione di queste FEC in una FEC più grande a cui legare una sola etichetta — è l'«aggregazione». Riduce numero di etichette e traffico di controllo.

Per un insieme di FEC aggregabili si può (a) aggregare in una FEC (granularità più grossa), (b) in più FEC, o (c) non aggregare affatto (più fine). In Ordered, ogni LSR deve allineare la granularità al next-hop. In Independent, due LSR adiacenti possono differire: se Ru è più fine di Rd, mappa semplicemente più etichette sulle meno di Rd; se Ru è più grossolano, preferisce la granularità più fine di Rd (ritira m, distribuisce n) o mappa le sue m su un sottoinsieme delle n di Rd (se il risultato di routing è identico). Ogni LSR deve (per configurazione) conoscere la granularità delle etichette che assegna.

3.20 Selezione della rotta (Route Selection)​

MPLS supporta due selezioni di rotta per l'LSP: (1) hop-by-hop; (2) esplicita. In hop-by-hop ogni nodo sceglie da solo il next-hop (modo IP classico). In esplicita, un singolo LSR (solitamente ingresso o uscita) specifica tutti o parte dei nodi: tutti = stretta, parte = lasca. La sequenza può essere configurata o calcolata dinamicamente. Il routing esplicito serve al policy routing e al traffic engineering; MPLS lo specifica all'assegnazione dell'etichetta, molto più efficiente del source-routing IP. I dettagli sono fuori architettura.

3.21 Mancanza di etichetta in uscita (Lack of Outgoing Label)​

Un pacchetto etichettato che percorre un LSP può raggiungere un LSR la cui ILM non mappa l'etichetta (valida) in ingresso ad alcuna NHLFE (stato transitorio o next-hop errato). Anche qui non si deve rimuovere lo stack e proseguire secondo l'header di rete — se l'LSP era esplicito, è possibile un loop, e l'header di rete può non bastare al LSR per inoltrare correttamente. Salvo accertare l'assenza di entrambi, l'unica azione sicura è scartare il pacchetto.

3.22 Time To Live (TTL)​

L'IP classico decrementa il TTL a ogni hop e scarta a 0, offrendo una protezione contro loop dovuti a errori di configurazione o lente convergenze; il TTL serve anche alla portata multicast e a traceroute. MPLS deve trattare due aspetti TTL: (i) inibizione dei loop; (ii) controllo di portata e altre funzioni.

Dopo aver percorso un LSP, il TTL di un pacchetto deve essere pari a quello che avrebbe avuto senza label switching sulla stessa sequenza di router; per una gerarchia di LSP, il numero totale di hop LSR attraversati deve riflettersi nel TTL.

La gestione dipende dalla codifica — shim MPLS ([MPLS-SHIM]) o header L2 (ATM [MPLS-ATM], FR [MPLS-FRMRLY]):

  • shim: il campo TTL è obbligatorio; caricato dal TTL di rete, decrementato a ogni hop LSR, ricopiato nel TTL di rete all'uscita.
  • header L2 (es. VPI/VCI ATM AAL5) senza TTL: il decremento per hop è impossibile. Un tale «segmento LSP senza TTL» richiede, all'uscita, un TTL che rifletta il numero di hop LSR (in unicast la lunghezza LSP può essere propagata all'ingresso per un pre-decremento). Se all'ingresso di un segmento senza TTL si può dedurre che il TTL si esaurirà prima dell'uscita, il LSR non deve fare label switching (servono procedure proprie per traceroute).

3.23 Controllo dei loop (Loop Control)​

Su un segmento LSP senza TTL, il TTL non protegge dai loop. L'importanza dipende dall'hardware. Esempio: se l'hardware ATM non decrementa il TTL, non c'è protezione; se offre accesso equo al pool di buffer per cella secondo VPI/VCI, un loop transitorio non danneggia il resto; altrimenti degrada seriamente le prestazioni.

Anche con buffer equo, conviene rilevare loop oltre una durata plausibile. E anche se sopravvivibile via TTL/code eque, è preferibile evitare LSP a loop quando possibile. Perciò ogni LSR che può collegarsi a un segmento senza TTL deve supportare una tecnica comune di rilevamento, ma il suo uso è opzionale (vedi [MPLS-ATM], [MPLS-LDP]).

3.24 Codifiche delle etichette (Label Encodings)​

Per trasportare lo stack di etichette con il pacchetto occorre definire una codifica concreta. L'architettura ne supporta diverse secondo il tipo di hardware.

3.24.1 Hardware/software MPLS dedicato​

Il più diretto: porre un protocollo «shim» tra livello di collegamento e header di rete, come incapsulamento di rete «indipendente dal protocollo» (generic MPLS encapsulation), portato dal collegamento. Vedi [MPLS-SHIM].

3.24.2 Usare uno switch ATM come LSR​

Il trasferimento MPLS somiglia al switching ATM: lo switch indicizza una tabella di cross-connessione per porta + VPI/VCI. Se l'etichetta può essere codificata in questi campi, un semplice aggiornamento software basta a farne un LSR (ATM-LSR). Tre codifiche nell'header di cella ATM (AAL5):

  1. SVC: VPI/VCI codifica l'etichetta in cima. Ogni LSP è uno SVC ATM, e il protocollo di distribuzione è la segnalazione ATM. Questo modo non permette push/pop di stack.
  2. SVP: VPI codifica l'etichetta in cima, VCI la seconda (se presente). Realizza il «VP switching» ATM (LSP = SVP). Ma se un virtual path ATM attraversa una rete non MPLS, il VPI può non essere libero; all'uscita VP, l'ATM-LSR esegue di fatto un «pop».
  3. SVP Multipoint: VPI codifica l'etichetta in cima, una parte del VCI la seconda, il resto del VCI identifica l'ingresso LSP. Col VP switching ATM si realizza un VP multipoint-to-point dove celle di sorgenti diverse portano VCI distinti, permettendo il merge senza intreccio di celle su switch che non supportano VC merge. Ciò richiede l'assegnazione di valori VCI 16 bit senza sovrapposizione.

Se lo stack ha più etichette di quante l'header ATM ne possa codificare, si combinano codifica ATM e shim generico.

3.24.3 Interoperabilità tra codifiche​

Hop diversi di un LSP possono usare codifiche diverse. L'LSR deve decodificare lo stack corrente, operarvi e codificarlo per il next-hop. Ma uno switch ATM non può convertire tra due codifiche; l'architettura esige perciò che due switch ATM che possano essere LSR consecutivi su un LSP di livello m usino la stessa codifica. Un LSR misto (ATM + shim) può all'ingresso rimuovere la codifica ATM e all'uscita rimetterne una shim.

3.25 Label Merging​

Quando un LSR lega più etichette in ingresso a una stessa FEC e vuole usare una sola etichetta in uscita per tutto quel traffico — è il «label merging».

Un LSR «può fare merge» se può ricevere due pacchetti da interfacce/etichette diverse e inviarli dalla stessa interfaccia di uscita con la stessa etichetta (l'informazione di origine si perde). «Non può fare merge» se due pacchetti da interfacce/etichette diverse devono andare a interfacce o etichette diverse. Gli ATM-LSR in SVC/SVP non possono fare merge.

Un LSR non merging deve inoltrare con etichette di uscita diverse i pacchetti di una stessa FEC arrivati con etichette di ingresso diverse. Nel merge basta 1 etichetta di uscita per FEC; altrimenti fino al numero di nodi della rete. L'architettura comprende entrambi i tipi di LSR e la loro interoperabilità.

3.25.1 LSR non merging​

Il trasferimento MPLS somiglia ad ATM/Frame Relay: ricerca in una tabella di cross-connessione per etichetta (VPI/VCI o DLCI), scelta porta, riscrittura etichetta; il protocollo di distribuzione fa da segnalazione. Ma queste tecnologie non supportano sempre il merge: forzare il merge su ATM intreccia le celle di pacchetti diversi, irrecuperabili; alcuni switch Frame Relay con backplane a celle hanno lo stesso problema.

MPLS offre due soluzioni: procedure che permettono l'uso di LSR non merging, e il supporto di alcuni switch ATM come LSR merging. MPLS include anche la corretta interoperabilità tra i due.

3.25.2 Etichette per LSR merging / non merging​

Un LSR upstream che supporta il merge non ha bisogno che di un'etichetta per FEC; un peer upstream non merging ne serve diverse (numero a priori incerto). L'architettura prescrive: verso un peer upstream non merging, non inviare alcuna etichetta se non la richiede esplicitamente; può richiederla più volte, ottenendo di volta in volta una nuova; se il peer a valle è a sua volta non merging, deve a sua volta richiederne una al proprio valle.

Un nodo che può unire solo un numero limitato di etichette in ingresso a una in uscita (es. max 4 su 6 ricevute) può unire in 2 in uscita. L'applicabilità del merge a LSP a routing esplicito resta da studiare.

3.25.3 Merge su ATM​

Eliminare l'intreccio di celle:

  1. VP merge (SVP Multipoint): più virtual path fusi in uno, distinti da VCI diversi nel VP.
  2. VC merge: lo switch bufferizza tutte le celle di un pacchetto fino alla fine AAL5, poi invia.

Il VP merge è compatibile con più implementazioni ATM e non introduce latenza/buffer al punto di merge, ma richiede di coordinare lo spazio VCI nel VP. La scelta resta da studiare. MPLS dovrebbe supportare entrambi; ogni switch ATM coinvolto deve sapere se il vicino diretto fa VP merge, VC merge o nessun merge.

Interoperabilità (VC / VP / nessun merge): la più semplice è VC e nessun merge, entrambi basati su forward VC (VPI/VCI). Se l'upstream fa VC merge, basta una coppia VPI/VCI; se non fa merge, gliene serve una per sé più abbastanza per i suoi upstream. Un nodo VP richiede un VP (un VPI) più diversi VCI nel VP. Per i tre insieme, il nodo upstream deve poter richiedere una combinazione di «zero o più VC (VPI/VCI) + zero o più VP (un VPI), ciascuno con un numero specificato di VC».

3.26 Tunnel e gerarchia (Tunnels and Hierarchy)​

Un router Ru può recapitare esplicitamente un pacchetto a un altro router Rd benché non siano adiacenti sul percorso hop-by-hop e Rd non ne sia la destinazione finale — ad esempio incapsulando il pacchetto in un pacchetto di rete indirizzato a Rd, formando un «tunnel» Ru→Rd. Un tale pacchetto è «incapsulato in tunnel».

  • Tunnel a routing hop-by-hop: il pacchetto incapsulato segue il percorso hop-by-hop Ru→Rd; «punto di emissione» Ru, «punto di ricezione» Rd.

  • Tunnel a routing esplicito: il pacchetto incapsulato segue un percorso non hop-by-hop (es. source-routing).

  • Tunnel LSP: un tunnel realizzato tramite un LSP, il pacchetto lo attraversa per label switching anziché per incapsulamento di rete. Il tunnel è l'LSP <R1, ..., Rn>, R1 emettitore, Rn ricevitore. I pacchetti da immettervi formano una FEC; ogni LSR nel tunnel deve assegnare un'etichetta a tale FEC (il tunnel). Si immette un pacchetto pushando l'etichetta di tunnel e inviandola al tunnel next-hop. Se il ricevitore non deve distinguere, si fa il pop al penultimo hop.

    • «Tunnel LSP a routing hop-by-hop» = LSP hop-by-hop tra emettitore e ricevitore.
    • «Tunnel LSP a routing esplicito» = tunnel LSP che è anche LSP a routing esplicito.

  • Gerarchia: tunnel LSP in un LSP: considera <R1,R2,R3,R4>. R1 pusha per questo percorso, ma R2 e R3 non sono direttamente collegati; sono adiacenti come estremità di un tunnel LSP. P percorre allora <R1,R2,R21,R22,R23,R3,R4>. R1→R2 profondità 1; R2 sostituisce con un'etichetta sensata per R3 e pusha un'etichetta di livello 2 per R21; R21/R22/R23 commutano sul livello 2; R23 (penultimo hop del tunnel R2-R3) poppa verso R3; R3 vede P solo con l'etichetta di livello 1 (uscito dal tunnel) e, come penultimo hop dell'LSP di livello 1, poppa; R4 riceve P non etichettato. Lo stack permette l'annidamento a profondità arbitraria.

  • Peer di distribuzione e gerarchia: sull'LSP di livello 1 <R1,R2,R3,R4>, R2→R3 usa l'LSP di livello 2 <R2,R21,R22,R3>. Per il livello 2, il peer di R2 è R21; per il livello 1, sono R1 e R3. Ogni livello ha i suoi peer. R2 e R21 devono essere vicini IGP; R2 e R3 non necessariamente.

    • Vicini IGP anche = «peer locale»; non vicini IGP ma peer possibili = «peer remoto». Qui R2-R21 locale, R2-R3 remoto.
    • L'architettura supporta due modi di distribuzione tra livelli: peer esplicito (messaggi indirizzati esplicitamente al peer, adatto a pochi peer remoti) e peer implicito (l'etichetta di livello superiore è attributo di quella inferiore, distribuita con essa al peer locale che la propaga, adatto a molti peer remoti ma costringe i nodi intermedi a memorizzare info non direttamente pertinenti).

3.27 Trasporto del protocollo di distribuzione (Label Distribution Protocol Transport)​

Il protocollo di distribuzione stabilisce e mantiene le associazioni tra i nodi MPLS. Per operare correttamente serve trasporto affidabile, messaggi di una stessa FEC ordinati, possibilmente controllo di flusso e più messaggi per datagramma. Un modo è usare TCP come trasporto (così [MPLS-LDP] e [MPLS-BGP]).

3.28 Perché più di un protocollo di distribuzione?​

L'architettura non fissa regole rigide, ma nota:

  • BGP e LDP: spesso è opportuno legare un'etichetta a una FEC identificabile da un prefisso di indirizzo. Se un algoritmo di routing standard distribuisce tali rotte, è ottimale «piggybackare» la distribuzione delle etichette su quella delle rotte. Es. BGP distribuisce tali rotte; se un speaker BGP deve distribuire etichette ai suoi peer, usare BGP ([MPLS-BGP]) permette al route reflector BGP di distribuire anche etichette, con chiaro vantaggio di scalabilità su LDP tra peer BGP.
  • Etichette per un Flowspec RSVP: quando RSVP prenota risorse per un flusso, etichettarne i pacchetti evita di applicare il filtro RSVP a ogni hop; il più efficiente è che RSVP distribuisca le etichette durante l'instaurazione path/resv.
  • Etichette per LSP a routing esplicito: il traffic engineering richiede routing esplicito dall'ingresso all'uscita con prenotazione. Due approcci: estendere il protocollo di prenotazione per routing esplicito ed etichette ([MPLS-RSVP-TUNNELS]), o estendere LDP per routing esplicito e prenotazione ([MPLS-CR-LDP]).

3.29 Multicast​

Sezione lasciata a ulteriori studi.