4.1. Aspetti generali 4. RSVP-TE/ns

4.

RSVP-TE/ns

4.1. Aspetti generali

In questo capitolo parleremo dell’implementazione del protocollo RSVP-TE (che abbiamo chiamato RSVP-TE/ns) per l’ambiente di simulazione Network Simulator.

Per realizzarla siamo partiti dalla versione 2-26 di Network Simulator, su cui abbiamo istallato il modulo MPLS (MNS, versione 2 per ns 2-26) e il modulo RSVP (RSVP/ns, patch per ns 2-26).

Quello che abbiamo fatto è stato estendere il modulo RSVP/ns con gli oggetti introdotti dal nuovo protocollo e permettere che il modulo MNS interagisca con esso per la distribuzione delle label.

RSVP-TE/ns prevede la presenza di molti file di RSVP/ns e di

MNSv2, file che abbiamo modificato cambiando delle funzioni o aggiungendone interamente delle altre. Nei prossimi

paragrafi descriveremo in termini qualitativi le modifiche apportate e tutte le parti aggiunte, rimandando all’Appendice B per il dettaglio dei file.

4.2. I file di RSVP-ns

Abbiamo costruito il nodo RSVP-TE integrando un agent

RSVP e un classifier MPLS, col primo che si occupa

principalmente della prenotazione delle risorse e della distribuzione delle label e il secondo che si occupa invece delle operazioni di label switching per il forwarding.

Per quanto riguarda i file del modulo RSVP/ns, tutti implementati in C++ [13], abbiamo principalmente aggiunto i nuovi oggetti previsti dallo standard RSVP-TE, inserito una serie di nuovi elementi nei psb e negli rsb e implementato la gestione dell'explicit routing.

In particolare, abbiamo aggiunto gli oggetti indicati nella tabella in figura 4.1, seguendo fedelmente i dettami dell'RFC 3029 [7]; naturalmente, per una completa gestione di questi oggetti, abbiamo implementato costruttori, distruttori, funzioni di stampa e funzioni per l'estrazione dei valori dai vari campi dell'oggetto.

Oggetti inseriti RSVP_LABEL_TE LABEL_REQUEST_TE EXPLICIT_ROUTE_TE RECORD_ROUTE_TE SESSION_ATTRIBUTE_TE DIFFSERV_OBJECT CLASSTYPE

Non tutti gli oggetti menzionati sono stati utilizzati nell’implementazione, ma sono stati comunque inseriti nell’ottica di future espansioni del codice; in particolare ci riferiamo al DiffServ_Object e al Classtype, utilizzabili in ambito DiffServ.

Abbiamo inoltre modificato alcuni oggetti già presenti in RSVP/ns, come Session_Objecct, FilterSpec_Object e SenderTemplate_Object, ai quali abbiamo aggiunto il campo TunnelID.

Ci siamo poi occupati dell’aggiunta di nuove informazioni nei psb e negli rsb.

PSB RSB Sender_Template * RSVP_Hop * Sender_Tspec * Filter_Spec * RSVP_Hop * Flowspec * Explicit_Route_TE * Style * Record_Route_TE * Resv_Confirm * Session_Attribute_TE * RSVP_Label_TE * ClassType * psb *p

DiffServ_Object * nsaddr_t outifacehop

Label_Request_TE * double timeout double timeout char is_new int ingressinterface char processed

int penultimate rsb * next

int ingress rsb * old

int LIB char modified

int tid

RSVPChecker * psb * next

int flag

In particolare, come mostra la figura 4.2, nel psb abbiamo inserito gli elementi in rosso, e cioè i puntatori (indicati con un asterisco in C++) ai nuovi oggetti implementati e alcuni flag utili durante la costruzione delle tabelle di forwarding e durante le operazioni di label switching; nell'rsb invece abbiamo aggiunto il puntatore all'oggetto RSVP_Label_TE, contenente il valore della label da inserire nei pacchetti per un determinato LSP.

Conseguentemente a queste aggiunte, abbiamo dovuto modificare tutte le funzioni riguardanti psb e rsb, per la creazione, la cancellazione e l’aggiornamento degli state block.

