2. RSVP-TE

2. RSVP-TE

Nel capitolo precedente abbiamo parlato di due protocolli, RSVP-TE e CR-LDP, che estendono le capacità dei protocolli per la distribuzione delle label nell’ottica del setup dei forwarding state lungo un path esplicito.

I due protocolli sono stati proposti all’interno del working group MPLS, e dopo lunghe discussioni sui vantaggi di uno rispetto all’altro si è deciso di standardizzarli entrambi.

In questo capitolo ci occuperemo di RSVP-TE (RSVP-Tunnel Extension), che estende le funzionalità di RSVP e permette di sviluppare varie applicazioni nell’ambito del Traffic Engineering e della Quality of Service.

Inizieremo con una breve descrizione di RSVP, passando poi

ad RSVP-TE e a tutto ciò che di nuovo è stato introdotto, e

concludendo infine con le applicazioni rese possibili da questo

protocollo.

2.1. RSVP

Il protocollo RSVP (Resource reSerVation Protocol) nasce intorno al 1996 nell’ambito delle architetture per la qualità del servizio, e in particolare per gli Integrated Services, per permettere ad un’applicazione di effettuare la prenotazione di risorse prima di iniziare la trasmissione dei dati.

Il protocollo è utilizzato dagli host per comunicare alla rete richieste di servizio e dai router all’interno della rete per stabilire un reservation state lungo il percorso. Più precisamente, RSVP è utilizzato per la prenotazione di risorse tra un sender e un receiver, in modalità simplex (unidirezionale).

2.1.1. Caratteristiche di RSVP

RSVP [6] è receiver-oriented: sono i ricevitori, e non i mittenti, a decidere l’ammontare delle risorse da richiedere e ad iniziare la prenotazione; ciò favorisce il multicast, la gestione dinamica dei gruppi e l’eterogeneità dei ricevitori.

RSVP è anche indipendente dai protocolli di routing, e ciò permette di utilizzarlo con un’ampia gamma di protocolli.

Inoltre è soft-state: gli stati di prenotazione all’interno dei

router hanno dei timer alla scadenza dei quali vengono

cancellati, a meno che non siano inviati precedentemente dei

messaggi di refresh; anche questa caratteristica favorisce una gestione rapida e dinamica dei gruppi multicast, nonché la possibilità di variare facilmente l’ammontare delle risorse riservate.

Infine RSVP mette a disposizione diversi stili di prenotazione, che permettono per esempio di condividere una prenotazione tra flussi di diversi mittenti o di scegliere un particolare mittente al quale il ricevitore è interessato; questi stili sono il Fixed-Filter (FF), che prevede una prenotazione distinta per ogni specifico mittente, lo Shared Explicit (SE), che prevede una prenotazione condivisa da una lista esplicita di mittenti, e il Wild-card-Filter (WF), che prevede una singola prenotazione per ricevitore che può essere condivisa da qualsiasi mittente.

2.1.2. Funzionamento base di RSVP

Mostriamo ora il funzionamento base di RSVP, grazie al semplice esempio mostrato in figura 2.1, con un trasmettitore (S) e due ricevitori (R

e R

).

Supponiamo che il mittente S abbia del traffico da inviare ai

ricevitori R

e R

: egli invia un Path Message verso ognuno dei

due ricevitori, che viene inoltrato secondo il normale

forwarding di livello 3 (figura 2.2).

Questo messaggio contiene sempre il nodo precedentemente attraversato nel campo Previous Hop, una descrizione del traffico che il mittente vorrebbe inviare nel campo Sender T- Spec, le “coordinate” per il traffico (indirizzo IP del sender e

R1

Figura 2.2: inoltro del Path Message S

R2 R1

Figura 2.1: topologia d’esempio S

R2

porta del processo) nel Sender Template ed eventualmente alcune informazioni opzionali.

Alla ricezione del Path Message, ogni router si costruisce un path state in cui memorizza tutte le informazioni suddette, in particolare il Previous Hop.

Una volta che i messaggi arrivano ai destinatari, ciascuno di loro può decidere indipendentemente se effettuare una prenotazione e stabilisce l’ammontare della stessa, inviando un Resv Message verso il mittente (nel nostro esempio, solo il ricevitore R

effettua la richiesta, come mostra la figura 2.3).

Questo messaggio viene inoltrato dai router verso il mittente

