Multicast introduzione

Davide Guerri CASPUR 1
Multicast

Davide Guerri CASPUR 2
Nota di copyright
Copyright © 2006 by Davide Guerri (<davide.guerri@gmail.com>).
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

Introduzione
Cos’è 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

Introduzione
Concetti 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
Introduzione
Concetti di base

 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.
Introduzione
Concetti di base

 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)
Introduzione
Concetti di base

 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
Introduzione
Concetti di base

 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
Introduzione
Concetti di base

 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
Introduzione
Concetti di base

 È 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)
Introduzione
Concetti di base

Multicast intradominio
PIM

 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 Intradominio
PIM::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
PIMSM::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 InterDominio
Esempio di costruzione dell’albero di distribuzione per PIMSM

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 G
d) 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.

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)
PIMSM::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 Interdominio
MSDP::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
MSDP::Cenni

 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
MSDP::Cenni

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
MSDP::Cenni
Entrando più nel dettaglio con un esempio:

MSDP::Cenni
 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

MBGP::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

MBGP::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

IGMP::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

IGMP::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
IGMP::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
IGMP::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
IGMP::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
IGMP::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 (…)
IGMP::Ottimizzazioni (IGMP Snooping)

Fine

Multicast introduzione

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (6)

Plus de Davide Guerri

Plus de Davide Guerri (7)

Multicast introduzione