Appendix I. Internet Group Management Protocol (Protocollo di gestione dei gruppi Internet)

Il protocollo Internet Group Management Protocol (protocollo di gestione dei gruppi Internet, IGMP) viene utilizzato dagli host IP per segnalare le loro appartenenze ai gruppi di host a tutti i router multicast immediatamente adiacenti. IGMP è un protocollo asimmetrico ed è specificato qui dal punto di vista di un host, piuttosto che da quello di un router multicast. (IGMP può anche essere utilizzato, in modo simmetrico o asimmetrico, tra router multicast. Tale utilizzo non è specificato qui.)

Come ICMP, IGMP è parte integrante di IP. Deve essere implementato da tutti gli host conformi al livello 2 della specifica di multicasting IP. I messaggi IGMP sono incapsulati in datagrammi IP, con un numero di protocollo IP pari a 2. Tutti i messaggi IGMP riguardanti gli host hanno il seguente formato:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Type  |    Unused     |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version (Versione)

Questo memo specifica la versione 1 di IGMP. La versione 0 è specificata in RFC-988 ed è ora obsoleta.

Type (Tipo)

Ci sono due tipi di messaggi IGMP riguardanti gli host:

1 = Host Membership Query (query di appartenenza dell'host)
2 = Host Membership Report (rapporto di appartenenza dell'host)

Unused (non utilizzato)

Campo non utilizzato, impostato a zero durante l'invio, ignorato durante la ricezione.

Checksum (somma di controllo)

Il checksum è il complemento a uno a 16 bit della somma in complemento a uno del messaggio IGMP da 8 ottetti. Per calcolare il checksum, il campo del checksum viene impostato a zero.

Group Address (indirizzo di gruppo)

In un messaggio Host Membership Query, il campo dell'indirizzo di gruppo viene impostato a zero durante l'invio, ignorato durante la ricezione.

In un messaggio Host Membership Report, il campo dell'indirizzo di gruppo contiene l'indirizzo del gruppo di host IP del gruppo segnalato.

Descrizione informale del protocollo

I router multicast inviano messaggi Host Membership Query (di seguito chiamati Query) per scoprire quali gruppi di host hanno membri sulle loro reti locali collegate. Le Query sono indirizzate al gruppo all-hosts (indirizzo 224.0.0.1) e hanno un time-to-live IP di 1.

Gli host rispondono a una Query generando Host Membership Report (di seguito chiamati Report), segnalando ogni gruppo di host a cui appartengono sull'interfaccia di rete dalla quale è stata ricevuta la Query. Al fine di evitare una "implosione" di Report simultanei e ridurre il numero totale di Report trasmessi, vengono utilizzate due tecniche:

Quando un host riceve una Query, anziché inviare immediatamente i Report, avvia un timer di ritardo del rapporto per ciascuna delle sue appartenenze al gruppo sull'interfaccia di rete della Query in arrivo. Ogni timer viene impostato su un valore diverso, scelto casualmente tra zero e D secondi. Quando un timer scade, viene generato un Report per il gruppo di host corrispondente. Quindi, i Report vengono distribuiti su un intervallo di D secondi anziché verificarsi tutti contemporaneamente.
Un Report viene inviato con un indirizzo di destinazione IP uguale all'indirizzo del gruppo di host segnalato, e con un time-to-live IP di 1, in modo che altri membri dello stesso gruppo sulla stessa rete possano ascoltare il Report. Se un host ascolta un Report per un gruppo a cui appartiene su quella rete, l'host interrompe il proprio timer per quel gruppo e non genera un Report per quel gruppo. Quindi, nel caso normale, verrà generato un solo Report per ogni gruppo presente sulla rete, dall'host membro il cui timer di ritardo scade per primo. Si noti che i router multicast ricevono tutti i datagrammi IP multicast e quindi non hanno bisogno di essere indirizzati esplicitamente. Si noti anche che i router non hanno bisogno di sapere quali host appartengono a un gruppo, solo che almeno un host appartiene a un gruppo su una particolare rete.

Ci sono due eccezioni al comportamento descritto sopra. In primo luogo, se un timer di ritardo del rapporto è già in esecuzione per un'appartenenza a un gruppo quando viene ricevuta una Query, quel timer non viene reimpostato su un nuovo valore casuale, ma è invece autorizzato a continuare a funzionare con il suo valore attuale. In secondo luogo, un timer di ritardo del rapporto non viene mai impostato per l'appartenenza di un host al gruppo all-hosts (224.0.0.1), e tale appartenenza non viene mai segnalata.

Se un host utilizza un generatore di numeri pseudo-casuali per calcolare i ritardi dei rapporti, uno degli indirizzi IP individuali propri dell'host dovrebbe essere utilizzato come parte del seed per il generatore, al fine di ridurre le possibilità che più host generino la stessa sequenza di ritardi.

Un host dovrebbe verificare che un Report ricevuto abbia lo stesso indirizzo di gruppo di host IP nel suo campo di destinazione IP e nel suo campo di indirizzo di gruppo IGMP, per garantire che il proprio Report dell'host non venga annullato da un Report ricevuto erroneamente. Un host dovrebbe silenziosamente scartare qualsiasi messaggio IGMP di tipo diverso da Host Membership Query o Host Membership Report.

I router multicast inviano Query periodicamente per aggiornare la loro conoscenza delle appartenenze presenti su una particolare rete. Se non viene ricevuto alcun Report per un particolare gruppo dopo un certo numero di Query, i router presumono che quel gruppo non abbia membri locali e che non abbiano bisogno di inoltrare i multicast originati da remoto per quel gruppo sulla rete locale. Le Query vengono normalmente inviate raramente (non più di una volta al minuto) al fine di mantenere l'overhead IGMP sugli host e sulle reti molto basso. Tuttavia, quando un router multicast si avvia, può emettere diverse Query ravvicinate al fine di costruire rapidamente la sua conoscenza delle appartenenze locali.

Quando un host si unisce a un nuovo gruppo, dovrebbe immediatamente trasmettere un Report per quel gruppo, anziché attendere una Query, nel caso in cui sia il primo membro di quel gruppo sulla rete. Per coprire la possibilità che il Report iniziale venga perso o danneggiato, si raccomanda di ripeterlo una o due volte dopo brevi ritardi. (Un modo semplice per realizzare questo è agire come se fosse stata ricevuta una Query solo per quel gruppo, impostando il timer di ritardo del rapporto casuale del gruppo. Il diagramma di transizione di stato qui sotto illustra questo approccio.)

Si noti che, su una rete senza router multicast presenti, l'unico traffico IGMP è il Report o i Report inviati ogni volta che un host si unisce a un nuovo gruppo.

Diagramma di transizione di stato

Il comportamento IGMP è specificato più formalmente dal diagramma di transizione di stato qui sotto. Un host può trovarsi in uno dei tre possibili stati, rispetto a qualsiasi singolo gruppo di host IP su qualsiasi singola interfaccia di rete:

Non-Member state (stato non membro): quando l'host non appartiene al gruppo sull'interfaccia. Questo è lo stato iniziale per tutte le appartenenze su tutte le interfacce di rete. Non richiede alcuna memorizzazione nell'host.
Delaying Member state (stato membro in attesa): quando l'host appartiene al gruppo sull'interfaccia e ha un timer di ritardo del rapporto in esecuzione per quell'appartenenza.
Idle Member state (stato membro inattivo): quando l'host appartiene al gruppo sull'interfaccia e non ha un timer di ritardo del rapporto in esecuzione per quell'appartenenza.

Ci sono cinque eventi significativi che possono causare transizioni di stato IGMP:

"join group" (unisciti al gruppo): si verifica quando l'host decide di unirsi al gruppo sull'interfaccia. Può verificarsi solo nello stato Non-Member.
"leave group" (lascia il gruppo): si verifica quando l'host decide di lasciare il gruppo sull'interfaccia. Può verificarsi solo negli stati Delaying Member e Idle Member.
"query received" (query ricevuta): si verifica quando l'host riceve un messaggio IGMP Host Membership Query valido. Per essere valido, il messaggio Query deve essere lungo almeno 8 ottetti, avere un checksum IGMP corretto e avere un indirizzo di destinazione IP di 224.0.0.1. Una singola Query si applica a tutte le appartenenze sull'interfaccia dalla quale viene ricevuta la Query. Viene ignorata per le appartenenze nello stato Non-Member o Delaying Member.
"report received" (rapporto ricevuto): si verifica quando l'host riceve un messaggio IGMP Host Membership Report valido. Per essere valido, il messaggio Report deve essere lungo almeno 8 ottetti, avere un checksum IGMP corretto e contenere lo stesso indirizzo di gruppo di host IP nel suo campo di destinazione IP e nel suo campo di indirizzo di gruppo IGMP. Un Report si applica solo all'appartenenza nel gruppo identificato dal Report, sull'interfaccia dalla quale viene ricevuto il Report. Viene ignorato per le appartenenze nello stato Non-Member o Idle Member.
"timer expired" (timer scaduto): si verifica quando il timer di ritardo del rapporto per il gruppo sull'interfaccia scade. Può verificarsi solo nello stato Delaying Member.

Tutti gli altri eventi, come la ricezione di messaggi IGMP non validi o di messaggi IGMP diversi da Query o Report, vengono ignorati in tutti gli stati.

Ci sono tre possibili azioni che possono essere intraprese in risposta agli eventi sopra:

"send report" (invia rapporto): per il gruppo sull'interfaccia.
"start timer" (avvia timer): per il gruppo sull'interfaccia, utilizzando un valore di ritardo casuale tra 0 e D secondi.
"stop timer" (ferma timer): per il gruppo sull'interfaccia.

Nel diagramma seguente, ogni arco di transizione di stato è etichettato con l'evento che causa la transizione e, tra parentesi, qualsiasi azione intrapresa durante la transizione.

                          ________________
                         |                |
                         |                |
                         |                |
                         |                |
                   ----->|   Non-Member   |&lt;---------
                  |      |                |          |
                  |      |                |          |
                  |      |                |          |
                  |      |________________|          |
                  |               |                  |
                  | leave group   | join group       | leave group
                  | (stop timer)  |(send report,     |
                  |               | start timer)     |
          ________|________       |          ________|________
         |                 |&lt;-----          |                 |
         |                 |                |                 |
         |                 |&lt;---------------|                 |
         |                 |   query received   |                 |
         | Delaying Member |    (start timer)   |   Idle Member   |
         |                 |----------------->|                 |
         |                 |   report received  |                 |
         |                 |    (stop timer)    |                 |
         |_________________|----------------->|_________________|
                                timer expired
                                (send report)

Il gruppo all-hosts (indirizzo 224.0.0.1) viene trattato come un caso speciale. L'host inizia nello stato Idle Member per questo gruppo su ogni interfaccia, non passa mai a un altro stato e non invia mai un Report per questo gruppo.

Parametri del protocollo

Il ritardo massimo del rapporto, D, è di 10 secondi.