Evolution du fonctionnement d IGMP

Evolution du fonctionnement d IGMP I/ Introduction Le multicast sur IP est la possibilité de pouvoir transmettre un datagramme IP non pas un hôte isole (l'unicast) mais a tout un groupe d'hôtes en évitant d'inonder le réseau (le broadcast). Le paquet IP sera délivré aux sources avec la même approche "best effort" (== «au mieux» cela signifie que le datagramme n'est pas assure d arriver intact ou bien que le séquencement des paquets n'est pas assuré...) a chaque hôte. Un groupe d'hôtes est dynamique; chaque participant peut a sa guise joindre ou quitter un groupe déjà existant... Le groupe est caractérisé par le fait que tous les hôtes d'un même groupe écoutent tous la même adresse IP multicast (adresse typique de classe D). Afin d'acheminer les paquets jusqu aux hôtes, le multicast repose sur deux grands types de protocoles : l'un qui va permettre la communication entre l'hôte appartenant au groupe multicast et le routeur local (appelé aussi routeur de bordure) et l'autre permettant d'acheminer le paquet entre les différents routeurs formant le réseau. Le but de ce devoir est de présenter IGMP en vulgarisant son mode de fonctionnement, nous verrons dans quel catégorie de protocoles il se situe et nous mettrons en valeur les évolutions qui lui ont été apportées et dans quel mesure il peut être utilisé aujourd'hui. II/ IGMP : Qu'est ce que c'est? Dans l'introduction, le multicast est présenté comme reposant sur deux types de protocoles : les protocoles de routages multicast (pour la communication entre routeurs dans la réseau) et le protocole permettant la communication entre l'hôte et le routeur local. L'architecture multicast peut donc être ainsi représentée : IGMP (== Internet Group Management Protocol) se situe dans la catégorie des protocoles de communication entre l'hôte et le routeur de bordure. En effet IGMP permet de répondre a la question suivante : "comment un routeur détermine-t-il si son LAN possède des récepteurs pour un groupe multicast donné?", car il serait inutile de faire suivre un trafic multicast sur un LAN si personne n'est intéressé par ce dernier. IGMP s'utilise uniquement sur des LANs a diffusion et permet donc la gestion d'appartenance d'un hôte a un groupe : l'idée est qu'un hôte puisse indiquer a son routeur local s'il souhaite joindre, voire quitter un groupe spécifique. Voila pourquoi IGMP est important pour le Ben Souiden Erwan WgsGro 1/15 MMQoS 2004/2005

multicast. Cependant nous allons voir que les évolutions de ce protocole ont différentes approches pour cette gestion de groupe (l'hôte doit il spécifier son départ d'un groupe ou non?...) et nous allons donc voir quelles améliorations ont été pensées et apportées pour optimiser ce protocole. III/ Contraintes pour utiliser IGMP 3-1/ Implémentation des protocoles au niveau 3 Tout hôte intéressé pour faire du multicast (et donc utiliser IGMP) doit posséder une extension du protocole IP dans sa pile comme suivant : Ce dessin nous montre bien ou se situe IGMP dans la pile de protocole, c'est donc un protocole de niveau 3 au même titre qu'icmp. Sans cette extension les hôtes ne peuvent prétendre a participer a une session multicast (uniquement en réception cf. les degrés de conformité décrits plus bas). 3-2/ Services supplémentaires nécessaires A/ Pour l'émission multicast - Extension pour le module IP : Pour pouvoir assurer l'émission de paquet IP en multicast, le module IP doit pouvoir reconnaître une adresse de groupe (donc de classe D). A la base la plupart des implémentations IP suivent l'algorithme suivant : si l'adresse IP de destination est sur le même réseau local alors on envoie le paquet en local a l'adresse IP de destination si autre cas alors on envoie le paquet en local a la passerelle Cette logique est appliquée par toutes machines ne pouvant reconnaître les adresses de classe D! Car ces machines enverront les paquets de données IP directement a la passerelle alors que ce n'est pas la cible. Typiquement ce sera le cas des hôtes de conformité 0 qui ne peuvent pas émettre en multicast (cf. les degrés de conformité décrits plus bas). Ben Souiden Erwan WgsGro 2/15 MMQoS 2004/2005

Les machines voulant donc émettre en multicast doivent suivre la logique suivante : si l'adresse IP de destination est sur le même réseau local ou si l'adresse IP de destination est une adresse de groupe multicast alors on envoie le paquet en local a l'adresse IP de destination si autre cas alors on envoie le paquet en local a la passerelle Cette logique est implémentée pour tout les hôtes de conformité 1 ou 2. - Extensions pour l'interface de service IP : Plusieurs extensions sont nécessaires ou du moins désirables pour faire du multicast : - utilisation de la même opération SendIP pour envoyer un paquet en unicast sauf que la couche supérieure doit pouvoir spécifier une adresse de groupe comme adresse de destination pour assurer l'envoi multicast. Evidemment cette extension est indispensable pour faire du multicast. - possibilité au niveau supérieur de spécifier un TTL au paquet multicast. Cette extension est désirable car sans elle, une valeur de TTL sera choisie par défaut. Typiquement cette valeur choisie est 1 ce qui rend impossible de faire du multicast au delà d'un simple réseau (mais cela peut, parfois, correspondre aux besoins de l'émetteur...). B/ Pour la réception multicast - Extensions pour l'interface de service IP : Tout comme l'émission multicast, pour pouvoir recevoir du trafic multicast, certaines extensions sont nécessaires. Pour que l'hôte puisse spécifier les groupes qu'il l'intéresse, le niveau supérieur a IP doit pouvoir spécifier les adresses multicast qui l'intéressent. Deux nouvelles opérations doivent ainsi être disponibles : JoinHostGroup (group-address, interface) qui permet un hôte de devenir membre du groupe spécifié par l'adresse passée en paramètre dans l'opération. et LeaveHostGroup (group-address, interface) qui permet un hôte de quitter un groupe spécifié par l'adresse passée en paramètre dans l'opération. Ce sont des opérations et non des messages réseaux! Ces opérations sont nécessaires pour l'utilisation de l'opération ReceiveIP qui est utilisée comme pour le trafic unicast sauf que l'extension regarde les groupes qui intéressent ou n'intéressent plus l'hôte afin de sélectionner le trafic multicast voulu. On notera que les opérations LeaveHostGroup et JoinHostGroup sont aussi présentes au niveau 2 (seul différence on n'a pas besoin de spécifier une interface puisqu on est au niveau 2) pour permettre au module IP de faire redescendre l'information et spécifier quel paquet multicast sont a accepter. - Extension pour le module IP : Le module IP doit aussi posséder certaines extensions, pour assurer la réception multicast, telles que : - la possibilité de maintenir une liste des groupes dont l'hôte est membre pour chacune de ses interfaces (les mise a jour étant faites par les opérations de Join et Leave). Cette extension sert aussi bien les hôtes que les routeurs de bordures qui devront par la suite sélectionner les différents trafics multicasts pour les faire suivre aux hôtes de son réseau. - intégrer l'implémentation niveau 3 décrit plus haut dans le devoir. L'utilisation du multicast, et donc par extension d'igmp, nécessite de se plier a certaines contraintes matérielles et logicielles. Nous venons de spécifier, dans cette partie, tous les Ben Souiden Erwan WgsGro 3/15 MMQoS 2004/2005

mécanismes que doivent utiliser les hôtes souhaitant émettre et recevoir du trafic multicast. C est donc a partir de la qu on est capable de cataloguer les différents types d hôte par degré de conformité. 3-3/ Les degrés de conformité Il existe 3 niveaux de conformités qui définissent le degré d'aptitude de l'hôte a pouvoir participer a une session multicast et donc a pouvoir utiliser IGMP. Ces degrés sont établis par rapport aux contraintes vues plus haut. Niveau 0 : Ce niveau indique que l'équipement est incapable de supporter le multicast; généralement on considère l'équipement comme non affecte par le trafic multicast. Si par hasard sur le même réseau qu'un hôte de niveau 0 se trouve des hôtes de niveau supérieur alors il se peut que du trafic multicast arrive jusqu'a lui... mais ceci ne sera pas un problème vu que le trafic multicast est facilement identifiable grâce aux adresse typique de classe D (ainsi il pourra ignorer ce trafic sans problème). Niveau 1 : Ce niveau indique que l'hôte a la capacité d'émettre des données en multicast cependant ce même hôte est dans l'incapacité de joindre un groupe multicast et donc de recevoir du trafic multicast. La limite entre le degre 0 et le degré 1 est donc très fine puisque un hôte de degre 0 peut très vite être upgrade en niveau 1 (grâce à un script par exemple). Niveau 2 : A ce niveau on considère l'hôte comme complet pour les communication IP multicast. L'hôte a la capacité de rejoindre ou de quitter un groupe et même d envoyer des données a la façon multicast. L'hôte doit implémenter IGMP ainsi que certaines extensions d'ip (décrites plus haut) pour prétendre appartenir a ce niveau de conformité. Pour la suite de ce devoir on considérera que tous les hôtes implémentent toutes ces extensions (on considère donc les hôtes comme étant de conformité 2). Nous allons nous attaque a la description et l'évolution des différents version du protocole IGMP en essayant de vulgariser les mécanismes et de mettre en valeur les diverses points forts du protocole. IV/ IGMP v1 rfc 1112 (http://www.ietf.org/rfc/rfc1112.txt) 4-1/ Description et fonctionnement IGMP (Internet Group Management Protocol) est comme son nom l'indique le protocole qui permet la gestion des groupes multicast. Dans la brève présentation d'igmp nous avons spécifié que c'est un protocole utilisé uniquement entre les hôtes d'un LAN et le routeur de bordure de ce même LAN. Tout comme ICMP, IGMP est une réelle partie d'ip (cf. le dessin des couches protocolaires) et est implémenté par tout les hôtes de conformité 2. Les messages IGMP sont encapsulés dans un datagramme IP (dont le champ protocole de l'entête IP est fixé a 2). Voici la structure du message IGMPv1 : 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 Ben Souiden Erwan WgsGro 4/15 MMQoS 2004/2005

Le message est donc composé de plusieurs champs qui sont les suivants : Version : Numéro de version du protocole IGMP, fixé à 0x1. Une version 0 a été spécifie nous la décrirons très brièvement plus loin dans le devoir. Type : deux types de messages sont possibles 1 = Host Membership Query : c'est le message qui est utilisé par le routeur de bordure pour interroger les hôtes du LAN afin de découvrir si certains d'entre eux sont intéressés par des groupes multicast particuliers. 2 = Host Membership Report : c'est le message qui est utilisé par un hôte pour spécifier au routeur de bordure qu'il est intéressé par un groupe. Unused : Champ inutilisé devant être mis à zéro par l'émetteur et ignoré par le récepteur Checksum : checksum de 16bits réalisé uniquement sur l'entête IP pour le contrôle d'erreur Group Address : ce champs est utilisé seulement dans les messages Host Membership Report envoyés par un hôte. C'est dans ce champ que ce dernier inscrit l'adresse du groupe multicast qu'il souhaite rejoindre. Ce champs présent aussi dans les messages de type Host Membership Query est mis entièrement a 0. On notera que bien souvent le message possède un TTL (champs de l'entête IP indiquant le nombre de saut maximum) égal a 1 pour préciser que le message doit "rester" uniquement sur le LAN. Le fonctionnement de ce protocole est relativement simple : - lorsqu'un hôte souhaite rejoindre un groupe multicast, il envoie un message IGMP de type Host Membership Report contenant l'adresse du groupe. A la réception de ce message le routeur de bordure va regarder si il possède déjà dans sa table des membres de ce groupe, si ce n'est pas le cas (aucun groupre correspondant) il modifie sa table afin d'indiquer qu'un hôte de son réseau est intéressé par ce nouveau groupe défini dans le message. - IGMPv1 ne donne pas la possibilité aux hôtes d'indiquer si ils ne sont plus intéressés par un groupe, c'est pour cela que le routeur de bordure se doit d'envoyer périodiquement des messages Host Membership Query pour vérifier si sur le réseau il reste toujours des participants aux sessions multicast (c est le comportement typique des protocoles dit Soft State : mise a jour periodique des informations). Cela évite de faire suivre du trafic pour rien et donc de gaspiller de la bande passante. Lorsque les hôtes voient passer un message Host Membership Query ils doivent répondre par un Host Membership Report en spécifiant toujours les groupes auxquels ils appartiennent. Malgré un fonctionnement simple, on voit tout de suite les premières limitations et risques de ce système tel que le risque de congestion. En effet si à chaque Host Membership Query du routeur tout les hôtes abonnés a un groupe multicast répondent en même temps, il y aura un fort risque de congestion au niveau du routeur de bordure (qui devra gérer la réception de tout les Reports!). Une optimisation consiste à étaler dans le temps les réponses des hôtes; voici son fonctionnement : - le routeur envoie son Host Membership Query car il doit rafraîchir la liste des groupes multicasts qui intéressent les hôtes de son réseau (cf. le Soft State). - à la réception de ce message tout hôte appartenant a un ou plusieurs groupes multicast va enclencher un timer (appelé le report delay timer) pour chaque groupe auquel il appartient. Le timer est fixé avec une valeur aléatoire au bout de laquelle l'hôte enverra le message Host Membership Report correspondant. Ben Souiden Erwan WgsGro 5/15 MMQoS 2004/2005

Ainsi il y a moins de chance que tout les hôtes envoient leur message Report au même moment. Cependant on peut encore améliorer le processus de la façon suivante : lorsqu'un hôte enverra son Report concernant un groupe, tout les autres membres du même groupe présents sur le LAN stopperont leur timer et n'enverront pas de Report. Ainsi pour chaque abonnement multicast il y aura uniquement un seul message sur le réseau quelque soit le nombre d'abonnés. On réduit donc encore le risque de congestion et le routeur peut tout de même faire la mise a jour de sa liste. Sur ce schéma une petite représentation du fonctionnement d une Query : On distingue donc trois états pour les hôtes : - non state member : cela signifie que l'hôte ne fait parti d'aucun groupe multicast. - delaying member state : cela signifie que l'hôte appartient a un groupe et qu'il a déjà activé un timer. - idle member state : même état que précèdent sauf qu'aucun timer n'a été enclenché. Sur ce schéma on récapitule les différents événements qui peuvent se produire ainsi que le changement d'états qu'ils entraînent. Ben Souiden Erwan WgsGro 6/15 MMQoS 2004/2005

4-2/ Avantages et inconvénients Apres la description du fonctionnement de ce protocole on peut tout de suite soulever plusieurs points néfastes : - comme l'hôte ne spécifie pas son départ au routeur de bordure, ce dernier va devoir attendre les réponses a son message Host Membership Query (pas plus d'un query par minute) pour savoir si il reste encore des hôtes sur le LAN. Cela signifie que lorsque le dernier hôte quitte le groupe multicast, le routeur va continuer quelque temps de faire suivre les paquets associés a ce groupe (tant qu'il considère qu'il y a des abonnés). Il y a donc un léger gaspillage de la bande passante. Bien entendu si il ne reçoit toujours pas de Report pour un groupe il considère qu il n y a plus d abonnés mais cela n est pas instantané. - si aucun changement n'est constaté dans l'appartenance aux groupes multicast, le routeur va envoyer des messages Host Membership Query pour rien car il n'aura aucune mise a jour a faire de sa liste et comme les hôtes vont devoir répondre a ce message pour indiquer qu'il y a toujours des intéressés, il va y avoir du trafic généré pour rien. - en revanche la mise en place d'un tel protocole permet de réduire le trafic sur le LAN si aucun membre n'est reconnu, c'est tout l'intérêt du protocole IGMP! V/ IGMPv2 rfc 2236 (http://www.ietf.org/rfc/rfc2236.txt) Au vu des quelques défauts de la première version de ce protocole, une deuxième version a donc vu le jour avec comme objectifs rectifier les imperfections en gardant la même approche de base. 5-1 / Description et fonctionnement Tout d'abord la structure du message IGMP a changé, mais tout comme IGMPv1, le message IGMPv2 est encapsulé dans un paquet IP dont le champs protocole porte la même valeur qu'en IGMPv1 soit 2. 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 Type Max Resp Time Checksum Group Address Ce nouveau message est compose des champs suivants : Type : quatre types de message sont possibles : - Membership Query : même objectif que le message Host Membership Query d'igmpv1. Cependant on distingue deux sous type messages : Le General Query qui est utilisé par le routeur exactement de la même façon que le message Host Membership Query d'igmpv1 (le routeur souhaite savoir si sur le LAN des hôtes sont intéressés par des trafics multicast) Le Group Specific Query utilisé aussi par le routeur pour savoir si des hôtes sont interessés par un groupe particulier dont il spécifie l'adresse. - Version 2 Membership Report : permet a un hôte de spécifier par quel groupe multicast il est intéressé. Ben Souiden Erwan WgsGro 7/15 MMQoS 2004/2005

- Leave Group : ce message va permettre a l'hôte d'expliciter au routeur son départ d'un groupe multicast. - Version 1 Membership Report : ce message est en fait utilisé pour la compatibilité des protocoles, pour que les hôtes utilisant encore IGMPv1 puisse tout de même préciser par quel groupe multicast ils sont intéressés. Max Response Time : permet de définir le délai maximum accordé a l'hôte avant de renvoyer un message Report. Checksum : même utilité que dans la version précédente. Group Address : même utilité que dans la version précédente sauf pour le message Membership Query : si le message est un General Query alors le champs Group Address sera entierement mis a 0 alors que dans le cas d'un Group Specific Query le routeur spécifie l'adresse d'un multicast. Le fonctionnement est grossièrement le même que pour IGMPv1 avec quelques petites améliorations : - de la même façon qu'en IGMPv1, lorsqu'un hôte souhaite rejoindre un groupe il envoie un message Membership Report avec l'adresse multicast du groupe qu'il souhaite rejoindre. Le travail du routeur a partir de la reste toujours le même (vérification dans de la liste des groupe multicast et mise a jour de cette dernière si nécessaire). - de la même façon qu'en IGMPv1 le routeur envoie périodiquement des messages Membership Query-General afin de vérifier (voire déterminer lors du démarrage du routeur) les informations d'appartenance. Cependant la version 2 permet aux routeurs de spécifier un temps (Max Response Time) correspondant au délai maximum accordés aux hôtes pour répondre. Ceci permet donc d'avoir une meilleure réaction vis a vis des changements : car si personne ne répond dans les temps, le routeur considérera qu'il n'y a plus d'abonnés multicast. En revanche les hôtes réagissent de la même façon a la réception de ce message : choix d'une valeur pour le timer comprise entre 0 et Max Response Time, si quelqu'un dit appartenir aux même groupe avant, alors l'hôte ne renvoie pas de Report et stoppe le timer. - utilisation du nouveau message Leave Group pour qu'un hôte explicite son départ au routeur de bordure. Dans ce message l'hôte précise l'adresse du groupe qu il souhaite quitter dans le champ Group Address. A la réception de ce message le routeur va envoyer un message Membership Query-Specific pour savoir si il reste encore des abonnés avec un nouveau Max Response Time. Les hôtes qui attendent avant d'envoyer leur Membership Report mette a jour la valeur de leur timer uniquement si cette valeur est supérieure au Max Response Time. On notera qu'une optimisation de ce système est possible : le message Leave Group est envoyé par un hôte uniquement si il a envoyé le dernier message Report concernant ce groupe (car dans ce cas il pourrait être le dernier membre de ce groupe) sinon il n'est pas obligé d'expliciter son départ vu qu'il reste d'autres membres (qui aurait donc répondu avant lui au message Query). Cette petite optimisation permet de réduire un peu le trafic. Ben Souiden Erwan WgsGro 8/15 MMQoS 2004/2005

Voici un schéma présentant la procédure du Leave : On retrouve dans cette version du protocole les mêmes états que dans IGMPv1 : - non state member - delaying member state - idle member state Voici un schéma présentant les phases de transitions des hôtes suivant le fonctionnement du protocole : 5-2/ Qu'est ce qu'apporte IGMPv2 par rapport a la version précédente? - le champs Version présent dans la structure du message IGMPv1 n'étant pas vraiment utile, on l'a combiné avec le champs Type pour donner le champs Type d'igmpv2. Grâce à ce nouveau champs les routeurs peuvent donc savoir si les hôtes envoient des messages Report de la version 1 ou de la version 2. La cohabitation des deux protocoles est possible mais l'intérêt de ce devoir étant de présenter l'évolution des mécanismes je n'ai pas insisté sur ce point. Ben Souiden Erwan WgsGro 9/15 MMQoS 2004/2005

- IGMPv2 apporte un tout nouveau type de message : Leave Group. Grâce a ce message un hôte explicite son départ d'un groupe ce qui permet de réduire la latence du aux désabonnements des hôtes. - Des nouveaux mécanismes tel que l'obligation de répondre dans un certain délai, permet aux routeurs de bordure de gérer encore plus vite l'appartenance des hôtes et ainsi de réduire le trafic (cf. le fonctionnement décrit plus haut) ou encore la possibilité de ne pas envoyer de message Leave dans certains cas. - Dans le cas ou plusieurs routeurs de bordures existent, IGMPv2 incorpore un mécanisme permettant l'élection de celui qui gérera les groupes et hôtes (alors qu'en IGMPv1 ce travail est laissé au protocole d'établissement de l'arbre multicast...) : on fera la différence entre les routeurs "qui posent les questions" et les autres. Mais je n'ai pas insisté sur ce point pour me consacrer uniquement au fonctionnement des protocoles. VI/ IGMPv3 rfc 3376 (http://www.ietf.org/rfc/rfc3376.txt) IGMPv3 est la toute dernière version d'igmp. La RFC a été déposée en 2002, c'est donc une version très récente. 6-1/ Description et fonctionnement La structure du message IGMPv3 varie suivant le type de message mais tout comme IGMPv1 et IGMPv2, le message IGMPv3 est encapsulé dans un paquet IP dont le champ protocole porte la valeur 2. Les types de messages sont les suivants : Membership Query, le Version 3 Membership Report (nous allons décrire ces deux messages juste après) puis nous retrouvons les messages Version 1 Membership Report, Version 2 Membership Report et Version 2 Leave Group (que nous avons déjà décrit plus tôt dans le devoir et qui sont essentiellement utilises pour l'interoperabilite d'igmpv3 avec les deux versions antérieures). A/ Le message Membership Query Il existe maintenant 3 types de message Query : la General Query : même utilité que dans les versions antérieures, pour connaitre l'état général des hôtes sur les abonnements. la Group-Specific Query : même utilité que dans la version 2 du protocole, pour savoir si des hôtes sont intéressés par le groupe spécifié dans le champs Group Address. la Group-and-Source-Specific Query : est utilisé de la même façon que la Group- Specific Query sauf qu'on a la possibilité de préciser une liste de sources émettrices (défini dans le champs Source Address). Ben Souiden Erwan WgsGro 10/15 MMQoS 2004/2005

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 Type = 0x11 Max Resp Code Checksum Group Address Resv S QRV QQIC Number of Sources (N) Source Address [1] +- -+ Source Address [2] +-. -+.. +- -+ Source Address [N] Type : le type sera donc toujours fixé a ox11 pour spécifier que c'est une Query. Max Resp Code : ce champs à la même fonction que le champs Max Response Time de la version 2, il permet de définir le délai maximum accordé a l'hôte avant qu il puisse renvoyer un message Report. Checksum : même utilité que dans la version précédente. Group Address : si le message est un General Query alors le champs Group Address sera entièrement mis a 0 alors que dans le cas d'un Group Specific Query le routeur spécifie l'adresse d'un multicast. Resv : champs réservé pour d éventuelles options futures, il est initialisé a 0. S Flag : flag qui permet d indiquer que l on supprime le temporisateur actuel. QRV : (Querier's Robustness Variable) si ce champs n'est pas a 0 alors il indique la variable de résistance. Cette valeur indique le nombre de paquets pouvant être perdus. Cette valeur n'est utile que pour le routeur Querier (celui qui envoie les messages Query). La robustesse du protocole se fait donc par rapport à la perte de paquets et donc cette valeur. QQIC : (Querier's Query Interval Code) le Query Interval est le temps qui existe entre l'émission de 2 General Query. Plus cette valeur est grande moins de General Query seront envoyés. Cette valeur est fixée par le paquet Report reçu par le Querier le plus récent. Ce champs est intéressant lorsque les abonnements/désabonnements n'évolue plus; car il ne sera pas nécessaire de demander si il y a eu des changements si rien ne change... Number of Sources (N) : permet de préciser combien d'adresses sources sont présentes dans le message Query. Ce champs est à 0 pour une General Query, ou une Group-Specific Query, mais ce n'est pas le cas pour une Group-and-Source-Specific Query. Ce champs est limité par la MTU du réseau sur lequel on transmet le message. Source Address : ce champs est une sorte de vecteur comprenant N (cf. le champs décrit plus haut) adresses IP unicast. Ben Souiden Erwan WgsGro 11/15 MMQoS 2004/2005

B/ Le message Version 3 Membership Report Le message report est constitue de la manière suivante 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 Type = 0x22 Reserved Checksum Reserved Number of Group Records (M). Group Record [1].. Group Record [2]..... Group Record [M]. Type : toujours fixe a Ox22 pour préciser que le message est un Report Number of Group Record : permet de préciser combien de Group Records sont présents dans ce Report Ben Souiden Erwan WgsGro 12/15 MMQoS 2004/2005

Group Record : chaque Group Record contient des informations contenant des informations de l'émetteur sur ses divers abonnements structure du Group record : Record Type Aux Data Len Number of Sources (N) Multicast Address Source Address [1] +- -+ Source Address [2] +- -+... +- -+ Source Address [N]. Auxiliary Data. Record Type : on distingue plusieurs type : Current State Record : est envoyé par le système en réponse à une Query a propos d'une adresse multicast particulière. On distingue deux cas : - MODE_IS_INCLUDE : indique que le filtre inclus cette adresse multicast. - MODE_IS_EXCLUDE : indique que le filtre exclu cette adresse multicast. Filter Change Mode Change Record : envoyé par le système lorsque un changement dans les filtres est recensé (par exemple A passe de «source qu'on écoutait» a «source qui nous interesse plus») a propos d'une adresse multicast particulière. Deux types de changements possibles : - CHANGE_TO_INCLUDE_MODE : adresse source spécifiée vient d'être incluse dans le filtre alors qu'elle en était exclue. - CHANGE_TO_EXLUDE_MODE : adresse source spécifiée vient d'être supprimée du filtre alors qu'elle était écoutée. Source List Change Record : est envoyé par un abonné pour indiquer des sources supplémentaires a écouter ou pour indiquer les sources qui ne l'intéressent plus. D'ou deux messages : - ALLOW_NEW_SOURCES : toutes les adresses sources spécifiées dans le champ adéquat de ce Group record indiquent que ce sont des adresses supplémentaires que l'hôte souhaite écouter. - BLOCK_OLD_SOURCES : toutes les adresses sources spécifiées dans le champ adéquat de ce Group record indiquent que ce sont des adresses que l'hôte ne souhaite plus écouter. On notera que si pour une même adresse multicast, des sources sont rajoutées et d'autres sont supprimées (on veut écouter A a la place de B par exemple) alors deux Group Records seront envoyés pour cette même adresse. Les autres messages d IGMPv3 sont les mêmes que rencontrés précédemment et ont donc été décrits dans les parties IV/ et V/. Ben Souiden Erwan WgsGro 13/15 MMQoS 2004/2005

C/ Le fonctionnement Le fonctionnement est le même qu'igmpv2 (cf IGMPv2 plus haut) avec en plus l'incorporation des nouvelles options. En effet la différence c'est que maintenant le routeur doit pouvoir enregistrer des informations supplémentaires a propos de la source des émetteurs multicast (d'ou l'utilité du message Group-and-Source-Specific Query qui permet de mettre a jour ces informations). Le message Group-and-Source-Specific Query, généré par le routeur, est donc utilisé pour vérifier les sources qui sont désirées par les abonnés du réseau. Ce message est envoyé par le routeur uniquement lorsqu'il a eu une réponse ayant un Record Type indiquant un changement d'état dans les filtres ou dans la liste des sources (Filter Change Mode Change Record ou Source List Change Record). Ainsi le routeur pourra tenir a jour sa liste d'abonnés et de sources associées. Le but étant de montrer l'évolution de du fonctionnement je ne présenterai pas ici les mécanismes mis en place par IGMPv3 pour cohabiter avec les deux autres versions antérieures. 6-2/ Qu'est ce qu'apporte IGMPv3 par rapport a la version précédente? La grande nouveauté est la possibilité que les hôtes ont de pouvoir préciser les sources qui les intéressent. On peut voir dans cette nouveauté la possibilité de faire de la sécurité (l'hôte spécifie uniquement une source de confiance pour la session multicast par exemple) mais surtout ce nouveau système permet a l'hôte de choisir la source qui nous offre le meilleur service. On notera aussi qu un champ additionnel a été prévu afin de permettre des futures évolutions. Ben Souiden Erwan WgsGro 14/15 MMQoS 2004/2005

VII/ Bilan IGMP est un protocole qui permet la gestion les appartenances des hôtes aux groupes multicast. Il n intervient uniquement entre les machines d un réseau et le routeur de bordure et n est utilisé que sur les LANs a diffusion. Il est caractérise par deux choses : - C est un protocole annonce-écoute avec suppression cela signifie que les hôtes ne répondent que si aucun hôte n a répondu avant. Optimisation du trafic! - De plus c est un protocole Soft State (== état mou) cela signifie que périodiquement des mises a jours seront demandées même si aucun changement n a été observé. Comme le multicast est supposé évoluer fréquemment et très vite, cette caractéristique permet de rendre la gestion des abonnés beaucoup plus souple. Ce protocole est donc indispensable pour réaliser du multicast cependant il doit être compléter par des protocoles de routage multicast (type DVMRP, PIM ou bien MOSPF) qui permettent de créer dynamiquement des arbres (équivalent de route) entre les sources et les récepteurs abonnés (non développé dans ce devoir). Voici un tableau bilan récapitulant les évolutions et les apports des nouvelles versions pour optimiser l utilisation du protocole IGMP : Aujourd hui le multicast n existent qu au niveau expérimental (dans le réseau MBone par exemple) mais les matériels qu on trouve sur le marché peuvent supporter ce type de trafic. Si au niveau de la création des arbres de routages multicast plusieurs protocoles sont possibles, pour la gestion de groupe IGMPv3 tend a devenir le standard car c est celui qui répond le mieux aux besoins des utilisateurs (en question de qualité de service avec le choix de la source par exemple ou de temps de convergence). Ben Souiden Erwan WgsGro 15/15 MMQoS 2004/2005