Extensions d’hôte pour la diffusion groupée sur IP

1. Statut du présent mémoire

Le présent mémoire spécifie les extensions requises d’une mise en œuvre d’hôte du protocole Internet (IP) pour la prise en charge de la diffusion groupée (multicasting). Il est la norme recommandée pour la diffusion groupée sur l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.

2. Introduction

La diffusion groupée sur IP est la transmission d’un datagramme IP à un "groupe hôte", ensemble de zéro, un ou plusieurs hôtes identifiés par une seule adresse de destination IP. Un datagramme en diffusion groupée est délivré à tous les membres de son groupe hôte de destination avec la même fiabilité "au mieux" que les datagrammes IP en envoi individuel réguliers, c’est-à-dire qu’il n’est pas garanti que le datagramme arrive intact à tous les membres du groupe de destination ou dans le même ordre par rapport aux autres datagrammes.

L’appartenance à un groupe d’hôte est dynamique ; c’est à dire que les hôtes peuvent se joindre aux groupes et les quitter à tout moment. Il n’y a pas de restriction sur la localisation ou le nombre des membres dans un groupe d’hôtes. Un hôte peut être membre de plus d’un groupe à la fois. Un hôte n’a pas besoin d’être membre d’un groupe pour lui envoyer des datagrammes.

Un groupe d’hôtes peut être permanent ou transitoire. Un groupe permanent a une adresse IP bien connue, allouée administrativement. C’est l’adresse, et non l’adhésion au groupe, qui est permanente ; à tout moment, un groupe permanent peut avoir n’importe quel nombre de membres, même zéro. Ces adresses de diffusion groupée sur IP ne sont pas réservées aux groupes permanents et sont disponibles pour une allocation dynamique à des groupes transitoires qui n’existent que tant qu’ils ont des membres.

La transmission inter-réseau de datagrammes IP en diffusion groupée est traitée par des "routeurs de diffusion groupée" qui peuvent être co-résidents avec les passerelles internet, ou en être séparés. Un hôte transmet un datagramme IP en diffusion groupée comme une diffusion groupée de réseau local qui atteint tous les membres immédiatement voisins du groupe hôte de destination. Si le datagramme a une durée de vie IP supérieure à 1, le ou les routeurs de diffusion groupée rattachés au réseau local sont chargés de le transmettre vers tous les réseaux qui ont des membre du groupe de destination. Sur ces autres réseaux membres qui sont joignables pendant la durée de vie IP, un routeur de diffusion groupée rattaché achève la livraison en transmettant le datagramme comme une diffusion groupée locale.

Le présent mémoire spécifie les extensions requises pour qu’une mise en œuvre IP d’hôte prenne en charge la diffusion groupée sur IP, un "hôte" étant tout hôte ou passerelle internet autre que ceux agissant comme routeurs de diffusion groupée. Les algorithmes et protocoles utilisés au sein des routeurs de diffusion groupée et entre eux sont transparents aux hôtes et seront spécifiés dans des documents distincts. Le présent mémoire ne spécifie pas non plus comment la diffusion groupée de réseau local est accomplie pour tous les types de réseau, bien qu’il spécifie l’interface de service exigée pour un réseau local arbitraire et donne comme exemple une spécification Ethernet. Les spécifications pour les autres types de réseau feront l’objet d’autres mémoires à l’avenir.

3. Niveaux de conformité

Il y a trois niveaux de conformité à la présente spécification:

Niveau 0 : aucune prise en charge de la diffusion groupée sur IP.
Il n’y a, pour l’instant, aucune exigence que toutes les mises en œuvre IP prennent en charge la diffusion groupée sur IP. Les hôtes de niveau 0 ne vont, en général, pas être affectés par l’activité de diffusion groupée. La seule exception apparaît sur certains types de réseau local, où la présence d’hôtes de niveau 1 ou 2 peut causer la mauvaise livraison de datagrammes IP en diffusion groupée à des hôtes de niveau 0. De tels datagrammes peuvent facilement être identifiés par la présence d’une adresse IP de classe D dans leur champ d’adresse de destination ; ils devraient être éliminés en silence par les hôtes qui ne prennent pas en charge la diffusion groupée sur IP. Les adresses de classe D sont décrites à la Section 4 du présent mémoire.

Niveau 1 : prise en charge de l’envoi mais pas de la réception des datagrammes IP en diffusion groupée.
Le niveau 1 permet à un hôte de participer à certains services fondés sur la diffusion groupée, comme la localisation de ressource ou le rapport d’état, mais il ne permet pas à un hôte de se joindre à des groupes d’hôtes. Une mise en œuvre IP peut être promue très facilement du niveau 0 au niveau 1 et avec peu de nouveau code. Seules les sections 4, 5, et 6 de la présente spécification sont applicables aux mises en œuvre de niveau 1.

