Multicast introduzione

Davide Guerri CASPUR 1

Multicast

Davide Guerri CASPUR 2

Nota di copyright

Copyright © 2006 by Davide Guerri (<[email protected]>).

Fatte salve esplicite autorizzazioni, la copia letterale e la distribuzione di questo documento sono permesse con qualsiasi mezzo, a

condizione che questa nota sia riprodotta nella sua interezza e che venga mantenuto il riferimento all’autore.

Introduzione al Multicast Davide Guerri CASPUR 3

Sommario Introduzione

Cos’è il Multicast Concetti di base

Multicast intradominio PIMSM

Multicast interdominio MSDP MBGP

Multicast su rete locale IGMP Ottimizzazioni


Introduzione


IntroduzioneCos’è il multicast

Nelle reti a commutazione di pacchetto abbiamo 4 tipi di indirizzamento riferiti a differenti schemi di routing:

Lo scopo del multicast è quello di ottimizzare, rispetto a unicast, l’invio e

l’instradamento delle informazioni destinate a più client


IntroduzioneConcetti di base

Il paradigma d’instradamento è totalmente differente da quello tradizionale IP (destination based) Un gruppo o indirizzo multicast identifica l’insieme di client che

intendono ricevere uno specifico flusso• Nella notazione standard, un gruppo multicast G proveniente da

qualunque sorgente è identificato dalla coppia (*,G) mentre se la sorgente S è definita si utilizza la notazione (S,G) dove S è un indirizzo IP unicast.

Gli indirizzi IP di classe D sono tutti e soli quelli riservati al multicast:• 224.0.0.0/4 ovvero da 224.0.0.0 a 239.255.255.255

• alcuni range sono riservati a specifici scopi (GLOP, SAP, Local Scoped, …) L’indirizzo IP degli effettivi destinatari di una trasmissione multicast non

è in alcun modo in relazione con il gruppo multicast al quale essi appartengono


Esistono 2 modalità di distribuzione dei flussi multicast utilizzabili in relazione al rapporto tra il numero di destinatari e quello totale degli host della rete: Densa

• Si assume che i destinatari siano la maggior parte degli host• Basata su flooding periodico e pruning• Adatta in domini circoscritti e per alcune tipologie di applicazioni

Sparsa• Si assume che i destinatari siano una frazione degli host della rete• Basata su richiesta esplicita di unione (“join”) al gruppo• Adatta per la distribuzione su scala “geografica”

In queste slides tratteremo esclusivamente la distribuzione sparsa



Gli algoritmi alla base della distribuzione multicast fanno uso di “tabelle di routing” (nell’accezione canonica) ma solo per decisioni che riguardano indirizzi unicast (segnalazione) I percorsi di distribuzione del multicast sono costruiti in direzione

contraria rispetto a quella del flusso: dai recevitori alla sorgente. Si parla infatti di Reverse Path Forwarding (RPF)

I router abilitati al multicast possono mantenere una tabella d’instradamento separata da quella utilizzata dal routing unicast, denominata RPF table

• In questo modo è possibile applicare delle politiche differenti per traffico unicast e multicast

Per un dato indirizzo IP unicast U, il RPF neighbor di un router A è il “next hop” per raggiungere U secondo la RPF table.



L’instradamento dei pacchetti IP con indirizzi multicast è regolato da apposite strutture dati nelle quali ad un dato gruppo multicast è associata una lista di interfacce sulle quali replicare il traffico

Tali “liste”, costruite dagli algoritmi di routing multicast, sono denominate Output Interface List (OIL) e sono sempre riferite ad un gruppo multicast in termini di (*,G) o (S,G)

Le OIL sono strutture altamente dinamiche, al contrario delle RPF table (che pur potendo essere dinamiche, non variano molto spesso)

Fe1/2

Fe0/1.1(S,G)

Gi0/1/1.1

Gi0/0/3.10

Gi0/0/2.1

(*,G) Attenzione: (S,G) ⊄ (*,G)

Le OIL e gli stati del router che inoltra il traffico per G possono coesistere per (S,G) e (*,G)

Esempio di OIL per (*,G) e (S,G)



Due modelli di servizio: Molti a Molti (Any Source Multicast, ASM)

• Più sorgenti possono trasmettere verso lo stesso gruppo multicast• Adatto a sessioni di chat, videoconferenze, giochi online• Realizzato, ad esempio, con un sottoinsieme delle funzionalità di PIMSM

