LSP release e failure handling

Nel caso si debba simulare il rilascio di un LSP o il guasto di un link, si continuano ad usare i comandi precedentemente visti per il modulo RSVP- TE\ns, tuttavia, non appena l’agent RSVP-TE processa il messaggio da Path Tear nel primo caso e i messaggi di Path Tear e Resv Tear nel secondo caso, esso chiama l’agent OSPF-TE per effettuare la procedura di flooding. Tale procedura permette di rendere note agli LSR della rete le seguenti informazioni:

• nel caso di rilascio di un LSP, si informano tutti i nodi che la banda allocata sui link dell’LSP è stata liberata ed è quindi necessario aggiornare i TED

• nel caso di guasto di un link viene effettuata la procedura di rilascio risorse, e successivamente vengono comunicate sia la variazione di banda disponibile, sia il cambiamento della topologia della rete, rendendo necessario aggiornare i TED e le tabelle di routing

4.2.3

LSP Recovery

Tramite il seguente comando si abilita la tecnica di rerouting in caso di guasto:

<Ingress-LSR> reroutereroutereroutereroute----ospfteospfteospfteospfte <Source> <Egress-LSR> <Destination> <OldSID> <SessionID> <FlowID> <TunnelID> <Rate> <Bucket> <TTL>

La procedura di creazione dell’LSP alternativo viene lanciata nel momento in cui l’ingress LSR processa il messaggio di Path Tear ed avviene in modo analogo a quanto descritto per la funzione createcreatecreatecreate----crlspcrlspcrlspcrlsp----ospfospfospfospf.

4.3

Modulo DBCTE\ns

Questo modulo permette di instaurare gli LSP utilizzando come algoritmo di calcolo dei percorsi il DBCTE (Delay and Bandwidth Constrained with TE objectives). DBCTE è in grado di calcolare un percorso che rispetti vincoli sia sulla banda che sul ritardo end-to-end. Sotto opportune condizioni DBCTE è in grado di distribuire in modo bilanciato il traffico della rete,

4.3.1

LSP establishment

<Ingress-LSR> createcreatecreatecreate----crlspcrlspcrlspcrlsp----DBCTEDBCTEDBCTEDBCTE <Source> <Egress-LSR> <FlowID>

<TunnelID> <Bandwidth> <MaxDelay> <Buffer> <TTL>

L’agent RSVP-TE, che riceve la richiesta per la creazione di un LSP, la invia all’agent link state with delay (LSD) dello stesso nodo a cui è demandato il compito di calcolare un percorso che rispetti le richieste specificate in termini di banda e ritardo e, possibilmente, trovi anche il percorso a costo minimo secondo la metrica TE introdotta.

L’algoritmo implementato nel simulatore, dopo aver eliminato dalla topologia tutti i link con banda residua minore di <Bandwidth>, cercherà, attraverso l’algoritmo di Dijkstra, il percorso con costo minore secondo la metrica TE introdotta. Dopodiché si verifica se il bound sul ritardo (<MaxDelay>) del path calcolato verifica il vincolo: in caso affermativo è possibile procedere all’instaurazione dell’LSP, viceversa si calcola il percorso a ritardo complessivo minimo (algoritmo Wang Crowcroft): se anche in questo caso la ricerca di un path fattibile ha esito negativo si conclude che, con le risorse a disposizione, non esiste un percorso all’interno della rete che riesca a soddisfare contemporaneamente i vincoli richiesti.

Creato l’LSP, LSD viene chiamato ancora una volta per eseguire l’operazione di flooding ed informare tutti i nodi di rete della modifica di banda disponibile sui link attraversati dal nuovo LSP.

4.3.2

LSP Recovery

La tecnica di rerouting end-to-end prevista dal nuovo modulo può essere abilitata attraverso il comando:

<Ingress-LSR> reroutereroutereroutereroute----LSDLSDLSD <Source> <Egress-LSR> <Destination> <FlowID> LSD <TunnelID> <Rate> <Bucket> <TTL>

In questo modo, l’ingress LSR avvia la procedura di instaurazione di un LSP alternativo da utilizzare in caso di guasto di un link attraversato dall’LSP principale. La procedura di creazione di un LSP alternativo viene lanciata quando l’ingress processa un messaggio di Path Tear.

E’ utile sottolineare inoltre, che, nonostante nel comando mostrato non venga specificato nessun vincolo di ritardo, il parametro <MaxDelay> viene recuperato dalla richiesta originaria di instaurazione dell’LSP abbattuto.

4.4

Modulo EBMP e MPBF\ns

Tramite questo modulo gli LSP possono seguire percorsi calcolati con gli algoritmi EBMP (Equal Bandwidth Multi Path) e MPBF (Maximum Path Bandwidth First). Entrambi gli algoritmi sono in grado di distribuire il traffico degli LSP su più percorsi, nel caso in cui non esista un singolo percorso che rispetti tutti i vincoli imposti

4.4.1

LSP establishment

La richiesta di creazione di un LSP viene effettuata mediante uno dei seguenti comandi:

<Ingress-LSR> createcreate----crlspcreatecreatecrlspcrlspcrlsp----mpathmpathmpathmpath <Source> <Egress-LSR> <FlowID>

<TunnelID1> <TunnelID2> <Bandwidth> <MaxDelay> <Buffer> <TTL>

<Ingress-LSR> createcreate----crlspcreatecreatecrlspcrlspcrlsp----MPBFMPBFMPBFMPBF <Source> <Egress-LSR> <FlowID>

<TunnelID1> <TunnelID2> <Bandwidth> <MaxDelay> <Buffer> <TTL>

In entrambi i comandi: l’agent RSVP-TE, che riceve la richiesta per la creazione di un LSP, la invia all’agent link state with delay (LSD) dello stesso nodo, a cui è demandato il compito di calcolare un percorso che rispetti le richieste specificate in termini di banda e ritardo.

Nel caso del comando create-crlsp-mpath: l’algoritmo di path computation, dopo aver eliminato dalla topologia tutti i link con banda residua minore di

<Bandwidth>, cercherà, attraverso l’algoritmo di Dijkstra, il percorso a

ritardo di propagazione minimo. Se viene trovato tale path, si verifica se il bound sul ritardo d’attraversamento verifica il vincolo: in caso affermativo è possibile procedere all’instaurazione dell’LSP. Se viceversa tale path non è stato trovato o il ritardo complessivo non rispetta il vincolo, si procede alla ricerca di due LSPs con lo stesso vincolo sul ritardo e con vincoli di banda scanditi da un ciclo che ricerca paths con vincoli pari rispettivamente a

termina non appena vengono trovati due paths fattibili o si raggiunge il numero massimo di iterazioni ammissibile.

Il comando createcreatecreate----crlspcreatecrlspcrlspcrlsp----MPBFMPBFMPBFMPBF ricerca, attraverso l’algoritmo di Djikstra, il

percorso a ritardo di propagazione minimo con banda residua non nulla. Qualora il path trovato non rispetti il vincolo di ritardo, non esiste alcun path in grado di soddisfare i vincoli, pertanto l’algoritmo termina; viceversa si alloca a tale path una banda pari a B = min { <Bandwidth>, B1 }, dove B1 è

la banda residua del path. Se B = <Bandwidth> l’algoritmo termina; in caso contrario si ricerca un altro path con vincolo di ritardo pari a <MaxDelay> e vincolo di banda pari a <Bandwidth> - B1.