Internet Group Management Protocol: differenze tra le versioni

Versione delle 19:21, 17 dic 2014

Versione delle 09:12, 23 dic 2014

Riga 1:

L''''Internet Group Management Protocol''' è un protocollo per la gestione dei gruppi [[multicast]].

Costituisce il mezzo per un [[host]] di informare il [[router]] ad esso collegato che un'applicazione che funziona nell'host vuole unirsi a uno specifico [[gruppo multicast]]. IGMP opera fra un host e il router ad esso collegato direttamente, per coordinare i router multicast invece è richiesto un altro protocollo, affinché i [[datagramma|datagrammi]] multicast possano essere [[instradamento|instradati]] alle loro destinazioni finali. Questa funzionalità è svolta da algoritmi di instradamento multicast dello strato della rete: [[Protocol Independent Multicast|PIM]], [[Distance Vector Multicast Routing Protocol|DVMRP]], [[Multicast Open Shortest Path First|MOSPF]].

Il protocollo attualmente è alla terza versione (IGMPv3) che ha introdotto un sostanziale cambiamento rispetto alle versioni precedenti per quanto riguarda il modello del multicast in Internet: infatti ora IGMP è compatibile col modello [[Source_specific_multicast|Source Specific Multicast (SSM)]], cioè gli host non sono più obbligati a ricevere dall’intero gruppo ma possono selezionare un sottoinsieme di sorgenti da cui ricevere. Il protocollo nella sua versione più recente è definito nell’RFC 3376.

== Indirizzi di gruppo ==

Riga 22:

== Overview protocollo ==

Il funzionamento di IGMP si basa su un modulo presente negli host e su un modulo presente nei router. Il primo svolge tutte le attività richieste ad un host che partecipa alla sessione multicast: gestione del proprio stato di ricezione, risposta alle query inviate dal Designated Router (DR) per quella LAN, invio triggered di report al DR quando lo stato di ricezione di un 'interfaccia cambia per informarlo del nuovo stato di ricezione. Il secondo a bordo di un router IGMP svolge, per ogni gruppo desiderato, funzionalità di gestione e tracciamento dello stato di ricezione degli host della LAN di cui è DR e regola l’inoltro dei pacchetti provenienti dalla struttura di instradamento sulla LAN, se è contemporaneamente DR IGMP e DR per il protocollo di routing usato, altrimenti suggerisce le regole di inoltro al router che è il DR per il protocollo di routing (in genere quindi un router deve avere a bordo sia il modulo per la membership che per il routing).

== Protocollo lato Host ==

Riga 53:

l’interfaccia ifc_i ricorda come filtro exclude e la lista di sorgenti sarà data da ({a,b,c,d} ∩ {b,c,d,e}) - {d,e,f} = {b,c,d} - {d,e,f} = {b,c}.

=== Messaggi scambiati: Query ===

Le query IGMP sono il modo con cui il Designated Router viene a conoscenza e rimane informato sullo stato di membership degli host nella LAN. Si differenziano tre tipi di query:

Riga 77:

* ''Source Address [1], ..... , Source Address [N]'' specificano ognuno l’indirizzo unicast IP di una sorgente per il guppo indicato nel campo Group Address. La lista di sorgenti è non vuota solo nelle Group And Source Specific Query.

=== Messaggi scambiati: Report ===

I report IGMP sono messaggi inviati dagli host al DR all’indirizzo 224.0.0.22 (IGMPv3_capable routers). Possono essere di due tipi:

Riga 105:

Tutti i messaggi IGMP devono stare in un pacchetto IP. Se il numero di sorgenti (che determina la lunghezza del messaggio) eccede la dimensione del pacchetto è necessario frammentare i report. In questo caso il comportamento è diverso a seconda del contenuto del campo Record_Type. Se è uno tra Mode_Is_Include, Change_To_Include_Mode oppure Source_List_Change allora è possibile frammentare su più pacchetti IP successivi, altrimenti (causa non additività del filtro exclude) l’host invia un solo pacchetto in cui inserisce più sorgenti possibili e le altre non vengono indicate. Lo standard suggerisce che le sorgenti indicate dovrebbero essere sempre le stesse nei report successivi. Dato che il filtro è exclude, questo significa che alcune sorgenti che in realtà non dovrebbero passare invece passano: l’ottica del multicast è che si preferisce far passare qualcosa in più in situazioni di incertezza piuttosto di correre il rischio di scontentare utenti paganti.

=== Cambio di stato dell'interfaccia ===

A seguito di direttive IPMulticastListen provenienti dai livelli superiori lo stato di ricezione per un particolare gruppo su una data interfaccia può cambiare. Come conseguenza, l’interfaccia interessata deve inviare il più prontamente possibile un unsolicited report al DR corrente per informarlo del cambiamento. Il DR provvederà quindi ad aggiornare il proprio stato per quel gruppo.

Riga 158:

* {source_record} è un insieme di coppie di valori < source_address, source_timer >, dove source_timer è rinfrescato ogni volta che la sorgente compare in un report.

Il group_timer è stato pensato per permettere al DR del protocollo di routing di tagliare traffico non più desiderato da alcun host quando il filtro corrente è exclude e il timer scade. Infatti exclude fa passare tutto il traffico tranne quello proveniente dalle sorgenti specificate nella lista: se il timer scade significa che nessun host in stato exclude ha provveduto a rinfrescare il proprio stato di ricezione (altrimenti almeno uno avrebbe inviato un report) e quindi con molta probabilità gli host non sono più interessati a ricevere dal gruppo. Allora il DR converte il filtro in include con le sole sorgenti che hanno associato un timer > 0, restringendo la quantità di traffico che viene inoltrata sulla LAN. Se ora anche per le sorgenti rimaste il DR vede scadere il timer, allora può dedurre con certezza che nessuno è più interessato a ricevere dal gruppo e può cancellare il record associato.

=== Struttura filtri Include ed Exclude ===