e IGMPv2 Uno a Molti (Source Specific Multicast, SSM)

• Più sorgenti possono trasmettere verso lo stesso gruppo multicast ma si può selezionarne uno specifico sottoinsieme

• Adatto a trasmissioni audio/video o dati• Realizzato, ad esempio, mediante un sottoinsieme delle

funzionalità di PIMSM e IGMPv3



Per raggiungere tutti i membri del gruppo multicast, la rete deve configurarsi per creare un albero di distribuzione Le foglie sono i client, la radice è la sorgente del gruppo

Si possono avere alberi di distribuzione “sovrapposti” se più sorgenti trasmettono su uno stresso gruppo

Nel modello di servizio SSM, si seleziona un sottoinsieme di alberi, riferiti a specifiche sorgenti



Nel modello ASM la sorgente del gruppo multicast non è definita È necessario un configurare nella rete un “punto di ritrovo”

tra sorgenti e ricevitori• Ogni sorgente comunica a quest’entità la sua presenza • Ogni ricevente si riferisce ad esso per conoscere l’indirizzo delle

sorgenti di un dato gruppo multicast

Nel modello SSM si assume che, in qualche modo, i membri del gruppo multicast conoscano l’indirizzo della sorgente



È importante capire la differenza tra i protocolli di routing che popolano la RPF table e quelli che popolano le OIL (e che dunque creano dinamicamente l’albero di distribuzione multicast) Protocol Indepependent Multicast Sparse Mode (PIMSM) è un esempio di

protocollo di routing multicast che non agisce sulle RPF Tables ma è responsabile dell’instradamento del traffico.

• PIMSM utilizza le RPF table per determinare i neighbor RPF cui inoltrare i messaggi di segnalazione

Spesso i protocolli di routing responsabili del popolamento delle tabelle RPF sono estensioni di protocolli usati tipicamente per unicast Multicast Extension for BGP (MBGP), è utilizzato esclusivamente per popolare le RPF

table Altri protocolli utilizzati per multicast sono

Protocol Indepependent Multicast Dense Mode (PIMDM) Multicast Extension for OSPF (MOSPF) DVRMP (simile a PIMDM ma è legato a IP)



Multicast intradominioPIM


PIM è un protocollo di routing in grado di governare l’instradamento del traffico multicast È indipendente dal protocollo di rete:

• Può essere incapsulato in diversi tipi di pacchetti L3 (e.g.: IPv4 e IPv6) e può essere utilizzato per diverse tipologie di routing multicast (e.g.: IPv4 e IPv6)

È basato sullo scambio di messaggi tra router Può operare sia in modalità densa sia sparsa

• PIMSM mira a costruire un albero di distribuzione multicast dove ogni cammino da una foglia alla radice sia lo shortest path dalla sorgente ai client. Tale albero è denominato Shortest Path Tree (SPT)

Multicast IntradominioPIM::Concetti di base


Nel modello ASM, PIMSM richiede la presenza di un Rendezvous Point (RP) Ogni sorgente multicast è registrata (dal router ad essa direttamente

connesso) presso un RP Ogni router del dominio PIMSM conosce l’indirizzo di un RP

• ad esempio in quanto configurato manualmente … Per ASM, prima di costruire lo SPT radicato nella sorgente, PIMSM

costruisce un Rendevouz Point Tree (RPT), ovvero un albero di distribuzione (subottimale) costituito da due SPT:

• Uno radicato nel RP ed in grado di distribuire i pacchetti multicast dal RP ai membri del gruppo multicast

• Uno radicato nella sorgente ed in grado di distribuire i pacchetti dalla sorgente al RP

In un dominio PIMSM, possono convivere più RP ognuno dei quali responsabile di differenti gruppi multicast

Multicast IntradominioPIMSM::Concetti di base


Sorgenti e riceventi di gruppi multicast non agiscono direttamente sull’instradamento Tutte le operazioni di iscrizione e abbandono di un gruppo o di

registrazione di una sorgente multicast sono mediate dai router Se su una LAN con degli host vi sono più router multicast,

solo uno di questi ha un “ruolo attivo” nel soddisfacimento delle richieste degli host Tale router è denominato PIM Designated Router e, per conto degli

host della LAN, è responsabile• Dell’iscrizione ai gruppi multicast• Dell’abbandono di un gruppo multicast• Della registrazione di nuove sorgenti multicast sul RP

L’elezione del DR avviene per mezzo di appositi messaggi PIM Hello, destinati a tutti i router della LAN



