Se si vuole fare una query non per uno specifico gruppo multicast il campo Group Address viene lasciato a 0.

LEZIONE 22 Le comunicazioni multicast vengono definite per risolvere il problema delle comunicazioni di gruppo. Una possibilità per realizzare questo è dire: se una stazione deve fare una trasmissione di gruppo manda tante copie dello stesso pacchetto a tutti i destinatari. Questo ovviamente è ingestibile dal punto di vista del traffico. Una prima soluzione più efficiente è quella di usare un multicast server. Questo tipo di server è installato da qualche parte nella rete: quando una stazione vuole trasmettere a tanti, manda al server e il server manderà a tutti. In questo modo il traffico si riduce della metà (perché comunque il multicast server deve mandare a tutti). Ho lo svantaggio che il multicast server è una funzionalità da aggiungere ed è un single point of failure. Inoltre il server diventa facilmente un collo di bottiglia: siccome la comunicazione multicast si usa per traffico abbastanza pesante (trasmissione video) c è un rischio. In questo caso ci sono più copie del pacchetto, ma le copie vengono create solo dove servono e il più vicino possibile. Nelle reti IP le trasmissioni multicast sono state introdotte più di recente e si è standardizzata in modo che qualunque nodo di rete riesca a farlo (si è introdotto il concetto di tunnel).

Per supportare il multicast nelle reti IP ci serve supporto a livello host (gli ES devono avere un estensione rispetto a IP tradizionale che gli permetta di supportare questo servizio) e il concetto di host group (= insieme di stazioni che ricevono lo stesso pacchetto). La cosa interessante è che l appartenenza a un host group non è determinata dai mittenti, ma sono i destinatari che possono aderire a un host group. Gli host group si identificano tramite indirizzi (i. multicast) che sono indirizzi di classe D (1110 nel primo byte). Non c è nessuna stazione che ha indirizzi del genere, ovviamente. Se vedo un indirizzo 228.3.8.2 ho un pacchetto che parte da un mittente e va a un insieme di destinatari, parti di quel particolare gruppo multicast. Quello che vedremo è come fanno gli host a diventare parte del gruppo multicast. Nella prossima lezione invece vediamo come fanno i router a mandare i pacchetti. Esistono alcuni indirizzi particolari. 224.0.0.0 non viene usato, 224.0.0.1 è il gruppo permanente che include qualsiasi host che capisce multicast (non su Internet ma su una certa rete locale). Lo stesso vale per tutti i router: la visibilità è sempre all interno della rete locale. Non esiste un gruppo globale sulla rete a cui si iscrivono tutti gli host. Teniamo presente che il multicast non era supportato nelle installazioni tipiche di IP,

Come funziona questo servizio che sotto certi aspetti sembra anche magico? Il servizio è basato su due parti: consegna all interno delle reti locali consegna a livello globale (multicast router: router che supportano la consegna di pacchetti multicast) Come si fa a sapere se su una rete locale c è qualcuno interessato alla consegna? C è IGMP che serve agli host per dire agli Mrouter io sono interessato a ricevere. La diffusione delle informazioni è invece fatta coi protocolli di routing. Primo passo: come funziona il multicast sulle reti locali? E basato sul multicast di L2: in modo simile a quanto abbiamo detto, gli indirizzi multicast MAC non sono associati a nessuna scheda reale. L idea è che un host che abbia il supporto per il multicast ha una scheda di rete e nel momento in cui sull host attiviamo un applicazione che vuole ricevere pacchetti destinati a un certo gruppo multicast succede che il software di rete è in grado di dire alla scheda di rete, per mezzo di un opportuna primitiva, ricevi i pacchetti per questo indirizzo MAC multicast. Qual è l indirizzo MAC multicast corrispondente a un IP multicast? Invece che usare un protocollo tipo ARP per fare questa corrispondenza, si fa un mapping algoritmico. Dato un indirizzo IP multicast si prendono i 23 bit meno significativi e si trasferiscono in un indirizzo MAC. Ad esempio se un host vuole ricevere pacchetti destinati all host group 224.0.0.5 dice alla sua scheda di rete di ricevere pacchetti MAC inviati all indirizzo MAC 01:00:5E:00:01:05. Un tizio che vuole mandare un pacchetto a un host group lo mette allora in una trama Ethernet che va a un certo indirizzo MAC propagato su tutta la rete Ethernet. Se la scheda non è stata istruita ignorerà il pacchetto. Dall esempio dovrebbe essere chiaro che ci possono essere diversi indirizzi IP multicast che finiscono mappati sullo stesso MAC muticast. 225.0.0.5 verrebbe mappato sullo stesso MAC: è un problema? No, a L2 passa ma a L3 no: c è un po di inefficienza, però vabbè. Al di fuori della rete locale cosa succede? Il router che supporta multicast riceve i pacchetti multicast e lo inoltra ad altri router multicast. A quali? Ne parliamo poi. Sulla rete locale è importante anche poter dire al router quali sono i gruppi multicast a cui una stazione è interessata. Solo i- struendo le schede di rete non si riesce.