Niveau 2 : pleine prise en charge de la diffusion groupée sur IP.
Le niveau 2 permet à un hôte de se joindre à des groupes d’hôtes et de les quitter, ainsi que d’envoyer des datagrammes IP à des groupes d’hôtes. Il exige la mise en œuvre du protocole de gestion de groupe Internet (IGMP, Internet Group Management Protocol) et l’extension des interfaces IP et de service de réseau local au sein de l’hôte. Toutes les sections suivantes du présent mémoire sont applicables aux mises en œuvre de niveau 2.

4. Adresses de groupe d’hôte

Les groupes d’hôtes sont identifiés par des adresses IP de classe D, c’est-à-dire, celles qui comportent "1110" comme quatre bits de plus fort poids. Les adresses IP de classe E, c’est-à-dire, celles qui comportent "1111" comme quatre bits de plus fort poids, sont réservées pour des modes d’adressage futurs.

Dans la norme Internet, la notation "décimale séparée par des points" des adresses de groupe d’hôtes est dans la gamme de 224.0.0.0 à 239.255.255.255. L’adresse 224.0.0.0 est assurée de n’être pas allouée à un groupe quelconque, et 224.0.0.1 est alloué au groupe permanent de tous les hôtes IP (incluant les passerelles). Elles sont utilisée pour s’adresser à tous les hôtes en diffusion groupée sur le réseau connecté directement. Il n’y a pas d’adresse en diffusion groupée (ou d’autre adresse IP) pour tous les hôtes sur l’Internet total. Les adresses des autres groupes permanents bien connus seront publiées dans les "Numéros alloués".

L’Appendice II contient un exposé de fond sur plusieurs questions se rapportant aux adresses de groupes d’hôtes.

5. Modèle de mise en œuvre d’hôte IP

Les extensions de diffusion groupée à une mise en œuvre d’hôte IP spécifiées en termes de modèle en couche sont illustrées ci-dessous. Dans ce modèle, ICMP et (pour les hôtes de niveau 2) IGMP sont considérés comme mis en œuvre au sein du module IP, et la transposition des adresses IP en adresses de réseau local est considérée comme étant de la responsabilité des modules de réseau local. Le présent modèle n’est destiné qu’aux besoins de l’exposé, et ne devrait pas être vu comme imposant des obligations à une mise en œuvre réelle.

Pour fournir la diffusion groupée de niveau 1, une mise en œuvre d’hôte IP doit prendre en charge la transmission de datagrammes IP en diffusion groupée. Pour fournir la diffusion groupée de niveau 2, un hôte doit aussi prendre en charge la réception de datagrammes IP en diffusion groupée. Chacun de ces deux nouveaux services est décrit dans une section distincte, ci-dessous. Pour chaque service, les extensions sont spécifiées pour l’interface de service IP, le module IP, l’interface de service de réseau local, et pour un module de réseau local Ethernet. Les extensions pour des modules de réseau local autres qu’Ethernet sont mentionnées brièvement, mais ne sont pas spécifiées dans le détail.

6. Envoi des datagrammes IP en diffusion groupée

6.1. Extensions à l’interface de service IP

Les datagrammes IP en diffusion groupée sont envoyés en utilisant la même opération "Send IP" qu’utilisée pour envoyer des datagrammes IP en envoi individuel ; un module de protocole de couche supérieure spécifie simplement une adresse IP de groupe d’hôtes, plutôt qu’une adresse IP individuelle, comme destination. Cependant, un certain nombre d’extensions peuvent être nécessaires ou désirables.

Tout d’abord, l’interface de service devrait fournir un moyen pour que le protocole de couche supérieure spécifie la durée de vie IP d’un datagramme en diffusion groupée sortant, si une telle capacité n’existe pas déjà. Si le protocole de couche supérieure choisit de ne pas spécifier une durée de vie, il devrait fixer 1 par défaut pour tous les datagrammes IP en diffusion groupée, de sorte qu’un choix explicite est exigé pour faire une diffusion groupée au delà d’un seul réseau.

Ensuite, pour les hôtes qui peuvent être rattachés à plus d’un réseau, l’interface de service devrait fournir un moyen pour que le protocole de couche supérieure identifie quelle interface de réseau est utilisée pour la transmission en diffusion groupée. Une seule interface est utilisée pour la transmission initiale ; les routeurs de diffusion groupée sont chargés de la transmission à tous les autres réseaux, si nécessaire. Si le protocole de couche supérieure choisit de ne pas identifier une interface sortante, une interface par défaut devrait être utilisée, de préférence sous le contrôle de la gestion système.