Abbiamo poi modificato le funzioni per il processing e l’invio dei messaggi di segnalazione, funzioni che in RSVP-TE/ns devono tener conto di tutti i nuovi oggetti aggiunti e soprattutto devono saper gestire l'explicit routing: il next hop non si ricava più dal semplice routing di livello 3, ma bisogna processare l'oggetto ERO, scorrere opportunamente la lista e ricavare il passo successivo (come mostra il processing effettuato dal nodo 5 nell’esempio in figura 4.3).

Abbiamo inoltre scelto, come permesso dall'RFC, di utilizzare in tutti i nodi una label unica per ogni LSP, dando così alla label stessa valore globale all'interno del dominio RSVP-TE.

Analizziamo a tal proposito l’implementazione della funzione per la gestione delle label e delle interfacce: a seconda di quale nodo si tratti, la funzione sceglie opportunamente i valori di label e interfacce e richiama le funzioni per l’inserimento di questi dati nelle relative tabelle da parte del modulo MPLS. In particolare, come mostra la figura 4.4:

¾ l'ingress node dell'LSP pone a -1 label e interfaccia di ingresso e il valore della label relativa a quell'LSP nella

5

11

8

5

Figura 4.3: gestione dell’oggetto ERO da parte del nodo 5 ERO OBJECT

label d'uscita, e inoltra poi i pacchetti verso il next hop indicato dall'ERO;

¾ i nodi interni non fanno altro che utilizzare questa label sia in ingresso che in uscita e le interfacce indicate dall'ERO; ¾ il penultimo nodo pone invece la label d'uscita a 0,

effettuando una sorta di penultimate hop popping;

¾ il nodo d'uscita dell’LSP vede infatti la label nulla e capisce di essere l'ultimo nodo per quell'LSP, passando quindi alla label di livello inferiore o effettuando il classico routing di livello 3. InLabel -1 OutLabel 52 InIface -1 OutIface 3 InLabel 52 OutLabel 0 InIface 3 OutIface 8 InLabel 52 OutLabel 52 InIface 1 OutIface 5 InLabel 0 OutLabel - InIface 5 OutIface -

Figura 4.4: scelta delle label e delle interfacce LSP

Direzione dei pacchetti

4.3. I file di MNS

Per quanto riguarda il modulo MNS abbiamo aggiunto diverse procedure. Le prime tre sono quelle a cui abbiamo accennato nel paragrafo precedente; esse vengono richiamate dall’agent RSVP e servono al setup dell’LSP da parte del modulo MPLS, con l’inserimento di label e interfacce nelle opportune tabelle (ERB, LIB e PFT):

¾ label-create-ing: setup per il nodo d'ingresso (valore -1 per label e interfaccia di ingresso);

¾ label-create-pen: setup per il penultimo nodo (valore 0 per la label d'uscita);

¾ label-create: setup per i nodi interni.

Ma le procedure più importanti, che aggiungono veramente delle nuove funzionalità al modulo implementato, sono create-erlsp e create-crlsp, che comportano l’istaurazione degli LSP: esse permettono di settare un LSP su un percorso esplicito, e nel caso di CR-LSP, di allocare anche una certa banda lungo il path. Nello specifico, le operazioni che questi comandi attivano sono le seguenti:

¾ creazione della sessione da parte del mittente;

¾ invio da parte del mittente di un messaggio di Path lungo il percorso esplicito con l’indicazione della banda e la richiesta di setup delle label per l’LSP;

¾ all’arrivo del messaggio di Path, creazione da parte del destinatario di una label e invio di un messaggio di Resv lungo il percorso inverso con la richiesta dell’allocazione della banda e la pubblicizzazione della label;

¾ processing del messaggio di Resv da parte dei nodi interni, con allocazione della banda e generazione dell’opportuna label;

¾ costruzione da parte dei nodi interni delle tabelle di label switching e inoltro del messaggio di Resv lungo i nodi upstream.

Se il messaggio di Resv arriva al nodo sorgente, vuol dire che tutti i nodi hanno potuto effettuare l’allocazione delle risorse e l’associazione delle label all’LSP: il mittente può iniziare ad inviare traffico, con la certezza che i suoi pacchetti seguano il percorso prestabilito e sfruttino le risorse allocate.

4.4. Script d’esempio

Inseriamo in questo paragrafo un file di esempio, che ci mostrerà nelle specifico le principali funzionalità di RSVP-TE/ns.

#associazione dei colori ai flussi $ns color 0 green $ns color 1 blue $ns color 2 black $ns color 50 yellow $ns color 46 purple $ns color 3 red

#apertura e gestione del file di trace e NAM set nf [open out.nam w]

$ns namtrace-all $nf

set trace [open traccia.tr w] $ns trace-all $trace

#costruzione della topologia della rete set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns mpls-node] set n4 [$ns mpls-node] set n5 [$ns mpls-node] set n6 [$ns mpls-node] set n7 [$ns mpls-node] set n8 [$ns mpls-node] set n9 [$ns mpls-node] set n10 [$ns mpls-node] set n11 [$ns mpls-node] set n12 [$ns node]

set n13 [$ns node] set n14 [$ns node] $ns duplex-rsvp-link $n0 $n3 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n1 $n11 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n2 $n10 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n3 $n11 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n11 $n4 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n4 $n5 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n5 $n6 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n6 $n7 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n7 $n8 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n8 $n9 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n9 $n10 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n7 $n5 1Mb 10ms 0.99 200 5000 Param Null

$ns duplex-rsvp-link $n10 $n3 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n5 $n12 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n5 $n13 1Mb 10ms 0.99 200 5000 Param Null $ns duplex-rsvp-link $n5 $n14 1Mb 10ms 0.99 200 5000 Param Null

#caricamento del modulo MPLS sui nodi di backbone for {set i 3} {$i < 12} {incr i} {

set a n$i

set m [eval $$a get-module "MPLS"] eval set LSRmpls$i $m}