In PIMv2 il Designated Router è generalmente il router con indirizzo IP più alto È possibile specificare

esplicitamente una priorità che interviene nell’elezione del DR

È possibile che un router con metriche più favorevoli per raggiungere la sorgente (o il RP) svolga il ruolo di DR nella costruzione dell’albero di distribuzione multicast



Multicast InterDominioEsempio di costruzione dell’albero di distribuzione per PIMSM


Multicast Intradominio PIMSM::Costruzione dell’albero di distribuzione

♦ Il router C è il RP del dominio PIMSM♦ B è un router multicast direttamente

connesso ad una sorgente S♦ A è un router multicast direttamente

connesso ad un client R

Sia G un gruppo multicast,inizialmente S non trasmette su G e nessuno ha richiesto l’iscrizione a tale

gruppo



a) R richiede l’iscrizione al gruppo G per mezzo di un IGMP Membership Report (*,G)

b) A invia un PIM Join (*,G) verso il RPF neighbor per il RP (ovvero il router C)

• Nell’esempio, i Join si propagano verso C ed ogni router aggiunge l’interfaccia dalla quale li riceve alla OIL per (*,G)

• Quest’ultima operazione crea un ramo del RPT, che rimane attivo anche se non c’è ancora traffico attraverso esso



c) S comincia a trasmettere sul gruppo Gd) Appena “appresa” l’esistenza di una nuova

sorgente, B provvede a registrarla sul RP mediante invio di messaggi PIM Register (S,G)

• Quest’ultimi messaggi (unicast) incapsulano i pacchetti multicast trasmessi da S.

• Viene generato un PIM Register (S,G) per ogni pacchetto multicast che B riceve.

e) C apprende l’esistenza di una nuova sorgente ed inoltra il traffico che riceve direttamente da B sulle interfacce presenti nella OIL per G

• Il flusso multicast si propaga fino al router A

f) R riceve il primo pacchetto relativo al gruppo G


g) Per evitare l’incapsulamento del traffico multicast, C invia un messaggio PIM Join (S,G) verso la sorgente S. Il messaggio è inviato al RPF neighbor per S e si propaga fino al router direttamente connesso con la sorgente, B.

• Nell’esempio, tutti i router coinvolti aggiungono le interfacce sulle quali ricevono i Join, alla OIL per (S,G)

h) B comincia ad inoltrare verso C il traffico multicast “nativo”

• Quando quest’ultimo raggiunge il RP, C riceve 2 volte ogni pacchetto multicast: una volta incapsulato nei PIM Register ed una volta “nativamente”

i) Per fermare i PIM Register (S,G), C invia un PIM RegisterStop (S,G) a B.

Multicast IntradominioPIMSM::Costruzione dell’albero di distribuzione


j) Fin dal passo e), A conosce la sorgente del gruppo multicast in quanto riceve i pacchetti da quest’ultima tramite il RP. Per costruire lo SPT, A invia un PIM Join (S,G) verso il RPF neighbor per S.

k) Alla ricezione di quest’ultimo messaggio, B aggiunge l’interfaccia verso A alla OIL per (S,G) e, come conseguenza, comincia l’invio del traffico multicast anche su quest’ultima.

A questo punto il flusso multicast arriva a R ma l’albero di distribuzione costruito (detto Rendezvous Point Tree, RPT) non è ottimale. Il router direttamente connesso al ricevente del gruppo (i.e.: A), se configurato per farlo, può dare inizio alla creazione dello Shortest Path Tree (SPT) per S.



l) A comincerà a riceve due volte ogni pacchetto multicast: una volta da B ed una volta dal RP. Quando questo accade, A invia un PIM Prune (S,G,RPT) verso C.

• Tale messaggio richiede l’eliminazione degli stati d’inoltro del solo RPT per una sorgente specifica di G: più sorgenti potrebbero trasmettere sullo stesso gruppo ma per esse lo SPT potrebbe non essere stato costruito. Gli stati per (*,G) rimangono invariati.

• Il router che riceve il messaggio di pruning elimina l’interfaccia dalla quale lo riceve dalla OIL per (S,G,RPT); se, dopo questa operazione, la OIL per (S,G,RPT) risulta vuota, esso genera a sua volta un PIM Prune (S,G,RPT) verso il RPF neighbor per il RP



m) Se C non ha più entry nella OIL associate a (S,G), invia a sua volta un PIM Prune (S,G) verso la sorgente B