Ecco che entra dunque in gioco IGMP: quello che fa è permettere alle stazioni di dire se alle stazioni interessa far parte di un certo gruppo multicast oppure no. I messaggi IGMP vengono imbustati in pacchetti IP e vengono mandati sempre e solo su una LAN (mai inoltrati dai router). Il campo protocol di IP è 2. Com è fatto un messaggio IGMP? Ogni riga è grande 32 bit. Abbiamo un campo Type (1B): il Query serve ai router per chiedere se c è qualcuno interessato a un qualche gruppo, il Membership Report serve agli host per dire io sono interessato a un certo gruppo, il Leave Group serve agli host per lasciare i gruppi (non obbligatori, ci sono dei meccanismi a timeout). Max Resp Time: tempo massimo entro cui un host interessato deve rispondere. La risposta infatti non sempre è inviata subito. Checksum. Indirizzo di gruppo a cui un messaggio si riferisce. Se si vuole fare una query non per uno specifico gruppo multicast il campo Group Address viene lasciato a 0. Se il Max Resp Time è basso si obbligano gli host a rispondere al volo e i router hanno informazioni in poco tempo, ma si genera più traffico. Se il valore è lungo i report sono più sparsi nel tempo e ci vuole di più al router per capire quali sono i gruppi attivi, però c è meno burst. Un router periodicamente manda una richiesta chiedendo chi è interessato a un certo gruppo (richiesta mandata all indirizzo IP di tutte le stazioni, mappato su un opportuno MAC). A quel punto le varie stazioni rispondono con un Host Membership Report che viene mandato usando l indirizzo IP-MAC del gruppo a cui fa riferimento. Il router riceverà sempre i Report. Le stazioni che non sono interessati al gruppo F non ricevono la risposta all Host Membership Report del gruppo F. Le stazioni del gruppo F invece ricevono il report: non è obbligatorio, ma è possibile che le stazioni supportino una modalità di ottimizzazione del traffico per la quale quando ricevono un Host Membership Query non rispondono immediatamente ma fanno partire un timer casuale e mandano la risposta entro Max Resp Time.

Si cerca di minimizzare la quantità di risposte mandate. Varie versioni di IGMP. La v2 è retrocompatibile (così come la v3) e offre la possibilità di eleggere un designated router: si immagini una rete locale con due router, entrambi supportanti multicast. Tutti e due ricevono un pacchetto multicast per un certo gruppo X: è inutile che tutti e due facciano l inoltro, basta che lo faccia uno solo. Con IGMP v1 era il protocollo di routing a far capire ai due router che solo uno doveva fare quell inoltro. Il designated router è quello con l IP più basso. Inoltre ci sono le Group-Specific Query: nella v1 il router non poteva chiedere c è qualche iscritto al gruppo X?. Questo è molto importante quando qualcuno abbandona X, perché altrimenti dovrebbe chiedere se c è qualche iscritto ai gruppi? Quando un host lascia un gruppo, manda un messaggio all indirizzo di tutti i router informando che sta lasciando il gruppo. Se nessuno risponde alla successiva Group Specific Query evita di mandare pacchetti: questo facilità la distribuzione dei pacchetti, evitando di mandarli a parti dell albero non più interessato. Nella v1 si faceva, ma meno ottimizzato (vedi slide precedente). Siccome le query generali non vengono mandate spessissimo si rischiava di lasciare la rete in uno stato incoerente. Il multicast oggi non è usatissimo, ma se un giorno fosse usato in modo massivo è importante avere queste ottimizzazioni. IGMP v3 introduce nuove funzionalità: ad esempio la possibilità di mandare report Inclusion/Exclusion (permettono a un host, interessato a un gruppo X, di dire che se i pacchetti arrivano da una certa stazione S mi interessano/non mi interessano). Questo può anche essere utile per evitare traffico indesiderato.

