Appendix I. Internet Group Management Protocol (Protocole de gestion de groupe Internet)

Le protocole Internet Group Management Protocol (protocole de gestion de groupe Internet, IGMP) est utilisé par les hôtes IP pour signaler leurs appartenances aux groupes d'hôtes à tous les routeurs multicast immédiatement voisins. IGMP est un protocole asymétrique et est spécifié ici du point de vue d'un hôte, plutôt que d'un routeur multicast. (IGMP peut également être utilisé, de manière symétrique ou asymétrique, entre des routeurs multicast. Une telle utilisation n'est pas spécifiée ici.)

Comme ICMP, IGMP est une partie intégrante d'IP. Il doit être implémenté par tous les hôtes conformes au niveau 2 de la spécification de multidiffusion IP. Les messages IGMP sont encapsulés dans des datagrammes IP, avec un numéro de protocole IP de 2. Tous les messages IGMP concernant les hôtes ont le format suivant:

    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

Ce mémo spécifie la version 1 d'IGMP. La version 0 est spécifiée dans RFC-988 et est maintenant obsolète.

Type

Il existe deux types de message IGMP concernant les hôtes:

1 = Host Membership Query (requête d'appartenance d'hôte)
2 = Host Membership Report (rapport d'appartenance d'hôte)

Unused (inutilisé)

Champ inutilisé, mis à zéro lors de l'envoi, ignoré lors de la réception.

Checksum (somme de contrôle)

La somme de contrôle est le complément à un sur 16 bits de la somme en complément à un du message IGMP de 8 octets. Pour calculer la somme de contrôle, le champ de somme de contrôle est mis à zéro.

Group Address (adresse de groupe)

Dans un message Host Membership Query, le champ d'adresse de groupe est mis à zéro lors de l'envoi, ignoré lors de la réception.

Dans un message Host Membership Report, le champ d'adresse de groupe contient l'adresse de groupe d'hôtes IP du groupe signalé.

Description informelle du protocole

Les routeurs multicast envoient des messages Host Membership Query (ci-après appelés Queries) pour découvrir quels groupes d'hôtes ont des membres sur leurs réseaux locaux attachés. Les Queries sont adressées au groupe all-hosts (adresse 224.0.0.1) et portent un time-to-live IP de 1.

Les hôtes répondent à une Query en générant des Host Membership Reports (ci-après appelés Reports), signalant chaque groupe d'hôtes auquel ils appartiennent sur l'interface réseau depuis laquelle la Query a été reçue. Afin d'éviter une "implosion" de Reports concurrents et de réduire le nombre total de Reports transmis, deux techniques sont utilisées:

Lorsqu'un hôte reçoit une Query, plutôt que d'envoyer des Reports immédiatement, il démarre une minuterie de délai de rapport pour chacune de ses appartenances au groupe sur l'interface réseau de la Query entrante. Chaque minuterie est réglée sur une valeur différente, choisie aléatoirement entre zéro et D secondes. Lorsqu'une minuterie expire, un Report est généré pour le groupe d'hôtes correspondant. Ainsi, les Reports sont répartis sur un intervalle de D secondes au lieu de se produire tous en même temps.
Un Report est envoyé avec une adresse de destination IP égale à l'adresse de groupe d'hôtes signalée, et avec un time-to-live IP de 1, de sorte que les autres membres du même groupe sur le même réseau peuvent entendre le Report. Si un hôte entend un Report pour un groupe auquel il appartient sur ce réseau, l'hôte arrête sa propre minuterie pour ce groupe et ne génère pas de Report pour ce groupe. Ainsi, dans le cas normal, un seul Report sera généré pour chaque groupe présent sur le réseau, par l'hôte membre dont la minuterie de délai expire en premier. Notez que les routeurs multicast reçoivent tous les datagrammes IP multicast et n'ont donc pas besoin d'être adressés explicitement. Notez également que les routeurs n'ont pas besoin de savoir quels hôtes appartiennent à un groupe, seulement qu'au moins un hôte appartient à un groupe sur un réseau particulier.

Il existe deux exceptions au comportement décrit ci-dessus. Premièrement, si une minuterie de délai de rapport est déjà en cours d'exécution pour une appartenance à un groupe lorsqu'une Query est reçue, cette minuterie n'est pas réinitialisée à une nouvelle valeur aléatoire, mais est plutôt autorisée à continuer à fonctionner avec sa valeur actuelle. Deuxièmement, une minuterie de délai de rapport n'est jamais définie pour l'appartenance d'un hôte au groupe all-hosts (224.0.0.1), et cette appartenance n'est jamais signalée.

Si un hôte utilise un générateur de nombres pseudo-aléatoires pour calculer les délais de rapport, l'une des adresses IP individuelles propres de l'hôte doit être utilisée dans le cadre de la graine pour le générateur, afin de réduire les chances que plusieurs hôtes génèrent la même séquence de délais.

Un hôte doit confirmer qu'un Report reçu a la même adresse de groupe d'hôtes IP dans son champ de destination IP et son champ d'adresse de groupe IGMP, pour s'assurer que le propre Report de l'hôte n'est pas annulé par un Report reçu erroné. Un hôte doit discrètement rejeter tout message IGMP de type autre que Host Membership Query ou Host Membership Report.

