IGMP : ce qui se cache derrière l’Internet group ma­na­ge­ment protocol

Depuis le franc succès rencontré par les services de streaming, tels que Netflix ou Spotify, le multicast IP s’est imposé comme une méthode de trans­mis­sion in­dis­pen­sable sur Internet et dans les réseaux do­mes­tiques. En effet, ce processus technique permet à une personne expédiant des données d’envoyer des flux de données de façon ciblée à des groupes entiers de des­ti­na­taires, et d’exploiter ainsi ces capacités de transport et de routage de façon optimale. Sans cette méthode de trans­mis­sion, des paquets de données séparés devraient être envoyés à tous les appareils des­ti­na­taires, ce qui né­ces­si­te­rait une énorme bande passante et en­traî­ne­rait ra­pi­de­ment une surcharge. Il serait ainsi pra­ti­que­ment im­pos­sible de maintenir de façon durable la dis­po­ni­bi­lité des services offerts.

L’Internet group ma­na­ge­ment protocol (IGMP) est un protocole qui joue un rôle essentiel dans l’or­ga­ni­sa­tion des groupes de des­ti­na­taires multicast précités au sein de réseaux IPv4.

L'In­ter­net group ma­na­ge­ment protocol est un protocole de com­mu­ni­ca­tion ap­par­te­nant à la suite TCP/IP, développé à l’Uni­ver­sité de Stanford et spécifié pour la première fois en 1989 dans les requêtes RFC 1112. Cette première version du protocole IGMPv1 fut suivie par les versions révisées Igmpv2 (RFC 2236) et Igmpv3 (RFC 3376 ; RFC 4604). Chacune des versions est ré­tro­com­pa­tible, ce qui permet à un appareil Igmpv3 de supporter au­to­ma­ti­que­ment les versions 1 et 2. L’Internet group ma­na­ge­ment protocol est destiné ex­clu­si­ve­ment aux réseaux IPv4 – dans les réseaux IPv6, les fonctions d’IGMP sont assurées par le protocole similaire Multicast Listener Discovery (MLD).

La tâche prin­ci­pale d’IGMP est d’ad­mi­nis­trer les groupes dy­na­miques pour les trans­mis­sions IP multicast. Cette ad­mi­nis­tra­tion est effectuée à la fois par l’appareil émetteur lui-même et le routeur intégré qui, d’une part, reçoivent des machines des­ti­na­taires (ou des éventuels routeurs su­bor­don­nés) des requêtes d’adhésion à un groupe multicast donné et, d’autre part, relayent les messages IGMP aux routeurs su­bor­don­nés cor­res­pon­dants lorsqu’ils reçoivent des paquets de données multicast adaptés. Dans ce cas, la station émettrice ne reçoit aucune in­for­ma­tion sur les stations de des­ti­na­tion atteintes par le paquet de données envoyé, ainsi que sur leur nombre, étant donné qu’elle n'envoie qu'un seul paquet de données aux routeurs qui lui sont su­bor­don­nés.

Nous avons déjà précisé que l’émetteur du paquet n'était pas res­pon­sable de l'ad­mi­nis­tra­tion des groupes via IGMP. Mais l’hôte émetteur doit, comme toutes les autres stations im­pli­quées dans le réseau (y compris la station du des­ti­na­taire), être com­pa­tible avec les con­nexions multicast. La réception des requêtes client pour l’adhésion à un groupe multicast donné, ainsi que la no­ti­fi­ca­tion des clients dans le cas de flux de données multicast entrants est assurée par les dif­fé­rents routeurs du réseau situés entre l’émetteur et le des­ti­na­taire.

Pour y parvenir, l’Internet group ma­na­ge­ment protocol dispose, d’une part, de fonc­tion­na­li­tés per­met­tant à une station de notifier au routeur qui lui est affecté que l’adhésion à un groupe multicast doit être effectuée. D’autre part, le protocole permet au routeur de retenir les in­ter­faces sortantes des appareils des­ti­na­taires devant recevoir certains flux de données IP multicast afin de pouvoir envoyer des messages (rapports) de façon ciblée, dès réception des données cor­res­pon­dantes. Dans ce cadre, les groupes multicast se dis­tin­guent par des adresses spé­ci­fiques dans la plage 224.0.0.x. Dans la plupart des cas, le premier point de contact d’un appareil est le routeur Internet local, qui reçoit la requête d’adhésion et la re­trans­met au prochain nœud du réseau : en règle générale, le routeur du four­nis­seur d’accès Internet. Cette chaîne de com­mu­ni­ca­tion prend fin avec le routeur de l’ex­pé­di­teur du flux de données qui duplique le paquet IP si né­ces­saire lorsqu’il doit répondre à plusieurs in­ter­faces sortantes.

