![[successivo]](../icons/right.gif){kind=icon}
![[precedente]](../icons/left.gif){kind=icon}
![[indice]](../icons/contents.gif){kind=icon}
Il routing multicast e' l'invio di un pacchetto IP ad un indirizzo di gruppo in modo da farlo ricevere a tutti i membri del gruppo, che possono essere distribuiti in tutta l'Internet.
Lo stesso risultato lo si puo' ottenere con una serie di trasferimenti punto-punto, in teoria, ma il multicast ha i seguenti vantaggi:
Sia OSPF che RIP-2 che BOOTP sono protocolli che usano funzionalita' broadcast o multicast per scoprire la locazione dei propri server. Anche la posizione dei name server DNS puo' essere scoperta con un multicasting a scopo crescente.
Il pericolo del multicasting e' la non limitazione dello scopo o estensione massima a cui far propagare i pacchetti dalla stazione trasmittente. Si possono facilmente generare dei loop o delle valanghe di pacchetti.
Il metodo piu' comune di limitare lo scopo di trasmissione dei pacchetti e' di usare il campo TTL (Tempo di Vita) dei pacchetti IP.
In una trasmissione punto-punto di un file in una rete complessa i pacchetti passano per piu' segmenti di rete. In N trasmissioni e' molto probabile che vi siano dei segmenti di rete in comune, che quindi vengono utilizzati piu' volte.
Una trasmissione multicasting impiega invece ciascun segmento di rete una sola volta, risparmiando traffico.
Vi e' un sempre maggiore requisito moderno di teleconferenze tra molti nodi sparsi per la rete. Queste conferenze sono basate su mezzi multimediali che hanno vasti requisiti di banda e di operazioni in tempo-reale. La trasmissione piu' efficiente consiste in modo naturale nell'invio di pacchetti in modo multicast.
E' da notare che l'alternativa di aprire piu' circuiti virtuali punto-punto e' completamente fattibile e sperimentalmente praticata, ma richiede piu' traffico e banda per la stessa quantita' di dati scambiati e quindi necessita' l'impiego di mezzi trasmissivi piu' veloci.
Una caratteristica di gestione delle conferenze e' che il gruppo di partecipanti e' in numero variabile, e questa proprieta' e' molto piu' agevole da gestire in modalita' multicast.
L'algoritmo di flooding, di cui esistono varie versioni, consiste essenzialmente in:
E' evidente l'importanza del controllo che sia la prima ricezione o si moltiplicherebbe all'infinito il traffico generato.
OSPF e il servizio News implementano protocolli di flooding a livello applicativo. Sarebbe pensabile di implementare facilmente l'algoritmo direttamente a livello IP, ma vi sarebbero i requisiti:
L'algoritmo di flooding si usa quando il requisito principale e' la robustezza, ma l'algoritmo e' piuttosto pesante in risorse di memoria.
La tecnica di scansione alberi consiste nel mappare una topologia complessa di rete interconnessa in un albero, marcando certi link come non in uso, in cui ogni nodo e' attraversato una sola volta.
Questo puo determinare una leggera inefficienza nel raggiungimento di singoli nodi, ma garantisce che ogni nodo riceve un pacchetto una e una sola volta.
La dimensione dell'albero generato deve essere un massimo ragionevole e quindi questo metodo e' piu' usato per insiemi di stazioni limitati, come Sistemi Autonimi o aree. Per poter costruire l'albero la stazione trasmittente deve possedere una mappa della rete, cioe' usare un protocollo di routing a Link State.
L'algoritmo in uso nel MBONE oggi e' chiamato Reverse Path Forwarding (RPF) ed il suo proposito e' di prientare la rete costruendo un albero di scansione implicito.
La forma piu' semplice dell'algoritmo e':
RPF non richiede piu' risorse di una normale tabella di routing unicast, ma la tabella di routing non dovrebbe essere usata: il percorso piu' breve da calcolare e' dalla stazione di provenienza e non verso di essa, in caso di asimmetria delle metriche nelle due direzioni.
RPF risulta in un albero di scansione implicito diverso per ogni sorgente. Tali alberi hanno le proprieta':
Un problema di RPF e' che nella versione base non viene tenuto conto dell'appartenenza delle stazioni al gruppo di multicasting: viene compiuto un semplice flooding a tutta la rete.
La rete MBONE fornisce una variante detta "pruning" (potatura) all'algoritmo RPF. L'idea e' di memorizzare l'appartenenza a gruppi delle stazioni e di inoltrare un pacchetto in un ramo dell'albero solo se il ramo contiene almeno un membro del gruppo.
Gli alberi costruiti sono di dimensione ridotta, ma gli aggiornamenti devono essere molto dinamici. Il metodo consiste in un flooding iniziale a tutta la rete, seguito da messaggi di 'prune' che si propagano all'indietro dai nodi e rami che non contengono membri.
I router devono mantenere informazioni di stato che variano molto rapidamente con l'appartenenza ai gruppi e la topologia di rete. Gli stati hanno quindi un tempo di vita limitato.
Una variante all'algoritmo RPF e' un Albero di Steiner. RPF cerca di ottenere il recapito piu' veloce dei pacchetti ma senza tentare di minimizzare l'uso delle risorse della rete.
Un albero di Steiner minimizza il numero di link necessari a connettere i membri di un gruppo entro un grafo. E' una variante del famoso algoritmo del Commesso Viaggiatore.
Il problema e' che un albero di Steiner e' altamente instabile e la sua forma varia con l'appartenenza delle stazioni ai gruppi.
La strategia Core-Based (CBT) inizia con la scelta di un 'core', un punto della rete che funge da centro di un gruppo di multicast. I potenziali riceventi devono prima inviare un messaggi di adesione al gruppo al nodo core. I messaggi di adesione vengono processati da tutti i router intermedi che marcano l'interfaccia da cui i messaggi sono arrivati come appartenenti all'albero di scansione del gruppo.
I router devono quindi mantenere un'informazione di stato per ciascun gruppo. Se il router che riceve un comando di adesione e' gia' membro del gruppo, deve solo incrementare un contatore di appartenenza associato all'interfaccia. Se e' il primo messaggio di appartenenza al gruppo, deve inoltre propagare il messaggio di appartenenza al router successivo in direzione del core.
Vantaggi del metodo CBT sono:
Svantaggi di CBT sono:
La rete MBONE e' una rete sperimentale di overlay per testare i protocolli di multicast. E' basata sul protocollo sperimentale Internet Group Membership Protocil (IGMP) definito nel 1988 e su una tecnologia di rete chiamata DARTNET finanziata da ARPA. I primi esperimenti di multicast di conferenza IETF su MBONE datano dal 1992.
L'unica differenza tra un pacchetto IP punto-punto ed uno multicast e' la presenza nell'indirizzo di destinazione di un indirizzo di gruppo, che appartiene alla Classe D. Nelle reti broadcast e' importante che venga inviata una sola copia del pacchetto multicast.
Vi sono due tipi di reti broadcast: quelle che supportano solo il broadcast globale, e quelle che possono gestire indirizzi di gruppo. Le seconde derivano l'indirizzo di gruppo a livello Data Link direttamente dall'indirizzo Classe D di multicast. Una porzione degli indirizzi IEEE 802 di reti locali sono stati riservati a questo proposito. L'indirizzo Data Link viene ricavato ponendo i 23 bit piu' bassi dell'indirizzo IP nei corrispondenti 23 bit piu' bassi dell'indirizzo multicast Ethernet 01:00:5E:00:00:00 (esadecimale).
IGMP e' definito dal documento RFC1112. Consiste di due tipi di messaggi: Richiesta di Appartenenza a gruppo e Rapporto di Appartenenza a gruppo, entrambi con lo stesso formato.
Il campo Versione e' correntemente 1. Il Tipo vale 1 per le richieste e 2 per i rapporti. Vi sono altri tipi usati in estensioni sperimentali. Il campo Codice normalmente e' 0. Il Checksum e' normale.
I router multicast inviano richieste periodiche all'indirizzo multicast 224.0.0.1 di tutti i sistemi, usando un campo TTL di 1 per limitare lo scopo alla rete locale. L'Indirizzo di Gruppo delle richieste e' settato a 0 e viene usato solo nei rapporti.
I nodi che ricevono le richieste rispondono con un rapporto per ciascun gruppo di appartenenza. Per impedire picchi di traffico ogni nodo risponde ad una richiesta dopo un intervallo di tempo casuale; se nell'intervallo di attesa viene sentito l'invio di un rapporto al router per lo stesso gruppo da parte di un altro nodo, il nodo corrente non invia il suo rapporto.
La rete MBONE usa dei 'tunnel' per collegare 'isole multicast', aree dell'Internet ove la funzionalita' multicast e' supportata.
Un'isola consiste minimamente di una rete locale in cui tutti i nodi hanno ricevuto un upgrade software per:
Le stazioni aggiornate possono scambiarsi pacchetti multicast in formato nativo.
Per estendere la rete multicast occorre un router con capacita' multicast collegato ad un altro router di un'altra isola multicast. Se i due router sono direttamente collegati si ha semplicemente l'unione di due isole in un arcipelago.
Se il collegamento tra i due router multicast transita da router intermedi non multicast, vi sono due possibilita' di collegamento:
La seconda possibilita' implementa un tunnel tra le due isole.
I router partecipanti ad MBONE devono essere capaci di multicasting. MBONE definisce un protocollo di routing multicast detto Distance Vector Multicast Routing Protocol (DVMRP), il cui software per UNIX consiste nel programma mrouted.
DVMRP e' un semplice protocollo Distance Vector, simile a RIP-2, che usa l'algoritmo Reverse Path Forwarding. Gli aggiornamenti sono inviati sia su link diretti con capacita' multicast, sia tramite tunnel a router distanti.
I tunnel devono essere configurati manualmente. Un tunnel e' definito da tre parametri: Router di Destinazione, Costo o metrica del link e un parametro di Soglia. Il pacchetto viene inviato attraverso un tunnel solo se il suo campo TTL e' inferiore al valore di Soglia.
La soglia serve quindi come contenimento dello scopo dei gruppi multicast. Sono comunemente usate tre soglie: 32 per scopo limitato all'organizzazione, 64 per regione geografica e 128 per routing intercontinentale.
Vista l'estensione rapida dell'Internet e del MBONE stesso, la nuova versione di DVMRP include una estensione di 'pruning' all'algoritmo RPF.
MBONE e' stato un esperimento da cui sono state tratte lezioni:
L'esperimento ha riscontrato problemi che devono essere corretti prima di finalizzare il servizio: imprecisione di DVRMP, incertezza sul posizionamento dei tunnel e sui corretti parametri di costo e di soglia, mancanza di software per router dedicati che velocizzino il traffico.
E' necessario attendere la decisione formale di IETF per protocolli di routing multicast definitivi.
I gruppi di lavoro IETF hanno allo studio due direzioni di sviluppo:
MOSF indirizza il multicasting all'interno di Sistemi Autonomi, e tentano di ottimizzare l'efficienza di calcolo dei percorsi.
PIM tenta di definire il routing multicast a livello Internet globale in modalita' indipendente da singoli protocolli di routing unicast. PIM deve affrontare problemi di esplosione del numero di record di stato che un gran numero di gruppi causerebbe, il supporto alla selezione di fornitori e a politiche di uso accettabile della rete.
PIM viene in due varianti, chiamate 'densa' e 'sparsa' corrispondenti approssimativamente all'uso di RPF col 'pruning' e all'uso di CBT.