Troisièmement (pour les mises en œuvre de niveau 2 seulement), pour les cas dans lesquels l’hôte est lui-même membre d’un groupe auquel est envoyé un datagramme, l’interface de service devrait fournir un moyen pour que le protocole de couche supérieure inhibe la livraison locale du datagramme ; par défaut, une copie du datagramme est renvoyée en boucle. Ceci est une optimisation de performance pour les protocoles de couche supérieure qui restreignent l’adhésion d’un groupe à un processus par hôte (comme les protocoles d’acheminement), ou qui traitent le renvoi en boucle de la communication de groupe à une couche supérieure (comme les protocoles de transport de diffusion groupée).

6.2 Extensions au module IP

Pour prendre en charge de l’envoi des datagrammes IP en diffusion groupée, le module IP doit être étendu pour reconnaître les adresses IP du groupe d’hôtes lors de l’acheminement des datagrammes sortants. La plupart des mises en œuvre IP incluent le programme suivant :

si la destination IP est sur le même réseau local,
envoyer le datagramme localement à la destination IP
autrement
envoyer le datagramme localement à GatewayTo( destination IP )

Pour permettre les transmissions en diffusion groupée, le programme d’acheminement doit être changé en :

si la destination IP est sur le même réseau local
ou si la destination IP est un groupe d’hôtes,
envoyer le datagramme localement à la destination IP
autrement
envoyer le datagramme localement à GatewayTo( destination IP )

Si l’hôte d’envoi est lui-même un membre du groupe de destination sur l’interface de sortie, une copie du datagramme sortant doit être renvoyée en boucle pour une livraison locale, sauf si c’est inhibé par l’envoyeur. (Seulement pour les mises en œuvre de niveau 2.)

L’adresse IP de source du datagramme sortant doit être une des adresses individuelles correspondant à l’interface de sortie.

Une adresse de groupe d’hôtes ne doit jamais être placée dans le champ d’adresse de source ou n’importe où ailleurs dans une option de route de source ou enregistrement de route d’un datagramme IP sortant.

6.3 Extensions à l’interface de service de réseau local

Aucun changement à l’interface de service de réseau local n’est exigé pour la prise en charge de l’envoi des datagrammes IP en diffusion groupée. Le module IP spécifie simplement une destination de groupe d’hôtes IP, au lieu d’une destination IP individuelle, lorsqu’il invoque l’opération "Send Local" existante.

6.4 Extensions à un module de réseau local Ethernet

Ethernet prend directement en charge l’envoi des paquets en diffusion groupée locale en permettant des adresses de diffusion groupée dans le champ de destination des paquets Ethernet. Tout ce qui est nécessaire pour prendre en charge l’envoi des datagrammes IP en diffusion groupée est une procédure pour la transposition des adresses IP des groupes d’hôtes en adresses de diffusion groupée Ethernet.

Une adresse IP de groupe d’hôtes est transposée en adresse de diffusion groupée Ethernet en plaçant les 23 bits de plus faible poids de l’adresse IP dans les 23 bits de plus faible poids de l’adresse de diffusion groupée Ethernet 01-00-5E-00-00-00 (hex). Parce qu’il y a 28 bits significatifs dans une adresse IP de groupe d’hôtes, plus d’une adresse de groupe d’hôtes peut correspondre à la même adresse de diffusion groupée Ethernet.

6.5 Extensions à des modules de réseau local autres qu’Ethernet

Les autres réseaux qui prennent directement en charge la diffusion groupée, comme les anneaux ou les bus conformes à la norme IEEE 802.2, peuvent être traités de la même façon qu’Ethernet pour l’envoi des datagrammes IP en diffusion groupée. Pour un réseau qui accepte la diffusion mais pas la diffusion groupée, comme l’Ethernet expérimental, toutes les adresses IP de groupe d’hôtes peuvent être transposées en une seule adresse de diffusion locale (au prix d’une redondance accrue chez les hôtes locaux). Pour une liaison point à point joignant deux hôtes (ou un hôte et un routeur de diffusion groupée), les diffusions groupées devraient être transmises exactement comme les envois individuels. Pour un réseau à traitement différé comme ARPANET ou un réseau X.25 public, toutes les adresses IP de groupe d’hôtes peuvent être transposées à l’adresse locale bien connue d’un routeur IP de diffusion groupée ; un routeur sur un tel réseau prendrait la responsabilité de l’achèvement de la livraison de la diffusion groupée au sein du réseau aussi bien que parmi les réseaux.