L inoltro del traffico multicast avviene solo tra i router abilitati al multicast. Se ce ne sono di alcuni non abilitati i router possono comunque scambiarsi traffico multicast, tunnellizzando. I router grigi non capiscono il multicast, ma non importa: se tra due router che parlano multicast c è un router normale, quello a sx manderà un normalissimo pacchetto IP destinato al router di dx e per quello in mezzo va tutto bene. Questo è stato importantissimo agli albori del multicast, quando in pochi lo parlavano. Oggi tutti i router lo parlano, ma normalmente viene disabilitato perché agli operatori non piace molto: il tunnel dunque mi viene un sacco in aiuto I tunnel vanno configurati. Normalmente ai tunnel si associa una metrica. Interessante anche la soglia: noi sappiamo del TTL, nel multicast è possibile fare una cosa in più e dire che quando un router riceve un pacchetto multicast decrementa il TTL e guarda la soglia. Se questa soglia è più alta del TTL il pacchetto non viene inoltrato. La soglia serve dunque per limitare la diffusione del traffico multicast. Questo è molto importante perché quando stazioni multicast decidono di usare un certo indirizzo (228.1.2.3) loro si iscrivono al gruppo e il pacchetto si propaga: se queste stazioni sono collegate su Internet (cosa che comunque oggi non esiste) il pacchetto si può propagare. Questo problema lo posso risolvere usando la soglia: se uso una soglia bassa il router non inoltra all esterno. E l applicazione che permette all utente di specificare il TTL.

C è anche un altro modo: usare indirizzi particolari. Per convenzione gli indirizzi che iniziano per 224.0.0 non vengono mai inoltrati dai router, ma restano solo sulla rete locale che li ha generati. TTL è uguale a 1 per convenzione. Gli indirizzi che invece iniziano per 239 sono Administratively Scoped Multicast: non vengono mai inoltrati al di fuori di un Autonomous System. L idea degli indirizzi GLOP (233) è che nei 2 byte in mezzo si va a mettere il numero dell Autonomous System in cui il gruppo multicast è stato creato. Questo permette di creare gruppi multicast unici globalmente. I 232 invece sono Source-Specific multicast e si usano su una variante del protocollo PIM (di cui si parlerà). Il modo in cui i pacchetti vengono portati in giro per la rete dipende dai protocolli di routing multicast. Il primo creato è il DVMRP: il più semplice, basato su DV, cerca di fare in modo che i router creino alberi di distribuzione specifici della sorgente e del gruppo multicast (se A genera traffico per un certo gruppo multicast si fa seguire un percorso, che sarà diverso rispetto a quello seguito da B: alberi di inoltro ottimizzati, un po più costoso). MOSPF invece è una variante dell OSPF (LS) per supportare il multicast. Siccome in OSPF i router costruiscono una mappa della rete, tutto ciò che ci serve è poter mettere delle bandierine sulla mappa per identificare i membri di ogni gruppo. Un altro protocollo molto diffuso si chiama PIM. Nasce come proprietario Cisco e poi reso pubblico. Ha due varianti: Dense Mode (quando i membri di un gruppo sono molto vicini, non genera traffico di routing e carica poco la rete ma è poco efficiente in caso di destinazioni sparse) e Sparse Mode (si cerca di ottimizzare la situazione quando i membri sono distanti fra loro utilizzando un albero condiviso customizzato per le sorgenti più attive). Infine il BGMP, che è un estensione del BGP e viene usato per fare multicast tra Autonomous System.