attraverso il percorso inverso rispetto a quello che ha compiuto

il Path Message (e che compiranno poi i pacchetti di traffico),

grazie al Previous Hop memorizzato nei path state, che in

questo caso diventa il next hop per il pacchetto di richiesta. Il

Resv Message contiene informazioni sullo stile della

prenotazione, le “coordinate” del traffico nel Filter Spec

(analogo al Sender Template) e le caratteristiche del servizio

richiesto nel Flow Spec, in particolare la QoS desiderata nel

Reservation Spec (RSpec) e la descrizione del traffico nel

Traffic Spec (TSpec). Ogni router lungo il percorso analizza la

richiesta di prenotazione di risorse, e se può soddisfarla manda

avanti nel percorso inverso il Resv Message e memorizza le sue informazioni in un reservation state.

Nel caso in cui invece un router non riesca a soddisfare la richiesta, manda indietro al ricevitore un messaggio di ResvError, in cui comunica questa impossibilità.

Se tutto il processo è stato effettuato correttamente, la prenotazione viene registrata in ognuno dei router che collegano il destinatario al mittente: ora il mittente può iniziare ad inviare i suoi pacchetti verso il ricevitore con la certezza che ci sono risorse sufficienti a far sì che essi arrivino (figura 2.4).

Il ricevitore deve spedire lo stesso Resv Message ogni 30 secondi (il valore abituale dei timer) fino a quando vuole

R1

Figura 2.3: inoltro del Resv Message S

R2

usufruire della prenotazione di risorse, in modo da aggiornare gli state nei router (e lo stesso per il Path Message del sender).

Oltre ai messaggi già descritti (Path, Resv, ResvErr), abbiamo altri tipi di messaggi:

ƒ PathErr: per l’indicazione di un errore in risposta ad un Path Message (dai router al mittente);

ƒ PathTear: per abbattere i path state di una prenotazione (dal mittente ai router);

ƒ ResvTear: per abbattere i reservation state di una prenotazione (dal destinatario ai router);

ƒ ResvConf: per la conferma dell’avvenuta prenotazione (dal mittente al destinatario).

R1

Figura 2.4: inoltro dei pacchetti di traffico e del messaggio di refresh S

R2

2.2.RSVP-TE

Passiamo ora alla descrizione accurata del protocollo RSVP- TE, che, come detto, estende le funzionalità di RSVP per la creazione di LSP, con o senza prenotazione delle risorse, nelle reti MPLS.

Poiché il traffico che transita lungo un percorso label-switched è definito dalla label applicata al nodo d’ingresso dell’LSP, questi path possono essere trattati come tunnel, nascosti sotto il normale routing IP e i meccanismi di filtering: si parla allora di tunnel LSP.

I tunnel LSP permettono tutta una serie di applicazioni, in particolare riguardo all’ottimizzazione dell’utilizzazione delle risorse della rete, ma anche riguardo al fast rerouting, alla preemption e alla rivelazione dei loop.

Il grande vantaggio di RSVP-TE è che, grazie alla

combinazione di MPLS e RSVP, la definizione di un flusso è

molto flessibile: una volta che un LSP è stato definito, il

traffico che passa attraverso quel path è identificato

semplicemente dalla label applicata al nodo d’ingresso

dell’LSP, e il mapping di questa label con un particolare

traffico può essere effettuato a vari livelli di granularità. Tutti i

pacchetti ai quali viene assegnata la stessa label si dicono

appartenenti alla stessa FEC, e definiscono effettivamente il flusso RSVP-TE.

Nel classico RSVP invece le prenotazioni vengono fatte esclusivamente per singoli microflussi, flussi cioè identificati dai tipici 5 campi dell’header del pacchetto (indirizzi IP del mittente e del destinatario, porte del mittente e del destinatario e identificativo del protocollo), rendendo molto difficile la scalabilità del sistema.

Inoltre con RSVP-TE, poiché le label sono associate ai flussi di traffico, i router hanno la possibilità di identificare il giusto reservation state per un pacchetto basandosi solo sul valore della sua label, e ciò semplifica in maniera netta tutte le varie operazioni.

2.2.1. Funzionamento generale

Analizziamo ora il funzionamento generale del protocollo RSVP-TE, lasciando alla sezione successiva la descrizione particolareggiata dei nuovi oggetti introdotti.

Facciamo riferimento alla figura 2.5, dove l’LSR A vuole

