Multi Protocol Label Switching (MPLS): Architettura e Ingegneria del Traffico

Транскрипт

1 Marco Listanti Dipartimento INFOCOM Università di Roma "La Sapienza" Multi Protocol Label Switching (MPLS): Architettura e Ingegneria del Traffico Versione 5.0 A.A 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

2 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 () E MODALITÀ DI DEFINIZIONE DELLE LABEL... 7 I.4 LABEL SWITCHING PATH (LSP): DEFINIZIONE E FUNZIONI DEGLI I.4.1 Tabelle di trattamento delle label in un I.4.2 Penultimate Hop Popping I.4.3 Aggregazione e merging delle label I.5 INSTAURAZIONE E SELEZIONE DEL PERCORSO DI UN LSP I.6 LSP TUNNELS I.7 ELABORAZIONE DEL CAMPO TTL DELLA LABEL MPLS II MULTI PROTOCOL LABEL SWITCHING (MPLS) GESTIONE DELLE LABEL E INGEGENRIA DEL TRAFFICO II.1 PROCEDURE DI GESTIONE DELLE LABEL II.1.1 Procedura di distribuzione (Distribution procedure) II.1.2 Procedura di disattivazione (Withdrawal procedure) II.1.3 Procedura di richiesta (Request procedure) II.1.4 Procedura di dichiarazione di indisponibilità (Not Available procedure) II.1.5 Procedura di rilascio (Release procedure) II.1.6 Procedura di uso della label (Label Use procedure) II.2 MPLS E INGEGNERIA DEL TRAFFICO II.2.1 Aspetti generali del ingegneria del traffico in reti IP II.2.2 Limiti degli attuali protocolli di routing IP II.2.3 Definizione del problema di Ingegneria del Traffico in MPLS II.2.4 Funzioni e attributi associati ai Traffic Trunk (Traffic Trunk Attribute) II.2.5 Attributi associati alle risorse di rete (Resource Attribute) II.2.6 Constraint-Based Routing (CBR) 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) II.5 BIBLIOGRAFIA

3 I MULTI PROTOCOL LABEL SWITCHING (MPLS) PRINCIPI GENERALI I.1 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 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

4 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

5 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

6 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. Payload Header IP FEC a FEC b... FEC k... FEC W Next hop N Next hop 1... Next hop i... Figura I 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

7 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 () 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 () e la tipologia di commutazione è denominata in generale come label switching. Un dominio di rete MPLS è formato quindi da un insieme di direttamente connessi tra loro. Il traffico entrante ad un dominio MPLS può provenire sia da reti esterne al dominio, 7

8 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 che connette un dominio MPLS con altri nodi che sono all esterno del dominio è detto Edge, mentre un che è connesso solo ad altri è detto Core. Rete IP Rete IP Edge Core Dominio MPLS Edge Core Core Rete IP Edge 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, 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 Ru e come label entrante al Rd. Inoltre nei confronti di questo binding, Ru sarà indicato come upstream, mentre Rd avrà il ruolo di downstream. La Figura I.3.2 illustra i concetti ora introdotti. E responsabilità dei due, 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 che informa l upstream 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

9 da un downstream per distribuire le etichette verso l upstream 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. MPLS- BGP, 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 - Ru Downstream - Rd Figura I 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 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

10 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 8 bit 8 bit Label value Exp S TTL 20 bit 3 bit 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 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. La descrizione puntuale delle regole di elaborazione del campo TTL saranno indicate nel seguito. I.4 Label Switching Path (LSP): definizione e funzioni degli 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 (R 1, R 2,, R n ) che soddisfano le seguenti proprietà: l R 1, che rappresenta il punto di inizio del LSP, è il router che applica la label di ordine m al pacchetto P; 10

11 in tutti gli R i (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, R i e R i+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 R i 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 ) applica la label di ordine m; b) i router intermedi (Transit ) eseguono l instradamento elaborando e quindi sostituendo la label di ordine m; c) l ultimo router (Egress ) 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. Ingress Routing Table Destination Out 134.5/16 (y1, 84) Ingress y1 Rete IP Rete MPLS MPLS Table In Out (x3, 46) (y3, 3) Transit 46 y3 x3 x Egress Rete IP x2 y2 Egress Routing Table Transit In Next Hop (x4, 3) 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 Entrando in un maggior grado di dettaglio nel meccanismo di elaborazione delle label in un nodo MPLS, si evidenzia che un 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