#caricamento del modulo RSVP sui nodi set rsvp0 [$n0 add-rsvp-agent] set rsvp1 [$n1 add-rsvp-agent] set rsvp2 [$n2 add-rsvp-agent] set rsvp3 [$n3 add-rsvp-agent] set rsvp4 [$n4 add-rsvp-agent] set rsvp5 [$n5 add-rsvp-agent] set rsvp6 [$n6 add-rsvp-agent] set rsvp7 [$n7 add-rsvp-agent] set rsvp8 [$n8 add-rsvp-agent] set rsvp9 [$n9 add-rsvp-agent] set rsvp10 [$n10 add-rsvp-agent] set rsvp11 [$n11 add-rsvp-agent]

set rsvp12 [$n12 add-rsvp-agent] set rsvp13 [$n13 add-rsvp-agent] set rsvp14 [$n14 add-rsvp-agent]

#creazione delle sorgenti di traffico set udp0 [new Agent/UDP]

$ns attach-agent $n0 $udp0 $udp0 set packetSize_ 500 $udp0 set fid_ 1

set cbr0 [new Application/Traffic/CBR] $cbr0 set rate_ 500k

$cbr0 set packetSize_ 500 $cbr0 attach-agent $udp0

set udp1 [new Agent/UDP] $ns attach-agent $n1 $udp1 $udp1 set packetSize_ 500 $udp1 set fid_ 2

set cbr1 [new Application/Traffic/CBR] $cbr1 set rate_ 400k

$cbr1 set packetSize_ 500 $cbr1 attach-agent $udp1

set udp2 [new Agent/UDP] $ns attach-agent $n2 $udp2 $udp2 set packetSize_ 500 $udp2 set fid_ 3

$cbr2 set packetSize_ 500 $cbr2 set rate_ 300k $cbr2 set random_ 1 $cbr2 attach-agent $udp2

#creazione dei ricevitori

set sink0 [new Agent/LossMonitor] $ns attach-agent $n12 $sink0 set sink1 [new Agent/LossMonitor] $ns attach-agent $n13 $sink1 set sink2 [new Agent/LossMonitor] $ns attach-agent $n14 $sink2 $ns connect $udp0 $sink0 $ns connect $udp1 $sink1 $ns connect $udp2 $sink2

#procedura per la chiusura dei file proc finish {} {

global ns nf $ns flush-trace close $nf

exec nam out.nam puts "Well Done!!!" exit 0}

#lista degli eventi

$ns at 0.0 "$n0 label Sorg0" $ns at 0.0 "$n1 label Sorg1"

