IGMP: spie­ga­zio­ne dell’Internet Group Ma­na­ge­ment Protocol

Con il grande successo dei servizi di streaming come Netflix o Spotify, l'IP mul­ti­ca­sting è diventato un metodo di tra­smis­sio­ne in­di­spen­sa­bi­le per Internet e le reti do­me­sti­che. Questa procedura tecnica consente al mittente di inviare flussi di dati spe­ci­fi­ca­men­te a interi gruppi di de­sti­na­ta­ri, con­sen­ten­do loro di uti­liz­za­re al meglio le capacità di trasporto e di in­stra­da­men­to. Senza questo metodo di tra­smis­sio­ne, il mittente sarebbe costretto a inviare pacchetti di dati separati ad ogni di­spo­si­ti­vo de­sti­na­ta­rio, il che ri­chie­de­reb­be una larghezza di banda notevole e por­te­reb­be ra­pi­da­men­te a una con­ge­stio­ne, rendendo pra­ti­ca­men­te im­pos­si­bi­le offrire il servizio senza in­ter­ru­zio­ni.

L'In­ter­net Group Ma­na­ge­ment Protocol (IGMP) è un pro­to­col­lo che gioca un ruolo im­por­tan­te nell'or­ga­niz­za­zio­ne dei gruppi di de­sti­na­ta­ri multicast nelle reti IPv4.

L'In­ter­net Group Ma­na­ge­ment Protocol è un pro­to­col­lo di co­mu­ni­ca­zio­ne della famiglia TCP/IP, svi­lup­pa­to presso la Stanford Uni­ver­si­ty e definito per la prima volta nel 1989 nell'RFC 1112. Questa prima versione del pro­to­col­lo IGMPv1 è stata seguita dalle revisioni IGMPv2 (RFC 2236) e IGMPv3 (RFC 3376; RFC 4604). Le versioni sono sempre re­tro­com­pa­ti­bi­li, per cui un di­spo­si­ti­vo IGMPv3 supporta au­to­ma­ti­ca­men­te anche le versioni 1 e 2. L'In­ter­net Group Ma­na­ge­ment Protocol è uni­ca­men­te re­spon­sa­bi­le delle reti IPv4, mentre per le reti IPv6 viene uti­liz­za­to il Multicast Listener Discovery (MLD).

Il compito fon­da­men­ta­le dell'IGMP è quello di gestire gruppi dinamici per tra­smis­sio­ni IP multicast, dove questa gestione non avviene tramite il di­spo­si­ti­vo tra­smit­ten­te stesso, ma at­tra­ver­so i router coinvolti. Questi router ricevono, da un lato, richieste dai di­spo­si­ti­vi riceventi (o anche dai ri­spet­ti­vi router secondari) per l'adesione a un gruppo multicast specifico. Dal­l'al­tro inoltrano i messaggi IGMP ai ri­spet­ti­vi router primari se ricevono adeguati pacchetti di dati multicast. La stazione mittente non riceve alcuna in­for­ma­zio­ne su quali e quante stazioni finali un pacchetto inviato raggiunge, poiché inoltra un singolo pacchetto di dati al suo router primario.

Come accennato, la gestione di un gruppo tramite IGMP non è di re­spon­sa­bi­li­tà del mittente del pacchetto. Questo host di uscita deve, tuttavia, sup­por­ta­re le con­nes­sio­ni multicast, come d'al­tron­de tutte le altre stazioni coinvolte nella rete (compreso il de­sti­na­ta­rio). L'ac­cet­ta­zio­ne delle richieste dei client per l'a­de­sio­ne a un gruppo multicast specifico e la notifica ai client in caso di flussi di dati multicast in entrata vengono gestite dai singoli router di rete, che si trovano tra il mittente e il de­sti­na­ta­rio.

A questo scopo l'In­ter­net Group Ma­na­ge­ment Protocol offre, da una parte, funzioni che con­sen­to­no a una stazione di informare il router assegnato che deve essere incluso in un gruppo multicast. D'altra parte, il pro­to­col­lo consente ai router di ricordare le in­ter­fac­ce in uscita di quei di­spo­si­ti­vi de­sti­na­ta­ri che devono ricevere de­ter­mi­na­ti flussi di dati IP multicast, in modo che possano inviare notifiche mirate (report) non appena i dati cor­ri­spon­den­ti vengono ricevuti.

I gruppi multicast sono ca­rat­te­riz­za­ti da indirizzi specifici nel­l'in­ter­val­lo 224.0.0.x. Nella maggior parte dei casi un di­spo­si­ti­vo contatta in­nan­zi­tut­to il router Internet domestico che riceve la richiesta di adesione e la inoltra al nodo di rete più vicino, in genere il router dell'ISP. Questa catena di co­mu­ni­ca­zio­ne termina al router del tra­smet­ti­to­re del flusso di dati che duplica il pacchetto IP se deve servire diverse in­ter­fac­ce in uscita.