7. Réception de datagrammes IP en diffusion groupée

7.1. Extensions à l’interface de service IP

Les datagrammes IP en diffusion groupée entrants sont reçus par les modules de protocole de couche supérieure en utilisant la même opération "Receive IP" que pour les datagrammes en envoi individuel normaux. Le choix d’un protocole de couche supérieure de destination est fondé sur le champ de protocole dans l’en-tête IP, sans considération de l’adresse IP de destination. Cependant, avant qu’aucun datagramme destiné à un groupe particulier puisse être reçu, un protocole de couche supérieure doit demander au module IP de se joindre à ce groupe. Et donc, l’interface de service IP doit être étendue pour fournir deux nouvelles opérations :

JoinHostGroup ( adresse de groupe, interface )

LeaveHostGroup ( adresse de groupe, interface )

L’opération JoinHostGroup exige que cet hôte devienne membre du groupe d’hôtes identifié par "adresse de groupe" sur l’interface réseau en question. L’opération LeaveGroup exige que cet hôte abandonne son adhésion au groupe d’hôtes identifié par "adresse de groupe" sur l’interface réseau en question. L’argument de l’interface peut être omis sur les hôtes qui ne prennent en charge qu’une seule interface. Pour les hôtes qui peuvent être rattachés à plus d’un réseau, le protocole de couche supérieure peut choisir de quitter l’interface non spécifiée, auquel cas la demande s’applique à l’interface par défaut pour envoyer des datagrammes en diffusion groupée (voir le paragraphe 6.1).

Il est permis de se joindre au même groupe sur plus d’une interface, auquel cas des datagrammes en diffusion groupée dupliqués peuvent être reçus. Il est aussi permis que plus d’un protocole de couche supérieure demande l’adhésion au même groupe.

Les deux opérations devraient effectuer un retour immédiat (c’est-à-dire que ce sont des opérations non bloquantes), pour indiquer le succès ou l’échec. L’une ou l’autre opération peut échouer du fait d’une adresse de groupe ou d’un identifiant d’interface invalide. JoinHostGroup peut échouer à cause d’un manque de ressources locales. LeaveHostGroup peut échouer parce que l’hôte n’appartient pas au groupe en cause sur l’interface concernée. LeaveHostGroup peut réussir, mais l’adhésion persister, si plus d’un protocole de couche supérieure a demandé l’adhésion au même groupe.

7.2 Extensions au module IP

Pour prendre en charge la réception des datagrammes IP en diffusion groupée, le module IP doit être étendu pour maintenir une liste des adhésions aux groupes d’hôtes associés à chaque interface réseau. Un datagramme entrant destiné à un de ces groupes est traité exactement de la même façon que les datagrammes destinés à une des adresses individuelles de l’hôte.

Les datagrammes entrants destinés aux groupes auxquels n’appartient pas l’hôte sont éliminés sans générer de rapport d’erreur ou d’entrée de journal. Sur les hôtes qui ont plus d’une interface réseau, si un datagramme arrive via une interface, destiné à un groupe auquel l’hôte n’appartient que sur une interface différente, le datagramme est éliminé en silence. (Ces cas ne devraient survenir que par suite d’un filtrage inadéquat des adresses de diffusion groupée dans un module de réseau local.)

Un datagramme entrant n’est pas rejeté parce qu’il a une durée de vie IP de 1 (c’est-à-dire que la durée de vie ne devrait pas être automatiquement décrémentée à l’arrivée de datagrammes qui ne sont pas retransmis). Un datagramme entrant avec une adresse IP de groupe dans son champ d’adresse de source est supprimé en silence. Un message d’erreur ICMP (Destination injoignable, Temps excédé, Problème de paramètre, Source éteinte, ou Redirection) n’est jamais généré en réponse à un datagramme destiné à un groupe d’hôtes IP.

La liste des adhérents à un groupe d’hôtes est mise à jour en réponse aux demandes JoinHostGroup et LeaveHostGroup de la part des protocoles de couche supérieure. Chaque adhérent devrait avoir un compte de référence associé ou un mécanisme similaire pour traiter plusieurs demandes d’adhésion et de retrait du même groupe. À la première demande d’adhésion et à la dernière demande de quitter un groupe sur une interface donnée, le module de réseau local pour cette interface est notifié, de sorte qu’il puisse mettre à jour son filtre de réception de diffusion groupée (voir le paragraphe 7.3).

