left.gif (284 bytes) up.gif (289 bytes) right.gif (280 bytes)

Multicast Routing

Per fare in modo che ns possa simulare una rete in cui esistono dei gruppi multicast, prima di definire la topologia bisogna inserire nel proprio script il comando:

$ns multicast

oppure si può sostituire la solita prima riga (set ns [new Simulator]) con la seguente:

set ns [new Simulator -multicast on]

oppure ancora si può assegnare alla variabile EnableMcast_ il valore 1.

I nodi che verranno creati avranno degli indirizzi in cui il bit più significativo servirà a indicare se l'indirizzo è di tipo multicast o unicast: se il bit più significativo sarà un 1, l'indirizzo sarà di tipo multicast, se sarà uno 0 l'indirizzo sarà di tipo unicast. Questo implica che, se non si espande lo spazio degli indirizzi, una simulazione di tipo multicast può essere realizzata su una tipologia di al massimo 128 nodi.

I nodi che verranno creati conterranno inoltre un classificatore e un ripetitore per l'inoltro di pacchetti multicast.

Ad ogni pacchetto entrante in un nodo verrà assegnata un'etichetta diversa a seconda del link di provenienza.

Per creare un indirizzo multicast si usa la procedura allocaddr. Ad esempio creiamo un indirizzo multicast e chiamiamolo gruppo1:

set gruppo1 [Node allocaddr]

Perché un agent abbia come destinatario un indirizzo multicast si imposta opportunamente il suo parametro dst_. Ad esempio se vogliamo che udp1 abbia come destinatario gruppo1 scriviamo:

$udp1 set dst_ $gruppo1

Per iscrivere un agent situato su un nodo a un gruppo multicast si usa la procedura join-group. Ad esempio iscriviamo all'istante 0.5 della simulazione l'agent recv1 posto sul nodo n1 al gruppo gruppo1:

$ns at 0.5 "$n1 join-group $recv1 $gruppo1"

Analogamente si può usare la procedura leave-group per cancellare l'iscrizione di un agent a un gruppo multicast. Ad esempio ritiriamo l'iscrizione di recv1 da gruppo1 all'istante 10.5:

$ns at 10.5 "$n1 leave-group $recv1 $gruppo1"

In ns sono implementate tre diverse strategie di multicast routing:

  1. Centralized Multicast Routing "CtrMcast"
  2. Static Dense Mode "DM"
  3. Detailed Dense Mode "detailedDM".

Per specificare quale di queste strategie si desidera utilizzare, si usa il comando mrtproto. Ad esempio per usare su tutti i nodi dello scenario il protocollo di routing multicast di tipo detailedDM si deve scrivere:

$ns mrtproto detailedDM

Per usare invece questo protocollo solo sui nodi n1, n2, n3, si deve scrivere:

$ns mrtproto detailedDM $n1 $n2 $n3

 

  1. Centralized Multicast Routing "CtrMcast"

  2. Si sceglie un nodo come punto di riferimento ("RP") che avrà il compito di gestire le iscrizioni ai gruppi multicast e realizzare una computazione centralizzata dei diversi spanning tree . I pacchetti con i quali i vari agent dello scenario si iscrivono o si ritirano da un gruppo, e i pacchetti con i quali RP informa i router dei cambiamenti degli spanning tree relativi ai vari gruppi multicast, non vengono mostrati nella simulazione. Si possono anche definire RP diversi per i vari gruppi multicast; di default viene scelto un unico RP per tutti i gruppi. Le sorgenti spediscono pacchetti unicast a RP e questo provvede a inoltrare opportunamente i pacchetti.

    Se si desidera poter scegliere i nodi sui quali porre i punti di riferimento RP, il protocollo di routing CtrMcast va abilitato in un modo leggermente più complesso di quello visto sopra:

    set mproto CtrMcast

    set mrthandle [$ns mrtproto $mproto {}]

    Infatti si deve poter avere a disposizione la "maniglia" mrthandle per poter poi eseguire la procedura get_c_rp che permette di scegliere RP. Supponiamo ad esempio di voler porre RP di gruppo1 sul nodo n7:

    $mrthandle get_c_rp $n7 $gruppo1

    Un semplice esempio di multicast routing centralizzato è multic1.tcl, nel quale sono presenti tre nodi connessi a stella; un nodo è la sorgente e gli altri due sono destinatari che si iscrivono allo stesso gruppo multicast. E' possibile osservare che anche quando nessuno è iscritto al gruppo multicast la sorgente spedisce i suoi pacchetti unicast al nodo RP.

    Questo esempio può essere prelevato cliccando qui.

  3. Static Dense Mode "DM"

  4. Questo protocollo funziona solo su reti con link di tipo point-to-point, e non sulle LAN; inoltre non funziona in simulazioni in cui la topologia della rete cambia dinamicamente.

    Ogni nodo che riceve pacchetti di un gruppo multicast al quale non è iscritto, e che sa di non avere nodi ad esso collegati ai quali ripetere questi pacchetti, invia al nodo dal quale ha ricevuto i pacchetti multicast un pacchetto di "prune" grazie al quale non riceverà più da parte di quel nodo i pacchetti di quel gruppo multicast per "PruneTimeout" secondi. In questo modo in brevissimo tempo si realizza una potatura bottom-up dell'albero di inoltro dei pacchetti.

    Quando un nodo vuole iscriversi ad un gruppo multicast invia alla sorgente un pacchetto di "graft". Quindi l'albero potato viene aggiornato non tanto allo scadere dei "PruneTimeout" ai vari nodi, ma soprattutto al passaggio dei pacchetti di "graft".

    "Prune Timeout" di default vale 0.5 secondi. Si può impostare un valore diverso, ad esempio 0.3 secondi, come segue:

    DM set PruneTimeout 0.3

    Un semplice esempio di multicast routing di tipo DM è multic2.tcl, nel quale la topologia della rete è identica a quella di multic1.tcl; questo esempio può essere prelevato cliccando qui.

  5. Detailed Dense Mode "detailedDM".

Questo protocollo è molto simile al DM.

Oltre ai pacchetti di "prune" e di "graft" sono presenti i pacchetti "ackgraft" che sono dei semplici riscontri di pacchetti "graft".

Anche in questo protocollo il "PruneTimeout" di default vale 0.5 secondi, ma la sintassi per impostarne il valore è leggermente diversa:

Timer/Iface/Prune set timeout_ 0.3s

Un semplice esempio di multicast routing di tipo DM è multic3.tcl, nel quale la topologia della rete è identica a quella di multic1.tcl; questo esempio può essere prelevato cliccando qui.

Il protocollo DetailedDM funziona anche con le LAN e in reti la cui topologia cambia dinamicamente nel corso della simulazione.
 
 

E' possibile ottenere un file trace nel quale vengono elencati i pacchetti relativi all'attivita' di un gruppo multicast.

Con il metodo trace-topo dovrebbe essere possibile monitorare tutti i link della rete; in realta' per ora non e' funzionante.

Con il metodo trace-tree vengono monitorati solo i link dell'albero potato, e ogni period_ secondi viene stampata sullo standard output una linea nella quale si puo' leggere quanti pacchetti di tipo graft, prune, dati, hanno viaggiato nell'albero potato durante gli ultimi period_ secondi.

Il valore di default di period_ e' 0.03 secondi.

Per utilizzare il metodo trace-tree, ad esempio per monitorare con period_ 0.02 i pacchetti relativi al gruppo multicast "group" la cui sorgente e' "src", si devono inserire nel proprio script le seguenti linee:

set mcastmonitor [$ns McastMonitor]

$mcastmonitor set period_ 0.02

$mcastmonitor trace-tree $src $group
 
 

L'esempio multic4.tcl, che può essere prelevato cliccando qui, presenta una topologia di rete magliata, con 11 nodi e 3 gruppi multicast. Il protocollo di multicast routing usato e' DM.Ecco come si prersenta nell'interfaccia del NAM:

multic4.gif (16430 bytes)

left.gif (284 bytes) up.gif (289 bytes) right.gif (280 bytes)