Quando il multicast è stato creato è stata fatta una rete MBone, rete che supporta il multicast, che man mano è diventata sempre più densa. Siccome i router commerciali hanno perlopiù multicast disabilitato, se si vogliono mandare pacchetti IP multicast bisogna in qualche modo collegarsi alla MBone creando dei tunnel. E nata agli inizi del 1992 quando si è cominciato a lavorare al multicast. L IETF lo usava ogni volta che aveva una riunione. MBone non è andata da nessuna parte. E una rete virtuale e riesce a funzionare anche se tutti i router non supportano il multicast. Siccome poi le applicazioni che usano multicast generano tanto traffico, alcuni assorbono tanto traffico Ha fatto comunque molto scalpore perché era una cosa eccezionale. MBone infatti non la si è mai usata per fare niente, ma in molti l hanno usata perché è degna di nota: mando un pacchetto in giro per il mondo, fa tutto un bel giro e arriva solo a chi è interessato a riceverlo. Lo scalpore oggi è finito e MBone non ha molta diffusione. Che protocolli usiamo col multicast? Normalmente UDP, perché TCP funziona da un punto a un altro e non da un punto a tanti. Dentro i messaggi UDP si usa RTP per le applicazioni multimediali (si può benissimo usare il multicast senza RTP, ma non senza UDP).

Oggi il multicast è supportato da tutti, ma sui router non è abilitato (e se è abilitato, mai su scala globale). Fastweb fa trasmissione della TV usando multicast. Fare multicast in modo affidabile non è facile: bisogna usare degli ACK, e la probabilità che su un alto numero di clienti qualche ACK si perda non è trascurabile. Perché il multicast ha poco successo? Perché non piace agli ISP, in quanto la distribuzione del traffico avviene con un paradigma diverso rispetto a quella attuale (in cui è il mittente che decide dove va il pacchetto). Nel multicast invece non si sa chi sia il destinatario. LEZIONE 23 In questa lezione parliamo del processo fatto dai router per capire dove poi dovranno inoltrare i pacchetti multicast Vediamo come fare una catalogazione. Volendo fare una prima distinzione, questi algoritmi usano degli alberi di distribuzione (in quanto vanno da una sorgente a diverse destinazioni, partendo da una radice e andando a tutte le foglie). L albero che si crea può essere specifico della sorgente oppure può essere condiviso. Naturalmente il source specific tree è migliore: nel caso del multicast riesco sia a far fare meno strada ai miei pacchetti, sia risparmiare banda sulla rete. Ovviamente è più complicato da calcolare perché devo calcolare un albero per ogni sorgente del gruppo multicast. Lo shared tree è meno ottimale, ma si carica di meno il router nella fase preparatoria. PIM Sparse li usa tutti e due, a seconda delle necessità.

Abbiamo un certo numero di algoritmi di instradamento proposti da Stephen Deering nel 1988. Il multicast IP è stato standardizzato negli anni 90, ma un po di lavoro è stato fatto in precedenza. Selective flooding: io cerco di mandare i pacchetti dappertutto (non so a priori dove sono le destinazioni), o meglio, quasi dappertutto in modo da non bloccare la rete Come faccio a fare la parte Selective del flooding? Un pacchetto viene inoltrato sulle interfacce diverse da quella da cui lo ha ricevuto solo se l interfaccia da cui lo ha ricevuto è l interfaccia con la quale il router riceverebbe il mittente. Ragioniamo dunque in termini di mittenti: se il percorso migliore passa dall interfaccia da cui ho ricevuto il pacchetto vuol dire che quel pacchetto ha fatto la strada migliore dalla sorgente a me, e quindi lo butto fuori. Se a un certo punto mi arriva un pacchetto per lo stesso gruppo multicast da una stessa sorgente ma da un altra interfaccia scarto il pacchetto. Il router dunque calcola i reverse path, ovvero i percorsi verso i mittenti. Tutto bello, molto carino, ma funziona solo se la rete è simmetrica. Un problema che abbiamo col Reverse Path Forwarding è che manca la presenza di meccanismi che si accertino dell interesse dell inoltro. Inoltre in una situazione del genere posso avere problemi di duplicazione del pacchetto. L evoluzione del RPF. Sostanzialmente si cerca di migliorare un po le cose, tentando di evitare un po di traffico inutile. Creo dunque un albero (a differenza del RPF in cui non ho un vero e proprio albero) e in una situazione come quella descritta qui sopra non ho problemi di duplicazione. I router devono capire qual è l interfaccia padre (quella che usano per raggiungere la radice). Dopodichè date tutte le interfacce, devono capire se inoltrare o meno, cercando di capire se sull interfaccia figlia è collegato un altro router.