Le module IP doit aussi être étendu pour mettre en œuvre le protocole IGMP, spécifié à l’Appendice I. IGMP est utilisé pour tenir les routeurs de diffusion groupée voisins informés des adhérents de groupes d’hôtes présents sur un réseau local particulier. Pour prendre en charge IGMP, chaque hôte de niveau 2 doit se joindre au groupe "tous-hôtes" (adresse 224.0.0.1) sur chaque interface réseau au moment de l’initialisation et doit rester membre tant que l’hôte est actif.

(Les datagrammes adressés au groupe tous-hôtes sont reconnus comme un cas particulier par les routeurs de diffusion groupée et ne sont jamais retransmis au-delà d’un seul réseau, sans considération de leur durée de vie. Et donc, l’adresse tous-hôtes ne peut pas être utilisée comme adresse de diffusion pour l’ensemble de l’Internet. Pour les besoins d’IGMP, l’adhésion au groupe tous-hôtes n’est réellement nécessaire que lorsque l’hôte appartient au moins à un autre groupe. Cependant, il est spécifié que l’hôte doit tout le temps rester membre du groupe tous-hôtes parce que (1) c’est plus simple, (2) la fréquence de réception d’interrogations IGMP inutiles devrait être assez faible pour que la redondance soit négligeable, et (3) l’adresse tous-hôtes peut servir à d’autres besoins en rapport avec l’acheminement, comme de publier la présence des passerelles ou de résoudre les adresses locales.)

7.3. Extensions à l’interface de service de réseau local

Les paquets en diffusion groupée entrant sur le réseau local sont livrés au module IP en utilisant la même opération "Réception locale" que les paquets en envoi individuel sur réseau local. Pour permettre au module IP de dire au module de réseau local quels paquets en diffusion groupée accepter, l’interface de service du réseau local est étendue pour fournir deux nouvelles opérations :

JoinLocalGroup ( adresse de groupe )

LeaveLocalGroup ( adresse de groupe )

où "adresse de groupe" est une adresse IP de groupe d’hôtes. L’opération JoinLocalGroup exige que le module de réseau local accepte et délivre ensuite les paquets arrivants destinés à l’adresse IP du groupe d’hôtes concerné. L’opération LeaveLocalGroup exige du module de réseau local qu’il arrête de délivrer les paquets destinés à l’adresse IP du groupe d’hôtes concerné. Le module de réseau local est supposé transposer en tant que de besoin les adresses IP de groupe d’hôtes en adresses de réseau local pour mettre à jour son filtre de réception de diffusion groupée. Un module de réseau local a toute liberté pour ignorer les demandes LeaveLocalGroup, et il peut livrer les paquets destinés à plus d’adresses que ce qui est spécifié dans les demandes JoinLocalGroup, si il n’est pas capable de filtrer adéquatement les paquets entrants.

Le module de réseau local ne doit pas livrer de paquets en diffusion groupée transmis à partir de ce même module ; le rétro bouclage des diffusions groupées est traité à la couche IP ou plus haut.

7.4 Extensions à un module de réseau local Ethernet

Pour prendre en charge la réception de datagrammes IP en diffusion groupée, un module Ethernet doit être capable de recevoir des paquets adressés aux adresses de diffusion groupée Ethernet qui correspondent aux adresses IP du groupe d’hôtes de l’hôte. Il est vivement recommandé de tirer parti de toutes les capacités de filtrage d’adresse que peut avoir l’interface matérielle Ethernet, de sorte que l'hôte reçoive seulement les paquets qui lui sont destinés.

Malheureusement, de nombreuses interfaces Ethernet actuelles sont très limitées quant au nombre des adresses que le matériel peut être configuré à reconnaître. Néanmoins, une mise en œuvre doit être capable d’écouter sur un nombre arbitraire d’adresses de diffusion groupée Ethernet, ce qui peut vouloir dire "d’ouvrir" le filtre d’adresses pour accepter tous les paquets en diffusion groupée durant les périodes où le nombre des adresses excède la limite du filtre.

Pour les interfaces qui ont un matériel de filtrage d’adresse inadéquat, il serait souhaitable (pour des raisons de performance) d’effectuer le filtrage d’adresse Ethernet au sein du logiciel du module Ethernet. Ceci n’est cependant pas obligatoire, parce que le module IP effectue son propre filtrage sur la base des adresses de destination IP.

7.5 Extensions à des modules de réseau local autres qu’Ethernet

D’autres réseaux de diffusion groupée, tels que les réseaux IEEE 802.2, peuvent être traités de la même façon qu’Ethernet pour les besoins de la réception des datagrammes IP en diffusion groupée. Pour les réseaux de diffusion pure, comme l’Ethernet expérimental, tous les paquets en diffusion reçus peuvent être acceptés et passés au module IP pour le filtrage de niveau IP. Sur les réseaux en point à point ou en mode différé, les datagrammes IP en diffusion groupée vont arriver comme des envois individuels du réseau local, aussi aucun changement au module de réseau local ne devrait être nécessaire.

