Multi Protocol Label Switching (MPLS): Architettura e

Marco Listanti
Dipartimento INFOCOM
Università di Roma "La Sapienza"
Multi Protocol Label Switching (MPLS):
Architettura e Ingegneria del Traffico
Versione 5.0
A.A. 2007-2008
Nota:
Allo scopo di migliorare la stesura della presente dispensa, si invitano gli studenti che ne
usufruiranno a segnalare eventuali errori e/o imprecisioni presenti nel testo e nelle figure.
Un grazie anticipato a tutti per la collaborazione.
1
Indice
I
MULTI PROTOCOL LABEL SWITCHING (MPLS) – PRINCIPI GENERALI.............................. 3
I.1
INTRODUZIONE .................................................................................................................................. 3
I.2
LA TECNICA MPLS: PRINCIPI GENERALI ............................................................................................ 5
I.3
LABEL SWITCHING ROUTER (LSR) E MODALITÀ DI DEFINIZIONE DELLE LABEL ................................ 7
I.4
LABEL SWITCHING PATH (LSP): DEFINIZIONE E FUNZIONI DEGLI LSR............................................ 10
I.4.1
I.4.2
I.4.3
II
Tabelle di trattamento delle label in un LSR....................................................................... 11
Penultimate Hop Popping. .................................................................................................. 12
Aggregazione e merging delle label .................................................................................... 13
I.5
INSTAURAZIONE E SELEZIONE DEL PERCORSO DI UN LSP ................................................................ 14
I.6
LSP TUNNELS ................................................................................................................................. 16
I.7
ELABORAZIONE DEL CAMPO TTL DELLA LABEL MPLS .................................................................. 18
MULTI PROTOCOL LABEL SWITCHING (MPLS) – GESTIONE DELLE LABEL E
INGEGENRIA DEL TRAFFICO .......................................................................................................... 21
II.1
PROCEDURE DI GESTIONE DELLE LABEL .......................................................................................... 21
II.1.1
II.1.2
II.1.3
II.1.4
II.1.5
II.1.6
II.2
Procedura di distribuzione (Distribution procedure) ......................................................... 22
Procedura di disattivazione (Withdrawal procedure)......................................................... 24
Procedura di richiesta (Request procedure) ....................................................................... 24
Procedura di dichiarazione di indisponibilità (Not Available procedure).......................... 25
Procedura di rilascio (Release procedure) ......................................................................... 25
Procedura di uso della label (Label Use procedure) .......................................................... 26
MPLS E INGEGNERIA DEL TRAFFICO ............................................................................................... 26
II.2.1
II.2.2
II.2.3
II.2.4
II.2.5
II.2.6
Aspetti generali del ingegneria del traffico in reti IP.......................................................... 26
Limiti degli attuali protocolli di routing IP......................................................................... 28
Definizione del problema di Ingegneria del Traffico in MPLS ........................................... 29
Funzioni e attributi associati ai Traffic Trunk (Traffic Trunk Attribute) ............................ 31
Attributi associati alle risorse di rete (Resource Attribute) ................................................ 34
Constraint-Based Routing (CBR)........................................................................................ 34
II.3
SUPPORTO DELLA QUALITÀ DI SERVIZIO IN RETI MPLS (ARCHITETTURA DIFFSERV OVER MPLS) . 35
II.4
ESTENSIONE DEL PROTOCOLLO RSVP PER L’INSTAURAZIONE DI LSP (RSVP-TE) .......................... 38
II.5
BIBLIOGRAFIA ................................................................................................................................. 41
2
I
I.1
MULTI PROTOCOL LABEL SWITCHING (MPLS) – PRINCIPI
GENERALI
Introduzione
La definizione dell’architettura Multi-Protocol Label Switching (MPLS) ha avuto
origine dall’intensa attività, condotta a partire dalla metà degli anni ’90 da diverse aziende
manifatturiere nel settore del networking IP, che aveva come obiettivo la definizione di un
modo di trasferimento capace di unire le caratteristiche delle tecnologie IP e ATM.
In una prima fase, tale attività ha condotto alla proposta di numerosi nuovi paradigmi di
rete tra cui: IP switching (sviluppata in IPSILON); Tag switching (origine CISCO); Aggregate
route-based IP switching (definita da IBM). L’obiettivo di queste proposte era quello di
migliorare le prestazioni della tecnologia IP, con particolare riguardo al throughput dei router
e al ritardo di commutazione dei pacchetti, utilizzando le soluzioni tipiche dell’ATM.
L’approccio seguito era lo stesso in tutte le soluzioni e consisteva nei seguenti principi: a)
individuare, mediante un protocollo standard di routing (es. OSPF), i cammini tra due punti
terminali all’interno della rete; b) identificare questo cammino mediante un’etichetta; c)
assegnare questa etichetta ai pacchetti IP entranti; d) effettuare la commutazione dei pacchetti
esclusivamente mediante l’elaborazione della sola etichetta (label switching) e non mediante
l’elaborazione dell’indirizzo di destinazione e, eventualmente, di altri campi dell’header del
pacchetto IP.
La ragione di questo approccio risiedeva nel fatto che, all’epoca, la commutazione
ATM, che adotta la tecnica label switching in modo nativo, era nettamente più veloce di
quella IP che è invece basata sull’elaborazione degli indirizzi. L’obiettivo primario era quindi
quello di eseguire, per quanto possibile, la commutazione nello strato a commutazione di
etichetta piuttosto che in quello IP.
A seguito di queste iniziative, a partire dal 1997, l’IETF ha proposto la creazione di un
gruppo di lavoro avente come obiettivo lo sviluppo di uno standard comune denominato Multi
Protocol Label Switching (MPLS). La prima edizione di questo standard risale al gennaio
2001. Il termine Multi Protocol indica che la soluzione proposta in questo standard può essere
applicata a qualsiasi protocollo di rete (IP, SNA, IPX, ecc.). Nel seguito in questo capitolo ci
si riferirà esclusivamente al caso di supporto del protocollo IP che rappresenta l’applicazione
di maggiore interesse della tecnica MPLS.
Nel corso degli stessi anni, mentre si sviluppavano i lavori di definizione
3
dell’architettura MPLS, lo scenario tecnologico ha subito un’importante evoluzione con la
diffusione di una nuova generazione di router IP (GigaRouter) che di fatto cancellavano il
divario di prestazioni tra la tecnica ATM e quella IP dal punto di vista dei tempi di
commutazione e del throughput. Tuttavia, nonostante questo mutamento tecnologico, la
tecnica MPLS ha continuato a mantenere un ruolo chiave perché è in grado di fornire ad una
rete IP, oltre ad un miglioramento delle prestazioni, una serie di funzionalità addizionali,
quali:
•
Supporto della qualità di servizio
Una rete connectionless, come è una rete IP, non è in grado di soddisfare in modo pieno e
pienamente affidabile le richieste di trasferimento con garanzia di determinati parametri
di QoS: l’architettura Diffserv opera su traffico aggregato, mentre l’approccio utilizzato
nell’architettura Intserv è difficilmente scalabile. Una rete basata su un modo di
trasferimento orientato alla connessione ha invece la possibilità di gestire in modo molto
efficiente gli aspetti di QoS; la tecnica MPLS, che definisce una modalità di trasferimento
connection-oriented in una rete IP, fornisce quindi la base per la fornitura flessibile di
servizi con prefissati livelli di qualità.
•
Ingegneria del traffico
La tecnica MPLS consente l’instaurazione di cammini in rete in modo da ottimizzare
l’utilizzazione delle sue risorse. Questa funzione, normalmente indicata con il termine
Ingegneria del traffico (Traffic Engineering – TE), non può essere realizzata, almeno in
modo semplice, mediante le tecniche tradizionali di instradamento utilizzate nelle reti IP.
La ragione di questo risiede nel fatto che nelle reti IP il traffico tra due punti segue
sempre un’unica via, mentre con MPLS tra due punti può essere utilizzata una pluralità di
cammini; i flussi di traffico possono essere quindi instradati utilizzando tutti i camini
disponibili in modo da ottenere una distribuzione uniforme del traffico sulle risorse di
rete e di conseguenza un miglioramento complessivo delle prestazioni di rete.
•
Definizione di servizi evoluti
La tecnica MPLS consente di definire reti private virtuali (Virtual Private Network –
VPN) all’interno di una rete IP. Mediante questo servizio il traffico tra punti d’accesso
remoti può transitare in modo trasparente e completamente segregato dagli altri flussi di
traffico all’interno della rete IP con conseguenti vantaggi sia per la gestione della qualità
del servizio che per i requisiti di sicurezza.
•
Realizzazione di tecniche efficienti di riconfigurazione dei cammini in caso di guasto.
4
La tecnica MPLS consente, al momento dell’instaurazione di un cammino in rete, la
predisposizione di cammini alternativi, detti di protezione o di back-up, da utilizzarsi in
caso di guasto di uno o più tratte del cammino principale per re-instradare il flusso di
traffico supportato da quest’ultimo; questa soluzione consente di raggiungere dei tempi di
riconfigurazione dei cammini molto inferiori a quelli ottenibili utilizzando i normali
protocolli di routing IP e praticamente comparabili con quelli tipici di tecniche a circuito
come l’SDH.
Nel seguito vengono dapprima descritte le caratteristiche generali dell’architettura
MPLS e le sue modalità di applicazione, successivamente sono illustrate le funzionalità di
Ingegneria del traffico che sono rese disponibili dall’utilizzazione della tecnica MPLS.
I.2
La tecnica MPLS: principi generali
In una rete senza connessione, come la rete IP, il cammino seguito da un pacchetto tra la
sorgente e la destinazione viene determinato mediante la composizione di operazioni di
instradamento elementari ed indipendenti eseguite dai router che sono attraversati dal
pacchetto. Ogni router sceglie il router successivo (next-hop) verso cui rilanciare il pacchetto.
Tale scelta è eseguita esaminando l’header del pacchetto e accedendo ad una tabella di
instradamento che è aggiornata mediante l’utilizzazione di un protocollo di instradamento.
La scelta del next-hop operata da un router può essere modellata come la
concatenazione di due funzioni distinte: i) la suddivisione dell’insieme dei pacchetti da
rilanciare in una serie di sottoinsiemi distinti, denominati Forwarding Equivalent Class
(FEC); ii) l’associazione di una FEC ad uno specifico next-hop. Secondo questo modello, i
pacchetti appartenenti ad una stessa FEC saranno rilanciati da un router verso lo stesso nexthop. La Figura I.2.1 illustra il significato ora illustrato del concetto di FEC.
In particolare, in una rete IP, un router classificherà due pacchetti, che recano due
indirizzi di destinazione diversi A e B, come appartenenti alla stessa FEC se nella tabella di
instradamento del router esiste un prefisso X per cui tale prefisso rappresenta la
corrispondenza di lunghezza maggiore (longest match) per entrambi gli indirizzi A e B. In
questa visione, ogni router esegue, indipendentemente dagli altri, la propria classificazione dei
pacchetti in FEC e quindi due pacchetti che sono classificati come appartenenti alla stessa
FEC in un router possono appartenere a FEC diverse in un altro router.
In MPLS [RFC3031] l’assegnazione di un pacchetto ad una FEC è effettuata, una volta
per tutte, al momento in cui il pacchetto entra in una rete MPLS. La FEC assegnata al
pacchetto è codificata in un’etichetta, di lunghezza breve e fissa, trasportata nell’header del
5
pacchetto stesso. Questa etichetta sarà indicata nel seguito con il termine label. Quando il
router attraverso cui il pacchetto è entrato in una rete MPLS rilancia il pacchetto, questi
assegna al pacchetto il valore della label che sarà utilizzata dal router successivo per effettuare
la commutazione. Quando un pacchetto entra in un router, la label è utilizzata infatti come
indice per l’accesso diretto ad una tabella che conterrà il valore del next-hop e il valore della
nuova etichetta. La vecchia etichetta è sostituita con la nuova e il pacchetto è rilanciato verso
il router successivo. E’ il caso di sottolineare che una volta che ad un pacchetto sia stata
assegnata una label, la commutazione del pacchetto stesso è effettuata esaminando
esclusivamente la label senza tenere conto del valore degli altri campi dell’header IP.
FEC a
Payload
Next hop 1
FEC b
Header IP
......
......
FEC k
.....
FEC W
Next hop i
......
Next hop N
Figura I.2.1 - Illustrazione del concetto di FEC
I vantaggi della tecnica label switching sono numerosi:
•
il rilancio dei pacchetti è notevolmente semplificato e quindi si ottiene un miglioramento
delle prestazioni di un router IP;
•
il router di ingresso di una rete MPLS può associare un pacchetto ad una FEC anche sulla
base di informazioni non direttamente contenute nell’header IP del pacchetto; ad esempio
la porta di ingresso al router o il tipo di flusso informativo; si ha la possibilità quindi di
definire le FEC in modo più generale e flessibile;
•
l’etichetta assegnata ad un pacchetto che entra in una rete MPLS può essere definita in
modo da tenere conto del particolare router di ingresso e quindi rendendo possibile la
differenziazione del trattamento del traffico interno alla rete in base a questa
informazione;
•
in generale le regole di assegnazione delle label ai pacchetti possono essere rese più
sofisticate considerando anche altri fattori, quali ad esempio la priorità, la qualità di
servizio, senza per questo avere nessun impatto sulla complessità delle operazioni di
commutazione all’interno della rete;
6
•
un insieme di pacchetti può essere forzato a seguire in rete un cammino fissato a priori
(explicit routing), indipendentemente dalle indicazioni fornite dal tradizionale
instradamento IP; questa funzione è di fondamentale importanza nella realizzazione delle
funzioni di ingegneria del traffico.
In accordo alla precedenti osservazioni, una FEC può quindi corrispondere a: i) un
insieme di pacchetti che in un router sono instradati in accordo ad uno stesso prefisso IP: ii)
un flusso di pacchetti che devono subire lo stesso trattamento in rete (stesso percorso, stessa
qualità di servizio, ecc.). Nel primo caso un rouer IP con funzionalità MPLS può
autonomamente definire le FEC e quindi procedere all’assegnazione delle label; nel secondo
caso la definizione delle FEC deve essere stabilita a priori dall’amministratore di rete che
deve effettuare l’opportuna configurazione dei router. L’assegnazione delle label deve essere
quindi attivata utilizzando funzionalità del piano di controllo della rete mediante specifici
protocolli di segnalazione.
numerose tecniche di commutazione a pacchetto: le più note di queste tecniche sono
l’X.25, il Frame Relay e l’ATM.
A titolo di esempio nel caso dell’X.25, una tecnica a pacchetto largamente utilizzata
negli anni ’70 e ’80, il concetto di label trova una quasi completa analogia con il numero di
canale logico (logical channel number) che aveva lo scopo di distinguere i vari flussi di
traffico generati utenti diversi che condividevano lo stesso link. Nelle tecniche Frame Relay e
ATM la corrispondenza della label può essere trovata rispettivamente nel Data Link
Connection Identifier (DLCI) e nel coppia Virtual Channel Identifier e Virtual Path Identifier
(VCI/VPI) che hanno lo scopo di distinguere i flussi di traffico generati dagli utenti e di
determinare il tipo di trattamento in rete dei vari flussi.
I.3
Label Switching Router (LSR) e modalità di definizione delle label
Nel paragrafo precedente è stato già definito il concetto di FEC come un insieme di
pacchetti IP che devono essere trattati da un router nello stesso modo, ad esempio: che devono
essere rilanciati verso lo stesso next-hop e appartenenti alla stessa classe di servizio. Ad ogni
FEC è assegnata una label che sarà utilizzata dai router per eseguire la funzione di
commutazione dei pacchetti.
Un router che supporta la tecnica MPLS è denominato Label Switching Router (LSR) e
la tipologia di commutazione è denominata in generale come label switching.
Un dominio di rete MPLS è formato quindi da un insieme di LSR direttamente connessi
tra loro. Il traffico entrante ad un dominio MPLS può provenire sia da reti esterne al dominio,
7
quali ad esempio le reti locali d’utente, sia da router IP tradizionali appartenenti a sezioni di
rete IP che non supportano la tecnologia MPLS (Figura I.3.1). Un LSR che connette un
dominio MPLS con altri nodi che sono all’esterno del dominio è detto Edge LSR, mentre un
LSR che è connesso solo ad altri LSR è detto Core LSR.
Rete IP
Edge
LSR
Core
LSR
Edge
LSR
Core
LSR
Rete
IP
Rete
IP
Dominio
MPLS
Edge
LSR
Core LSR
Figura I.3.1 – Rappresentazione di un dominio MPLS.
Una label è un identificatore di lunghezza fissa che è utilizzato per identificare una FEC.
Una label ha validità locale, ciò significa che l’associazione tra FEC e uno specifico valore di
una label è valida solo su una tratta di rete, la stessa FEC può essere quindi identificata da
label diverse su tratte di rete diverse.
L’operazione di associazione di una label ad una FEC è denominata binding. Due LSR,
indicati come Ru e Rd, possono accordarsi per eseguire un’associazione tra la FEC F e
l’etichetta L, ciò significa che quando Ru trasmetterà verso Rd un pacchetto appartenente alla
FEC F, il pacchetto venga etichettato con la label L. Tale etichetta sarà indicata come label
uscente dal LSR Ru e come label entrante al LSR Rd. Inoltre nei confronti di questo binding,
Ru sarà indicato come upstream LSR, mentre Rd avrà il ruolo di downstream LSR. La Figura
I.3.2 illustra i concetti ora introdotti. E’ responsabilità dei due LSR, Ru e Rd, assicurare
l’univocità dell’associazione tra la FEC F e la label L, ciò significa che non dovranno essere
accettati ulteriori binding tra la label L e FEC diverse da F.
Nell’architettura MPLS la decisione di effettuare un’associazione tra una FEC F e una
label L è sempre presa dal downstream LSR che informa l’upstream LSR dell’avvenuto
binding. Quest’ultima operazione è detta distribuzione della label ed è quindi sempre eseguita
nella direzione downstream-upstream rispetto alla direzione del traffico. Le procedure seguite
8
da un downstream LSR per distribuire le etichette verso l’upstream LSR sono definite in un
protocollo denominato genericamente protocollo di distribuzione delle etichette (Label
Distribution Protocol. - LDP). Come sarà più in dettaglio illustrato nel seguito, l’architettura
MPLS [RFC 3031] non definisce l’uso di uno specifico protocollo di distribuzione, ma sono
state proposti numerosi protocolli, sia derivati da estensioni di protocolli esistenti, es. MPLSBGP, MPLS-RSVP, sia appositamente definiti, es. MPLS-LDP, MPLS-CR-LDP. Nel seguito,
salvo indicazione contraria, con il termine Label Distribution Protocol si indicherà un
generico protocollo di distribuzione delle etichette, senza riferimento specifico ad uno dei
protocolli proposti.
Pacchetti della FEC F
Label L
Direzione del traffico
Direzione di distribuzione delle label
Upstream
LSR - Ru
Downstream
LSR - Rd
Figura I.3.2 - Illustrazione dei concetti di binding tra label e FEC.
L’architettura MPLS prevede un modello molto flessibile di uso delle label in cui un
singolo pacchetto può trasportare un numero m, con m≥1, di label organizzate in m livelli
gerarchici (label stack). La label di livello gerarchico più basso sarà indicata come label di
livello 1, mentre la label di livello gerarchico più elevato sarà indicata come label di livello m
(Figura I.3.3). In ogni caso, qualsiasi sia il numero di label trasportate l’instradamento di un
pacchetto in un LSR dipende sempre ed esclusivamente dalla label di livello gerarchico
maggiore trasportata dal pacchetto stesso.
E’ il caso di notare che il concetto di label stack può essere visto come una
generalizzazione del doppio livello di multiplazione (VCI/VPI) definito nell’ATM. Come sarà
illustrato anche nel seguito, la disponibilità di un numero qualsiasi di livelli di etichetta è
particolarmente utile per la creazione di tunnel MPLS e per la definizione di livelli gerarchici
all’interno di un dominio MPLS.
Label
m
Label
2
Label
1
Datagramma IP
Figura I.3.3 – Illustrazione del concetto di label stack
9
Una label MPLS [RFC 3032] ha una lunghezza uguale a 32 bit ed il suo formato è
mostrato in Figura I.3.4. Il significato dei campi è il seguente:
32 bit
8 bit
8 bit
Label value
20 bit
8 bit
Exp S
3 bit
8 bit
TTL
8 bit
1 bit
Figura I.3.4 – Formato di una label MPLS.
•
Label value (20 bit): indica il valore della label ed è utilizzato come indice per l’accesso
alla tabella di routing dell’LSR in cui sono indicati l’identificatore della porta d’uscita
verso cui deve essere rilanciato il pacchetto e il valore della label sulla tratta successiva.
•
Experimental Use (EXP) (3 bit): questi bit sono riservati per usi successivi, ad esempio,
nel caso di architettura Diffserv over MPLS, possono codificare la classe di servizio a cui
appartiene il pacchetto.
•
Bottom of Stack (S) (1 bit): se questo bit è posto ad 1, indica che la label è quella di livello
più basso, in tutti gli altri casi il bit S è sempre posto a 0.
•
Time To Live (TTL) (8 bit): il campo ha un significato del tutto analogo a quello del
campo omonimo presente nel header di un datagramma IP ed indica il numero massimo di
salti che ancora il pacchetto può eseguire in rete prima che raggiunga la destinazione o
venga scartato. Il valore di tale campo viene decrementato di uno ogniqualvolta viene
elaborato da un LSR. La descrizione puntuale delle regole di elaborazione del campo TTL
saranno indicate nel seguito.
I.4
Label Switching Path (LSP): definizione e funzioni degli LSR
Il cammino seguito da un pacchetto in una rete MPLS è denominato Label Switching
Path (LSP). In particolare, per uno specifico pacchetto P, un LSP di livello m è definito dalla
sequenza di LSR (R1, R2, …, Rn) che soddisfano le seguenti proprietà:
•
l’LSR R1, che rappresenta il punto di inizio del LSP, è il router che applica la label di
ordine m al pacchetto P;
10
•
in tutti gli LSR Ri (1<i<n) il pacchetto P sarà instradato attraverso l’esame della label di
ordine m, inoltre il numero di label contenute nel pacchetto sarà sempre non inferiore a m;
•
se nel transito tra due LSR, Ri e Ri+1, il pacchetto P attraversa altri elementi di rete che
effettuano l’instradamento sulla base di una label diversa da quella di ordine m, ad
esempio di ordine m+k, ciò avviene solo se altre label k addizionali sono state aggiunte
dal router Ri e da altri elementi di rete intermedi.
In altre parole un LSP di ordine m per un pacchetto P è dato dalla sequenza di router per
cui: a) il primo LSP (Ingress LSR) applica la label di ordine m; b) i router intermedi (Transit
LSR) eseguono l’instradamento elaborando e quindi sostituendo la label di ordine m; c)
l’ultimo router (Egress LSR) che provvede all’eliminazione della label di ordine m.
La Figura I.4.1 illustra i concetti precedentemente esposti nel caso di gestione di
etichette di ordine m=1.
Rete
MPLS
Ingress Routing Table
Destination
Out
134.5/16
(y1, 84)
MPLS Table
Out
(x3, 46)
(y3, 3)
134.5.1.5 46
134.5.1.5
y3
x3
y1
x4
134.5.1.5
x2
134.5.1.5 84
y2
Egress
LSR
3
Egress Routing Table
Transit
LSR
Rete IP
Rete IP
Transit
LSR
Ingress
LSR
134.5.1.5
In
In
Next Hop
(x4, 3)
134.5.6.1
MPLS Table
In
Out
(x2, 84)
(y2, 46)
Figura I.4.1 – Illustrazione del concetto di Label Switched Parth (LSP) in una rete MPLS.
I.4.1
Tabelle di trattamento delle label in un LSR
Entrando in un maggior grado di dettaglio nel meccanismo di elaborazione delle label in
un nodo MPLS, si evidenzia che un LSR memorizza le informazioni di correlazione tra le
label entranti e quelle uscenti in tabelle denominate Next Hop Label Forwarding Entry
(NHLFE). Una NHLFE contiene le seguenti informazioni:
•
Il next hop verso cui deve essere rilanciato il pacchetto;
•
Le operazioni da eseguire sulle etichette del pacchetto, queste possono appartenere ad una
delle seguenti categorie:
11
− sostituzione dell’etichetta di livello gerarchico più elevato (label swapping);
− eliminazione dell’etichetta di livello gerarchico più elevato (label popping);
− sostituzione dell’etichetta di livello gerarchico correntemente più elevato e
inserimento di una nuova etichetta in testa allo stack delle label (label pushing).
Nel caso in cui ad un LSR arrivi un pacchetto che trasporta una label MPLS e che
quindi è stato già etichettato da un LSR precedente, l’LSR individua la NHFLE da applicare
al pacchetto utilizzando una tabella denominata Incoming Label MAP (ILM). Il valore della
label di livello gerarchico più elevato trasportata dal pacchetto entrante viene utilizzata come
indice per l’accesso alla ILM (Figura I.4.2).
Incoming Label Map
(ILM)
Label A
Pacchetto
NHLFEA
.
.
Label L
Label L
NHLFEL
.
.
Label W
NHLFEW
Figura I.4.2 – Utilizzazione della Incoming Label Map (ILM) in un LSR.
Nel caso invece in cui ad un LSR arrivi un pacchetto che non trasporta una label MPLS
e che deve essere rilanciato in un LSP, l’LSR individua la NHFLE da applicare al pacchetto
utilizzando una tabella denominata FEC-to-NHLFE MAP (FTN) che mette in relazione ogni
FEC con la corretta NHLFE (Figura I.4.3).
FEC-to-NHLFE Map
(FTN)
FEC A
Payload
NHLFEA
.
.
Header
FEC X
NHLFEX
.
.
FEC W
NHLFEW
Figura I.4.3 – Utilizzazione della FEC-to-NHLFE Map (FTN) in un LSR.
I.4.2
Penultimate Hop Popping.
Per quanto riguarda l’eliminazione di una label da un pacchetto, questa operazione può
12
essere eseguita, oltre che dal router Rn, ovvero l’Egress LSR di un LSP, anche dal router Rn-1,
ovvero dal penultimo LSR di un LSP. Questa seconda possibilità, denominata Penultimate
Hop Popping, è giustificata dal fatto che l’instradamento sul link che unisce gli LSR Rn-1 e Rn
è effettuato dal router Rn-1 esaminando la label associata al pacchetto in entrata al router
stesso, applicata dal router Rn-2; inoltre, una volta che il pacchetto è stato rilanciato verso
l’Egress LSR, la label non ha più nessuna utilità poiché l’operazione di instradamento che
sarà effettuata da questo LSR dovrà necessariamente avvenire esaminando la label di livello
inferiore o direttamente l’header del pacchetto IP. Il vantaggio pratico del Penultimate Hop
Popping risiede nel fatto che viene semplificata l’elaborazione delle etichette nell’Egress
LSR. Viene infatti eliminata la necessità di accedere alla tabella di routing con la label che
deve essere rimossa e che quindi non darà nessun risultato dal punto di vista
dell’instradamento, per poi ripetere l’operazione con la label di livello inferiore o mediante la
completa elaborazione dell’header IP. La Figura I.4.4 mostra la differenza tra la funzione di
label popping eseguita all’ultimo o al penultimo LSR di un LSP.
Rn
Rn-1
35
IP
IP
27
Rn
Rn-1
IP
LSP
Label Popping all’ultimo LSR di un LSR
IP
35
IP
IP
LSP
Label Popping al penultimo LSR di un LSR
(Penultimate Hop Popping)
Figura I.4.4 – Rimozione dell’etichetta al penultimo LSR di un LSP in una rete MPLS.
I.4.3
Aggregazione e merging delle label
Con riferimento alla creazione di FEC sulla base dei prefissi IP, possono essere definite
due possibili approcci. Il primo, che è raffigurato in Figura I.4.5a, prevede di creare FEC
distinte per ogni prefisso. Con tale approccio però si corre il rischio di definire un numero
molto elevato di FEC, e quindi di label, che seguono lo stesso percorso in rete. In queste
condizioni, per superare questo elemento di inefficienza, considerando che, nella logica
MPLS, FEC che seguono lo stesso percorso in rete formano esse stesse una FEC, si può
creare un’unica FEC, o un sottoinsieme di FEC, ognuna delle quali è associato un insieme di
prefissi (Figura I.4.5b). Questa seconda modalità è definita aggregazione. Il numero di
prefissi che sono associati ad una FEC difinisce la granularità dell’aggregazione.
13
L’aggregazione consente di ridurre il numero di label che sono necessarie per gestire un
insieme di pacchetti ed inoltre riduce il traffico di segnalazione necessario alla gestione degli
LSP presenti in rete.
Egress
LSR
Ingress
LSR
151.25.10.5/18
151.25.27.3/18
151.25.32.8/18
191.144.26.12/24
191.144.26.24/24
N prefissi = N FEC
a
Egress
LSR
Ingress
LSR
151.25.10.5/18
151.25.27.3/18
151.25.32.8/18
191.144.26.12/24
191.144.26.24/24
N prefissi = 1 FEC
b
Figura I.4.5 – Modalità di associazione dei prefissi IP alle FEC: a) FEC separate per ogni
prefisso (non aggregazione); b) unica FEC per un insieme di prefissi (aggregazione).
Nell’ipotesi che ad un LSR arrivino pacchetti, entranti da più interfacce d’ingresso,
appartenenti alla stessa FEC ed etichettati con label diverse, l’LSR ha la possibilità di
rilanciare tali pacchetti etichettandoli in uscita con la stessa label. Questa operazione è detta
label merging. Un LSR che supporta la funzione di label merging è detto merging LSR,
mentre se non è in grado di effettuare questa funzione è detto non-merging LSR.
Se un LSR utilizza la funzione di label merging, il numero di label entranti per una FEC
è inferiore o uguale al numero di LSR upstream, adiacenti all’LSR in questione, per quella
FEC; il numero di label uscenti per una FEC è invece sempre unitario. In caso invece di nonmerging LSR, il numero di label entranti e uscenti per una FEC è uguale al numero
complessivo di LSR upstream che rilanciano traffico appartenente a quella FEC.
I.5
Instaurazione e selezione del percorso di un LSP
L’instaurazione di un LSP può avvenire secondo due modalità: i) controllo indipendente
(Indipendent LSP Control); ii) controllo ordinato (Ordered LSP Control).
Nel caso di controllo indipendente, ogni LSR nel momento in cui riconosce una nuova
FEC, ad esempio un nuovo prefisso segnalato dal protocollo di routing IP, può decidere di
assegnare a questa FEC una nuova label MPLS e di distribuire la nuova etichetta in rete
(Figura I.5.1).
Questa soluzione riproduce esattamente la modalità di funzionamento dei classici
protocolli di routing delle reti IP e si basa proprio su quest’ultimi per assicurare una rapida
convergenza così da assicurare la corretta consegna dei pacchetti a destinazione. Occorre
tuttavia osservare che con questa modalità non è possibile stabilire e controllare in anticipo le
14
caratteristiche che deve avere un LSP ed è quindi inadatta se occorre assicurare che una
particolare FEC segua un particolare camminino in rete, eventualmente caratterizzato da una
specifico insieme di parametri.
(1) Messaggio OSPF (151.100/18)
(3) Messaggio OSPF (151.100/18)
(2) Binding 151.100/18 – Label X
LSR A
(4) Binding 151.100/18 – Label Y
LSR B
LSR C
Figura I.5.1 – Modalità a controllo indipendente nell’instaurazione di un LSP.
L’alternativa al controllo indipendente è il controllo ordinato; in questo caso un LSR
esegue le operazioni di assegnazione di un etichetta ad una FEC solo in due casi: a) se è
l’Egress LSR per quella LSR; b) se riceve per quella FEC una label dal downstream LSR
della FEC stessa (Figura I.5.2).
(1) Binding FEC F – Label X
LSR A
(1) Binding FEC F/18 – Label Y
LSR B
LSR C
Figura I.5.2 – Modalità a controllo ordinato nell’instaurazione di un LSP.
La modalità di controllo ordinato è in grado di assicurare che l’LSP soddisfi un insieme
di specifiche proprietà sia logiche che prestazionali, ad esempio che segua un determinato
percorso in rete o che sia disponibili su link attraversati un specifico ammontare di risorse.
Le due modalità di controllo sono pienamente interoperabili e la scelta tra le due
alternative è lasciata all’operatore di rete.
Accanto alle modalità di controllo sono da definire le modalità di selezione del percorso
associato ad un LSP per una particolare FEC. L’architettura MPLS prevede l’esistenza di due
modalità: a) hop by hop routing; b) explicit routing.
La modalità hop by hop routing prevede che ogni LSR scelga indipendentemente il next
hop per ogni FEC operando in modo del tutto analogo ad un router di una rete IP. Un LSP il
cui percorso è stato individuato secondo questo modalità è detto hop by hop routed LSP.
Dovrebbe risultare evidente che un hop by hop routed LSP può essere instaurato sia con la
modalità a controllo indipendente che con la modalità a controllo ordinato.
Al contrario della precedente, la modalità explicit routing non consente che la scelta del
15
next hop di un cammino sia eseguita in modo indipendente dai singoli LSR, ma impone che
un LSR, solitamente l’ingress o l’egress LSR di un LSP, specifici l’intero insieme, o
eventualmente un sottoinsieme, degli LSR che devono essere attraversati dall’LSP. Se l’LSR
iniziatore specifica tutti gli LSR si dice che l’LSP è instradato in modo esplicito strettamente
vincolato (strictly explicitly routed LSP), mentre se indica solo un sottoinsieme degli LSR,
l’LSP è detto instradato in modo esplicito loscamente vincolato (loosely explicitly routed
LSP).
La sequenza degli LSR attraversati da un explicit router LSP può essere determinata su
base configurazione o può essere decisa dinamicamente dall’LSR che prende l’iniziativa di
instaurare l’LSP sulla base, ad esempio, della tipologia di traffico associato alla FEC e delle
informazioni in suo possesso sulla topologia di rete e sul grado di occupazione delle risorse.
Si sottolinea che la modalità di instradamento esplicito fornisce un supporto
indispensabile per l’implementazione delle strategie di ingegneria del traffico; inoltre
l’instaurazione di un explicitly routed LSP può avvenire esclusivamente mediante la modalità
a controllo ordinato.
I.6
LSP Tunnels
Un LSP può essere utilizzato per la creazione di tunnel all’interno di reti IP.
Come è noto, in una rete IP, se due router, Ru e Rd, non sono direttamente connessi da
un link, può essere realizzato un tunnel tra i due router incapsulando i pacchetti emessi da Ru
e diretti verso Rd in un’unità dati in cui l’indirizzo di destinazione corrisponde l’indirizzo del
router Rd. In questo caso il router Ru è detto punto terminale trasmittente (Transmit endpoint), mentre Rd è detto punto terminale ricevente (Receive end-point). La Figura I.6.1
illustra il concetto di tunnel in una rete IP.
Destination
Address
Router
Ru
Rete IP
Router
B
Router
Rd
Destination
Address
Router
A
Destination
Address
Address
Router Rd
Figura I.6.1 – Illustrazione del concetto di tunnel in una rete IP.
16
Se un tunnel IP è realizzato mediante un LSP MPLS; l’LSP è detto LSP Tunnel. Si
distinguono due tipi di LSP Tunnel: a) hop-by-hop routed LSP tunnel sono realizzati mediante
hop by hop routed LSP, tali tunnel quindi seguono all’interno del dominio MPLS i cammini
indicati dai protocolli di instradamento, tali tunnel sono anche indicati con il termine Uniform
Model LSP; b) explicit routed LSP tunnel sono realizzati mediante explicitly routed LSP, di
conseguenza, i percorsi seguiti da tali LSP nel dominio MPLS possono essere diversi rispetto
a quelli indicati dal protocollo di instradamento e decisi in base a considerazioni e strategie
alternative, tali tunnel sono anche indicati con il termine Pipe Model LSP.
Il concetto di LSP tunnel semplice può essere generalizzato definendo una gerarchia di
LSP tunnel. Con riferimento alla Figura I.6.2, consideriamo un LSP, denominato LSP tunnel
di livello 1, costituito da quattro LSR (R1, R2, R3, R4), supponiamo inoltre che i router R2 e
R3 non siano connessi direttamente, ma che a sua volta siano i punti terminali di un nuovo
LSP tunnel, indicato come LSP tunnel di livello 2, composto dai router (R2, R21, R22, R23,
R3). Un pacchetto emesso dal router R1 avrà quindi sulla tratta R1-R2 una singola label (label
di livello 1). L’LSR R2 esaminando la label entrante determinerà che il pacchetto dovrà
entrare nel tunnel di livello 2, effettuerà quindi la sostituzione della label di primo livello che
sarà elaborata dal router R3 e applicherà la label di secondo livello. Quest’ultima label
guiderà il pacchetto all’interno dell’LSP tunnel di livello 2. Il router R23, che è il penultimo
LSR nel tunnel di livello 2, rimuoverà la label di livello 2 e rilancerà il pacchetto verso il
router R3 con la sola etichetta di livello 1. Il router R3 essendo il penultimo LSR nel tunnel di
livello 1, rimuoverà a sua volta la label di livello 1 e rilancerà il pacchetto senza etichette
verso il router terminale R4.
R1
LSP
Tunnel
1
R2
LSP
Tunnel
2
R21
Pacchetto IP
R22
Label di livello 1
R23
R3
R4
Label di livello 2
Figura I.6.2 – Gerarchia di LSP e utilizzazione della tecnica di label stack.
L’utilizzazione di una gerarchia di LSP realizzata mediante la tecnica del label stacking
fornisce un elevato grado di flessibilità ad una rete MPLS. Ad esempio un grande utente affari
che gestisce una rete MPLS distribuita su più aree può definire all’interno di ciascuna area un
17
insieme di LSP. Gli LSP che trasportano traffico inter-area possono essere aggregati fra loro,
costituendo LSP di secondo livello, per essere offerti alla sezione di transito della rete. A loro
volta, gli LSP di secondo livello possono essere aggregati ad un livello gerarchico superiore,
con LSP provenienti da altri utenti, ciò allo scopo di ridurre il numero complessivo di flussi di
traffico da gestire in rete e quindi semplificando la gestione della rete stessa.
I.7
Elaborazione del campo TTL della Label MPLS
Come indicato precedentemente, in senso generale il campo TTL indica il numero
massimo di salti che ancora il pacchetto può eseguire in rete prima che raggiunga la
destinazione o venga scartato. Tale significato tuttavia deve essere meglio specificato per: a)
tener conto della possibile gerarchia di LSP che un pacchetto può attraversare in un dominio;
b) per definire meglio la sua relazione con il campo TTL compreso nell’header del pacchetto
IP.
Si definiscono:
•
Incoming TTL (iTTL) di un pacchetto MPLS è il valore del campo TTL contenuto nella
label di livello gerarchico più elevato trasportata dal pacchetto stesso all’ingresso di un
LSR;
•
Outgoing TTL (oTTL) di un pacchetto MPLS è invece il valore del campo TTL della label
di livello gerarchico più elevato trasportata dal pacchetto stesso all’uscita da un LSR;
normalmente risulta oTTL=iTTL-1, se oTTL=0 il pacchetto non è rilanciato ed è inviato
un pacchetto ICMP verso l’host sorgente.
La gestione del campo TTL [RFC 3443] si differenzia in base al tipo di tunnel LSP
impiegato. La Figura I.7.1 si riferisce alla determinazione del campo TTL nel caso di Uniform
Model LSP ed è valida sia nel caso di rimozione dell’etichetta all’Egress LSR o al Penultimate
LSR.
La Figura I.7.2 e la Figura I.7.3 si riferiscono invece al caso di Pipe Model LSP , in
particolare la Figura I.7.2 a si riferisce alla rimozione all’Egress LSR, mentre la Figura I.7.3
riporta il caso di Penultimate hop popping.
Come risulta dalla figure precedenti, la principale differenza tra i due modelli di LSP
consiste nella modalità con cui sono tenuti in conto i salti effettuati nei tunnel LSP.
Nel caso di Uniform Model LSP, il campo TTL all’uscita di un LSP è decrementato del
numero complessivo di salti effettuati sia all’interno dell’LSP stesso che degli eventuali salti
effettuati negli LSP di livello superiore. Il valore del campo TTL in uscita dal dominio MPLS
sarà quindi lo stesso di quello che sarebbe stato se il dominio attraversato fosse stata una
18
tradizionale rete IP.
TTL(k) TTL(k+1)
R2
---
n-2
TTL(k) TTL(k+1)
...
---
Ri-1
n-i+2
TTL(k) TTL(k+1)
---
TTL(k) TTL(k+1)
n-1
---
R1
TTL(k)
n
n-i+1
Ri
Ingress
LSR
LSP di
livello k
LSP di
livello k+1
TTL(k)
n-i
Egress o
Penultimate
LSR
Figura I.7.1 – Elaborazione del campo TTL nel caso di Uniform Model LSP in entrambi i casi
di rimozione dell’etichetta all’Egress LSR e al Penultimate LSR.
TTL(k) TTL(k+1)
R2
n-1
M-1
TTL(k) TTL(k+1)
...
n-1
Ri-1
M-i+3
TTL(k) TTL(k+1)
n-1
TTL(k) TTL(k+1)
M
n-1
R1
TTL(k)
n
Ri
Ingress
LSR
TTL(k)
Egress
LSR
LSP di
livello k
a
M-i+2
n-2
LSP di
livello k+1
Figura I.7.2 – Elaborazione del campo TTL nel caso di Pipe Model LSP con rimozione
dell’etichetta all’Egress LSR.
TTL(k) TTL(k+1)
R2
n-1
M-1
TTL(k) TTL(k+1)
n-1
TTL(k) TTL(k+1)
...
n-1
M-i+3
Ri-2
TTL(k) TTL(k+1)
M
n-1
M-i+2
TTL(k)
Ri
n-1
R1
TTL(k)
n
n-2
Ri-1
Penultimate
LSR
Ingress
LSR
b
TTL(k)
LSP di
livello k
Egress
LSR
LSP di
livello k+1
Figura I.7.3 – Elaborazione del campo TTL nel caso di Pipe Model LSP con rimozione
dell’etichetta al Penultimate LSR.
19
Nel caso invece di Pipe Model LSP, il valore del campo TTL della label uscente può
essere assegnato all’inizio di ogni LSP di livello gerarchico superiore indipendentemente dal
valore del campo iTTL in ingresso al LSR che esegue la funzione di pushing della label di
livello superiore. Inoltre, il transito in un LSP di livello gerarchico superiore viene considerato
come un singolo salto per il calcolo del campo TTL della label di livello gerarchico
immediatamente inferiore. Si noti infine che nel caso b, a differenza del caso a, il penultimate
LSR non decrementa il valore del campo TTL dell’etichetta di livello k, ciò consente di avere
lo stesso valore del campo TTL in uscita dell’Egress LSR nei due casi.
20
II
MULTI PROTOCOL LABEL SWITCHING (MPLS) – GESTIONE
DELLE LABEL E INGEGENRIA DEL TRAFFICO
II.1 Procedure di gestione delle label
Come detto in precedenza, nell’architettura MPLS l’operazione di associazione tra una
FEC F e una label L è sempre effettuata dal downstream LSR che informa l’upstream LSR
dell’avvenuto binding. Quest’ultima operazione è detta distribuzione della label (label
distribution) ed è quindi sempre eseguita nella direzione downstream-upstream rispetto alla
direzione del traffico.
In generale, possono però essere definite due modalità principali secondo cui viene
attivato questo processo.
Nella prima, un LSR può richiedere a un altro LSR verso cui deve rilanciare i pacchetti
appartenenti ad una specifica FEC F, che quindi rappresenta il next hop per quei pacchetti,
l’esecuzione del binding tra la FEC F e una nuova label L e la relativa distribuzione di questa
etichetta. Questa modalità è detta Downstream-on-demand.
La seconda modalità prevede che un LSR possa effettuare,in modo autonomo senza
ricevere richieste da parte di altri LSR, il binding tra una FEC F e una label L e la
distribuzione della label verso l’upstream LSR. Questa modalità è detta Unsolicetd
Downstream.
Le precedenti due modalità possono essere utilizzate contemporaneamente nello stesso
dominio MPLS.
Nel quadro delle due modalità principali ora illustrate, l’architettura MPLS definisce
anche un insieme di procedure particolari per la gestione di un LSP. Alcune di queste
procedure sono eseguite dal LSR downstream altre dal LSR upstream.
In particolare sono previste:
•
Procedure eseguite dall’LSR downstream
− Procedura di distribuzione (Distribution procedure)
− Procedura di disattivazione (Withdrawal procedure)
•
Procedure eseguite dall’LSR upstream
− Procedura di richiesta (Request procedure)
− Procedura di dichiarazione di indisponibilità (Not Available procedure)
− Procedura di rilascio (Release procedure)
− Procedura di uso della label (Label Use procedure)
21
Ognuna della precedenti procedure presenta alcune possibili varianti. Nel seguito sarà
descritto il significato di ogni procedura, le su varianti e lo scambio di messaggi che ciascuna
di esse comporta. E’ il caso di sottolineare che l’architettura MPLS non supporta tutte le
possibili combinazioni delle possibili varianti delle procedure. L’insieme delle possibili
combinazioni sarà anche descritto nel seguito.
Le procedure verranno presentate in modo astratto prescindendo dalla particolare
utilizzazione di uno specifico di Label Distribution Protocol. E’ evidente che ciascuna delle
procedure dovrà essere mappata nei messaggi e nei flussi informativi particolari di un
specifico protocollo.
II.1.1 Procedura di distribuzione (Distribution procedure)
La procedura di distribuzione è utilizzata da un LSR downstream per distribuire una
label associata ad una particolare FEC verso l’LSR upstream sull’LSP da instaurare.
Sono possibili quattro diverse alternative di attuazione di questa procedura:
•
PushUnconditional
Un LSR Rd esegue autonomamente un binding tra una FEC F e una label L e esegue la
distribuzione verso l’LSR Ru. Questa procedura si applica nel caso di assegnazione delle
etichette di tipo unsolicited downstream quando l’instaurazione avviene con la modalità a
controllo indipendente (Figura II.1.1) e comporta la distribuzione delle label per tutti i
prefissi contenuti nella tabella di instradamento di Rd.
(1)
Esecuzione binding
tra FEC F e Label L
(2) Invio del Messaggio di Label distribution
LSR Ru
LSR Rd
Figura II.1.1 – Procedura di distribuzione delle label di tipo PushUnconditional.
•
PushConditional
In questa procedura un LSR Rd esegue il binding tra una FEC F e una label L solo in due
casi: a) Rd riceve una notifica di binding da un LSR Rn a valle rispetto alla direzione del
traffico sull’LSP; b) Rd è l’Egress LSR del LSP.
22
(2)
Esecuzione binding
tra FEC F e Label L
(3) Invio del Messaggio di Label distribution
LSR Ru
(1) Invio del Messaggio di Label distribution
LSR Rd
LSR Rn
Figura II.1.2 – Procedura di distribuzione delle label di tipo PushConditional.
Questa procedura (Figura II.1.2) si applica nel caso di assegnazione delle etichette di tipo
unsolicited downstream quando l’instaurazione avviene con la modalità a controllo
ordinato. A differenza della procedura precedente, la distribuzione delle etichette è
condizionata al fatto che l’LSR riceva una un messaggio di label binding dall’LSR next
hop o che l’LSR sia l’ultimo LSR dell’LSP.
•
PulledUnconditional
In questa procedura un LSR Rd esegue il binding tra una FEC F e una label L solo se
riceve una richiesta di binding da un LSR Ru a monte rispetto alla direzione del traffico
sull’LSP (Figura II.1.3). Questa procedura si applica nel caso di assegnazione delle
etichette di tipo downstream-on-demand quando l’instaurazione avviene con la modalità a
controllo indipendente.
LSR Ru
(2)
Esecuzione binding
tra FEC F e Label L
(1) Invio di una richiest di binding
(3) Invio del Messaggio di Label distribution
LSR Ru
LSR Rd
Figura II.1.3 – Procedura di distribuzione delle label di tipo PulledUnconditional.
•
PulledConditional
In questa procedura un LSR Rd esegue il binding tra una FEC F e una label L solo se sono
soddisfatte entrambe le seguenti condizioni: a) Rd riceve una notifica di binding da un
LSR Rn a valle rispetto alla direzione del traffico sull’LSP o è l’Egress LSR del LSP; b)
Rd riceve una richiesta di binding da un LSR Ru a monte rispetto alla direzione del
traffico sull’LSP (Figura II.1.4).
Questa procedura si applica nel caso di assegnazione delle etichette di tipo downstreamon-demand quando l’instaurazione avviene con la modalità a controllo ordinato.
23
(3)
Esecuzione binding
tra FEC F e Label L
(2) Invio di una richiest di binding
(1) Invio del Messaggio di Label distribution
(4) Invio del Messaggio di Label distribution
LSR Ru
LSR Rd
LSR Rn
Figura II.1.4 – Procedura di distribuzione delle label di tipo PulledConditional.
II.1.2 Procedura di disattivazione (Withdrawal procedure)
La procedura di disattivazione è utilizzata da un LSR downstream per comunicare
all’LSR upstream il termine della validità di un’associazione tra una label L e una FEC F.
Esiste una sola alternativa di attuazione della procedura che consiste semplicemente nell’invio
da parte dell’LSR Rd di un messaggio di unbinding verso l’LSR Ru (Figura II.1.5).
(1)
Termine del binding
tra FEC F e Label L
(2) Invio del Messaggio di Unbinding
LSR Ru
LSR Rd
Figura II.1.5 – Procedura di disattivazione della label.
II.1.3 Procedura di richiesta (Request procedure)
La procedura di richiesta di un binding tra una FEC F e una label L è usata dall’LSR
upstream nell’ambito di una procedura di instaurazione di un LSP di tipo downstream-ondemand nella modalità a controllo ordinato.
Sono definite tre alternative di attuazione di questa procedura
•
RequestNever
L’LSR upstream (Ru) non invia in nessun caso la richiesta di binding.
Questa alternativa si adatta al caso di instaurazione di un LSP di tipo unsolicited
downstream sia di tipo a controllo indipendente che a controllo ordinato, in cui l’LSR
dowstream (Rd) usi le procedure di distruzione di tipo PushConditional o
PushUnconditional (Figura II.1.1 e Figura II.1.2). Non è invece ovviamente compatibile
con le alternative di instaurazione di un LSP downstream on demand di tipo
PulledConditional o PulledUnconditional.
•
RequestWhenNeeded
24
L’LSR upstream (Ru) invia una richiesta di binding all’LSR downstream ogniqualvolta
rivela una nuova FEC F a cui non è ancora associata una label L.
Questa alternativa si adatta al caso di instaurazione di un LSP di tipo downstream on
demand di tipo a controllo indipendente.
•
RequestonRequest
L’LSR upstream (Ru) invia una richiesta di binding all’LSR downstream ogniqualvolta
riceve una sua volta dall’LSR a monte una richiesta di binding tra una FEC F e una label
L.
Questa alternativa si adatta al caso di instaurazione di un LSP di tipo downstream on
demand di tipo a controllo ordinato.
II.1.4 Procedura di dichiarazione di indisponibilità (Not Available procedure)
Si applica quando un LSR che riceve una richiesta di binding non è in grado di
soddisfare la richiesta. L’LSR Rd emette verso l’LSR Ru un messaggio che specifica la
ragione di questa indisponibilità. Le modalità di reazione dell’LSR Ru sono codificate in due
possibili alternative procedurali:
•
RequestRetry
L’LSR Ru emette di nuovo la richiesta dopo un determinato intervallo di tempo. Questa
procedura si utilizza nel caso di modalità di instaurazione downstream on demand.
•
RequestNoRetry
L’LSR Ru non riemette la richiesta ma assume che sarà Rd a soddisfare la richiesta
quando le ragioni della indisponibilità saranno superate. Questa procedura si utilizza nel
caso di modalità di instaurazione unsoliceted downstream.
II.1.5 Procedura di rilascio (Release procedure)
Questa procedura stabilisce il comportamento dell’LSR Ru quando vuole richiedere
all’LSR Rd la terminazione dell’associazione tra una FEC F e una label L. Se, ad esempio,
una FEC F corrisponde ad un prefisso X ed è stato creto un binding tra la FEC F e una label L,
questa condizione si verifica quando l’LSR Rd non risulta essere più il next hop per il prefisso
X . Sono possibili due comportamenti dell’LSR Ru:
•
ReleaseOnChange
L’LSR Ru rilascia l’associazione tra FEC F e label L ed informa l’LSR Rd.
•
NoReleaseOnChange
L’LSR Ru mantiene l’associazione tra FEC F e label L in modo da poterla riutilizzare
successivamente.
25
II.1.6 Procedura di uso della label (Label Use procedure)
Tale procedura si applica nel caso in cui la FEC F corrisponda ad un prefisso X,
nell’ipotesi in cui Ru riceva un messaggio di binding tra la FEC F e la label L dall’LSR Rd,
ma Rd non corrisponda al next hop dei pacchetti appartenenti alla FEC F. In questo caso la
procedura di uso della label indica le modalità di reazione dell’LSR Ru.
Sono possibili due alternative
•
UseImmediate
L’LSR Ru utilizza immediatamente il binding inviato dall’LSR Rd.
•
UseIfLoopNotDetected
L’LSR Ru utilizza il binding inviato dall’LSR Rd solo se è certo che questa operazione
non causi loop di instradamento in rete.
II.2 MPLS e ingegneria del traffico
In questo paragrafo sono illustrati i concetti principali dell’utilizzazione della tecnica
MPLS per l’attuazione dei principi dell’ingegneria del traffico in reti IP.
II.2.1 Aspetti generali del ingegneria del traffico in reti IP.
Adottando la definizione data in [RFC2702] e [RFC3272], gli aspetti di ingegneria del
traffico (Traffic Engineering – TE) in reti IP riguardano la valutazione e l’ottimizzazione delle
prestazioni della rete e comprendono le tecniche di misura, di caratterizzazione, di
modellazione ed di controllo del traffico. In particolare, uno degli aspetti chiave delle tecniche
di TE in reti IP è il controllo e l’ottimizzazione delle funzioni di instradamento allo scopo di
veicolare nel modo più efficiente i pacchetti in rete.
L’obiettivo delle tecniche di TE è, da un lato, quello di migliorare le prestazioni della
rete sia dal punto di vista del trattamento del traffico (ritardo, jitter del ritardo, tasso di perdita
dei pacchetti e throughput) e, dall’altro, di garantire un’utilizzazione efficiente, economica e
affidabile delle risorse di rete. Si sottolinea che, accanto agli aspetti più tradizionalmente
prestazionali, l’ingegneria del traffico si rivolge anche ad aspetti che riguardano il
funzionamento affidabile di una rete. A questo scopo devono essere utilizzate tecniche che
aumentino la sopravvivenza della connettività della rete in presenza di errori e/o di guasti
dell’infrastruttura.
Uno dei punti chiave delle tecniche di TE che permette di raggiungere gli obiettivi le
prestazioni della rete è la minimizzazione dei fenomeni di congestione. Tali fenomeni si
presentano se si verifica una della seguenti due condizioni:
26
•
le risorse di rete non sono globalmente sufficienti a supportare il volume di traffico
offerto;
•
il traffico è distribuito in modo non ottimale sulle risorse di rete causando un sovraccarico
in alcune di esse, mentre altre risultano sotto-utilizzate.
La prima causa di congestione si può superare incrementando la capacità della rete e/o
limitando il traffico in ingresso mediante le classiche tecniche di controllo adottate nelle reti a
pacchetto (controllo a finestra, limitazione del rate, ecc.).
La secondo tipo di problemi di congestione, che emergono nel caso di distribuzione non
ottimale del traffico in rete, sono l’oggetto delle politiche di TE.
In sintesi, dal punto di vista di un operatore di rete, le tecniche di TE sono lo strumento
per raggiungere l’equilibrio ottimale tra la qualità del servizio e le prestazioni della rete, come
viste dagli utenti finali, e gli aspetti economici di fornitura dei servizi stessi. Tale obiettivo
può essere raggiunto mediante la minimizzazione della massima congestione, o
equivalentemente, la minimizzazione della massima occupazione delle risorse di rete. E’
evidente infatti che minimizzando la congestione, attraverso un efficiente utilizzazione delle
risorse, la qualità di servizio percepita dagli utenti risulta massimizzata.
Il processo di ottimizzazione ora delineato deve essere visto come un processo iterativo,
continuo nel tempo, orientato al miglioramento delle prestazioni in presenza anche di nuovi
scenari di servizio, di variazioni nei requisiti d’utente e di nuove tecnologie emergenti. Questo
concetto può essere ulteriormente schematizzato come uno schema di controllo in cui il
modulo TE agisce come controllore in un anello di controreazione che include anche un
modulo di monitoraggio e misura delle prestazioni e un modulo di configurazione e di
gestione della rete (Figura II.2.1). Il modulo di controllo osserva lo stato della rete ricavato
attraverso il modulo di monitoraggio e applica le politiche di TE attraverso gli strumenti di
configurazione e di gestione in modo da guidare la rete verso lo stato desiderato.
Le politiche di TE nelle reti IP possono essere di tipo preventivo o reattivo.
Nel caso di politiche preventive, i sistemi di TE hanno lo scopo di prevenire che la rete,
nella sua prevedibile evoluzione, assuma stati non favorevoli dal punto di vista delle
prestazioni offerte agli utenti e/o dell’uso delle sue risorse. Nel caso di politiche reattive, la
rete invece reagisce correggendo in modo adattativo gli eventi che si manifestano in rete.
In questo quadro, le tecniche di controllo utilizzate operano a diversi livelli di
risoluzione temporale. Le politiche di gestione, di pianificazione e di aggiornamento della rete
(capacity planning) operano con una bassa risoluzione temporale, dell’ordine dei mesi e/o
degli anni. Il controllo degli instradamenti, che modifica e adatta i percorsi di rete seguiti dai
27
pacchetti, opera invece a livello intermedio, in una fascia temporale che si estende dai secondi
alle ore. Infine, le funzioni di processamento a livello di pacchetto (traffic shaping, tecniche di
scheduling, gestione delle code, ecc.) operano con elevata risoluzione temporale, dell’ordine
del tempo di trasmissione di un pacchetto (dai picosecondi ai millisecondi). Queste ultime
tecniche sono quindi in grado di intervenire nei processi di rete praticamente in tempo reale.
Determinazione dello
stato della rete
Decisione di
politiche di controllo
Modulo di TE
Modulo di
Monitoraggio e
di Misura
Attuazione delle politiche di controllo
Modulo di
Configurazione
e di Gestione
Rete
Figura II.2.1 – Ruolo delle politiche di Ingegneria del traffico per l’ottimizzazione delle
prestazioni di rete.
E’ riconosciuto che una delle prioritarie applicazioni dell’architettura MPLS risiede nel
quadro degli aspetti di TE. Nel seguito saranno discussi gli aspetti concernenti le applicazioni
di ingegneria del traffico dell’architettura MPLS con particolare riguardo al controllo degli
instradamenti.
II.2.2 Limiti degli attuali protocolli di routing IP
Le capacità di controllo del traffico offerta dagli attuali protocolli di routine utilizzati
nelle reti IP (Interior Gateway Protocols – IGP) non sono adeguate per raggiungere
completamente gli obiettivi precedentemente esposti dell’ingegneria del traffico; al contrario,
gli attuali IGP, normalmente basati sulla ricerca del cammino più breve (shorthest path),
contribuiscono, almeno in determinati condizioni, ad aumentare lo stato di congestione in rete.
Ciò può essere spiegato considerando che questi protocolli considerano esclusivamente
aspetti legati alla topologia della rete, in termini di esistenza e di stato dei nodi e dei link,
mentre trascurano gli aspetti concernenti, da un lato, la disponibilità di banda sui link e,
dall’altro, le caratteristiche dei flussi di traffico iniettati in rete.
In queste condizioni i fenomeni di congestione non possono essere evitati se in rete si
verificano le condizioni per cui gli shortest path di numerosi flussi di traffico transitano su
uno specifico link o se un flusso di traffico è instradato su un link che non ha sufficiente
28
banda per ospitarlo. La congestione così generata non può essere alleviata dal protocollo IGP
anche se esistono cammini alternativi con banda disponibile.
Tradizionalmente le limitazioni dei protocolli IGP sono superate adottando un modello
di rete a due strati, denominato modello overlay. Questo modello (Figura II.2.2) prevede che
la rete IP sia lo strato client che utilizza i servizi di trasferimento offerti da una rete
sottostante, che opera come strato server, basata su una diversa tecnologia, normalmente
ATM o Frame Relay.
Nel caso dell’ATM, l’accesso ai servizi di trasferimento avviene definendo una
topologia virtuale composta da VC/VP che appaiono allo strato IP come link fisici sui quali
opera il protocollo di instradamento.
Il modello overlay fornisce un insieme addizionale di funzioni per il supporto delle
politiche di TE, quali: a) instradamenti vincolati a livello di VC; b) instaurazione di VC con
instradamento prefissato; c) controllo di ammissione di chiamata; d) traffic shaping e
policing; e) instaurazione di VC multipli per ragioni di affidabilità. Queste funzioni
completano il patrimonio funzionale della rete complessiva e consentono l’attuazione
completa delle politiche di ingegneria del traffico.
Rete IP
(Strato Client)
MPLS
Rete ATM
(Strato Server)
Modello
Overlay
Rete
IP/MPLS
Modello
Integrato
Figura II.2.2 – Esempio di modello overlay e di modello integrato per l’attuazione delle
politiche di TE in una rete IP.
Dal punto di vista dell’ingegneria del traffico, lo scopo dell’MPLS in una rete IP è
quello di evitare l’utilizzazione del modello overlay, ma di integrare all’interno dello strato IP,
opportunamente evoluto con l’aggiunta delle funzionalità MPLS, tutte le funzioni necessarie
all’attuazione delle politiche di TE (Figura II.2.2).
La funzione base che rende l’MPLS adatto per il raggiungimento di questo obiettivo
risiede nel fatto che possono essere creati LSP su base esplicita, aggiungendo quindi
funzionalità simili alla commutazione di circuito alla rete IP.
II.2.3 Definizione del problema di Ingegneria del Traffico in MPLS
Il problema chiave di ingegneria del traffico che deve essere risolto in ambito MPLS
riguarda essenzialmente le modalità di mappatura dei flussi di traffico e degli LSP sui link
29
fisici della rete in modo da garantire un funzionamento efficiente ed affidabile della rete.
Questo problema può essere definito anche in modo più formale introducendo il
concetto di grafo base (base graph) e di grafo MPLS indotto (induced MPLS graph).
Dato un dominio MPLS, i due grafi possono essere così definiti:
•
il grafo base G=(V,E,c) è associato alla topologia fisica del dominio MPLS; V è l’insieme
dei nodi della rete, E è l’insieme dei link fisici della rete e c è il vettore delle capacità
associate ai singoli link fisici della rete.
•
il grafo MPLS indotto H=(U,F,d) è un grafo in cui l’insieme dei nodi U è un sottoinsieme
di V che coincide con l’insieme degli LSR appartenenti al dominio MPLS, mentre
l’insieme dei rami F coincide con l’insieme degli LSP che hanno come estremi gli LSR,
infine d è l’insieme dei valori di banda associate ai singoli LSP.
Sulla base delle definizioni precedenti, il problema dell’ingegneria del traffico in MPLS
può definito come la ricerca del mappatura ottima del grafo H sul grafo G; ovvero la ricerca
dell’instradamento degli LSP sui link fisici della rete che minimizzi l’occupazione massima
dei link stessi.
Nel [RFC2702] viene introdotto anche il concetto di traffic trunk che viene utilizzato
per la definizione delle funzionalità addizionali previste in MPLS per il pieno supporto delle
politiche di TE. Un Traffic Trunk (TT) è definito come un’aggregazione di flussi di traffico
appartenenti alla stessa FEC che sono instradati in rete nello stesso LSP. In altre parole, un TT
è un oggetto astratto su cui si applicano le funzioni di instradamento dei pacchetti in rete
previste in MPLS.
Le funzionalità addizionali presenti all’interno dell’architettura MPLS per il supporto
delle politiche di TE sono:
•
la definizione di un insieme di attributi associato ad ogni TT (Traffic Trunk Attibute) che
specifica le modalità di trattamento del suo flusso di traffico;
•
la definizione di un insieme di attributi associato alla risorse di rete (Resource
Attribute)che vincolano l’instradamento dei TT su di esse;
•
un insieme di regole di instradamento vincolato (Constraint-Based Routing – CBR)
utilizzate per la scelta dei cammini di instradamento dei TT che rispettino i vincoli imposti
dagli insiemi di attributi, associati ai TT e alle risorse di rete, definiti nei punti precedenti.
Gli attributi associati ai TT e quelli associati alle risorse di rete insieme ai parametri di
instradamento costituiscono le variabili di controllo che possono essere modificate, attraverso
azioni di configurazione da parte dell’operatore di rete o in modo automatico, per pilotare la
30
rete verso lo stato di funzionamento ottimale.
II.2.4 Funzioni e attributi associati ai Traffic Trunk (Traffic Trunk Attribute)
Alla luce delle definizione date nel paragrafo precedente, un TT è un aggregato di flussi
di traffico, caratterizzato dagli LSR di ingresso e di uscita, dalla FEC a cui appartengono i
flussi che lo compongono e dagli attributi ad esso associato che determinano le sua
caratteristiche di comportamento.
Le operazioni che la rete MPLS deve essere in grado di compiere sui TT e che
riguardano gli aspetti di TE sono:
− Establish: questa operazione ha l’obiettivo di instaurare un nuovo TT e quindi di allocare
le risorse di rete necessarie al suo supporto;
− Activate: questa operazione ha l’obiettivo di attivare il transito dei pacchetti all’interno
dell’LSP che supporta un TT; le operazioni di instaurazione e di attivazione di un TT sono
logicamente separate, può esistere quindi un TT instaurato, ma non attivato;
− Deactivate: questa operazione ha l’obiettivo di porre termine al transito dei pacchetti
all’interno dell’LSP che supporta un TT;
− Modify attribute: questa operazione ha l’obiettivo di modificare il valore di uno o più
attributi associati ad un TT;
− Reroute: questa operazione ha l’obiettivo di modificare l’instradamento di un LSP che
supporta un TT;
− Destroy: questa operazione ha l’obiettivo di rimuovere un TT precedentemente instaurato
e quindi di liberare le risorse di rete associate ad esso.
Le modalità e le procedure di esecuzione delle precedenti operazioni dipende dallo
specifico protocollo di segnalazione utilizzato, ad esempio il protocollo RSVP-TE.
Gli attributi di un TT specifici per le funzioni di TE sono compresi nelle seguenti
categorie:
•
Parametri di traffico.
Sono usati per descrivere le caratteristiche statistiche del flusso di pacchetti appartenenti
al TT e, quindi, per stabilire l’ammontare di risorse di rete (es. banda) che occorre
allocare; l’insieme dei parametri di traffico può comprendere il bit rate di picco, il bit rate
medio, la dimensione massima di un burst, ecc. Gli algoritmi di allocazione delle risorse
sono di pertinenza dell’operatore di rete.
31
•
Selezione e gestione del cammino in rete.
Questa categoria di attributi definisce le regole per la scelta del cammino in rete su cui
instradare il TT e le regole per il suo mantenimento; un cammino può essere calcolato
automaticamente dai protocolli di instradamento della rete o definito a priori
dall’amministratore di rete: I principali attributi associati a questa categoria sono:
− Instradamento esplicito: questo attributo specifica se il cammino è specificato a priori,
completamente o parzialmente, dall’operatore per l’instradamento di un TT;
− Regole di scelta: questo attributo stabilisce una gerarchia di scelta in un insieme di
cammini specificati a priori per l’instradamento di un TT.
− Affinità di classe di risorse: questo attributo specifica le classi di risorse di rete che
possono essere utilizzate o meno per l’instradamento di un TT. Questo attributo è
usato per porre dei vincoli sull’instradamento di un TT e per implementare una varietà
di politiche di instradamento; ad esempio è possibile imporre che un LSP transiti su
link appartenenti esclusivamente ad una specificata regione della rete o la cui capacità
sia superiore ad un certo valore o che assicurino un determinato livello di affidabilità.
− Adattività: indica se l’LSP può essere soggetto a reinstradamenti durante la sua
utilizzazione allo scopo di mantenere costantemente le condizioni di ottimalità di
scelta del cammino.
− Distribuzione del carico: questo attributo indica la porzione di traffico che può essere
instradata su diversi TT che sono definiti tra due punti terminali della rete. Utilizzando
questo parametro è possibile realizzare politiche di distribuzione del carico su percorsi
alternativi tra due punti terminali.
•
Priorità di instaurazione (set-up).
Questa classe di attributi definisce l’importanza relativa del TT rispetto agli altri presenti
in rete e determina l’ordine in cui è effettuata l’operazione di scelta del cammino al
momento del instaurazione di un insieme di LSP o dei loro reinstradamenti in caso di
guasto.
•
Priorità di prelazione (preemption).
Con il termine prelazione ci si riferisce alla possibilità di abbattere un TT, e quindi il
corrispondente LSP, per istaurare un altro TT. Questo attributo stabiliscequindi se un TT,
e quindi il suo corrispondente LSP, possa essere prelazionato da un altro TT o possa
prelazionare un altro TT in fase di instaurazione.
Possono essere definite quattro modalità di prelazione di un TT:
32
1) TT con possibilità di prelazione;
2) TT senza possibilità di prelazione;
3) TT prelazionabile;
4) TT non prelazionabile.
Ad esempio, un TT di tipo (1) con priorità di instaurazione elevata può prelazionare un TT
di tipo (3) già instaurato con priorità di instaurazione più bassa; un TT di tipo (4) non
potrà essere prelazionato in nessun caso anche da TT con priorità di instaurazione più
elevati, mentre un TT di tipo (2) non può prelazionare altri TT qualsiasi sia la sua priorità
di instaurazione.
Gli attributi di priorità di instaurazione e di prelazione individuano le modalità con cui i
TT interagiscono tra loro e competono per l’utilizzazione delle risorse di rete. Tali
attributi possono essere utilizzati, da un lato, per assicurare che il traffico ad alta priorità
possa sempre essere instradato su percorsi adatti al livello richiesto di qualità e dall’altro,
per definire diverse politiche di ripristino degli LSP in caso di guasto in rete.
•
Resilienza.
Questo attributo determina il grado di sopravvivenza di un LSP in presenza di guasti in
rete. In particolare l’attributo specifica le azioni che devono essere intraprese se un TT in
caso di guasto lungo il cammino attraversato dal corrispondente LSP. Le politiche di
reazione ad un guasto possono essere classificate nel seguente modo:
− Assenza completa di re-instrada mento.
− Re-instradamento possibile solo su un cammino avente caratteristiche pienamente
compatibili con quelle richieste dal TT; se tale cammino non può essere individuato il
r-instradamento non può aver luogo.
− Re-instradamento possibile su qualsiasi cammino senza riguardo a nessun vincolo
sulle risorse disponibili.
− Qualsiasi altra politica basata su una composizione delle precedenti
•
Policing:
Questa classe di attributi determina le azioni che possono essere intraprese se le
caratteristiche del TT non sono compatibili con quelle dichiarate all’atto della sua
instaurazione, in particolare quando eccede i parametri stabiliti nel contratto di traffico.
L’insieme degli attributi delle categorie parametri di traffico e di policing sono analoghi a
quelli utilizzati per le funzioni Usage Parameter Control (UPC) nell’architettura ATM.
33
II.2.5 Attributi associati alle risorse di rete (Resource Attribute)
La classe di attributi associati alle risorse comprende i parametri che caratterizzano la
topologia della rete e sono necessari per vincolare la scelta del percorso su cui instradare un
TT.
Gli attributi appartenenti a questa classe sono:
•
Maximum Allocation Multiplier (MAM).
Il MAM di una risorsa di rete, ad esempio la banda di un link o il buffer di un LSR,
determina la proporzione della risorsa che è disponibile per l’allocazione dei TT. Questo
valore è configurabile dall’operatore di rete. Il valore del MAM può essere sia inferiore
che superiore a 1. Nel caso MAM>1, è consentita la sovra-allocazione della risorsa; ciò è
conveniente per sfruttare al meglio le caratteristiche statistiche del traffico e per
raggiungere un maggiore utilizzazione delle risorse stesse.
•
Classe della risorsa.
Questo attributo definisce la categoria a cui appartiene una risorsa e può essere visto come
un colore assegnato alla risorsa; ovviamente, due risorse distinte dello stesso colore
appartengono alla stessa classe. Questi attributi sono utilizzati per definire politiche
alternative per l’utilizzazione delle risorse di rete e per gestire in modo flessibile
l’instradamento in rete. Ad esempio, si può definire la classe dei link di rete con capacità
uguale a 2.5 Gbit/s assegnando a questi link lo stesso valore di attributo (stesso colore) e
quindi vincolare l’instradamento di una classe di TT a transitare, esclusivamente o
preferibilmente, attraverso i link appartenenti a quella classe.
II.2.6 Constraint-Based Routing (CBR)
In generale, con il termine Constraint-Based Routing (CBR) si indica un insieme di
regole per la scelta dei cammini di instradamento dei TT che rispetti i vincoli imposti dagli
insiemi di attributi associati ai TT e alle risorse di rete. Dal punto di vista terminologico il
concetto di constraint based routing è spesso riferito anche come QoS routing. Quest’ultimo
termine mette in evidenza come questa tecnica sia utilizzata per soddisfare nell’instradamento
i vincoli di qualità imposti da un TT; è’ da sottolineare però che l’utilizzazione delle tecniche
CBR è molto più ampia dell’esclusivo soddisfacimento dei vincoli di qualità.
Si consideri un TT originato in uno specifico LSR e caratterizzato da specifici parametri
di traffico. Il processo CBR nel nodo usa come ingressi gli attributi associati al TT, alle
risorse di rete e in generale qualsiasi altra informazione sullo stato della topologia di rete.
L’uscita del processo, eseguito esclusivamente nel nodo di origine, è l’individuazione di un
34
percorso di rete su cui instradare l’LSP associato al TT che soddisfi i requisiti di banda del TT
stesso e i vincoli relativi alla disponibilità delle risorse di rete e quelli imposti dalla specifica
politica di utilizzo delle risorse.
Input:
Richiesta di
instaurazione di un LSP
Procedura di set-up dell’LSP
Ingress
LSR
TT
Attribute
Resource
Attribute
Egress
LSR
Constraint
Based
Routing
Administrative
Policy
Database
Topologia
LSR
LSR
Dominio
MPLS
Output:
Percorso esplicito
dell’LSP
Figura II.2.3 – Applicazione della tecnica Constraint-Based Routing in ambiente MPLS.
Si sottolinea che, come mostrato in Figura II.2.3, il processo di determinazione del
percorso di un LSP viene eseguito esclusivamente nell’LSR d’origine che quindi determina
l’intera sequenza di LSR attraversati (explicit routing). Una volta determinato il percorso,
l’LSR attiva il processo di segnalazione che porta all’instaurazione dell’LSP in rete.
II.3 Supporto della qualità di servizio in reti MPLS (Architettura Diffserv over MPLS)
Negli ultimi anni, l’evoluzione dell’architettura delle reti IP prevede due direzioni di
sviluppo: la prima rivolta all’integrazione di funzioni orientata al trattamento di flussi di
traffico con specifici requisiti di qualità di servizio; la seconda principalmente orientata al
supporto di politiche di ingegneria del traffico. La definizione delle architetture Differentiated
Services (Diffserv) e MPLS sono il risultato degli studi in queste due aree.
Con l’adozione di queste due architetture, il processo di arricchimento delle funzionalità
dello strato IP si completa e rende possibile l’adozione del solo paradigma IP per il supporto
integrato di servizi dati e multimediali, senza ricorrere ad architetture di rete più complesse,
basate sulla sovrapposizione di diverse paradigmi di trasferimento secondo il modello
overlay.
Come è stato illustrato in precedenza, in un dominio Diffserv tutti i pacchetti che
attraversano un link di rete e che richiedono lo stessa tipologia di servizio formano un
Behavior Aggregate (BA). All’ingresso del dominio Diffserv, i pacchetti sono classificati ed
etichettati con uno specifico DiffServ Code Point (DSCP) che identifica il BA a cui ogni
pacchetto appartiene. In ogni router il campo DSCP viene utilizzato per stabilire le modalità
di trattamento del pacchetto definite nel Per Hop Behavior (PHB) associato a quel BA. In
35
particolare, il PHB indica le modalità di scheduling e di eventuale scarto dei pacchetti in caso
di congestione.
In questo quadro l’elemento che deve essere ancora approfondito riguarda le modalità di
supporto dell’architettura Diffserv da parte dell’MPLS. Lo studio delle modalità di interlavoro
tra le due architetture, che nel seguito verrà indicata per semplicità con il termine Diffserv
over MPLS, è necessario per rendere possibile la gestione degli aspetti di QoS direttamente
all’interno dello strato MPLS, eliminando la necessità di accedere a funzioni poste nello strato
IP e semplificando quindi l’architettura dei nodi di rete.
La definizione dell’interazione tra le architetture Diffserv e MPLS è semplificata dalle
analogie esistenti tra le modalità operative delle due architetture . In particolare:
•
entrambe operano su aggregati di pacchetti: BA in Diffserv e FEC in MPLS;
•
entrambe operano una classificazione dei pacchetti all’ingresso della rete;
•
entrambe assegnano un identificativo ai pacchetti che stabilisce in modo esplicito
l’aggregato a cui appartengono: DSCP in Diffserv, la label in MPLS;
•
in entrambe le architetture le operazioni svolte da un nodo sono completamente definite
dal valore dell’identificativo assegnato al pacchetto.
E’ evidente che la strategia per la definizione dell’architettura Diffserv-over-MPLS è
quella di stabilire una corrispondenza logica tra i concetti di FEC e di BA e di trasportare
nell’etichetta MPLS l’informazione contenuta nel DSCP del pacchetto in modo che un LSR
possa riconoscere immediatamente il PHB che deve essere applicato al pacchetto.
Le soluzioni proposte in [RFC3270] sono basate entrambe sull’utilizzazione del campo
EXP contenuto nell’etichetta MPLS e prevedono l’utilizzo di due tipologie di LSP:
− EXP-inferred-PHB (E-LSP): sono LSP che possono trasportare una molteplicità di BA e
quindi convogliano pacchetti caratterizzati da diversi PHB; l’informazione sul PHB a cui
appartiene il pacchetto, contenuta nel campo DSCP, è mappata nel campo EXP. In questo
caso, la label identifica la combinazione tra la FEC associata all’LSP e un insieme di BA a
cui appartengono i pacchetti trasportati dall’LSP. E’ evidente in questa modalità, poiché il
campo EXP può assumere al massimo otto configurazioni, non è possibile ottenere, a
livello MPLS, una piena corrispondenza con i PHB definiti dall’architettura Diffserv, ma
è necessario effettuare una riduzione del loro numero.
− Label-only-inferred-PHB (L-LSP): sono LSP che possono trasportare una singola classe
di BA e quindi convogliano pacchetti che devono essere trattati con PHB dello stesso tipo;
l’informazione della classe di PHB a cui appartiene il pacchetto è direttamente contenuta
36
nella label che identifica l’LSP, mentre il campo EXP codifica esclusivamente la priorità
di scarto del pacchetto. Questa definizione può essere chiarita meglio se si riferisce al caso
del trasporto nello stesso LSP di flussi di traffico appartenenti alla categoria Assured
Forwarding (AF) ma caratterizzati da diverse priorità di scarto; in questo contesto la label
indica che i pacchetti appartengono tutti alla categoria AF, mentre il completo PHB è
individuato con l’aggiunta dell’informazione contenuta nel campo EXP.
Nel seguito è descritta la sequenza di operazioni che devono essere eseguite da un LSR
compatibile con l’architettura Diffserv over MPLS su un pacchetto entrante. In particolare,
viene illustrato il caso in cui la rete MPLS interlavori direttamente con reti IP in assenza di
altri strati protocollari intermedi (es ATM, Frame Relay).
Le operazioni eseguite da un LSR possono essere classificate in quattro fasi:
a) Identificazione del PHB associato al pacchetto entrante;
b) Identificazione del PHB in uscita con cui trattare il pacchetto in uscita considerando
l’eventuale applicazione delle funzioni di traffic conditioning;
c) Individuazione della label in uscita;
d) Codifica dell’informazione Diffserv nello strato MPLS;
Al termine di queste operazioni il nodo esegue le operazioni di rilancio del pacchetto
applicando il PHB determinato nella fase (b).
La Figura II.3.1 identifica la relazione tra le fasi ora definite e si applica anche ai casi di
Ingress, Egress LSR. La differenza rispetto al caso di Transiti LSR risiede nei seguenti punti:
i) nel caso di Ingress LSR, il pacchetto entrante non trasporta nessuna label e le informazioni
di QoS sono contenute solo nell’header dello strato IP; ii) nel caso di Egress LSR, al
pacchetto uscente non deve essere assegnata nessuna label e le informazioni di QoS devono
essere codificate nell’header IP del pacchetto.
Occorre considerare infine che se le operazioni di traffic conditioning non devono
essere eseguite sul pacchetto, il PHB in uscita coincide con il PHB entrante.
Label
entrante
Info QoS
MPLS (o IP)
(a)
Identificazione
del PHB entrante
(b)
Identificazione
del PHB in uscita
con applicazione
delle funzioni di TC
(c)
Identificazione
della label in uscita
Label
uscente
(d)
Codifica
dell’informazione
Diffserv nello strato
MPLS o IP
Info QoS
MPLS (o IP)
Figura II.3.1 – Sequenza delle operazioni eseguite da un LSR di una rete Diffserv over MPLS
su un pacchetto entrante.
37
II.4 Estensione del protocollo RSVP per l’instaurazione di LSP (RSVP-TE)
L’architettura MPLS definisce un protocollo di distribuzione delle etichette (Label
Distribution Protocol – LDP) come l’insieme delle procedure mediante il quale un LSR
colloquia con un altro LSR per instaurare gli LSP e per assegnare ad essi le label da utilizzare
per rilanciare i pacchetti. E’ stato sottolineato in precedenza che l’architettura MPLS non
definisce un singolo protocollo LDP, ma prevede che queste funzioni possano essere svolte da
diversi protocolli.
In questo paragrafo è illustrata in dettaglio la soluzione che prevede l’estensione del
protocollo RSVP [RFC2205], in origine definito come protocollo per la gestione dei flussi dei
pacchetti nell’architettura Integrated Services (Intserv), al caso di instaurazione degli LSP e di
supporto delle funzioni di ingegneria del traffico in reti MPLS. Per questi motivi il protocollo
è detto anche RSVP-TE [RFC3209]; tale sigla sarà utilizzata nel seguito per semplicità per
indicare l’intero insieme di procedure di segnalazione.
Il protocollo RSVP-TE supporta l’instaurazione di LSP caratterizzati da instradamento
esplicito e da, eventualmente, una riservazione di banda sul percorso. Supporta inoltre il
reinstradamento degli LSP e le funzioni legate alle priorità di instaurazione e di prelazione
definite nell’architettura MPLS.
Poiché il flusso di pacchetti IP che transita attraverso un LSP è individuato dalla label
associata, questi LSP possono essere interpretati come tunnel che mascherano i meccanismi
originali di instradamento e di trattamento dei pacchetti propri dello strato IP. Nella
terminologia usata nel [RFC3209], si indicano gli LSP che sono gestiti dal protocollo RSVP
come LSP-tunnel. Tale termine sottolinea che il traffico trasportato da un LSP non è elaborato
dai nodi intermedi lungo l’LSP.
Il concetto di LSP-tunnel permette la realizzazione di una varietà di politiche relative
all’ottimizzazione delle prestazioni di rete. Ad esempio, un LSP-tunnel può essere instradato
in modo automatico o su base amministrativa, in modo da evitare punti di congestione o di
guasto nella rete; oppure possono essere previsti tra due nodi un insieme di LSP paralleli per
realizzare un’ottimale distribuzione del traffico.
Il protocollo RSVP-TE usa la modalità di distribuzione delle etichette di tipo
downstream-on-demand. La richiesta di effettuare un binding tra una label e una FEC e quindi
di instradare un LSP-tunnel è emessa dall’Ingess LSR utilizzando il messaggio RSVP Path. A
questo scopo il messaggio RSVP Path è stato arricchito dall’oggetto Label-Request.
Le label sono allocate nella direzione downstream-upstream per mezzo del messaggio
38
RSVP Resv. L’estensione del messaggio definita a questo scopo consiste nell’oggetto Label.
Il protocollo RSVP-TE supporta la funzionalità di explicit routing attraverso l’oggetto
Explicit Route compreso nel messaggio RSVP Path. Questo oggetto è determinato dall’Ingress
LSR e trasporta l’insieme di LSR che costituisce l’LSP-tunnel.
Il vantaggio di utilizzare il protocollo derivato dall’RSVP come protocollo di
segnalazione per la rete MPLS consiste nella possibilità di riutilizzare la funzione di
allocazione delle risorse presente in modo nativo in RSVP. L’allocazione di banda per un
LSP-tunnel può essere effettuata infatti in modo semplice utilizzando i meccanismi standard
di RSVP definiti per all’interno dell’architettura Intserv.
Il protocollo RSVP-TE definito in [RFC3209] ha l’obiettivo di gestire gli LSP Tunnel; a
questo scopo, rispetto alla versione originale del protocollo definita in [RFC2205], è stato
definito un nuovo oggetto denominato LSP_Tunnel.
Nelle applicazioni di ingegneria del traffico è utile associare insieme alcuni LSP tunnel,
ciò è utile nelle operazioni di reinstradamento in caso di guasti in rete. Un aggregato di LSP
tunnel utilizzato nelle funzioni di TE è indicato con il termine TE Tunnel. Per identificare
correttamente un LSP tunnel e il TE tunnel a cui appartiene è definito un doppio livello di
identificatori: un tunnel ID che identifica un TE tunnel e un LSP ID che identifica lo specifico
LSP.
Le funzioni supportate dal protocollo RSVP-TE sono le seguenti.
•
Instaurazione degli LSP tunnel con o senza requisiti di QoS.
La procedura di instaurazione di un LSP è la seguente. L’ingress LSR emette un
messaggio RSVP Path che contiene l’oggetto LSP_Tunnel e l’oggetto Label_request .
Quest’ultimo oggetto indica che è richiesta l’assegnazione di una label per l’LSP.
Nel caso in cui il nodo di ingresso richieda che l’LSP segua uno specifico cammino in
rete, il messaggio RSVP Path conterrà l’oggetto Explicit_Route che indica la sequenza di
LSR che compone l’LSP.
Infine nell’oggetto Session_Attribute, ugualmente contenuto nel messaggio RSVP Path
sono contenuti i parametri relativi al tipo di LSP, quali ad esempio la priorità di set-up, la
priorità di prelazione, la classe di risorse di rete utilizzabili, la classe di resilienza, ecc.
•
Reinstradamento dinamico degli LSP tunnel.
Se durante la vita di un LSP, l’ingress LSR individua un instradamento diverso per l’LSP,
invia un messaggio RSVP Path che trasporta l’oggetto Explicit_Route che indicherà il
nuovo percorso su cui dovrà essere reinstradato l’LSP.
•
Monitoraggio del percorso di rete utilizzato da un LSP tunnel;
39
Il nodo di ingresso di un LSP può ricevere informazioni sul percorso seguito da un LSP
aggiungendo nel messaggio RSVP Path l’oggetto Record_Route. Ogni nodo attraversato
dal messaggio inserirà il proprio indirizzo in modo da formare l’intera lista degli LSR che
compongono l’LSP.
•
Esecuzione l’allocazione delle label secondo la modalità downstream-on-demand.
Il nodo finale di un LSP, al momento della ricezione di un messaggio RSVP Path,
risponde con un messaggio RSVP Resv che contiene l’oggetto Label indicante il valore
della label assegnata a quel LSP
Il messaggio RSVP Resv percorrerà a ritroso il cammino seguito dal messaggio RSVP
Path; ogninodo attraversato userà la label contenuta nell’oggetto Label per etichettare il
traffico uscente dal nodo e provvederà a definire il valore della label che identificherà il
flusso di pacchetti dell’LSP entrante al nodo. Tale valore viene inserito nell’oggetto Label
ed il messaggio RSVP Resv che verrà rilanciato verso l’LSR upstream.
40
II.5 Bibliografia
W. Stallings : High Speed Networks and Internets Performance and Quality of Service,
second edition, Prentice Hall. 2002.
B. Davie, Y Rekhter : MPLS, Technology and Applications, Morgan Kaufmann Publisher,
2000.
U. Black : MPLS and Label switching Networks, Prentice Hall, 2001.
IETF, Resource ReServation Protocol (RSVP), RFC 2205, Version 1, Functional
Specification, September 1997
IETF, Requirements for Traffic Engineering Over MPLS, RFC 2702. September 1999.
IETF, RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209 December 2001.
IETF, Multiprotocol Label Switching Architecture, RFC 3031, January 2001.
IETF, MPLS Label Stack Encoding, RFC 3032, January 2001.
IETF, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, RFC 3270,
May 2002.
IETF, Overview and Principles of Internet Traffic Engineering, RFC 3272, May 2002.
IETF, Applicability Statement for Traffic Engineering with MPLS, RFC 3346, August 2002.
IETF, Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks,
RFC 3443, January 2003.
41
Indice delle Figure
Figura I.2.1 - Illustrazione del concetto di FEC........................................................................ 6
Figura I.3.1 – Rappresentazione di un dominio MPLS.............................................................. 8
Figura I.3.2 - Illustrazione dei concetti di binding tra label e FEC. ......................................... 9
Figura I.3.3 – Illustrazione del concetto di label stack ............................................................. 9
Figura I.3.4 – Formato di una label MPLS. ............................................................................ 10
Figura I.4.1 – Illustrazione del concetto di Label Switched Parth (LSP) in una rete MPLS. 11
Figura I.4.2 – Utilizzazione della Incoming Label Map (ILM) in un LSR.............................. 12
Figura I.4.3 – Utilizzazione della FEC-to-NHLFE Map (FTN) in un LSR. ............................ 12
Figura I.4.4 – Rimozione dell’etichetta al penultimo LSR di un LSP in una rete MPLS......... 13
Figura I.4.5 – Modalità di associazione dei prefissi IP alle FEC: a) FEC separate per ogni
prefisso (non aggregazione); b) unica FEC per un insieme di prefissi (aggregazione).......... 14
Figura I.5.1 – Modalità a controllo indipendente nell’instaurazione di un LSP..................... 15
Figura I.5.2 – Modalità a controllo ordinato nell’instaurazione di un LSP. .......................... 15
Figura I.6.1 – Illustrazione del concetto di tunnel in una rete IP............................................ 16
Figura I.6.2 – Gerarchia di LSP e utilizzazione della tecnica di label stack. ......................... 17
Figura I.7.1 – Elaborazione del campo TTL nel caso di Uniform Model LSP in entrambi i casi
di rimozione dell’etichetta all’Egress LSR e al Penultimate LSR............................................ 19
Figura I.7.2 – Elaborazione del campo TTL nel caso di Pipe Model LSP con rimozione
dell’etichetta all’Egress LSR.................................................................................................... 19
Figura I.7.3 – Elaborazione del campo TTL nel caso di Pipe Model LSP con rimozione
dell’etichetta al Penultimate LSR............................................................................................. 19
Figura II.1.1 – Procedura di distribuzione delle label di tipo PushUnconditional................. 22
Figura II.1.2 – Procedura di distribuzione delle label di tipo PushConditional..................... 23
Figura II.1.3 – Procedura di distribuzione delle label di tipo PulledUnconditional. ............. 23
Figura II.1.4 – Procedura di distribuzione delle label di tipo PulledConditional. ................. 24
Figura II.1.5 – Procedura di disattivazione della label........................................................... 24
Figura II.2.1 – Ruolo delle politiche di Ingegneria del traffico per l’ottimizzazione delle
prestazioni di rete..................................................................................................................... 28
Figura II.2.2 – Esempio di modello overlay e di modello integrato per l’attuazione delle
politiche di TE in una rete IP. .................................................................................................. 29
Figura II.2.3 – Applicazione della tecnica Constraint-Based Routing in ambiente MPLS. .... 35
42
Figura II.3.1 – Sequenza delle operazioni eseguite da un LSR di una rete Diffserv over MPLS
su un pacchetto entrante. ......................................................................................................... 37
43