Se su una rete locale ci sono due o più router collegati, A e B sono collegate con le interfacce figlie, C con quella padre. C quando riceve un pacchetto lo inoltra, A e B quando ricevono un pacchetto sulle interfacce figlie non lo inoltrano. Quando A e B si accorgono che c è un nuovo router vedono quale dei due ha il percorso migliore verso la sorgente: chi ha il percorso migliore inoltrerà. In questo caso in cui i percorsi sono uguali c è un qualche tiebreak. Chi fa inoltro è il router designato. In questo caso X è quello che ha il percorso migliore (guarda i pesi) quindi è lui a diventare il designated router. RPB risolve il problema del traffico duplicato, ma il traffico va comunque sulla LAN B e magari lì nessuno vuole riceverlo. Sarebbe bene che Z facesse un operazione di pruning, potando quel pezzo d albero.

Il problema pocanzi descritto è risolto dal Truncated RPB che implementa il concetto di pruning, partendo dalle foglie (interfacce figlie che non son collegati ad altri router). Se sulla LAN foglia dell interfaccia figlia non c è nessuno interessato, quella foglia dev essere eliminata. Questo si scopre con meccanismi di membership report. Il truncated RPB permette di eliminare le foglie. Quando si sono eliminate, questo meccanismo si può continuare verso gli altri router tramite messaggi per i quali l interfaccia padre può dire qui non c è nessuno interessato a quel gruppo multicast. E così via, in modo che il pruning coinvolga non solo foglie ma interi sottoalberi. Abbiamo poi un ultima estensione dove si può fare il pruning di interi alberi (che poi è quanto abbiamo detto in precedenza: RPB taglia solo le foglie, RPM può tagliare interi rami) Quando si ha questo meccanismo, i messaggi di Non Membership Report hanno validità limitata. Nell esempio di prima, se una stazione sulla LAN B si iscrive al gruppo multicast X e Y a un certo punto riprendono a mandare traffico multicast. Più messaggi si mettono nell algoritmo, più la complessità aumenta, quindi alle volte si preferiscono messaggi con validità limitata. Si tenga presente che poi i vari protocolli faranno delle scelte a livello di implementazione dei messaggi.

Un altra categoria di protocolli di routing multicast sono i protocolli LS: coi protocolli LS si può costruire una mappa della rete, e grazie ai messaggi IGMP questa mappa è colorabile con i membri dei gruppi multicast. Si evita di fare flooding (seppur con tutte le ottimizzazioni del caso). Molto meglio ma crea molto lavoro ai router perché i router devono calcolarsi un albero per ogni sorgente e per ogni gruppo, usando Dijkstra. Quello che si fa allora è evitare il precalcolo, perché le possibili destinazioni sono potenzialmente tutte le destinazioni di Internet. Si tenga presente che nel LS normale un router calcola un albero da sé a tutte le destinazioni: qui dobbiamo moltiplicare il tutto per il numero di gruppi e per il numero di membri in ogni gruppo. Il router dunque non calcola l albero, raccoglie le informazioni sulla rete e quando gli arriva il primo pacchetto per il gruppo X si calcola l albero (da sé verso tutte le destinazioni del gruppo X). Prestazioni scarse quando passa il primo pacchetto perché prima si calcola l albero e poi si inoltra (ma questo non è un gran problema). Algoritmo che costa molto. Gli altri algoritmi si possono implementare molto più facilmente, però genero più traffico. Solito trade-off. Un altra soluzione proposta si chiama Core-Based Tree. Visto che creare un albero per ogni sorgente può essere problematico, creiamo un albero per gruppo. Quest albero è fatto cercando un core (un punto centrale dell albero), poi si fa la strada ottimale da quel core a tutte le destinazioni del gruppo. Quando delle sorgenti mandano traffico, questo va prima al core e poi dal core viene redistribuito. La strada non è ovviamente ottimale perché verso il core facciamo strada subottimale e poi dal core andiamo in maniera ottimale: compromesso che semplifica le cose e usa un solo albero. Naturalmente il core diventa un punto nevralgico. Ci sono dei protocolli che usano quest algoritmo e usano core diversi per aumentare l affidabilità. Questo approccio non è più soft-state ma hard-state: soft-state è un protocollo che non richiede informazioni di stato nei nodi, hard-state invece mantiene delle informazioni e finchè non si ricevono messaggi espliciti le informazioni rimangono. Problemi di flessibilità.