$ns at 0.0 "$n2 label Sorg2" $ns at 0.0 "$n12 label Ricv0" $ns at 0.0 "$n13 label Ricv1" $ns at 0.0 "$n14 label Ricv2" $ns at 0.0 "$cbr0 start" $ns at 100.0 "$cbr0 stop" $ns at 1.0 "$cbr1 start" $ns at 100.0 "$cbr1 stop" $ns at 2.0 "$cbr2 start" $ns at 100.0 "$cbr2 stop" $ns at 5.0 "$LSRmpls3 create-crlsp $n0 $n12 0 1 0 +500000 5000 32 3_10_9_8_7_6_5_" $ns at 5.0 "$LSRmpls11 create-crlsp $n1 $n13 0 2 1 +400000 5000 32 11_4_5_" $ns at 5.0 "$LSRmpls10 create-crlsp $n2 $n14 0 3 2 +300000 5000 32 10_9_8_7_5_" $ns at 15.0 "$LSRmpls10 release 0" $ns at 16.0 "$LSRmpls10 create-crlsp $n2 $n14 1 3 3 +250000 5000 32 10_11_4_5_" $ns at 9.0 "$LSRmpls3 bind-flow-erlsp 12 -1 0" $ns at 10.0 "$LSRmpls11 bind-flow-erlsp 13 -1 1" $ns at 11.0 "$LSRmpls10 bind-flow-erlsp 14 -1 2" $ns at 18.0 "$LSRmpls10 bind-flow-erlsp 14 -1 3" $ns at 100.1 "finish" $ns run

Mostriamo tramite le immagini dell’animazione NAM i vari passaggi della simulazione:

¾ i pacchetti generati dalle sorgenti seguono i normali percorsi ricavati dal routing di livello 3; i link, congestionati dal traffico in arrivo, perdono diversi pacchetti (uno rosso e due blu nell’immagine in figura 4.5);

14 Ricv2 13 Ricv1 12 Ricv0 11 10 9 8 7 6 5 4 3 2 Sorg2 1 Sorg1 0 Sorg0

¾ le tre sorgenti decidono di creare un LSP e di allocare della banda per i loro pacchetti, e così, a seguito dei tre comandi “create-crlsp”, inviano un Path message (in viola in figura 4.6) lungo i percorsi prestabiliti;

14 Ricv2 13 Ricv1 12 Ricv0 11 10 9 8 7 6 5 4 3 2 Sorg2 1 Sorg1 0 Sorg0

¾ i messaggi di Path seguono il percorso indicato dall’ERO, fino a giungere alle rispettive destinazioni (nell’immagine in figura 4.7 un Path message è accodato in un nodo e non è perciò visibile); 14 Ricv2 13 Ricv1 12 Ricv0 11 10 9 8 7 6 5 4 3 2 Sorg2 1 Sorg1 0 Sorg0

Figura 4.6: invio dei Path Message da parte delle sorgenti

¾ i Path message sono arrivati a destinazione, e i destinatari inviano in risposta un Resv message (sempre in viola in figura 4.8) col quale chiedono l’allocazione della banda e pubblicizzano la label da usare per quell’LSP; i Resv message seguono il percorso inverso, ed ogni nodo che li processa effettua sia l’allocazione della banda che il setup dell’LSP con la creazione delle label e l’inserimento nelle relative tabelle; sottolineamo al riguardo l’uso dei messaggi di RSVP (Path e Resv) per la distribuzione delle label da utilizzare per il label switching MPLS;

14 Ricv2 13 Ricv1 12 Ricv0 11 10 9 8 7 6 5 4 3 2 Sorg2 1 Sorg1 0 Sorg0

¾ col comando “bind-flow-erlsp” si effettua l’associazione dei flussi agli LSP, e così i pacchetti iniziano a seguire i percorsi stabiliti dalle sorgenti (e non più quelli indicati dal routing di livello 3) e sfruttano le risorse loro allocate (figura 4.9); 14 Ricv2 13 Ricv1 12 Ricv0 11 10 9 8 7 6 5 4 3 2 Sorg2 1 Sorg1 0 Sorg0

¾ al secondo 15.0 la sorgente 2 decide di cambiare percorso: prima rilascia le risorse allocate precedentemente e le label utilizzate col comando “release”, e poi, sempre col comando “create-crlsp”, effettua lo stesso procedimento di prima, a partire dall’invio del Path message (figura 4.10);

14 Ricv2 13 Ricv1 12 Ricv0 11 10 9 8 7 6 5 4 3 2 Sorg2 1 Sorg1 0 Sorg0

