AccueilđŸ‡«đŸ‡·Chercher

Internet Group Management Protocol

Internet Group Management Protocol (IGMP, Protocole de gestion de groupe Internet) est un protocole de communication qui permet à des routeurs IPv4 d'établir de façon dynamique des groupes de plusieurs hÎtes pour qu'ils puissent rejoindre des diffusions multipoint (multicast).

IGMP dans un réseau local : les hÎtes indiquent au routeur les groupes multicast auxquels ils souscrivent.

IGMP est utilisĂ© pour des applications oĂč beaucoup d'hĂŽtes rejoignent simultanĂ©ment un mĂȘme serveur, par exemple pour le streaming en direct ou les jeux en ligne massivement multijoueur.

IGMP est un protocole de couche rĂ©seau (couche no 3 du modĂšle OSI), au mĂȘme niveau que le protocole Internet (IP). Il est dĂ©fini pour les rĂ©seaux IPv4. La gestion du multicast pour IPv6 est effectuĂ©e par la fonction Multicast Listener Discovery (MLD) du protocole ICMPv6. D'un point de vue fonctionnel, MLDv1 Ă©quivaut Ă  IGMPv2 et MLDv2 est semblable Ă  IGMPv3.

Utilisation d'IGMP

IGMP est un protocole asymĂ©trique en ce sens que le comportement spĂ©cifiĂ© pour les hĂŽtes diffĂšre de celui des routeurs multicast. Toutefois, un routeur multicast pouvant s'abonner Ă  un groupe multicast au mĂȘme titre qu'un hĂŽte, les routeurs multicast doivent exĂ©cuter les deux parties du protocole.

IGMP est un protocole exĂ©cutĂ© entre les machines hĂŽtes d'un mĂȘme sous-rĂ©seau et les routeurs multicast de ce sous-rĂ©seau. Il permet Ă  une machine hĂŽte d'informer un de ces routeurs multicast sur ses abonnements en cours Ă  des groupes multicast. Les routeurs maintiennent la liste des groupes multicast pour lesquels des machines hĂŽtes leur ont rapportĂ© ĂȘtre abonnĂ©es. Une telle liste est maintenue pour chacun des sous-rĂ©seaux qu'un routeur multicast interconnecte et permet au routeur de dĂ©terminer les paquets IP multicast Ă  relayer sur ces sous-rĂ©seaux. Un paquet IP multicast est relayĂ© sur un sous-rĂ©seau si l'adresse de destination de ce paquet est celle d'un des groupes multicast associĂ©s Ă  ce sous-rĂ©seau.

Une source de trafic multicast n'est pas nécessairement membre d'un groupe, elle peut donc émettre un flux à destination du groupe sans signalisation préalable et sans prendre en charge IGMP. Sur une interface, les routeurs peuvent également forcer une souscription de type (*,G), c'est-à-dire indépendant de la source, ou encore Any Source Multicast (ASM), ou (S,G) (Source-Specific Multicast, SSM).

Fonctionnement d'IGMP

Plusieurs versions d'IGMP existent et diffÚrent en fonctionnalité. Seule la version 3 est de type SSM.

Toutes les versions d'IGMP utilisent le numéro de protocole 2 d'IP et fixent le champ Time to Live des paquets à 1, évitant ainsi leur propagation au-delà du sous-réseau qu'ils concernent. Les versions rencontrées actuellement sont les versions 2 et 3.

IGMP v0

IGMPv0 est défini dans la RFC 988[1], cette version est considérée comme obsolÚte.

IGMP v1

Format du paquet IGMPv1.

IGMPv1 est décrit dans la RFC 1112[2].

Il existe deux types de messages dans IGMPv1 : requĂȘte d'adhĂ©sion (membership query) et rapport d'adhĂ©sion (membership report).

Un routeur qui assure la transmission des paquets multicast sert de requĂ©rant (querier), c'est-Ă -dire qu'il Ă©met les requĂȘtes Ă  intervalle rĂ©gulier (toutes les 60 secondes par dĂ©faut).