• Il router che riceve il messaggio (il RPF neighbor di C per B) elimina l’interfaccia dalla quale lo riceve dalla OIL per (S,G). Se, dopo questa operazione la OIL per (S,G) risulta vuota, esso genera a sua volta un PIM Prune (S,G) verso il suo RPF neighbor per S.



Situazione finale Finché la topologia della rete non cambia,

anche l’albero di distribuzione non varia. Periodicamente ogni router coinvolto, invia

al suo RPF neighbor per S un messaggio PIM di Join per effettuare il refresh dei timer di vita degli stati d’inoltro La scadenza di questi timer ha un effetto

assimilabile al pruning esplicito L’invio periodico di messaggi di Join,

consente la riconvergenza della distribuzione in caso di variazioni topologiche in quanto anche le RPF table (quando popolate da algoritmi di routing dinamico) sono modificate



Il router direttamente connesso alla sorgente continua a comunicare al RP la presenza di quest’ultima per mezzo di messaggi PIM Register (S,G) che però non incapsulano più traffico multicast Tali messaggi sono

denominati PIM null register messages (S,G) e terminano solo quando la sorgente non è più attiva



Il procedimento di costruzione dell’albero di distribuzione, viene ripetuto se qualche altro client richiede l’iscrizione al gruppo G:

1. Il router direttamente connesso al ricevente inizia la costruzione del RPT

2. Il RP costruisce uno SPT con radice nella sorgente

3. Viene infine costruito lo SPT tra sorgente e ricevitore


Il traffico generato da una nuova sorgente S’ che comincia a trasmettere su G raggiungerà il RP e, di conseguenza, tutti i client iscritti al gruppo G.Si ripeterà poi la costruzione dello SPT, come visto in precedenza anche per (S’,G)


Non tutti i passaggi visti sono sempre necessari: Se, durante la propagazione dei PIM

Join per (S,G), s’incontra un router che ha già uno stato d’inoltro per (S,G), l’interfaccia di provenienza di quest’ultimo viene aggiunta alla OIL per (S,G) ed il processo s’interrompe

Lo stesso vale per richieste inerenti (*,G) (utilizzate nella costruzione del RPT)



Nell’esempio precedente, un client R richiede l’iscrizione al gruppo G prima che S cominci a trasmettere su G

Se il RP non ha “richieste pendenti” quando S comincia a trasmettere: alla ricezione del PIM Register (S,G)

inviato da B, il RP invia subito un PIM Register Stop (S,G) verso B ma (al contrario dell’esempio precedente) non procede alla creazione dell’albero di distribuzione radicato in quest’ultimo router

B continua comunque il periodico invio di messaggi PIM Null Register (S,G) per segnalare l’esistenza di una sorgente attiva



Se un client richiede l’uscita da un gruppo multicast o se non ne rinnova l’iscrizione entro un certo periodo di tempo Il router direttamente connesso al client,

invia un PIM Prune (S,G) al RPF neighbor per la sorgente

• Ciò viene ripetuto per ogni sorgente per la quale è stato costruito uno SPT per G

Il router che riceve la richiesta elimina l’interfaccia sulla quale la riceve dalla OIL per (S,G)

• Se non vi sono più interfacce nella OIL per (S,G), il router di upstream invia a sua volta un prune verso il RPF neighbor per S.



SSM è realizzato con un sottoinsieme delle funzionalità di PIMSM Tutti i gruppi multicast possono essere utilizzati con questo modello ma, per

IPv4, è riservato allo scopo il blocco d’indirizzi 232.0.0.0/8 ASM può essere implementato con un insieme di “iscrizioni” a gruppi multicast

del modello SSM È però necessario utilizzare un meccanismo “esterno” per il discovery delle

sorgenti SSM è estremamente più semplice e versatile di ASM

Non è più necessario il RP(!) Risolve quasi del tutto i problemi di sicurezza legati al modello ASM (i.e.: DoS) L’identificativo di una “trasmissione” multicast comprende anche l’indirizzo della

sorgente• Risolve alcuni problemi legati al limitato spazio d’indirizzamento IPv4 dedicato al

multicast (e.g.: GLOP)

Multicast IntradominioPIMSM::Source Specific Multicast


Multicast InterDominio


Poiché ogni dominio PIMSM fa uso di un proprio RP, non è possibile utilizzare direttamente meccanismi di costruzione dell’albero di distribuzione PIMSM visti in precedenza È necessario un meccanismo in grado di permettere lo scambio di