12 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 arrivi un pacchetto che trasporta una label MPLS e che quindi è stato già etichettato da un precedente, l 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 NHLFE A Pacchetto Label L Label L.. NHLFE L Label W.. NHLFE W Figura I.4.2 Utilizzazione della Incoming Label Map (ILM) in un. Nel caso invece in cui ad un arrivi un pacchetto che non trasporta una label MPLS e che deve essere rilanciato in un LSP, l 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 NHLFE A Payload Header FEC X.. NHLFE X FEC W.. NHLFE W Figura I.4.3 Utilizzazione della FEC-to-NHLFE Map (FTN) in un. I.4.2 Penultimate Hop Popping. Per quanto riguarda l eliminazione di una label da un pacchetto, questa operazione può 12

13 essere eseguita, oltre che dal router R n, ovvero l Egress di un LSP, anche dal router R n-1, ovvero dal penultimo di un LSP. Questa seconda possibilità, denominata Penultimate Hop Popping, è giustificata dal fatto che l instradamento sul link che unisce gli R n-1 e R n è effettuato dal router R n-1 esaminando la label associata al pacchetto in entrata al router stesso, applicata dal router R n-2 ; inoltre, una volta che il pacchetto è stato rilanciato verso l Egress, la label non ha più nessuna utilità poiché l operazione di instradamento che sarà effettuata da questo 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. 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 di un LSP. R n-1 R n R n-1 R n IP 35 IP 27 IP IP 35 IP IP LSP LSP Label Popping all ultimo di un Label Popping al penultimo di un (Penultimate Hop Popping) Figura I.4.4 Rimozione dell etichetta al penultimo 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

14 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. Ingress Egress Ingress Egress / / / / /24 N prefissi = N FEC a / / / / /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 arrivino pacchetti, entranti da più interfacce d ingresso, appartenenti alla stessa FEC ed etichettati con label diverse, l ha la possibilità di rilanciare tali pacchetti etichettandoli in uscita con la stessa label. Questa operazione è detta label merging. Un che supporta la funzione di label merging è detto merging, mentre se non è in grado di effettuare questa funzione è detto non-merging. Se un utilizza la funzione di label merging, il numero di label entranti per una FEC è inferiore o uguale al numero di upstream, adiacenti all in questione, per quella FEC; il numero di label uscenti per una FEC è invece sempre unitario. In caso invece di nonmerging, il numero di label entranti e uscenti per una FEC è uguale al numero complessivo di 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 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

15 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 ( /18) (3) Messaggio OSPF ( /18) (2) Binding /18 Label X (4) Binding /18 Label Y A B 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 esegue le operazioni di assegnazione di un etichetta ad una FEC solo in due casi: a) se è l Egress per quella ; b) se riceve per quella FEC una label dal downstream della FEC stessa (Figura I.5.2). (1) Binding FEC F Label X (1) Binding FEC F/18 Label Y A B 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 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

16 next hop di un cammino sia eseguita in modo indipendente dai singoli, ma impone che un, solitamente l ingress o l egress di un LSP, specifici l intero insieme, o eventualmente un sottoinsieme, degli che devono essere attraversati dall LSP. Se l iniziatore specifica tutti gli si dice che l LSP è instradato in modo esplicito strettamente vincolato (strictly explicitly routed LSP), mentre se indica solo un sottoinsieme degli, l LSP è detto instradato in modo esplicito loscamente vincolato (loosely explicitly routed LSP). La sequenza degli attraversati da un explicit router LSP può essere determinata su base configurazione o può essere decisa dinamicamente dall 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 A Router B Router Rd Destination Address Destination Address Address Router Rd Figura I.6.1 Illustrazione del concetto di tunnel in una rete IP. 16