creare un LSP esplicito verso l’LSR C. Dapprima egli crea un

Path Message con un session-type LSP_Tunnel, quindi include

nel messaggio un oggetto Label_Request, che indica la

richiesta di un label binding, e un oggetto Explicit_Route (in

parentesi nel disegno), che indica il percorso prestabilito.

L’LSR può aggiungere eventualmente un oggetto Record- Route, che come vedremo in seguito permette di registrare il percorso effettuato (per successive operazioni di notifica, rilevazioni di loop, ecc.), e un oggetto Session_Attribute per informazioni addizionali quali preemption, priorità, protezione e diagnostica.

Una volta costruito il Path Message, l’LSR A lo invia al next hop indicato dall’Explicit_Route (se questo oggetto non è presente, il next hop è fornito dal classico routing hop-by-hop).

Il nodo intermedio B che riceve il Path Message modifica l’oggetto Explicit_Route (eliminando il suo nome) e inoltra il pacchetto verso il nodo di uscita C.

Il nodo C riceve il Path Message e riconosce di essere l’egress node dell’LSP, quindi alloca una nuova label (15), la inserisce nel Label object e pone questo oggetto nel Resv Message che

C A

ResvMsg (15) ResvMsg (12)

PathMsg (C) PathMsg (B,C)

Figura 2.5: funzionamento di RSVP-TE

B

invia verso il sender; il Resv Message seguirà il percorso inverso, grazie ai path state creati dal Path Message, come avviene nel classico RSVP.

Quando B riceve il messaggio, prende la label nel Label object e la usa come outgoing label per l’LSP; quindi alloca una nuova label (12) e la pone nel Label object del Resv Message che manderà al Previous Hop memorizzato nel path state.

Infine aggiunge la nuova coppia di label (12,15) alla tabella di label switching, insieme all’interfaccia di uscita (C in questo caso). Quando il Resv Message raggiunge A, l’LSP è costruito.

Per quanto riguarda la prenotazione delle risorse, essa non è obbligatoria, quindi un LSP può essere costruito con o senza risorse. Nel caso ci sia la prenotazione, essa viene effettuata contestualmente ai label binding, con le modalità classiche previste da RSVP.

2.2.2. Nuovi oggetti

Abbiamo fatto riferimento a diversi nuovi oggetti introdotti da

RSVP-TE [7]: andiamo ad analizzarli nel dettaglio, mostrando

dapprima la loro posizione nelle nuove versioni del Path

Message e del Resv Message (figure 2.6-a e 2.7-b); i campi in

blu sono opzionali e nel Resv Message non abbiamo ripetuto

l’intera struttura per gli oggetti già presenti nel Path Message.

Ver: 1 Flags Msg Type: 1 RSVP Checksum

Send_TTL (Reserved) RSVP Length

SESSION obj. length Class-num: 1 C-Type: 7 Ipv4 Egress Node Address

0 Tunnel ID

Extended Tunnel ID

RSVP_HOP obj. length Class-num: 3 C-Type: 1 Last Hop Address

Logical Interface Handle for Last Hop

TIME_VALUES obj. length Class-num: 5 C-Type: 1 Refresh Period

Max Refresh Period

ERO length Class-num: 20 C-Type: 1

L Type Length IPv4 Address

IPv4 Address (continued) Prefix length Reserved LABEL_REQUEST obj. length Class-num: 19 C-Type: 1

Reserved L3PID

SESSION ATTRIBUTE obj. length Class-num: 207 C-Type: 7 Setup Priorità Holding Priority Flags Name length

Session Name

POLICY DATA obj. (Class-num: 14; C-Type: 1)

SENDER TEMPLATE obj. length Class-num: 11 C-Type: 7 IPv4 Tunnel Sender Address

0 LSP ID

SENDER TSPEC obj. (Class-num: 12; C-Type: 2) ADSPEC obj. (Class-num: 13; C-Type: 2)

RRO length Class-num: 21 C-Type: 1

L Type Length IPv4 Address

IPv4 Address (continued) Prefix length Flags

Type Length Flags C-Type: 1

Contents of label obj.

Figura 2.6-a: formato del Path Message in RSVP-TE

Ver: 1 Flags Msg Type: 2 RSVP Checksum

Send_TTL (Reserved) RSVP Length

SESSION Obj.

RSVP_HOP Obj.

TIME_VALUES Obj.