Le tre versioni pub­bli­ca­te del­l'In­ter­net Group Ma­na­ge­ment Protocol hanno molto in comune. L'IGMPv2 e l'IGMPv3 offrono prin­ci­pal­men­te più funzioni rispetto al pre­de­ces­so­re, ma le ca­rat­te­ri­sti­che di base, come l'in­di­riz­zo di gruppo per le richieste generali (0.0.0.0), rimangono invariate. Ma come si pre­sen­ta­no nel dettaglio le ri­spet­ti­ve esten­sio­ni?

L'in­te­sta­zio­ne dell'IGMP ha quindi una lunghezza totale di 64 bit. I primi 8 bit indicano sempre la versione del pro­to­col­lo IGMPv1 e il tipo di messaggio. Per questo campo (Type) ci sono le due pos­si­bi­li­tà "1" (per le richieste di adesione) e "2" (per le notifiche di flussi di dati multicast). Seguono i bit da 8 a 15, che non hanno alcuna funzione e con­si­sto­no solo di zeri. Una somma di controllo conclude il primo blocco a 32 bit. Se si tratta di un pacchetto di notifica IGMP, segue l'in­di­riz­zo di gruppo composto da 32 bit. Alle richieste di adesione è allegata una sezione con­te­nen­te solo zeri (indirizzo di gruppo 0.0.0.0).

La versione originale della linea di pro­to­col­lo non specifica di per sé quale router deve essere usato per le richieste multicast (che viene de­ter­mi­na­to dal Multicast Routing Protocol).

La riga di in­te­sta­zio­ne somiglia alla prima versione del pro­to­col­lo, ma non specifica il numero della versione. I codici possibili del tipo sono "0x11" (per le richieste), "0x16" (per le notifiche) e "0x17" (per i leave message). Nel­l'am­bi­to della re­tro­com­pa­ti­bi­li­tà, c'è anche il codice "0x12" per le notifiche IGMPv1. I bit da 8 a 15 ottengono una funzione concreta in IGMPv2, almeno per quanto riguarda le richieste di adesione, e de­fi­ni­sco­no il tempo di risposta massimo con­sen­ti­to. Seguono un checksum (16 bit) e l'in­di­riz­zo di gruppo (32 bit), che assumono la tipica forma di pro­to­col­lo 0.0.0.0. per le richieste generali.

L'IGMPv2 specifica la regola secondo cui il router con l'in­di­riz­zo IP più basso nella sottorete viene usato per le richieste multicast.

Le prime due sequenze a 32 bit sono identiche a quelle del­l'in­te­sta­zio­ne IGMPv2: type, tempo massimo di risposta, somma di verifica e indirizzo di gruppo. Anche l'IGMPv3 è re­tro­com­pa­ti­bi­le con le vecchie versioni del pro­to­col­lo: a tale scopo gli host hanno a di­spo­si­zio­ne i codici "0x12" per la versione 1 e "0x16" per la versione 2. Dopo l'in­di­riz­zo di gruppo inizia la parte di in­te­sta­zio­ne specifica della richiesta IGMPv3, i cui primi 32 bit sono composti come segue:

• Res.: campo riservato a 4 bit che non ha funzioni e contiene solo zeri.
• S (Suppress Router-Side Pro­ces­sing): il flag S imposta i router al valore "1" se­gna­lan­do che do­vreb­be­ro sop­pri­me­re i normali ag­gior­na­men­ti quando ricevono una richiesta. Se il valore è "0", il campo è inattivo.
• QRV (Querier’s Ro­bust­ness Variable): 3 bit che possono contenere il valore della "variabile di ro­bu­stez­za", uti­liz­za­ta dagli host ri­chie­den­ti.
• QQIC (Querier’s Query Interval Code): campo a 8 bit per spe­ci­fi­ca­re l'in­ter­val­lo per le richieste IGMPv3.
• Numero di indirizzi sorgente: numero di indirizzi sorgente, elencati suc­ces­si­va­men­te.

Questi dati molto specifici sono seguiti dall'indirizzo sorgente o da un elenco dei singoli indirizzi sorgente (32 bit ciascuno) se devono essere definite più fonti.

A dif­fe­ren­za del suo pre­de­ces­so­re, che richiede due messaggi separati per farlo, l'IGMPv3 permette a un host di ab­ban­do­na­re un gruppo e aderire a un altro in una singola tran­sa­zio­ne.

Il ruolo dell'IGMP è chia­ra­men­te definito: il pro­to­col­lo di co­mu­ni­ca­zio­ne viene sempre uti­liz­za­to dove sono richieste tra­smis­sio­ni multicast in reti IPv4, come Internet. Lo scenario classico di utilizzo sono le ap­pli­ca­zio­ni in tempo reale che eseguono con­nes­sio­ni mul­ti­pun­to, come gli strumenti per con­fe­ren­ze web o servizi di live streaming. Evitare di fornire a ogni client in­di­vi­dual­men­te il flusso di dati richiesto è im­por­tan­te per evitare il so­vrac­ca­ri­co del server di uscita e dei nodi di rete in­te­res­sa­ti.