17 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 (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 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 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 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. LSP Tunnel LSP Tunnel R1 1 2 R2 R21 R22 R23 R3 R4 Pacchetto IP Label di livello 1 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

18 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 ; 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 ; 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 o al Penultimate. 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, 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

19 tradizionale rete IP. R2 TTL(k) TTL(k+1) --- n-2... TTL(k) TTL(k+1) --- n-i+2 Ri-1 TTL(k) TTL(k+1) --- n-1 TTL(k) TTL(k+1) --- n-i+1 TTL(k) n Ingress R1 LSP di livello k Ri LSP di livello k+1 Egress o Penultimate TTL(k) n-i Figura I.7.1 Elaborazione del campo TTL nel caso di Uniform Model LSP in entrambi i casi di rimozione dell etichetta all Egress e al Penultimate. R2 TTL(k) TTL(k+1) n-1 M-1... TTL(k) TTL(k+1) n-1 M-i+3 Ri-1 TTL(k) TTL(k+1) n-1 M TTL(k) TTL(k+1) n-1 M-i+2 TTL(k) n a Ingress R1 LSP di livello k Ri LSP di livello k+1 Egress TTL(k) n-2 Figura I.7.2 Elaborazione del campo TTL nel caso di Pipe Model LSP con rimozione dell etichetta all Egress. R2 TTL(k) TTL(k+1) n-1 M-1... TTL(k) TTL(k+1) n-1 M-i+3 Ri-2 TTL(k) TTL(k+1) n-1 M TTL(k) n Ingress b R1 LSP di livello k TTL(k) TTL(k+1) n-1 M-i+2 Ri-1 LSP di livello k+1 Penultimate TTL(k) n-1 Ri Egress TTL(k) n-2 Figura I.7.3 Elaborazione del campo TTL nel caso di Pipe Model LSP con rimozione dell etichetta al Penultimate. 19

20 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 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 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 nei due casi. 20

21 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 che informa l upstream 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 può richiedere a un altro 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 possa effettuare,in modo autonomo senza ricevere richieste da parte di altri, il binding tra una FEC F e una label L e la distribuzione della label verso l upstream. 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 downstream altre dal upstream. In particolare sono previste: Procedure eseguite dall downstream Procedura di distribuzione (Distribution procedure) Procedura di disattivazione (Withdrawal procedure) Procedure eseguite dall 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

22 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 downstream per distribuire una label associata ad una particolare FEC verso l upstream sull LSP da instaurare. Sono possibili quattro diverse alternative di attuazione di questa procedura: PushUnconditional Un Rd esegue autonomamente un binding tra una FEC F e una label L e esegue la distribuzione verso l 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 Ru Rd Figura II.1.1 Procedura di distribuzione delle label di tipo PushUnconditional. PushConditional In questa procedura un 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 Rn a valle rispetto alla direzione del traffico sull LSP; b) Rd è l Egress del LSP. 22

23 (2) Esecuzione binding tra FEC F e Label L (3) Invio del Messaggio di Label distribution (1) Invio del Messaggio di Label distribution Ru Rd 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 riceva una un messaggio di label binding dall next hop o che l sia l ultimo dell LSP. PulledUnconditional In questa procedura un Rd esegue il binding tra una FEC F e una label L solo se riceve una richiesta di binding da un 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. Ru (2) Esecuzione binding tra FEC F e Label L (1) Invio di una richiest di binding (3) Invio del Messaggio di Label distribution Ru Rd Figura II.1.3 Procedura di distribuzione delle label di tipo PulledUnconditional. PulledConditional In questa procedura un 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 Rn a valle rispetto alla direzione del traffico sull LSP o è l Egress del LSP; b) Rd riceve una richiesta di binding da un 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

24 (3) Esecuzione binding tra FEC F e Label L (2) Invio di una richiest di binding (4) Invio del Messaggio di Label distribution (1) Invio del Messaggio di Label distribution Ru Rd 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 downstream per comunicare all 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 Rd di un messaggio di unbinding verso l Ru (Figura II.1.5). (1) Termine del binding tra FEC F e Label L (2) Invio del Messaggio di Unbinding Ru 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 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 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 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

25 L upstream (Ru) invia una richiesta di binding all 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 upstream (Ru) invia una richiesta di binding all downstream ogniqualvolta riceve una sua volta dall 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 che riceve una richiesta di binding non è in grado di soddisfare la richiesta. L Rd emette verso l Ru un messaggio che specifica la ragione di questa indisponibilità. Le modalità di reazione dell Ru sono codificate in due possibili alternative procedurali: RequestRetry L 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 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 Ru quando vuole richiedere all 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 Rd non risulta essere più il next hop per il prefisso X. Sono possibili due comportamenti dell Ru: ReleaseOnChange L Ru rilascia l associazione tra FEC F e label L ed informa l Rd. NoReleaseOnChange L Ru mantiene l associazione tra FEC F e label L in modo da poterla riutilizzare successivamente. 25