Quando un router periferico vede che ha un host che vuol far parte di un gruppo manda un messaggio al core dicendogli attenzione, io ora voglio mandarti del traffico multicast!. Nel mandare questo messaggio al core si attraverseranno un certo numero di router intermedi che magari non sanno dov è il core - che vedono questo messaggio e si preparano: quando io vedo del traffico per questo particolare indirizzo multicast lo mando al core e il core poi lo distribuisce alle varie destinazioni. Questo meccanismo di join fa capire al core che c è un interessato al gruppo X. Il pacchetto ha fatto la strada più breve verso il core, quindi i router intermedi che hanno mandato le join al core si segnano i percorsi. Sostanzialmente si sfrutta il routing unicast tra i router periferici e il core per cercare la strada migliore per andare dai router periferici al core ma soprattutto dal core ai router periferici. Se a un certo punto si aggiungono router che joinano un certo gruppo, il core non duplica i messaggi, ma sono i router periferici che smistano. Per inteso: c è scalabilità dal punto di vista del routing e non dal punto di vista dell inoltro dei pacchetti perché il core diventa particolarmente carico (non solo lui, ma anche la zona della rete intorno al core, ma questo non è un gran problema perché basta creare core diversi per gruppi diversi) E tra i domini, in cui bisogna imporre delle gerarchie e delle regole, che cosa facciamo? Se abbiamo un utente Y che vuole ricevere i pacchetti di diversi gruppi noi sappiamo che i router devono saper raggiungere tutte le destinazioni (con routing non gerarchico). Con routing gerarchico prendiamo tutte le destinazioni in un dominio e al di fuori di questo dominio annunciamo che nel dominio X c è almeno uno che vuole ricevere pacchetti multicast. Solo all interno di X i router sanno dove mandare. Quali sono i protocolli che sono stati definiti per fare traffico multicast? DVMRP è basato su DV, crea source specific tree e usa un approccio flood and prune. MOSPF è un estensione di OSPF, usa LS e crea source specific tree.

PIM invece lavora in Dense Mode o in Sparse Mode: entrambi non hanno uno scambio di informazioni specifico per il multicast ma si basano su quelle dell unicast. Infine abbiamo il BGMP, modifica del BGP, ma non viene usato. Quindi non ne parleremo. DVMRP è stato il primo protocollo definito per fare routing multicast. Ora è alla v3. La v1 usa un algoritmo di tipo Truncated RPB, quindi si cerca di eliminare le foglie che non servono e i duplicati che non servono (ma continuiamo a mandare fino all ultimo nodo), la v3 fa anche pruning (se io ho sottoalberi con 0 interessati, li taglio via). Esistono messaggi di routing DVRMP che servono per calcolare i percorsi verso i mittenti: i router cercano di calcolare il percorso verso il mittente per capire quale interfaccia è quella padre, e i- noltrano solo i pacchetti che ricevono dall interfaccia padre. Crea source specific tree. Ha il suo bel messaggio di PRUNE che prima abbiam chiamato Non-Membership Report. Il fatto che un certo sottoalbero non sia interessato a un gruppo multicast scade, quindi non abbiamo messaggi specifici di Membership Report (c è un timeout). Se quando rimanda pacchetti non ci sono interessati il router rimanda un Non-Membership. MOSPF. LS, fa degli alberi specifici per le sorgenti, viene usato all interno di un AS (routing intradomain)