Appendice I Protocole de gestion de groupe sur Internet (IGMP)

Le protocole de gestion de groupe sur Internet (IGMP, Internet Group Management Protocol) est utilisé par les hôtes IP pour faire rapport de l’appartenance à des groupes d’hôtes à tous les routeurs de diffusion groupée de leur voisinage immédiat. IGMP est un protocole asymétrique et il est spécifié ici du point de vue d’un hôte, plutôt que du routeur de diffusion groupée. (IGMP peut aussi être utilisé, de façon symétrique ou asymétrique, entre les routeurs de diffusion groupée. Une telle utilisation n’est pas spécifiée ici.)

Comme ICMP, IGMP fait partie intégrante de IP. Sa mise en œuvre sur tous les hôtes conformes au niveau 2 de la spécification de diffusion groupée sur IP est exigée. Les messages IGMP sont encapsulés dans les datagrammes IP, avec un numéro de protocole IP de 2. Tous les messages IGMP qui concernent les hôtes ont le format suivant :

Version
Le présent mémoire spécifie la version 1 de IGMP. La version 0 est spécifiée dans la RFC 988 et est obsolète.

Type
Il y a deux types de message IGMP qui concernent les hôtes :
1 = Interrogation d’appartenance de l’hôte
2 = Rapport d’appartenance de l’hôte

Non utilisé
Champ inutilisé, mis à zéro à l’établissement, ignoré à réception.

Somme de contrôle
La somme de contrôle est la somme des compléments à un de 16 bits du message IGMP de 8 octets. Pour le calcul de la somme de contrôle, le champ de somme de contrôle est mis en zéros.

Adresse de groupe
Dans un message d’interrogation d’appartenance de l’hôte, le champ d’adresse de groupe est mis en zéros lors de l’envoi, et ignoré à réception.

Dans un message de rapport d’appartenance de l’hôte, le champ adresse de groupe détient l’adresse IP du groupe d’hôtes du groupe dont il est fait rapport.

Description informelle du protocole

Les routeurs de diffusion groupée envoient des messages d’interrogation d’appartenance de l’hôte (qu’on abrègera ci-après en interrogations) pour découvrir quels groupes d’hôtes ont des membres sur leurs réseaux locaux rattachés. Les interrogations sont adressées au groupe tous-hôtes (adresse 224.0.0.1), et portent une durée de vie IP de 1.

Les hôtes répondent à une interrogation en générant un rapport d’appartenance de l’hôte (qu’on abrègera ci-après en rapports), qui fait rapport de chaque groupe d’hôtes auquel ils appartiennent sur l’interface réseau de laquelle l’interrogation a été reçue. Afin d’éviter une "implosion" de rapports concurrents et de réduire le nombre total de rapports transmis, deux techniques sont utilisées :

1. Lorsque un hôte reçoit une interrogation, plutôt que d’envoyer immédiatement les rapports, il lance un temporisateur de retard de rapport pour chacune de ses adhésions de groupe sur l’interface réseau de l’interrogation entrante. Chaque temporisateur est réglé à une valeur différente, choisie au hasard entre zéro et D secondes. Lorsqu’un temporisateur arrive à expiration, un rapport est généré pour le groupe d’hôtes correspondant. Et donc, les rapports sont étalés sur un intervalle de D secondes au lieu de survenir tous en même temps.

2. Un rapport est envoyé avec une adresse de destination IP égale à l’adresse du groupe d’hôtes dont il est fait rapport, avec une durée de vie IP de 1, de sorte que les autres membres du même groupe sur le même réseau puissent avoir copie du rapport. Si un hôte entend un rapport pour un groupe auquel il n’appartient pas sur ce réseau, l’hôte arrête son propre temporisateur pour ce groupe et ne génère pas de rapport pour ce groupe. Et donc, dans le cas normal, un seul rapport sera généré pour chaque groupe présent sur le réseau, par l’hôte membre dont le temporisateur de retard arrive le premier à expiration. Noter que les routeurs de diffusion groupée reçoivent tous les datagrammes IP en diffusion groupée, et n’ont donc pas besoin d’être mis explicitement en destinataires. De plus, on notera que les routeurs n’ont pas besoin de savoir quels hôtes appartiennent à un groupe, mais seulement de savoir qu’au moins un hôte appartient à un groupe sur un réseau particulier.