26 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 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 Ru. Sono possibili due alternative UseImmediate L Ru utilizza immediatamente il binding inviato dall Rd. UseIfLoopNotDetected L Ru utilizza il binding inviato dall 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

27 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

28 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 Modulo di TE Decisione di politiche di controllo 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

29 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) Rete ATM (Strato Server) Modello Overlay MPLS 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

30 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 appartenenti al dominio MPLS, mentre l insieme dei rami F coincide con l insieme degli LSP che hanno come estremi gli, 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

31 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 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

32 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

33 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

34 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, 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 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

35 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. TT Attribute Resource Attribute Administrative Policy Input: Richiesta di instaurazione di un LSP Constraint Based Routing Database Topologia Ingress Procedura di set-up dell LSP Dominio MPLS Egress 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 d origine che quindi determina l intera sequenza di attraversati (explicit routing). Una volta determinato il percorso, l 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

36 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 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

37 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 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 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. La differenza rispetto al caso di Transiti risiede nei seguenti punti: i) nel caso di Ingress, 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, 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 (d) Codifica dell informazione Diffserv nello strato MPLS o IP Label uscente Info QoS MPLS (o IP) Figura II.3.1 Sequenza delle operazioni eseguite da un di una rete Diffserv over MPLS su un pacchetto entrante. 37

38 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 colloquia con un altro 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 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

39 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 e trasporta l insieme di 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 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 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 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

40 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 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 upstream. 40

41 II.5 Bibliografia W. Stallings : High Speed Networks and Internets Performance and Quality of Service, second edition, Prentice Hall B. Davie, Y Rekhter : MPLS, Technology and Applications, Morgan Kaufmann Publisher, U. Black : MPLS and Label switching Networks, Prentice Hall, IETF, Resource ReServation Protocol (RSVP), RFC 2205, Version 1, Functional Specification, September 1997 IETF, Requirements for Traffic Engineering Over MPLS, RFC September IETF, RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209 December IETF, Multiprotocol Label Switching Architecture, RFC 3031, January IETF, MPLS Label Stack Encoding, RFC 3032, January IETF, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, RFC 3270, May IETF, Overview and Principles of Internet Traffic Engineering, RFC 3272, May IETF, Applicability Statement for Traffic Engineering with MPLS, RFC 3346, August IETF, Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks, RFC 3443, January

42 Indice delle Figure Figura I Illustrazione del concetto di FEC... 6 Figura I.3.1 Rappresentazione di un dominio MPLS... 8 Figura I Illustrazione dei concetti di binding tra label e FEC Figura I.3.3 Illustrazione del concetto di label stack... 9 Figura I.3.4 Formato di una label MPLS 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 Figura I.4.3 Utilizzazione della FEC-to-NHLFE Map (FTN) in un Figura I.4.4 Rimozione dell etichetta al penultimo di un LSP in una rete MPLS 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) Figura I.5.1 Modalità a controllo indipendente nell instaurazione di un LSP Figura I.5.2 Modalità a controllo ordinato nell instaurazione di un LSP Figura I.6.1 Illustrazione del concetto di tunnel in una rete IP Figura I.6.2 Gerarchia di LSP e utilizzazione della tecnica di label stack Figura I.7.1 Elaborazione del campo TTL nel caso di Uniform Model LSP in entrambi i casi di rimozione dell etichetta all Egress e al Penultimate Figura I.7.2 Elaborazione del campo TTL nel caso di Pipe Model LSP con rimozione dell etichetta all Egress Figura I.7.3 Elaborazione del campo TTL nel caso di Pipe Model LSP con rimozione dell etichetta al Penultimate Figura II.1.1 Procedura di distribuzione delle label di tipo PushUnconditional Figura II.1.2 Procedura di distribuzione delle label di tipo PushConditional Figura II.1.3 Procedura di distribuzione delle label di tipo PulledUnconditional Figura II.1.4 Procedura di distribuzione delle label di tipo PulledConditional Figura II.1.5 Procedura di disattivazione della label Figura II.2.1 Ruolo delle politiche di Ingegneria del traffico per l ottimizzazione delle prestazioni di rete Figura II.2.2 Esempio di modello overlay e di modello integrato per l attuazione delle politiche di TE in una rete IP Figura II.2.3 Applicazione della tecnica Constraint-Based Routing in ambiente MPLS

43 Figura II.3.1 Sequenza delle operazioni eseguite da un di una rete Diffserv over MPLS su un pacchetto entrante