SCOPE Obj. (Class-num: 7, C-Type: 1) POLICY_DATA Obj.

STYLE Obj. length Class-num: 8 C-Type: 1

Flags Option vector

FLOW SPEC Obj. (Class-num: 9, C-Type: 1)

FILTER_SPEC Obj. length Class-num: 10 C-Type: 1 IPv4 Source Address

Reserved LSP ID

LABEL Obj. length Class-num: 16 C-Type: 1

0 Label Value

RRO

Indichiamo ora, per ogni nuovo oggetto di RSVP-TE, il formato, le diverse versioni e la funzione svolta:

ƒ Label Object:

è trasportato nel Resv Message e deve obbligatoriamente seguire il campo FilterSpec; ha un classnum pari a 16 ed un unico C_Type pari ad 1; il suo formato è rappresentato in figura 2.7.

Figura 2.6-b: formato del Resv Message in RSVP-TE

Il contenuto è una singola label codificata in 4 ottetti. Ogni label MPLS è un intero unsigned tra 0 e 1048575.

Come detto, lo scopo di questo oggetto è trasportare nel Resv Message una label dal nodo che ha fatto il binding al nodo che l’ha richiesto con il Path Message. Se nella richiesta è specificato un range per la scelta della label, e il nodo downstream non è in grado di soddisfare questo range, deve inviare un messaggio di PathErr, con codice di errore “routing problem” e valore “label allocation failure”.

Non appena un nodo ha mandato un Resv Message con un Label object, deve essere in grado di effettuare il forwarding dei pacchetti che trasportano la label assegnata.

Il Label object può esser memorizzato nel reservation state.

Un nodo upstream usa la label contenuta nel Label Object come outgoing label associata a quel flusso.

31 0

Figura 2.7: formato del Label object

(top label)

ƒ Label Request Object:

è trasportato nel Path Message; ha classnum pari a 19 e tre diversi C_Type. Il tipo 1 è una Label Request senza label range, dal formato mostrato in figura 2.8.

Il campo Reserved è un campo riservato, attualmente riempito di 0 in trasmissione ed ignorato in ricezione. Il campo L3PID è un identificativo del protocollo di livello 3 usato nel path.

Il tipo 2 (mostrato in figura 2.9) è un Label Request con label range ATM.

15 31

0

Reserved L3PID

Figura 2.9: Label Request Object, C_Type 2 Res Minimum VPI

Res Maximum VPI

Minimum VCI Maximum VCI M

15 31

0

Reserved L3PID

Figura 2.8: Label Request Object, C_Type 1

Rispetto al primo tipo, abbiamo un bit M che, se settato, indica che il nodo è capace di merging, un campo Minimum VPI, di 12 bit, che contiene il valore minimo supportato della parte VPI della label, e i campi Minimum VCI (16 bit), Maximum VPI (12 bit) e Maximum VCI (16 bit) con significati analoghi.

Il tipo 3 è invece un Label Request con label range Frame Relay:

Il campo DLI è un DLCI Length Indicator: se assume valore 0, vuol dire che il valore del DLCI è dato da 10 bit, mentre il valore 2 indica 23 bit. I campi Minimum DLCI e Maximum DLCI, entrambi di 23 bit, indicano i valori minimo e massimo supportati per la label del Data Link Connenction Identifier (DLCI).

15 31

0

Reserved L3PID

Figura 2.10: Label Request Object, C_Type 3

DLI Minimum DLCI

Res Maximum DLCI

Res

Quando si vuole stabilire un LSP tunnel, il sender crea un Path Message con un Label Request object, che indica agli altri nodi che è richiesto un label binding per quel path e che fornisce loro un’indicazione del protocollo di livello rete utilizzato.

Se il ricevitore non supporta il protocollo indicato, deve inviare un messaggio di PathErr con codice d’errore

“routing problem” e valore “unsupported L3PID”.

Il Label Request object può essere opzionalmente memorizzato nel path state.

Quando un Path Message raggiunge il ricevitore, la presenza del Label Request lo invita ad allocare una label e a porla nel Label object del Resv Message. Se è specificato un label range, la label deve essere scelta nell’intervallo indicato.

ƒ Explicit Route Object (ERO):

è trasportato nel Path Message, subito dopo il Time Values;

il suo classnum è 20, ed è formato da una serie di subobject del tipo mostrato in figura 2.11.