Les trois versions de l’Internet group ma­na­ge­ment protocol publiées ont de nombreux points communs. Par exemple, Igmpv2 et Igmpv3 ont enrichi avant tout la version pré­cé­dente de nouvelles fonc­tion­na­li­tés, tandis que les ca­rac­té­ris­tiques de base, telles que l’adresse du groupe pour les requêtes générales (0.0.0.0), ont été reprises sans mo­di­fi­ca­tion. Mais quelles amé­lio­ra­tions ont été apportées exac­te­ment ?

L’entête IGMP a donc une longueur totale de 64 bits. Les 8 premiers bits indiquent toujours la version du protocole IGMPv1, ainsi que le type de message. Ce champ (Type) peut être défini de deux façons : « 1 » (pour les requêtes d’adhésion) et « 2 » (pour les messages sur les flux de données multicast). Il est suivi par les bits 8 à 15 qui n’ont aucune fonction et se composent uni­que­ment de zéros. La fin du premier bloc de 32 bits constitue une somme de contrôle. S’il s’agit d’un paquet de messages IGMP, ce bloc est suivi de l’adresse du groupe de 32 bits. En revanche, dans le cas de requêtes d’adhésion, il est suivi d’une section composée uni­que­ment de zéros (adresse de groupe 0.0.0.0).

La version originale de cette suite de protocole n’indique pas quel routeur doit être utilisé pour les requêtes multicast (ceci est réglé par le protocole Multicast Routing Protocol).

L’entête commence comme celui de la première version, mais sans l'in­di­ca­tion du numéro de version. Les codes de type possibles sont « 0x11 » (pour les requêtes), « 0x16 » (pour les messages) et « 0x17 » (pour les messages Leave). Dans le cadre de la ré­tro­com­pa­ti­bi­lité, on trouve également le code « 0x12 » pour les messages IGMPv1. Les bits 8 à 15 se voient attribuer une fonction concrète dans Igmpv2, du moins pour les requêtes d’adhésion, et dé­fi­nis­sent le délai de réponse maximal autorisé. Ils sont suivis par la somme de contrôle (16 bits) et l’adresse de groupe (32 bits), qui prend à nouveau la forme ca­rac­té­ris­tique du protocole 0.0.0.0 pour les requêtes générales.

Igmpv2 instaure la règle suivante : le routeur ayant l’adresse IP la plus basse dans le sous-réseau est utilisé pour les requêtes multicast.

Les deux premières séquences de 32 bits sont iden­tiques à celles de l’entête IGMPv2 – type, délai de réponse maximal, somme de contrôle et adresse de groupe. La version Igmpv3 offre également la pos­si­bi­lité d'un échange avec d’anciennes versions du protocole : les hôtes disposent pour cela des codes « 0x12 » pour la version 1 et « 0x16 » pour la version 2. L’adresse de groupe est suivie par la séquence d’entête spé­ci­fique à la requête Igmpv3, dont les 32 premiers bits se composent comme suit :

• Res. : champ de 4 bits réservé, n’ayant aucune fonction et ne contenant que des zéros.
• S (Suppress Router-Side Pro­ces­sing) : champ S qui définit les routeurs sur la valeur « 1 », et signale qu’ils ne doivent pas tenir compte des mises à jour normales lors de la réception d’une requête. Si la valeur est « 0 », le champ est inactif.
• QRV (Querier’s Ro­bust­ness Variable) : 3 bits pouvant contenir la valeur « variable de ro­bus­tesse » utilisée par les hôtes re­qué­rants.
• QQIC (Querier’s Query Interval Code) : champ de 8 bits per­met­tant de spécifier l’in­ter­valle pour les requêtes IGMPV3.
• Nombre d’adresses source : nombre d’adresses source listées ci-après.

Ces in­di­ca­tions très spé­ci­fiques sont suivies de l’adresse source ou d’une liste d’adresses source in­di­vi­duelles (de 32 bits chacune), dans la mesure où plusieurs sources doivent être définies.

Con­trai­re­ment aux versions an­té­rieures, Igmpv3 permet à un hôte d’intégrer une tran­sac­tion unique d’un groupe et d’en quitter un autre – pour ce faire, Igmpv2 a besoin de deux messages séparés sup­plé­men­taires.

Le rôle d’IGMP est clai­re­ment défini : ce protocole de com­mu­ni­ca­tion est toujours utilisé lorsque des trans­mis­sions multicast sont né­ces­saires dans des réseaux IPv4 comme Internet. Les scénarios d’uti­li­sa­tion clas­siques sont par con­sé­quent les ap­pli­ca­tions en temps réel, qui se déroulent à travers des con­nexions mul­ti­points, par exemple des outils de con­fé­rence Web ou des services de streaming en direct. Dans ce cadre, tous les clients n'ont pas besoin de recevoir le flux de données né­ces­saire, ce qui en­traî­ne­rait ra­pi­de­ment une con­ges­tion du serveur de départ, et des nœuds de réseau en question.