Les hÎtes répondent en indiquant dans un rapport les groupes auxquels ils souscrivent. Pour éviter un flot de réponses simultanées, des rapports sont envoyés avec un délai aléatoire (compris entre 0 et 10 secondes par défaut). Si, pendant ce délai, un hÎte reçoit un rapport d'un autre hÎte concernant ce groupe, son message de souscription est supprimé.

Aucun rapport n'est envoyé pour le groupe 224.0.0.1 (All hosts).

La version est 1. Le type est 1 pour la requĂȘte et 2 pour le rapport.

Pour les requĂȘtes, l'adresse de destination est 224.0.0.1 (All hosts). Pour les rapports, l'adresse IP de destination est la mĂȘme que celle du groupe qu'il concerne.

Un hĂŽte qui souhaite joindre un groupe envoie un rapport sans attendre de requĂȘte.

Limitations d'IGMPv1
  • Il n'y a pas de message qui permet Ă  un hĂŽte d'indiquer qu'il quitte un groupe. Le requĂ©rant ne peut donc dĂ©terminer qu'un groupe ne dispose plus de membres sur un segment qu'aprĂšs un dĂ©lai gĂ©nĂ©ralement fixĂ© Ă  trois fois l'intervalle entre les requĂȘtes (c'est-Ă -dire trois minutes) et pendant lequel aucun rapport concernant ce groupe n'est reçu. Ceci peut poser des problĂšmes pour les flux multicast Ă  haut dĂ©bit, qui peuvent causer de la congestion au niveau de l'accĂšs au sous-rĂ©seau si un client passe rapidement d'un groupe Ă  un autre.
  • La RFC ne dit pas comment le requĂ©rant est choisi s'il existe plusieurs routeurs multicast dans le sous-rĂ©seau.

IGMP v2

Format du paquet IGMPv2.

RFC 2236[3] décrit la version 2 d'IGMP. C'est la version d'IGMP la plus répandue parmi les systÚmes d'exploitation généraux, elle est notamment prise en charge par Windows 98 et le noyau Linux 2.4[4].

Celle-ci corrige certaines limitations de la version 1, sont ajoutés :

  • une requĂȘte spĂ©cifique Ă  un groupe,
  • un mĂ©canisme d'Ă©lection d'un requĂ©rant,
  • le dĂ©lai maximal pour la rĂ©ponse est indiquĂ© dans la requĂȘte,
  • un message pour quitter le groupe.

Le champ Type englobe le champ version d'IGMPv1 et permet un certain niveau de rétrocompatibilité avec la version 1.

  • Une requĂȘte gĂ©nĂ©rale avec une valeur Type de 0x11 sera bien interprĂ©tĂ©e comme un message de requĂȘte par un hĂŽte qui ne prend en charge que la version 1. Une requĂȘte spĂ©cifique au groupe contient l'adresse du groupe.
  • La valeur Type 0x12 est utilisĂ©e pour la rĂ©trocompatibilitĂ©, il s'agit en rĂ©alitĂ© d'un rapport d'hĂŽte en version 1.
  • La valeur 0x16 est un rapport dans la version 2.
  • La valeur 0x17 (leave) est utilisĂ©e pour quitter un groupe.

Le champ Max Resp Time indique le temps maximal dont dispose un hĂŽte pour rĂ©pondre, en dixiĂšmes de secondes. Les hĂŽtes utilisent un dĂ©lai alĂ©atoire infĂ©rieur Ă  cette limite pour la rĂ©ponse et suppriment Ă©ventuellement les rapports comme en version 1. Le dĂ©lai maximal vaut 100 (10 secondes) pour une requĂȘte gĂ©nĂ©rale, et 10 (1 seconde) pour une requĂȘte spĂ©cifique Ă  un groupe.

La RFC indique qu'un hÎte « devrait » envoyer un message quitter quand il quitte un groupe, ceci implique que ce message n'est pas obligatoire. Ceci rend les optimisations telles que IGMP snooping particuliÚrement difficiles. Les implémentations du protocole utilisent cependant systématiquement ce message.

Processus pour quitter un groupe

Le message pour quitter un groupe est dirigé vers l'adresse 224.0.0.2 (All-routers). Quand le routeur requérant reçoit ce message, il envoie en réponse un message query spécifique au groupe quitté pour déterminer s'il subsiste un hÎte membre du groupe dans le sous-réseau. Si aucune réponse n'est reçue, le routeur considÚre qu'il n'existe plus d'abonnés au groupe. Ce message est généralement répété, de sorte que le délai pour qu'un groupe quitte un segment est situé entre 2 et 3 secondes par défaut.

Élection du requĂ©rant

Quand un routeur reçoit une requĂȘte provenant d'un autre routeur, il compare l'adresse IP source avec la sienne. Le routeur dont l'adresse est la plus basse est sĂ©lectionnĂ© comme requĂ©rant sur le segment. Quand un routeur reçoit une telle requĂȘte supĂ©rieure Ă  la sienne, il dĂ©marre un compteur de 250 secondes pendant lequel il s'abstient d'envoyer des requĂȘtes. Si aucun message d'un requĂ©rant avec une IP plus petite n'est reçu pendant cette pĂ©riode, les requĂȘtes sont Ă©mises Ă  nouveau.

Interopérabilité avec IGMP v1
  • Si un hĂŽte dĂ©tecte un requĂ©rant v1, il se comportera comme un hĂŽte IGMPv1 et Ă©mettra des rapports en format v1 pendant au moins 400 secondes. Un hĂŽte peut dĂ©terminer qu'il s'agit d'une requĂȘte v1 en examinant le contenu du champ Max Resp Time, s'il vaut 0, alors il s'agit en rĂ©alitĂ© du champ Unused en v1.
  • Un hĂŽte v1 rĂ©pondra aux requĂȘtes v2, cependant les rapports v2 ne seront pas interprĂ©tĂ©s correctement par les hĂŽtes v1 et seront donc ignorĂ©s par ces derniers. En prĂ©sence d'un mĂ©lange d'hĂŽtes v2 et v1, la suppression des rapports ne sera donc pas complĂštement efficace. D'autre part, le requĂ©rant doit ignorer les messages quitter d'un groupe s'il dĂ©tecte un hĂŽte v1 dans ce groupe.
Limitations d'IGMPv2

Les seuls états possibles sont de type (*,G), c'est-à-dire qu'il n'est pas possible à un hÎte d'indiquer qu'il ne souhaite recevoir un groupe que d'une source déterminée, ni exclure une source déterminée.

IGMP v3

Format de la requĂȘte IGMPv3 (Type=0x11).
Format du rapport IGMPv3 (Type=0x22).
Format de chacun des Group records.

La version 3 (RFC 3376[5]) ajoute la possibilité de spécifier une souscription à un groupe avec une source particuliÚre, ou à l'exclusion de certaines sources. La RFC précise que le champ ToS du paquet IP est fixé à 0xc0 (Internetwork Control) et que l'option Router Alert (RFC 2113[6]) est utilisée.

IGMPv3 est pris en charge par Linux Ă  partir de 2.6.7, par Windows XP, Cisco IOS 12.1(5)T et FreeBSD 8.0.

La suppression des rapports, dont la prise en charge est obligatoire pour les versions 1 et 2, est supprimĂ©e dans cette version. Ceci facilite le fonctionnement d'IGMP Snooping et permet de rĂ©duire la latence au moment oĂč le dernier membre quitte un groupe (fast leave).

Il existe deux types de messages IGMPv3 :

  • Type=0x11 : RequĂȘte
  • Type=0x22 : Rapport v3

Les champs type 0x12 (rapport v1), 0x16 (rapport v2) et 0x17 (quitter v2) doivent ĂȘtre pris en charge par une implĂ©mentation d'IGMP v3 pour la rĂ©trocompatibilitĂ©.

RequĂȘtes

Il existe trois types de requĂȘtes :

  • la requĂȘte gĂ©nĂ©rale : l'adresse de groupe est laissĂ©e vide, et N=0
  • la requĂȘte spĂ©cifique Ă  un groupe : l'adresse de groupe est indiquĂ©e, et N=0
  • la requĂȘte spĂ©cifique Ă  un groupe et Ă  des sources : l'adresse du groupe est indiquĂ©e, N≠0 et la liste des sources est fournie.

La requĂȘte gĂ©nĂ©rale est envoyĂ©e Ă  l'adresse 224.0.0.1 (All hosts), tandis que les requĂȘtes relatives Ă  des groupes sont envoyĂ©es Ă  l'adresse du groupe en question.

Le champ Max Resp Code est codé de la façon suivante :

  • s'il correspond Ă  un nombre infĂ©rieur Ă  128, il a le mĂȘme sens qu'en v2, c'est-Ă -dire des dixiĂšmes de secondes,
  • si le premier bit vaut 1, les trois bits suivants sont des bits d'exposant, tandis que les 4 bits suivants servent de mantisse, ce qui permet d'exprimer des valeurs plus Ă©levĂ©es, sachant que l’équation est (mant | 0x10) << (exp + 3), la valeur maximale est 111110000000000b en binaire, soit 31×2(7+3) = 31744 dixiĂšmes de seconde, soit un peu moins de 53 minutes, ce qui contribue Ă  limiter le flot des rĂ©ponses en prĂ©sence d'un grand nombre de membres dans un sous-rĂ©seau.

Le champ S, quand il est Ă  1, indique aux autres routeurs de ne pas tenir compte de ce message pour la mise Ă  jour de la minuterie.

Le champ QQIC (Querier's Query Interval Code) reprĂ©sente le dĂ©lai entre les requĂȘtes. Les routeurs qui sont non-requĂ©rants s'alignent sur cette valeur.

Le champ QRV (Querier's Robustness Variable) est une indication de la fiabilitĂ© de la transmission dans le sous-rĂ©seau. Les rapports et requĂȘtes sont retransmis en fonction de la valeur de ce champ.

Rapports

Les rapports indiquent les groupes et éventuellement les sources auxquels les hÎtes souscrivent. Ils sont envoyés à l'adresse 224.0.0.22 dédiée à IGMP v3. Deux modes sont possibles :

  • le mode d'inclusion, oĂč toutes les sources souhaitĂ©es sont indiquĂ©es,
  • le mode d'exclusion, oĂč toutes les sources sont souhaitĂ©es, sauf celles indiquĂ©es. La liste des sources exclues est Ă©ventuellement nulle, ce qui signifie que l'hĂŽte souscrit Ă  toutes les sources.

Conceptuellement, les routeurs tiennent à jour une table composées de tuples de la forme suivante :

(adresse multicast, minuterie de groupe, mode de filtrage, (liste des sources))

Chaque source est de la forme suivante :

(adresse source, minuterie de source)

Messages IGMP

Voici la liste des messages IGMP ainsi que leur adresse de destination.

G représente l'adresse du groupe concerné.

Version IGMPType de messageVersion/TypeAdresse destination
1requĂȘte0x11224.0.0.1
rapport0x12G
2requĂȘte0x11224.0.0.1
requĂȘte G0x11G
rapport0x16G
quitter0x17224.0.0.2
3requĂȘte0x11224.0.0.1
requĂȘte G0x11G
rapport0x22224.0.0.22
  • Rapport v2
    Rapport v2
  • Rapport v3
    Rapport v3

IGMP Snooping

La technique IGMP Snooping consiste, pour un commutateur Ethernet, Ă  optimiser la diffusion des trames multicast en observant le trafic IGMP.

Notes et références

  1. (en) Steve Deering, « Hosts extensions for IP Multicasting », Request for comments no 988, .
  2. (en) Steve Deering, « Host Extensions for IP Multicasting », Request for comments no 1112, .
  3. (en) William Fenner, « Internet Group Management Protocol, Version 2 », Request for comments no 2236, .
  4. Network Magic : Multicasting, UDP and IGMP
  5. (en) « Internet Group Management Protocol, Version 3 », Request for comments no 3376, .
  6. (en) D. Katz, « IP Router Alert option », Request for comments no 2113, .

Liens externes

Beau Williamson, Developing IP Multicast Networks, Cisco Press, , 568 p. (ISBN 1-57870-077-9, lire en ligne)

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.