IGMP: spiegazione dell’Internet Group Management Protocol

Con il grande successo dei servizi di streaming come Netflix o Spotify, l'IP multicasting è diventato un metodo di trasmissione indispensabile per Internet e le reti domestiche. Questa procedura tecnica consente al mittente di inviare flussi di dati specificamente a interi gruppi di destinatari, consentendo loro di utilizzare al meglio le capacità di trasporto e di instradamento. Senza questo metodo di trasmissione, il mittente sarebbe costretto a inviare pacchetti di dati separati ad ogni dispositivo destinatario, il che richiederebbe una larghezza di banda notevole e porterebbe rapidamente a una congestione, rendendo praticamente impossibile offrire il servizio senza interruzioni.

L'Internet Group Management Protocol (IGMP) è un protocollo che gioca un ruolo importante nell'organizzazione dei gruppi di destinatari multicast nelle reti IPv4.

L'Internet Group Management Protocol è un protocollo di comunicazione della famiglia TCP/IP, sviluppato presso la Stanford University e definito per la prima volta nel 1989 nell'RFC 1112. Questa prima versione del protocollo IGMPv1 è stata seguita dalle revisioni IGMPv2 (RFC 2236) e IGMPv3 (RFC 3376; RFC 4604). Le versioni sono sempre retrocompatibili, per cui un dispositivo IGMPv3 supporta automaticamente anche le versioni 1 e 2. L'Internet Group Management Protocol è unicamente responsabile delle reti IPv4, mentre per le reti IPv6 viene utilizzato il Multicast Listener Discovery (MLD).

Il compito fondamentale dell'IGMP è quello di gestire gruppi dinamici per trasmissioni IP multicast, dove questa gestione non avviene tramite il dispositivo trasmittente stesso, ma attraverso i router coinvolti. Questi router ricevono, da un lato, richieste dai dispositivi riceventi (o anche dai rispettivi router secondari) per l'adesione a un gruppo multicast specifico. Dall'altro inoltrano i messaggi IGMP ai rispettivi router primari se ricevono adeguati pacchetti di dati multicast. La stazione mittente non riceve alcuna informazione 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 responsabilità del mittente del pacchetto. Questo host di uscita deve, tuttavia, supportare le connessioni multicast, come d'altronde tutte le altre stazioni coinvolte nella rete (compreso il destinatario). L'accettazione delle richieste dei client per l'adesione 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 destinatario.

A questo scopo l'Internet Group Management Protocol offre, da una parte, funzioni che consentono a una stazione di informare il router assegnato che deve essere incluso in un gruppo multicast. D'altra parte, il protocollo consente ai router di ricordare le interfacce in uscita di quei dispositivi destinatari che devono ricevere determinati flussi di dati IP multicast, in modo che possano inviare notifiche mirate (report) non appena i dati corrispondenti vengono ricevuti.

I gruppi multicast sono caratterizzati da indirizzi specifici nell'intervallo 224.0.0.x. Nella maggior parte dei casi un dispositivo contatta innanzitutto 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 comunicazione termina al router del trasmettitore del flusso di dati che duplica il pacchetto IP se deve servire diverse interfacce in uscita.

Le tre versioni pubblicate dell'Internet Group Management Protocol hanno molto in comune. L'IGMPv2 e l'IGMPv3 offrono principalmente più funzioni rispetto al predecessore, ma le caratteristiche di base, come l'indirizzo di gruppo per le richieste generali (0.0.0.0), rimangono invariate. Ma come si presentano nel dettaglio le rispettive estensioni?

L'intestazione dell'IGMP ha quindi una lunghezza totale di 64 bit. I primi 8 bit indicano sempre la versione del protocollo IGMPv1 e il tipo di messaggio. Per questo campo (Type) ci sono le due possibilità "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 consistono 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'indirizzo di gruppo composto da 32 bit. Alle richieste di adesione è allegata una sezione contenente solo zeri (indirizzo di gruppo 0.0.0.0).

La versione originale della linea di protocollo non specifica di per sé quale router deve essere usato per le richieste multicast (che viene determinato dal Multicast Routing Protocol).

La riga di intestazione somiglia alla prima versione del protocollo, 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). Nell'ambito della retrocompatibilità, 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 definiscono il tempo di risposta massimo consentito. Seguono un checksum (16 bit) e l'indirizzo di gruppo (32 bit), che assumono la tipica forma di protocollo 0.0.0.0. per le richieste generali.

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

Le prime due sequenze a 32 bit sono identiche a quelle dell'intestazione IGMPv2: type, tempo massimo di risposta, somma di verifica e indirizzo di gruppo. Anche l'IGMPv3 è retrocompatibile con le vecchie versioni del protocollo: a tale scopo gli host hanno a disposizione i codici "0x12" per la versione 1 e "0x16" per la versione 2. Dopo l'indirizzo di gruppo inizia la parte di intestazione 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 Processing): il flag S imposta i router al valore "1" segnalando che dovrebbero sopprimere i normali aggiornamenti quando ricevono una richiesta. Se il valore è "0", il campo è inattivo.
• QRV (Querier’s Robustness Variable): 3 bit che possono contenere il valore della "variabile di robustezza", utilizzata dagli host richiedenti.
• QQIC (Querier’s Query Interval Code): campo a 8 bit per specificare l'intervallo per le richieste IGMPv3.
• Numero di indirizzi sorgente: numero di indirizzi sorgente, elencati successivamente.

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 differenza del suo predecessore, che richiede due messaggi separati per farlo, l'IGMPv3 permette a un host di abbandonare un gruppo e aderire a un altro in una singola transazione.

Il ruolo dell'IGMP è chiaramente definito: il protocollo di comunicazione viene sempre utilizzato dove sono richieste trasmissioni multicast in reti IPv4, come Internet. Lo scenario classico di utilizzo sono le applicazioni in tempo reale che eseguono connessioni multipunto, come gli strumenti per conferenze web o servizi di live streaming. Evitare di fornire a ogni client individualmente il flusso di dati richiesto è importante per evitare il sovraccarico del server di uscita e dei nodi di rete interessati.