Il y a deux exceptions au comportement décrit ci-dessus. D’abord, si un temporisateur de retard de rapport tourne toujours pour une adhésion à un groupe lorsqu’une interrogation est reçue, ce temporisateur n’est pas réinitialisé à une nouvelle valeur aléatoire, mais plutôt admis à poursuivre sa course avec la valeur actuelle. Ensuite, un temporisateur de retard de rapport n’est jamais établi pour l’adhésion d’un hôte dans le groupe tous-hôtes (224.0.0.1), et cette adhésion ne fait jamais l’objet d’un rapport.

Si un hôte utilise un générateur de nombres pseudo aléatoires pour calculer les délais de rapport, une des propres adresses IP individuelles de l’hôte devrait être utilisée comme partie du germe pour le générateur, pour réduire les chances que plusieurs hôtes génèrent la même séquence de retards.

Un hôte devrait confirmer qu’un rapport reçu a la même adresse IP de groupe d’hôtes dans son champ destination IP et son champ d’adresse de groupe IGMP, pour s’assurer que le propre rapport de l’hôte n'est pas annulé par un rapport erroné reçu. Un hôte devrait éliminer en silence tout message IGMP d’un type autre qu’une interrogation d’adhésion de l’hôte ou un rapport d’adhésion de l’hôte.

Les routeurs de diffusion groupée envoient périodiquement des interrogations pour rafraîchir leur connaissance des adhérents présents sur un réseau particulier. Si aucun rapport n’est reçu pour un groupe particulier après un certain nombre d’interrogations, les routeurs supposent que ce groupe n’a pas de membre local et qu’il n’a pas besoin de transmettre des diffusions groupées d’origine distante pour ce groupe sur le réseau local. Les interrogations sont normalement envoyées peu fréquemment (pas plus d’une fois par minute) de façon à garder très faible la redondance IGMP sur les hôtes et les réseaux. Cependant, lorsqu’un routeur de diffusion groupée démarre, il peut produire plusieurs interrogations très rapprochées afin de construire rapidement ses connaissances sur les adhésions locales.

Lorsqu’un hôte rejoint un nouveau groupe, il devrait immédiatement transmettre un rapport pour ce groupe, plutôt que d’attendre une interrogation, pour le cas où il serait le premier membre de ce groupe sur le réseau. Pour couvrir la possibilité que le rapport initial soit perdu ou endommagé, il est recommandé de le répéter une fois ou deux après un court délai. (Un façon simple de le faire est d’agir comme si une interrogation avait été reçue seulement pour ce groupe, en réglant le temporisateur de retard de rapport du groupe. Le diagramme de transition d’états ci-dessous illustre cette approche.)

Noter que sur un réseau où aucun routeur de diffusion groupée n’est présent, le seul trafic IGMP est le ou les rapports envoyés chaque fois qu’un hôte rejoint un nouveau groupe.

Diagramme de transition d’états

Le comportement IGMP est plus formellement spécifié par le diagramme de transitions d’état ci-dessous. Un hôte peut être dans un des trois états possibles, par rapport à tout groupe d’hôtes IP unique ou toute interface réseau unique :
- état de non membre, lorsque l’hôte n’appartient pas au groupe sur l’interface. C’est l’état initial pour toutes les adhésions sur toutes les interfaces réseau ; il n’exige aucune mémorisation chez l’hôte.
- état de membre en attente, lorsque l’hôte appartient au groupe sur l’interface et a un temporisateur de retard de rapport en cours pour cette adhésion.
- état de membre au repos, lorsque l’hôte appartient au groupe sur l’interface et n’a pas de temporisateur de retard de rapport en cours pour cette adhésion.

Il y a cinq événements significatifs qui peuvent causer des transitions d’état IGMP :
- "se joindre au groupe" survient lorsque l’hôte décide de se joindre au groupe sur l’interface. Il ne peut survenir que dans l’état de non membre.
- "quitter le groupe" survient lorsque l’hôte décide de quitter le groupe sur l’interface. Il ne peut survenir que dans les états de membre en attente et de membre au repos.
- "interrogation reçue" survient lorsque l’hôte reçoit un message IGMP d’interrogation d’adhésion de l’hôte valide. Pour être valide, le message d’interrogation doit être long d’au moins 8 octets, avoir une somme de contrôle IGMP correcte et avoir une adresse de destination IP de 224.0.0.1. Une seule interrogation s’applique à toutes les adhésions sur l’interface d’où l’interrogation a été reçue. Elle est ignorée pour les adhésions dans les états non membre ou membre en attente.
- "rapport reçu" survient lorsque l’hôte reçoit un message IGMP de rapport d’adhésion d’hôte valide. Pour être valide, le message de rapport doit être long d’au moins 8 octets, avoir une somme de contrôle IGMP correcte, et contenir la même adresse IP de groupe d’hôtes dans son champ de destination IP et dans son champ d’adresse de groupe IGMP. Un rapport ne s’applique qu’aux adhésions au groupe identifié par le rapport, sur l’interface d’où le rapport a été reçu. Il est ignoré pour les adhésions dans les états non membre ou membre au repos.
- "temporisateur expiré" survient lorsque expire le temporisateur de retard de rapport pour le groupe sur l’interface. Il ne peut survenir que dans l’état de membre en attente.

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