¾ il Path message arriva al destinatario che risponde con un Resv message, si fa una nuova associazione per il flusso e i pacchetti della sorgente 2 (in rosso) seguono il nuovo percorso e sfruttano le nuove risorse allocate (figura 4.11).

14 Ricv2 13 Ricv1 12 Ricv0 11 10 9 8 7 6 5 4 3 2 Sorg2 1 Sorg1 0 Sorg0

Figura 4.10: parte il setup di un nuovo LSP da parte della sorgente 2

Il modulo RSVP/ns (e per “ereditarietà” il nostro RSVP-TE/ns) permette di stampare su schermo ogni evento di processing dei pacchetti di segnalazione RSVP da parte dei vari nodi; vediamo allora quali sono gli eventi provocati dall’esecuzione dello script precedente (il primo parametro è il nodo che effettua l’azione):

11 PATH EVENT at 5.011: SID:0 RATE:400000 SENDER: 1 3 PATH EVENT at 5.011: SID:0 RATE:400000 SENDER: 0 10 PATH EVENT at 5.015: SID:0 RATE:400000 SENDER: 2 10 PATH EVENT at 5.022: SID:1 RATE:400000 SENDER: 0 4 PATH EVENT at 5.025: SID:0 RATE:400000 SENDER: 1 9 PATH EVENT at 5.026: SID:0 RATE:400000 SENDER: 2 9 PATH EVENT at 5.034: SID:1 RATE:400000 SENDER: 0 8 PATH EVENT at 5.038: SID:0 RATE:400000 SENDER: 2 5 PATH EVENT at 5.039: SID:0 RATE:400000 SENDER: 1 8 PATH EVENT at 5.045: SID:1 RATE:400000 SENDER: 0 7 PATH EVENT at 5.049: SID:0 RATE:400000 SENDER: 2 13 PATH EVENT at 5.051: SID:0 RATE:400000 SENDER: 1 7 PATH EVENT at 5.056: SID:1 RATE:400000 SENDER: 0 5 PATH EVENT at 5.060: SID:1 RATE:400000 SENDER: 2 5 RESV EVENT at 5.062: SID:0 RATE:400000 SENDER: 1 6 PATH EVENT at 5.067: SID:0 RATE:400000 SENDER: 0 14 PATH EVENT at 5.071: SID:0 RATE:400000 SENDER: 2 4 RESV EVENT at 5.073: SID:0 RATE:400000 SENDER: 1 5 PATH EVENT at 5.079: SID:2 RATE:400000 SENDER: 0 5 RESV EVENT at 5.082: SID:1 RATE:400000 SENDER: 2 11 RESV EVENT at 5.084: SID:0 RATE:400000 SENDER: 1 12 PATH EVENT at 5.090: SID:0 RATE:400000 SENDER: 0 7 RESV EVENT at 5.093: SID:0 RATE:400000 SENDER: 2 1 RESV EVENT at 5.095: SID:0 RATE:400000 SENDER: 1 5 RESV EVENT at 5.101: SID:2 RATE:400000 SENDER: 0 8 RESV EVENT at 5.104: SID:0 RATE:400000 SENDER: 2 6 RESV EVENT at 5.112: SID:0 RATE:400000 SENDER: 0 9 RESV EVENT at 5.115: SID:0 RATE:400000 SENDER: 2 7 RESV EVENT at 5.123: SID: 1 RATE:400000 SENDER: 0

10 RESV EVENT at 5.126: SID:0 RATE:400000 SENDER: 2 8 RESV EVENT at 5.134: SID:1 RATE:400000 SENDER: 0 2 RESV EVENT at 5.137: SID:0 RATE:400000 SENDER: 2 9 RESV EVENT at 5.145: SID:1 RATE:400000 SENDER: 0 10 RESV EVENT at 5.156: SID:1 RATE:400000 SENDER: 0 3 RESV EVENT at 5.167: SID:0 RATE:400000 SENDER: 0 0 RESV EVENT at 5.178: SID:0 RATE:400000 SENDER: 0 10 PATH EVENT at 15.011: SID:0 RATE:450000 SENDER:2 3 PATH EVENT at 15.022: SID:1 RATE:450000 SENDER: 2 11 PATH EVENT at 15.033: SID:1 RATE:450000 SENDER:2 4 PATH EVENT at 15.045: SID:1 RATE:450000 SENDER: 2 5 PATH EVENT at 15.056: SID:1 RATE:450000 SENDER: 2 14 PATH EVENT at 15.068: SID:0 RATE:450000 SENDER:2 5 RESV EVENT at 15.079: SID:1 RATE:450000 SENDER: 2 4 RESV EVENT at 15.090: SID:1 RATE:450000 SENDER: 2 11 RESV EVENT at 15.101: SID:1 RATE:450000 SENDER:2 3 RESV EVENT at 15.112: SID:1 RATE:450000 SENDER: 2 10 RESV EVENT at 15.123: SID:0 RATE:450000 SENDER:2 2 RESV EVENT at 15.134: SID:1 RATE:450000 SENDER: 2