informazioni tra RP circa le sorgenti registrate ed attive Multicast Source Discovery Protocol (MSDP)

È utilizzato per ricevere / comunicare le sorgenti attive di un RP (ovvero quelle registrate secondo i meccanismi di PIM visti in precedenza) ad altri RP

Il suo utilizzo tipico è tra differenti domini PIMSM ma può essere utilizzato per ridondare il RP di uno stesso dominio (ad esempio per mezzo dell’indirizzamento anycast)

Routing Multicast InterdominioMSDP::Cenni


Prima dell’avvento di MSDP, il routing multicast interdominio era realizzato posizionando i RP sul bordo dei punti di interscambio e abilitando PIMDM sulle interfacce di peering

Il traffico multicast che perveniva ad un RP veniva inviato in flooding a tutti gli altri RP che, in quanto router PIM, venivano a conoscenza delle sorgenti degli altri domini

Quest’approccio, oltre a generare una grossa quantità di traffico, costringeva ad un posizionamento non sempre ottimale dei RP per i domini afferenti l’IXP



I RP di due domini PIMSM che vogliano scambiare informazioni circa le sorgenti attive (SA) stabiliscono un peering MSDP Il peering è configurato manualmente dagli amministratori A meno di filtri, ogni sorgente attiva viene comunicata a tutti i peerer MSDP

(tranne quello dalla quale è ricevuto)• Sono comunicate anche le sorgenti ricevute dagli altri RP e questo è utile qualora

un dominio voglia dare transito al traffico multicast di altri domini I messaggi MSDP sono veicolati da una connessione TCP

I meccanismi di costruzione dell’albero di distribuzione multicast rimangono quelli di PIMSM, tuttavia il RP di riferimento per i router multicast rimane quello del dominio

d’appartenenza la sorgente può trovarsi in qualunque dominio per il quale si ricevono SAs

tramite MSDP



1. Secondo il protocollo PIMSM, le sorgenti attive del dominio A vengono registrate sul RP A

2. Attraverso il peering MSDP tali sorgenti, e i gruppi multicast ad esse relativi, sono comunicate al RP del dominio B

3. e 4. Viene costruito il RPT come visto in precedenza.

5. Viene costruito lo SPT radicato nel router direttamente connesso alla sorgente


Entrando più nel dettaglio con un esempio:



N.B.: Nel modello di servizio SSM, MSDP non è necessario (!) I router di un dominio possono direttamente costruire lo SPT in quanto

conoscono l’indirizzo della sorgente


Routing Multicast InterdominioMBGP::Cenni

Il multicast interdominio può funzionare anche senza uno specifico EGP per multicast Come abbiamo visto le tabelle di routing per unicast e multicast (RPF

tables) possono coincidere MSDP e PIM (ad esempio) sono sufficienti al funzionamento del

multicast interdominio, laddove non vi siano particolari esigenze d’instradamento

MBGP è una estensione del protocollo BGP in grado di popolare dinamicamente le tabelle RPF Le rotte annunciate o ricevute tramite MBGP non influenzano mai il

traffico unicast Al contrario di PIM, non agisce direttamente sugli stati d’inoltro del

traffico multicast


Routing Multicast InterdominioMBGP::Cenni

MBGP è utile quando le normali tabelle di routing unicast e quelle multicast devono essere differenti, ad esempio per Evitare che il RPF neighbor di un router sia un router non abilitato al

multicast Forzare la ricezione / instradamento del traffico multicast attraverso un

particolare percorso

MBGP funziona esattamente come BGP!È solo un modo per far distinguere ai peerer l’annuncio di rotte che (eventualmente) popoleranno le tabelle di routing unicast e quelle che (eventualmente) popoleranno le tabelle RPF


Multicast su rete locale


Multicast su rete localeIGMP::Concetti di base

Il più diffuso protocollo utilizzato per l’iscrizione ad un gruppo multicast da parte dei client è Internet Group Management Protocol (IGMP) IGMP viene utilizzato esclusivamente tra host e router Tramite IGMP gli host informano il router multicast della rete che

desiderano ricevere (non ricevere più) flussi multicast Attualmente esistono 3 versioni di IGMP

IGMPv3 è l’unica versione che permette il SSM Ogni versione è retrocompatibile con le precedenti

• Anche se i meccanismi di compatibilità sono quasi sempre di tipo fall back


IGMP è basato su tre tipologie di messaggio Query (IGMP v1, v2 e v3)