Il y a trois actions possibles qui peuvent être entreprises en réponse aux événements ci-dessus :
- "envoyer le rapport" pour le groupe sur l’interface.
- "lancer le temporisateur" pour le groupe sur l’interface, en utilisant une valeur de retard aléatoire entre 0 et D secondes.
- "arrêter le temporisateur" pour le groupe sur l’interface.
Dans le diagramme ci-dessous, chaque arc de transition d’état est marqué avec l’événement qui cause la transition, et, entre parenthèses, toute action entreprise durant la transition.

Le groupe tous-hôtes (adresse 224.0.0.1) est traité comme un cas particulier. L’hôte commence dans l’état de membre au repos pour ce groupe sur toute interface, ne passe jamais à un autre état, et n’envoie jamais un rapport pour ce groupe.

Paramètres du protocole

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

APPENDICE II Problèmes des adresses de groupe des hôtes

Cet appendice ne fait pas partie de la spécification de la diffusion groupée sur IP, mais fournit un exposé de base sur plusieurs questions en rapport avec les adresses IP de groupe d’hôtes.

Liaison d’adresse de groupe

La liaison des adresses IP de groupe d’hôtes à des hôtes physiques peut être considérée comme une généralisation de la liaison des adresses IP en envoi individuel. Une adresse IP en envoi individuel est liée statiquement à une seule interface de réseau local sur un seul réseau IP. Une adresse IP de groupe d’hôtes est liée dynamiquement à un ensemble d’interfaces de réseau local sur un ensemble de réseaux IP.

Il est important de comprendre qu’une adresse IP de groupe d’hôtes N’EST PAS liée à un ensemble d’adresses IP en envoi individuel. Les routeurs de diffusion groupée n’ont pas besoin d’entretenir une liste des membres individuels de chaque groupe d’hôtes. Par exemple, un routeur de diffusion groupée rattaché à un Ethernet n’a besoin de s’associer qu’à une seule adresse Ethernet de diffusion groupé avec chaque groupe d’hôtes ayant des membres locaux, plutôt qu’à une liste des adresses IP ou des adresses Ethernet des membres individuels.

Allocation des adresses de groupe transitoire d’hôte

Le présent mémoire ne spécifie pas comment les adresses de groupe transitoire sont allouées. On prévoit que différentes portions de l’espace d’adresse IP de groupe d’hôtes transitoire seront allouées en utilisant différentes techniques. Par exemple, il peut y avoir un certain nombre de serveurs qui peuvent être contactés pour acquérir une nouvelle adresse de groupe transitoire. Des protocoles de couche supérieure (tels que VMTP, spécifié dans la RFC 1045) peuvent générer des adresses "process group" ou "entity group" transitoires de niveau supérieur qui sont alors algorithmiquement transposées en un sous ensemble des adresses IP de groupe d’hôtes transitoire, de façon similaire à celle dont les adresses IP de groupe d’hôtes sont transposées en adresses Ethernet de diffusion groupée. Une portion de l’espace d’adresse IP de groupe peut être laissée de côté pour une allocation aléatoire par les applications qui peuvent tolérer des collisions occasionnelles avec d’autres usager de diffusion groupée, générant peut-être de nouvelles adresses jusqu’à ce qu’on en trouve une convenablement "tranquille".

En général, un hôte ne peut pas supposer que les datagrammes envoyés à toute adresse de groupe d’hôtes ne va atteindre que les hôtes prévus, ni que les datagrammes reçus en tant que membre d’un groupe d’hôtes transitoire sont destinés au receveur. La mauvaise livraison doit être détectée au niveau au-dessus de IP, en utilisant des identifiant de niveau supérieur ou des jetons d’authentification. Les informations transmises à une adresse de groupe d’hôtes devraient être chiffrées ou gouvernées par des contrôles administratifs d’acheminement si les receveurs imprévus posent un problème à l’envoyeur.

Adresse de l’auteur

Steve Deering
Stanford University
Computer Science Department
Stanford, CA 94305-2140
téléphone : (415) 723-9427
mél : deering@PESCADERO.STANFORD.EDU