L'analisi della simulazione del routing si può dividere in due sezioni:
1. Unicast Routing
Ci sono tre strategie di routing disponibili in NS:
Per specificare il tipo di protocollo che sarà utilizzato nella simulazione l'utente ha a disposizione la procedura di NS rtproto{}. E' possibile passarle diversi argomenti: Il primo è il protocollo, poi possono essere indicati i nodi su cui verrà implementato. Il default è "Static routing" su tutti i nodi.
$ns rtproto Session
$ns rtproto DV $n1 $n2
Nella creazione della toplogia della rete è possibile specificare i costi dei link come è spiegato nella sezione ad essi dedicata.
Vediamo ora in dettaglio i tre protocolli .
Si tratta di un routing centralizzato e statico.
Il calcolo delle tabelle d'instradamento viene effettuato solo all'inizio della simulazione da un'unità centrale. L'algoritmo utilizzato è il Dijkstra all-pairs SPF che si avvale di una matrice di adiacenze e dei costi dei link della rete.
Nell'esempio da noi provato si può vedere come alla rottura del link la sorgente continui a trasmettere ignorando l'accaduto. Ciò è anche dovuto al fatto che essa non dispone di uno strato di trasporto affidabile che richieda degli ack prima di inviare i pacchetti successivi. Se così fosse stato il flusso di dati si sarebbe arrestato dopo lo scadere del primo tout.
I pacchetti che la sorgente sul nodo n1 continua ad inviare, spariscono misteriosamente nel nodo n0, come se questo fosse in grado di memorizzarli su un buffer di dimensioni infinite, ma forzando il simulatore a visualizzare la coda in ingesso a n0 questa ipotesi non è stata confermata: Non si è formata nessuna coda. In realtà il livello di rete del nodo n0 non è a conoscenza della rottura del link e quindi decide ugualmente di inoltrare i pacchetti verso n4. Anche gli strati superiori di n0 si comportano allo stesso modo. Pertanto la coda si forma all'ingresso del link 0-4 e contiene sia pacchetti provenienti da n1 che da n0. Questa coda ha effettivamente dimensioni infinite; nessun pacchetto viene perso. Fissando a 10 il massimo numero dei pacchetti che la coda può contenere, non si ottiene alcun cambiamento. Da questo punto di vista la simulazione è deficitaria.
=>Questo protocollo di routing può essere utilizzato per simulare una rete periferica le cui tabelle d'instradamento siano compilate da un amministratore che deve intervenire ogni qual volta ci siano modificazioni della topologia.
Esempio routeStatic.tcl : visualizza o scarica questo file.
Questa strategia differisce dalla precedente solo per il fatto che è in grado di reagire alle modificazioni della topologia. Le tabelle d'instradamento vengono ricalcolate istantaneamente . Da questo punto di vista la simulazione è assai distante dalla realtà poiché non tiene conto dei tempi di convergenza di un algoritmo.
=>Questo protocollo può essere usato ad esempio per simulare il link-state-packet routing in una rete con pochi nodi, dove i tempi di convergenza possono essere effettivamente brevi.
Esempio routeSession.tcl : visualizza o scarica questo file.
DV Routing
Il protocollo Distance Vector ha le seguenti caratteristiche:
1)I nodi su cui è implementato spediscono DV di aggiornamento ogni advertInterval_ secondi. Questa variabile è definita nella classe Agent/rtProto/DV. Il suo valore di default è 2 secondi, ma può essere modificato dall'utente con la seguente riga di codice:
Agent/rtProto/DV set advertInterval_ nuovo_valore
Inoltre i DV vengono inviati anche in seguito a variazioni della topologia.
2)Le informazioni contenute nei distance vector seguono la politica "Split horizon with poisoned reverse mechanism". Quest'ultima è una variante di Split horizon; ogni nodo invia sulla linea prescelta per raggiungere una data destinazione un DV indicante costo infinito per il raggiungimento di quella stessa destinazione. Questa definizione può essere meglio compresa con un esempio:Il nodo A indica ad E che il costo per raggiungere F è infinito. In questo modo E non instraderà mai pacchetti per F verso A.
Split horizon velocizza enormemente i tempi di convergenza dell'algoritmo DV in caso di cattive notizie. C'è però una particolare topologia caso in cui il problema del count-to-infinity si presenta ugualmente ed è la seguente:
Quando il link tra C e D si rompe A e B ricevono un DV da C nel quale è indicato che D è irraggiungibile (costo infinito). A sa che B ha una linea di costo 2 verso D e quindi decide di raggiungere D passando per B con costo 3. Analogamente B decide di passare per A con costo 4 e purtroppo anche C fa lo stesso. Il processo va avanti fino a quando il costo della linea verso D non assume il valore previsto per infinito. Nel caso di NS questo valore dovrebbe essere 32.
NS è in grado di simulare bene questa situazione. L'esempio routeSH.tcl (visualizza o scarica il file) mostra come, alla rottura del link 0-3, i nodi 0,1 e 2 si inviino un gran numero di DV prima di convergere ad un equilibrio, mentre quando il link viene ripristinato sono sufficienti pochi scambi.
3)Ogni agente usa la variabile INFINITY (posta a 32) per determinare la validità di una linea.
4)La metrica utilizzata dall'algoritmo è la seguente:
Se la sorgente e il destinatario sono adiacenti i pacchetti vengono instradati sul link che li unisce qualunque sia il suo costo.
In tutti gli altri casi viene scelto il percorso con il minor costo e , a parità di costo, quello con il minor numero di hop.
Esempi DV
1)Esempio distvec1.tcl : visualizza o scarica questo file
Inizialmente non eravamo a conoscenza del fatto che il routing DV seguisse la politica SplitHorizon e quindi, basandoci su quanto appreso durante il corso, abbiamo provato a simulare un count-to-infinity ed alcuni effetti collaterali che esso comporta, usando la topologia dei cinque router in fila vista a lezione.
Ci aspettavamo che alla rottura del link 0-1 si scambiassero molti DV , poichè le cattive notizie avrebbero dovuto propagarsi lentamente, ma cio' non avviene. Inoltre pensavamo che durante il "presunto" count-to-infinity i nodi utilizzassero delle informazioni sbagliate, non aggiornate: ad esempio, dato che alla rottura del link viene scambiato un solo DV,il nodo n2 avrebbe potuto ritenere che la distanza tra n1 ed n0 fosse infinita, mentre tra n3 ed n0 fosse 3,instradando così i pacchetti per n0 verso n3. Ancor piu' sorprendente è il fatto che le sorgenti cbr4 e cbr2 trasmettano ugualmente anche quando il link è down. Ciò può dipendere dal fatto che si appoggiano su UDP che è un protocollo non connesso , ma è comunque irrealistico che il livello di rete inoltri pacchetti verso destinazioni irragiungibili. L'unico nodo che non si comporta in questo modo è n1, il quale si trova proprio sul link danneggiato.
2)Esempio distvec2.tcl : visualizza o scarica questo file
E'simile all'esempio precedente, dove però il livello di Trasporto è TCP. In questo caso in presenza del link 0-1 danneggiato non è possibile instaurare connessioni e , se ce ne sono di attive, la trasmissione si arresta per mancanza di ack.
3)Esempio routeDV.tcl : visualizza o scarica questo file
Mette in evidenza tutte le caratteristiche precedentemente elencate. Innanzitutto si può vedere come i nodi inizino a trasmettere i DV in istanti diversi e ripetano l'azione ogni 2 secondi (valore di default della variabile advertInterval_ ) in assenza di variazioni della topologia.
Le sorgenti, di tipo CBR, sono su n1 e su n0, e spediscono pacchetti a n4 . I percorsi utilizzati sono : n1-n0-n4 per i dati provenienti da n1, e n0-n4 per quelli provenienti da n0. Dopo 1.1 secondi di simulazione il link 0-4 si rompe. n0 si accorge immediatamente dell'accaduto, invia DV ai suoi vicini ed instrada tutti i pacchetti per n4 sul percorso 0-5-4. Quando n1 riceve i nuovi DV decide di instradare i suoi pacchetti sul percorso 1-2-3-4 che ha costo minore. Successivamente anche n0 sceglie il percorso 0-1-2-3-4.Una volta che il link 0-4 viene ripristinato, tutti i nodi si scambiano DV e rapidamente instradano i pacchetti sui percorsi utilizzati all'inizio della simulazione.
Routing asimmetrico
E' possibile che il collegamento più conveniente tra due nodi non sia lo stesso nei due versi. I protocolli di routing disponibili in NS sono in grado di instradare i due flussi su percorsi differenti. Nell'esempio da noi provato si può vedere come la strada migliore da n1 a n4 sia 1-0-4, mentre quella da n4 a n1 sia 4-3-2-1.
Esempio route_asym.tcl : visualizza o scarica questo file
Routing Multipath
In una topologia magliata possono essere presenti due percorsi differenti tra due nodi. Alcuni router in commercio sono in grado di distribuire su più link il traffico verso una stessa destinazione in modo da ottimizzare le prestazioni della rete. NS presenta un'opzione che farebbe pensare a questa politica di routing, ma in realtà un nodo può suddividere un flusso di dati su due o più link solo se questi sono identici per costo e numero di hop.
Per abilitare il routing multipath è necessario aggiungere le seguenti righe di testo nel codice tcl:
Node set multiPath_ 1
Con la precedente istruzione tutti i nodi presenti nella simulazione utilizzeranno il routing multipath ove possibile.
Set n1 [$ns Node]
$n1 set multiPath_ 1
In questo caso solo il nodo n1 è abilitato al routing multipath.
Nell'esempio da noi provato si vede come il nodo n1 instradi i pacchetti verso n4 alternativamente sui percorsi 1-0-4 e 1-3-4.
Nell'esempio da noi provato si vede come il nodo n1 instradi i pacchetti verso n4 alternativamente sui percorsi 1-0-4 e 1-3-4.
Esempio routeDV_mpath.tcl
: visualizza o scarica
questo file