• Generate dal router multicast della LAN per “sondare” l’interesse dei client nell’iscrizione ai gruppi multicast

• Le General Query richiedono informazioni per qualunque gruppo• IGMPv2 introduce le GroupSpecific Query, ovvero query relative ad

uno specifico gruppo multicast Membership Report (IGMP v1, v2 e v3)

• Generati dai client, solitamente in risposta alle query, per richiedere/confermare l’iscrizione ad un gruppo multicast

• IGMPv3 introduce le possibilità di specificare una o più sorgenti dalla quale ricevere un gruppo multicast

Leave (IGMP v2 e v3)• Generati dagli host per annullare l’iscrizione ad un gruppo multicast




I messaggi IGMP sono incapsulati in IP ed hanno TTL pari a 1 L’indirizzo sorgente è quello dell’host o del router che li emette L’indirizzo destinazione è un indirizzo IP multicast:

ALLROUTERS (224.0.0.2) Leave Message

The group being reported Membership Report

The group being queried GroupSpecific Query

ALLSYSTEMS (224.0.0.1) General Query

Destination Group Message Type


Multicast su rete localeIGMP::Indirizzi multicast di livello 2

Non essendo possibile applicare il meccanismo IP ARP per gli indirizzi multicast, è definito un mapping statico di quest’ultimi nei MAC addresses Le trame con questi indirizzi MAC di destinazione, sono trattate come

traffico broadcast dagli switch • a meno di ottimizzazioni…


Gli host della rete ricevono i messaggi generati dagli altri e, al fine di limitare il volume del traffico di segnalazione, richiederanno l’iscrizione ad un gruppo solo se questo non è già stato richiesto da qualche altro host

Multicast su rete localeIGMP::Soppressione dei messaggi ridondanti

Nei messaggi IGMP query, il router comunica un tempo massimo TMAX entro il quale devono essere generati i report.

Un client C che intende iscriversi (o confermare l’iscrizione) a qualche gruppo multicast G, aspetta un tempo casuale compreso tra 0 e TMAX secondi.

Se nessun altro client invia un report per il gruppo G, C genera il messaggio.


Se sulla stessa LAN sono presenti due o più router multicast, solo uno di essi genera le query IGMP sulla rete. Tale router prende il nome di querier della LAN

Per lo standard, il querier della LAN è il router multicast con indirizzo IP più basso

• L’elezione del querier si basa sull’analisi degli indirizzi IP sorgente nelle query IGMP inviate da ogni altro router

Multicast su rete localeIGMP::Elezione Querier della LAN


Un router non querier, rimane in ascolto dei messaggi IGMP e subentra al querier in caso esso non sia più visibile.

I router nello stato di non querier: Modificano il loro stato in funzione dei Membership Report che ricevono Al pari del querier, informano il protocollo di routing multicast della presenza

di membri di un gruppo multicast sulla LAN

Multicast su rete localeIGMP::Elezione Querier della LAN

Nota Bene Il querier della LAN può

non essere il designated router del protocollo di routing multicast (!)


Per ottimizzare la distribuzione del multicast su rete locale è necessario che gli switch L2 tengano traccia delle porte dalle quali è raggiungibile il querier e dalle quali si ricevono i Membership Report IGMP

Il traffico multicast generato dalla LAN (compresi i messaggi IGMP) viene esclusivamente inoltrato verso il querier

Il traffico multicast proveniente dal querier viene fatto fluire esclusivamente in direzione di chi ne ha fatto richiesta

Multicast su rete localeIGMP::Ottimizzazioni (IGMP Snooping)


IGMP snooping è molto oneroso per gli switch Ogni dispositivo L2 deve

• Mantenere l’elenco di tutti i gruppi multicast richiesti (e delle sorgenti per IGMPv3) con una lista di interfacce sulle quali dovrà inoltrare il traffico ad essi relativo

• Analizzare fino al livello 4 ogni singolo messaggio IGMP• E comunque fino al livello 3 tutte le trame ethernet/802.3 …

• Mantenere dei timer per ogni gruppo multicast richiesto Non esiste un vero e proprio standard per IGMP snooping

Il RFC 4541 (del 2006) è successivo alla maggior parte delle implementazioni oggi esistenti e riporta solo delle “linee guida”

Ogni vendor ha implementato una propria interpretazione di IGMP snooping (…)

Multicast su rete localeIGMP::Ottimizzazioni (IGMP Snooping)


Fine

Multicast introduzione

Technology

Transcript of Multicast introduzione