In un dominio di routing non è che tutti i router devono supportare il multicast OSPF, perché MOSPF è retrocompatibile con OSPF Sostanzialmente si aggiunge un nuovo Link State Advertisement per descrivere la situazione della rete attorno ad un router. Prima ne avevamo 5, se ne aggiunge un sesto che descrive una destinazione multicast. Questi LSA di tipo 6 sono generati dai router che sanno che qualcuno a loro attaccato è interessato al gruppo X. L informazione si propaga nell area: quando il pacchetto LSA arriva all ABR, questo genera un nuovo LSA di tipo 6 che dice che qualcuno da qualche parte nell area è interessato al gruppo X (si fa dell aggregazione) Esiste la possibilità per un ABR (o ASBR) di dire usatemi come default per qualsiasi gruppo, non ti sto a dire quali gruppi si raggiungono se passi da me. Questo si fa usando un bit particolare negli LSA di tipo 1 (router link states). MOSPF è un buon protocollo perché calcola percorsi, evita di mandare traffico che non serve ma è molto pesante sui router. E veniamo al PIM, Protocol Indipendent Multicast. Perché si chiama così? A differenza di OSPF e DVMRP in cui il protocollo manda messaggi specifici che riguardano il multicast usando un protocollo apposta (quindi i poveri router potenzialmente fanno girare 2 protocolli di routing), nel PIM l idea è di calcolare i Reverse Path utilizzando le informazioni dell unicast. In realtà c è una ragione un po storica per cui DVMRP usa i suoi messaggi e PIM no: PIM viene da Cisco, che già ha protocolli di routing implementati sui suoi router. Perché inventarne di nuovi? DVMRP invece viene dalla ricerca. Il vantaggio di avere un protocollo diverso è che si possono differenziare i percorsi e quindi ognuno calcola il percorso migliore secondo la sua filosofia. Altrimenti, come in PIM, multicast e unicast gira tutto allo stesso modo. Sparse mode: più adatto ai casi in cui i partecipanti sono sparsi. Dense mode: caso contrario. Tutti e due si chiamano PIM, ma sono diversi tra loro. Non sono compatibili.

Dense mode: sostanzialmente come DVRMP. Ci sono i router che mandano dappertutto, generano messaggi di pruning Esiste un protocollo specifico per fare il join. Lo sparse mode, invece, ha un meccanismo di join esplicito: prima di poter iniziare a instradare il traffico verso le destinazioni, i router attaccati alle foglie devono dire che c è qualcuno interessato al traffico, altrimenti non arriva. Nel PIM DM c è la possibilità di sollecitare, ma anche se non si sollecita dopo un po (scadenza timeout) il traffico arriva perché c è una sorta di join implicito. Su una rete locale le stazioni con IGMP dicono che sono interessate a un gruppo multicast e il router lo può dire. Se invece in un certo sottoalbero non c è nessuno interessato si usano i messaggi di pruning. Ci sono dunque tutte le funzionalità del Reverse Path Multicasting incluso quello che chiamavamo il Membership Report. Di default altrimenti broadcasting dappertutto, timeout, pruning e quant altro.

Il DM va bene quando ho densità perché tende a mandare dappertutto, poi quando qualcuno si accorge che non c è nessun i- scritto manda un messaggio di prune. Vediamo come funziona PIM-SM. Usa un core based tree. Quindi lui crea un core (che può essere diverso per ogni gruppo multicast) e la distribuzione è basata sul core. Nel PIM il core si chiama Rendezvouz point e ovviamente il core based tree è condiviso. Quando un router si accorge di avere degli interessati genera un messaggio di JOIN che manda al core, che dev essere noto per un certo gruppo. Qual è l idea? Supponiamo che la rete formata da 3 nodi abbia un Rendezvous point per uno specifico gruppo multicast. Nella fase iniziale si usa un albero condiviso: quando una sorgente genera traffico (es.: S1), il traffico viene mandato al core e il core poi lo distribuisce a R2 e a R3. In questo caso è positivo il fatto che è facile fare l albero, ma non va bene il fatto che il traffico S1-R3 farebbe una strada più breve da sotto (ma essendoci lo shared tree non ci passa).