Il bit L settato indica che il subobject rappresenta un loose

node, altrimenti si tratta di uno strict node.

Ogni hop dell’ERO è infatti rappresentato da un abstract node, che identifica un router (e allora si parla di strict node) oppure un gruppo di più router, per esempio un intero Autonomous System, la cui topologia interna è sconosciuta al router che calcola l’explicit route (e allora si parla di loose node).

L’uso combinato di loose e strict node consente una maggiore flessibilità nella definizione dei percorsi, e permette di dichiarare un explicit route anche se si è in possesso di informazioni incomplete sulla topologia della rete.

Il campo Type indica la tipologia del suboject; attualmente sono definiti tre possibili valori: 1 per un prefisso IPv4, 2 per un prefisso IPv6 e 32 per il numero di un Autonomous System.

Il campo Length contiene la lunghezza totale del subobject in byte. E’ almeno pari a 4 e comunque un multiplo di 4.

Type Length (contents) L

Figura 2.11: subobject dell’Explicit Route Object

Il contenuto infine del subobject è un indirizzo IPv4 (di lunghezza pari a 4 byte) o un indirizzo IPv6 (16 byte) o il numero di un Autonomous System (2 byte).

Come detto, il compito dell’Explicit Route Object è la definizione del percorso esplicito che si vuol far compiere ad un determinato flusso di pacchetti. Quando un nodo riceve un Path Message contenente un oggetto di questo tipo, effettua le seguenti operazioni:

o dapprima analizza il primo subobject, che deve per forza descrivere un abstract node di cui fa parte il nodo stesso (altrimenti si invia un messaggio di errore con codice “bad explicit route object”);

o quindi passa al secondo subobject (a meno che non ci

sia, e quindi il percorso esplicito è già finito): se

l’abstract node descritto dal subobject gli è

topologicamente adiacente, allora seleziona un

particolare next hop membro di questo secondo abstract

node e gli invia il Path Message (dopo aver tolto il

primo subobject dall’ERO); se invece non è adiacente,

seleziona un nodo all’interno del suo abstract node che

si trova lungo il path verso l’abstract node del secondo

subobject e gli invia il Path Message (senza togliere il

primo subobject dall’ERO).

ƒ Record Route Object (RRO):

può esser trasportato sia nel Path Message che nel Resv Message, e serve a registrare il percorso compiuto;

opzionalmente possono essere registrate anche le label. Il classnum di questo oggetto è il 21, e attualmente è definito solo il C_Type 1.

L’RRO è formato da una serie di subobject di lunghezza variabile, che possono contenere un indirizzo IPv4, un indirizzo IPv6 o una label, oltre ai classici campi Length e Type e ad un flag che indica se il link downstream del nodo è protetto da un meccanismo locale di riparazione.

Quando un nodo riceve un messaggio contenente l’oggetto RRO, lo memorizza nello state opportuno e inserisce poi il suo indirizzo, ed eventualmente la label usata, nell’oggetto stesso, prima di inviare il messaggio al nodo successivo.

Se un nodo riceve un RRO diverso dal precedente, può decidere di inviare un messaggio di refresh contenente tale oggetto prima della scadenza del timer relativo.

Ci son tre possibili usi dell’RRO in RSVP: rilevazione di

routing loop di livello 3, raccolta di informazioni hop-by-

hop sul percorso per il sender o il receiver, registrazione del

percorso da inserire poi nell’ERO.