Les routeurs multicast envoient des Queries périodiquement pour actualiser leur connaissance des appartenances présentes sur un réseau particulier. Si aucun Report n'est reçu pour un groupe particulier après un certain nombre de Queries, les routeurs supposent que ce groupe n'a pas de membres locaux et qu'ils n'ont pas besoin de transférer les multicasts d'origine distante pour ce groupe sur le réseau local. Les Queries sont normalement envoyées peu fréquemment (pas plus d'une fois par minute) afin de maintenir la surcharge IGMP sur les hôtes et les réseaux très faible. Cependant, lorsqu'un routeur multicast démarre, il peut émettre plusieurs Queries rapprochées afin de construire rapidement sa connaissance des appartenances locales.

Lorsqu'un hôte rejoint un nouveau groupe, il doit immédiatement transmettre un Report pour ce groupe, plutôt que d'attendre une Query, au cas où il serait le premier membre de ce groupe sur le réseau. Pour couvrir la possibilité que le Report initial soit perdu ou endommagé, il est recommandé de le répéter une ou deux fois après de courts délais. (Un moyen simple d'accomplir cela est d'agir comme si une Query avait été reçue pour ce groupe uniquement, en réglant la minuterie de délai de rapport aléatoire du groupe. Le diagramme de transition d'état ci-dessous illustre cette approche.)

Notez que, sur un réseau sans routeurs multicast présents, le seul trafic IGMP est le ou les Reports envoyés chaque fois qu'un hôte rejoint un nouveau groupe.

Diagramme de transition d'état

Le comportement IGMP est spécifié plus formellement par le diagramme de transition d'état ci-dessous. Un hôte peut être dans l'un des trois états possibles, par rapport à tout groupe d'hôtes IP unique sur toute interface réseau unique:

Non-Member state (état non-membre): lorsque l'hôte n'appartient pas au groupe sur l'interface. Il s'agit de l'état initial pour toutes les appartenances sur toutes les interfaces réseau. Il ne nécessite aucun stockage dans l'hôte.
Delaying Member state (état membre en attente): lorsque l'hôte appartient au groupe sur l'interface et a une minuterie de délai de rapport en cours d'exécution pour cette appartenance.
Idle Member state (état membre inactif): lorsque l'hôte appartient au groupe sur l'interface et n'a pas de minuterie de délai de rapport en cours d'exécution pour cette appartenance.

Il existe cinq événements significatifs qui peuvent provoquer des transitions d'état IGMP:

"join group" (rejoindre le groupe): se produit lorsque l'hôte décide de rejoindre le groupe sur l'interface. Il ne peut se produire que dans l'état Non-Member.
"leave group" (quitter le groupe): se produit lorsque l'hôte décide de quitter le groupe sur l'interface. Il ne peut se produire que dans les états Delaying Member et Idle Member.
"query received" (requête reçue): se produit lorsque l'hôte reçoit un message IGMP Host Membership Query valide. Pour être valide, le message Query doit avoir au moins 8 octets de long, avoir une somme de contrôle IGMP correcte et avoir une adresse de destination IP de 224.0.0.1. Une seule Query s'applique à toutes les appartenances sur l'interface depuis laquelle la Query est reçue. Elle est ignorée pour les appartenances dans l'état Non-Member ou Delaying Member.
"report received" (rapport reçu): se produit lorsque l'hôte reçoit un message IGMP Host Membership Report valide. Pour être valide, le message Report doit avoir au moins 8 octets de long, avoir une somme de contrôle IGMP correcte et contenir la même adresse de groupe d'hôtes IP dans son champ de destination IP et son champ d'adresse de groupe IGMP. Un Report ne s'applique qu'à l'appartenance au groupe identifié par le Report, sur l'interface depuis laquelle le Report est reçu. Il est ignoré pour les appartenances dans l'état Non-Member ou Idle Member.
"timer expired" (minuterie expirée): se produit lorsque la minuterie de délai de rapport pour le groupe sur l'interface expire. Il ne peut se produire que dans l'état Delaying Member.

Tous les autres événements, tels que la réception de messages IGMP invalides ou de messages IGMP autres que Query ou Report, sont ignorés dans tous les états.

Il existe trois actions possibles qui peuvent être prises en réponse aux événements ci-dessus:

"send report" (envoyer un rapport): pour le groupe sur l'interface.
"start timer" (démarrer la minuterie): pour le groupe sur l'interface, en utilisant une valeur de délai aléatoire entre 0 et D secondes.
"stop timer" (arrêter la minuterie): pour le groupe sur l'interface.

Dans le diagramme suivant, chaque arc de transition d'état est étiqueté avec l'événement qui provoque la transition et, entre parenthèses, toute action prise pendant la transition.

                          ________________
                         |                |
                         |                |
                         |                |
                         |                |
                   ----->|   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)

Le groupe all-hosts (adresse 224.0.0.1) est traité comme un cas spécial. L'hôte démarre dans l'état Idle Member pour ce groupe sur chaque interface, ne passe jamais à un autre état et n'envoie jamais de rapport pour ce groupe.

Paramètres du protocole

Le délai de rapport maximum, D, est de 10 secondes.