4.5. Rottura dei link

Accanto alle modifiche di carattere generale, tese all’implementazione vera e propria del protocollo RSVP-TE, abbiamo cercato di risolvere delle problematiche più particolari; per esempio, abbiamo cercato di implementare il rerouting necessario dopo la caduta di un link.

Nei moduli di NS2 attualmente presenti non è previsto alcun meccanismo di rerouting: addirittura quando un nodo rileva la rottura di un link ad esso adiacente, non si preoccupa nemmeno di avvisare gli altri nodi (e difatti in RSVP/ns non è presente il

PathErrorMessage, che nella realtà è il messaggio utilizzato per queste notifiche).

Guardiamo allora nello specifico come abbiamo provato a risolvere questo problema: all'inizio abbiamo creato un comando che fa cadere il link e poi richiama due funzioni di nostra creazione nel modulo RSVP. La prima funzione va ad agire sul nodo downstream del collegamento rotto: l’agent analizza le varie sessioni del nodo e, per quelle che utilizzavano il link rotto, costruisce un PathErrorMessage e lo invia al previous hop memorizzato nel psb (da notare che questo PathErrorMessage è stato creato da noi, poiché inesistente in RSVP/ns, e va bene solo nel caso particolare di rottura del link). La seconda funzione invece agisce sul nodo upstream del link rotto, e per ognuno degli rsb delle sessioni interessate alla rottura fa sì che il nodo mandi un messaggio di ResvError verso il destinatario, utilizzando le funzioni già implementate.

Nel caso in cui il nodo che riceve il messaggio di notifica sia il nodo di ingresso dell'LSP, esso deve inviare a tutti i nodi un PathTearMessage per la cancellazione degli state block memorizzati per quell’LSP e il rilascio delle eventuali risorse prenotate per quel path, e deve richiamare il modulo MPLS per il rilascio dello stesso LSP, con l’eliminazione delle opportune

entry nelle tabelle PFT, LIB ed ERB. Le stesse operazioni vengono effettuate in direzione inversa dall’egress node, con l’invio di un ResvTearMessage.

Andiamo a vedere, con l’aiuto delle immagini NAM di una simulazione, i vari passaggi appena descritti:

¾ siamo nella situazione iniziale in cui il link è funzionante e sono attivati gli LSP per i vari flussi (figura 4.12);

14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

¾ si rompe il link tra i nodi 7 e 5, utilizzato dalla sorgente 2: i pacchetti rossi iniziano ad essere scartati (figura 4.13);

14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

¾ il nodo 7 invia il messaggio di PathError (in giallo) in direzione downstream e il nodo 5 quello di ResvError (in viola) in direzione upstream (figura 4.14);

14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Figura 4.14: invio dei messaggi di PathError e di ResvError Figura 4.13: si rompe il link tra i nodi 7 e 5

¾ il nodo mittente (2) ha ricevuto il messaggio di PathError e invia un messaggio di PathTear (in viola); il destinatario (14) ha ricevuto il ResvError e invia un ResvTear (non visibile in figura 4.15); 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

¾ i messaggi di tear attraversano i vari nodi provocando il rilascio delle label dell’LSP e delle risorse allocate: può così partire il normale forwarding di livello 3 (figura 4.16) e i pacchetti rossi non vengono più scartati (i due pacchetti che vengono persi in figura sono il messaggio di PathTear giunto al nodo 7 e un precedente pacchetto della sorgente 2).

14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

¾ ora può essere effettuato il rerouting per il flusso proveniente dalla sorgente 2: viene creato un nuovo LSP, in modo da evitare il link rotto, e viene associato al flusso suddetto (figura 4.17). 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Figura 4.16: parte il forwarding di livello 3