Nel caso di un qualsiasi problema durante le varie operazioni con l’RRO, bisogna inviare un messaggio d’errore (“routing problem”, codice 24) o un messaggio di notifica (“notify", codice 25). Situazioni di errore possono essere per esempio un RRO divenuto troppo grande per l’MTU, un loop rilevato dall’RRO oppure procedura dell’RRO non supportata dal nodo.

ƒ Session Attribute Object:

trasportato nel Path Message, ha classnum pari a 207 e 2 C_Type. Il primo è l’LSP_Tunnel, con C_Type 1:

Il campo Setup Priority indica la priorità della sessione nell’ottenimento delle risorse; può assumere valore da 0 a 7, con 0 che è la priorità più alta. Questo campo è utilizzato per decidere se una sessione può fare preemption su un'altra sessione.

Holding Prio

31 0

Setup Prio Flags Name Len

Session Name

Figura 2.12: LSP_Tunnel, C-Type 7

Il campo Holding Priority indica la priorità della sessione nel mantenimento delle risorse; ha le stesse caratteristiche del campo precedente.

Il campo Flags può assumere valori particolari, ad indicare per esempio che è attivato un meccanismo locale di riparazione del link, che nell’RRO è richiesta anche la registrazione della label oppure che il nodo d’ingresso del tunnel può decidere di redirigere il tunnel senza abbatterlo.

Il campo Name Len indica la lunghezza in byte della stringa contenuta in Session Name prima del padding.

Il campo Session Name è una stringa di caratteri che contiene un identificativo della sessione.

Il secondo tipo di Session Attribute Object è l’LSP_Tunnel_RA, con C_Type 1, mostrato in figura 2.13.

Holding Prio Flags Name Len

0 31

Setup Prio

Session Name

Figura 2.13: LSP_Tunnel_RA, C-Type 1 Include-all

Include-any

Exclude-any

Oltre ai campi del tipo precedente, son presenti un vettore Exclude-any di 32 bit, che rappresenta un set di attributi che rendono inaccettabile un link, un vettore Include-any di 32 bit, che rappresenta un set di attributi che rendono adatto un link, e un vettore Include-all di 32 bit, che rappresenta un set di attributi che un link deve possedere interamente per poter essere accettato.

L’oggetto Session Attribute permette di gestire in modo dinamico l’assegnazione delle risorse, grazie ai campi Setup e Holding Priority. Quando arriva un Path Message che indica la possibilità della richiesta di una nuova prenotazione, se l’ammontare delle risorse non è sufficiente ad aggiungere la nuova prenotazione a quelle già presenti si guarda alle priorità delle varie sessioni: se il campo Setup Priority della nuova sessione è minore del campo Holding Priority di una sessione già presente, allora ci può essere preemption; in questo caso la nuova richiesta viene soddisfatta e quella precedente viene disattesa con l’invio di un messaggio di notifica al sender relativo.

I campi aggiuntivi dell’LSP_Tunnel_RA permettono

invece di effettuare le procedure di Resource Affinity, con

le quali si stabilisce se un link è accettabile o meno. In

particolare, quando lo strict node di un ERO sta

esaminando una richiesta di prenotazione, può validare l’affinità delle risorse del link confrontandone le proprietà con quelle indicate dai 3 campi appositi del Session Attribute: se il link supera tutti e tre i test, la prenotazione può essere accettata, altrimenti bisogna mandare un PathErr Message con valore ”no route available toward destination”. Lo stesso accade quando un nodo sta scegliendo un link nell’ottica di estendere un loose node di un ERO: tra i link verso la destinazione, si sceglie quello che, oltre a superare i test indicati dai campi Exclude-any e Include-all, possiede il maggior numero di proprietà indicate nel campo Include-any. Se nemmeno un link va bene, si invia il messaggio d’errore sopra descritto.

ƒ Nuovi C-Type per Session, SenderTemplate e FilterSpec:

oltre all’introduzione dei nuovi oggetti, il protocollo RSVP-

TE ha definito nuovi C_Type per oggetti già presenti in

RSVP, in modo da renderli più adeguati alle nuove

funzionalità; in particolare ha definito due nuovi tipi per gli

oggetti Session, Sender_Template e Filter_Spec,

aggiungendo sostanzialmente dei campi per l’identificativo

del tunnel LSP e per l’indirizzo degli estremi del tunnel

stesso.

2.3. Applicazioni di RSVP-TE

Oltre alle nuove funzionalità già espressamente descritte nei paragrafi precedenti (explicit routing, gestione delle priorità e preemption, registrazione del percorso effettuato, resource affinity), grazie al protocollo RSVP-TE c’è la possibilità di numerose altre applicazioni, che analizzeremo in questo paragrafo.

2.3.1. Rerouting

In molte circostanze è desiderabile poter redirigere un LSP esistente. Per esempio, un tunnel LSP può essere rediretto per ottimizzare l’utilizzazione delle risorse nella rete, oppure per ripristinare la connettività dopo una rottura (e magari, dopo aver ripristinato il collegamento, si vuole tornare all’LSP originario).

RSVP-TE usa in questi casi una tecnica chiamata “make- before-break” per minimizzare lo smembramento del flusso di traffico e la perdita di pacchetti durante il rerouting: per redirigere un LSP esistente, prima viene settato l’LSP sostitutivo e il traffico viene deviato su di esso, e solamente in seguito l’LSP originario viene abbattuto.

Durante il periodo di transizione, può sorgere il problema che il

vecchio e il nuovo LSP entrino in competizione per

l’assegnazione delle risorse sui segmenti di rete che hanno in comune. A seconda dalla disponibilità delle risorse, questa competizione può quindi portare l’Admission Control a negare il permesso di setup al nuovo LSP.

Per evitare questo inconveniente, è necessario far sì che la prenotazione delle risorse non venga conteggiata due volte, sia per il primo che per il secondo LSP. In RSVP_TE ciò si ottiene utilizzando lo stile di prenotazione SE, in modo che i due LSP condividano le risorse lungo i link che hanno in comune, come mostra la figura 2.14 nelle sue 3 fasi: LSP originario, entrambi gli LSP con prenotazione SE sui link in comune e infine solo il nuovo LSP.

Figura 2.14-a: prima fase, LSP originario

Figura 2.14-c: terza fase, con il solo LSP di rerouting

SE SE

Figura 2.14-b: seconda fase, con entrambi gli LSP e prenotazione SE

L’oggetto LSP_Tunnel è usato per descrivere la visibilità della sessione RSVP di un determinato tunnel. La combinazione dell’indirizzo IP del nodo d’ingresso, del tunnel ID e dell’indirizzo IP del nodo d’uscita viene utilizzata come identificativo unico del tunnel LSP.

Durante il rerouting, il nodo d’ingresso deve apparire per la sessione come un sender diverso rispetto a quello dell’LSP precedente (anche se in realtà è sempre lo stesso): ecco allora l’uso di un nuovo LSP_ID nel Sender_Template e nel Filter_Spec.

L’ingress node inizia le operazioni di rerouting mandando un nuovo Path Message con lo stesso oggetto Session di prima ma con un nuovo Sender_Template, un nuovo ERO ed un nuovo LSP_ID. Questo messaggio viene trattato come un convenzionale messaggio di setup di un nuovo LSP, ma sui link in comune col vecchio LSP la prenotazione SE assicura che i due LSP condividano le stesse risorse. Inoltre il nodo continua normalmente a usare il vecchio LSP e a rinfrescare il vecchio Path Message.

Una volta che il nodo d’ingresso riceve un Resv Message per il

nuovo LSP, può finalmente deviare il traffico su di esso e

abbattere il vecchio LSP: in questo modo non abbiamo avuto

né perdite di pacchetti di traffico né smembramenti del flusso.

2.3.2. Bandwidth increase procedure

Una situazione molto simile al rerouting si ha nel caso in cui si voglia incrementare la banda prenotata per un determinato tunnel: pensando sempre alla tecnica make-before-break, la nuova prenotazione nel complesso potrebbe essere eccessiva per l’ammontare delle risorse a disposizione, ma in realtà l’ulteriore allocazione necessaria è solo la differenza tra la nuova e la vecchia banda.

Usando il classico stile di prenotazione (incrementare cioè la richiesta di banda senza modificare il Sender_Template), un nodo intermedio potrebbe rifiutare la prenotazione perché pensa di non poterla soddisfare. Ecco allora che si utilizza esattamente la stessa tecnica usata per il rerouting: un nuovo Path Message con un nuovo LSP_ID viene utilizzato per richiedere una prenotazione di banda maggiore con stile SE, e l’LSP_ID originario continua ad essere rinfrescato per assicurare che la vecchia prenotazione non venga persa se quella con banda maggiore fallisce.

In questo modo si ottiene di nuovo che le due prenotazioni non

entrano in competizione, benché attive contemporaneamente

per evitare perdite di pacchetti negli eventuali momenti

transitori.

2.3.3. Loop detection

Un’altra applicazione permessa da RSVP-TE è la rilevazione di forwarding loop. Ricordiamo che i loop possono essere divisi in due grandi gruppi: i loop transitori, che sono una conseguenza naturale del processo di convergenza del routing di livello 3, e i loop permanenti, che di solito sono causati da errori di configurazione della rete.

Fra l’altro, oltre ai classici motivi che portano alla formazione di forwarding loop, uno ulteriore nasce proprio dalle nuove prospettive di RSVP-TE: la presenza nell’ERO di loose node (conseguenza di una non perfetta conoscenza della topologia della rete) facilita infatti la creazione di percorsi circolari durante i transitori.

L’oggetto che permette la rilevazione di questi loop, sia di livello 3 che inerenti l’explicit routing, è l’RRO, che, ricordiamo, è trasportato sia nel Path che nel Resv Message e consente la registrazione dei nodi intermedi durante il percorso.

Ad un router basta controllare la lista dell’RRO per verificare la presenza o meno di percorsi richiusi: se il suo nome è già presente nella lista, allora c’è un loop.

Una sessione RSVP è priva di loop se il nodo destinatario

riceve un Path Message, o se il nodo sorgente riceve un Resv

Message, senza rilevazione di percorsi circolari nell’RRO.

Le azioni effettuate da un nodo che rileva un loop grazie all’RRO son diverse al seconda del tipo di messaggio che trasporta l’oggetto: se è un Path Message, il router scarta questo messaggio e costruisce e manda un PathErr Message di tipo “routing problem” con valore “loop detected” (figure 2.15- a e 2.15-b).

Se invece a contenere l’RRO col loop è un Resv Message, il router scarta semplicemente il messaggio, come mostra la figura 2.16: d’altronde, se non è stato rilevato un loop nel Path Message, non può esserci nemmeno nel Resv Message, quindi

Figura 2.15-a: arriva il Path Msg con l’RRO e il router rileva il loop

Figura 2.15-b: si scarta il PathMsg e si invia un PathErr Msg

LOOP!!!!!!

c’è stato un semplice errore di forwarding e non deve essere inviato alcun messaggio d’errore.

2.3.4. Hello extension

Un’ultima funzionalità consentita dal protocollo RSVP-TE è la rilevazione della rottura di un nodo, che permette ad ogni nodo di scoprire quando un vicino non è più raggiungibile grazie alla cosiddetta Hello Extension.

Questo processo è stato pensato per i casi in cui siano assenti meccanismi di notifica di rotture a livello link, oppure essi non siano sufficienti per una rapida rilevazione della rottura.

Figura 2.16: arriva il Resv Msg, si rileva il loop e si scarta il messaggio

LOOP!!!!!!

La Hello Extension è composta da un Hello message, un Hello Request object e un Hello ACK object, tutti definiti nella RFC di RSVP-TE [7]. I due nodi in comunicazione possono scegliere indipendentemente la durata degli intervalli di controllo.

Tutto il processo si basa sull’osservazione di un valore specifico, l’instance value: il cambiamento di questo valore o il reporting sbagliato del valore pubblicizzato localmente indicano qualche problema nel nodo vicino. L’Hello Extension fornisce appunto un meccanismo di richiesta e di reporting dell’instance value, che permette il processing periodico del valore e l’eventuale rilevazione della rottura.

Un nodo genera periodicamente un Hello Message contenente un Hello Request object per ognuno dei vicini allo status dei quali è interessato; in questo messaggio egli pone nel campo Src_Instance il valore della sua istanza (valore che non deve cambiare durante lo scambio di messaggi di Hello) e nel campo Dst_instance l’instance value più recente ricevuto dal vicino in questione (se nessun valore è stato mai ricevuto, si setta il campo a zero).

Alla ricezione di un messaggio con un Hello Request object, il

nodo ricevente deve confrontare l’instance value appena

arrivato con quello ricevuto precedentemente (e quindi

memorizzato): se i due valori coincidono, il nodo mittente

“funziona”; se il valore precedente era uguale a zero, deve essere aggiornato col nuovo valore; se i due valori differiscono o quello appena ricevuto è uguale a zero, il nodo mittente deve essere considerato non funzionante.

In tutti i casi il nodo ricevente deve inviare un Hello message contenente un Hello ACK object, con tutti gli appositi valori delle istanze (il suo e quello ricevuto dall’altro nodo).

A sua volta il nodo che riceve l’Hello ACK object effettua i controlli appena visti e stabilisce se il suo vicino funziona o meno. Naturalmente la mancata risposta ad un Hello request viene interpretata come segnale della rottura del nodo in questione.

Quando un nodo rileva una rottura o la perdita di

comunicazione, può iniziare una nuova procedura di Hello,

utilizzando un nuovo valore di Src-Istance rispetto a quelli

usati precedentemente (valore che rimarrà inalterato fino ad un

reset o ad una nuova rottura) e ponendo a zero il campo

Dest_Value.