SM ha un meccanismo per cui quando si rende conto che c è tanto traffico da S1 a R3 si crea un albero specifico. I router si mettono d accordo dicendo sì sì, abbiamo un rendezvous point, continuiamo a usarlo per il traffico di S2 ma adesso passiamo ad alberi specifici e questi li ottimizziamo, minimizzando i percorsi. La cosa si fa in due step, perché finora abbiam visto algoritmi che cercano di fare tutto in uno step. DVRMP crea infatti un albero specifico della sorgente, ma nel farlo genera un sacco di traffico. MOSPF non genera traffico, crea un albero specifico ma fa un sacco di lavoro perché in caso di nuove stazioni si riparte con la ricerca del calcolo ottimale. Il PIM-SM cerca un compromesso: fammi fare un albero condiviso così io intanto mando a destinazione con poco sforzo, poi se vedo che un mittente genera tanto traffico genero un albero specifico (posso metterci anche un sacco di tempo a trovarlo, perché tanto il traffico arriva comunque). Y i pallini sulla slide sono tutti router Come si fa funzionare una cosa del genere in modo efficiente? Supponiamo che ci sia un gruppo G e un rendezvous point noto a tutti i router che supportano multicast. Nel triangolo c è una stazione interessata al gruppo G e lo comunica con IGMP. Un router che riceve il membership report genera il messaggio di JOIN e lo manda al core, dicendogli guarda che qui c è qualcuno interessato al gruppo G. Il messaggio va al RP seguendo la strada migliore secondo le classiche regole unicast (segui le frecce): i nodi intermedi devono segnarsi le informazioni intermedie. Y, ad esempio, deve segnarsi che attaccato all interfaccia 1 qualcuno è interessato al gruppo G e che quando ha dei pacchetti che gli arrivano di là per il gruppo G lui li manda a destra, mentre se invece gli arriva qualcosa per il gruppo G li manda in basso. A un certo punto supponiamo ci sia una LAN attaccata al router nero a sx. Quando il router riceve un pacchetto per G lui lo manda al RP. La prima volta, siccome i router intermedi non sanno come inoltrare pacchetti per il gruppo G, manda un messaggio PIM di registrazione (data: il pacchetto originale, G: il gruppo). Anche qui c è tutta la menata che i router imparano i percorsi. I messaggi successivi poi non hanno più bisogno della registrazione. Non proprio così, vedi sotto. Una volta che RP ha ricevuto i dati manda un messaggio di JOIN verso il mittente per il gruppo multicast. E qui che viene segnata la corrispondenza, non come detto prima.

S Da quel momento in poi S può mandare dati tranquillamente come dati mandati a G. Arriva prima al RP e poi va giù, seguendo il migliore reverse path (che non è il percorso migliore in assoluto). A un certo punto il router in fondo si accorge che arriva un sacco di traffico da S: S sta generando tanto traffico, sarebbe bene creare un albero specifico! Viene mandato dunque un messaggio di JOIN a S, messo in un pacchetto IP che va a S. Quel messaggio segue la strada migliore (unicast) dal destinatario alla sorgente. Dal messaggio JOIN si imparano le strade e quindi si crea un nuovo ramo dell albero specifico per la sorgente. # Una volta che il JOIN è stato fatto, quando la sorgente manda dei dati, il router # avrà imparato che quei dati per il gruppo G devono andare sia al RP, sia sull albero specifico. Man mano che nuove sorgenti diventano attive (o destinazioni vedono che esiste una sorgente molto attiva) generano messaggi di JOIN e ottimizzano il percorso. Una volta fatto l albero specifico ci sono due percorsi che portano sotto: uno sul core based tree e uno sull albero specifico. Il router foglia manda un messaggio di PRUNE, mandato verso RP, dicendo che non gli interessa più traffico per G che arrivi da S (non è che non gli interessa più traffico per G, attenzione!). Da quel momento in poi il traffico che arriva da S non viene mandato più giù dal RP. Il pacchetto arriva comunque al RP, ma non viene più mandato giù fintanto che che qualcuno fa un Membership Report per il gruppo G, viene generata una JOIN da cui deriva un nuovo pezzo dell albero core based tree e a questo punto il traffico per S va sia sul ramo specifico, sia su quello generale di destra. Si cercano dunque di ottimizzare i percorsi facendo uso di un albero condiviso e alberi specifici delle varie sorgenti.

Come prima: il router foglia a dx vuole unirsi allo shortest path tree perché vede che ci si scambia tanto traffico. JOIN va verso la sorgente e nell andarci incontra l albero specifico di prima: il nuovo albero creato è quello riportato nella slide di sotto, in cui per i nodi sopra non cambia niente. Si aggiunge solo un collegamento sui tre nodi col link spesso. Anche nel PIM c è il concetto di designated router che è l unico router che su una LAN deve inviare pacchetti. Si identifica con messaggi PIM particolari. Un altro punto interessante è il bootstrap router: questo viene letto dinamicamente e serve per far sì che tutti quanti possano sapere chi è il rendezvous point. Per ragioni di affidabilità ci sono più BSR. L informazione relativa agli RP viene distribuita a tutti i router, dopodiché esiste un algoritmo che guarda l IP di un gruppo multicast e l elenco di RP capisce qual è l RP per quel particolare gruppo multicast. Tutti i router PIM riescono così a capire qual è il loro RP per un certo gruppo multicast. L RP-Set naturalmente può cambiare dinamicamente.