CONSERVATOIRENATIONNALDES ARTSET METIERS PARIS MEMOIRE POUR L EXAMEN PROBATOIRE INFORMATIQUE. par. Marc PERRUDIN.

Transcription

1 CONSERVATOIRENATIONNALDES ARTSET METIERS PARIS MEMOIRE POUR L EXAMEN PROBATOIRE en INFORMATIQUE par Marc PERRUDIN Le multicast IP : Protocoleset mise en œuvre de la famille PIM Soutenu le 15 Janvier 2004 JURY PRESIDENT : Professeur Eric GRESSIER MEMBRES: Page 1 sur 40

2 Table des Matières INTRODUCTION...4 PRESENTATIONDU MULTICAST...5 Pourquoi le multicast...5 Apport du multicast à l existant...5 Les applications du multicast...6 Adressage...7 Plan d adressage...8 Plan d adressage...8 Adressage au niveau Allocation...9 IGMP...10 Routage...11 Les arbres...12 Mode dense - Mode épar...13 PIM...14 PIM DM...14 Découverte des voisins...14 Découverte des voisins...14 Inondation...15 Elagage et greffe...16 Election de l expéditeur désigné...17 PIM SM...17 Routeur désigné...17 Construction de l arbre partagé...18 Enregistrement de la source...18 Recherche de l arbre du plus court chemin...19 Election de l expéditeur désigné...20 Gestion des points de rendez-vous...20 Auto RP...21 PIM Bootstrap...22 Anycast RP...22 Variantes de PIM...24 PIM SDM...24 Page 2 sur 40

3 Bi-directional PIM...25 PIM SSM...26 MISE EN ŒUVRE...29 Multicast intra domaine...29 Les hôtes...29 Les routeurs...30 Les commutateurs Ethernet...32 Multicast inter domaine...34 Mode natif ou mode tunnel...34 Gestion des points de rendez-vous...35 Topologie congruente, non congruente...36 Sécurité...36 CONCLUSION...38 BIBLIOGRAPHIE...39 Page 3 sur 40

4 INTRODUCTION En 1992, lors du meeting de l IETF à San Diego, eut lieu la première diffusion audio à grande échelle utilisant la technologie multicast. La communication multicast, l acheminement de données d un émetteur vers plusieurs destinataires ou de plusieurs émetteurs vers plusieurs destinataires, n est pas très récente puisqu elle fut introduite dès 1985 par Steve Deering dans la RFC966, mais c est actuellement un domaine qui offre de nombreuses perspectives de développement dans l Internet. Comparé au Web qui date de la même époque, le premier navigateur fut écrit en 1990, le multicast en est encore aux prémices de son développement alors que le Web est déjà largement répandu. Cette différence peut s expliquer par le fait que le multicast est l une des premières technologies Internet qui nécessite une intelligence additionnelle dans le réseau pour être déployée. Ceci a remis en cause la conception du réseau qu avait la communauté Internet à l époque et qui voulait que l intelligence devait être implantée aux bords du réseau. Le multicast inaugurait l arrivée d une nouvelle génération de services qui nécessitaient plus qu un réseau best-effort en mode unicast. Partant de ce constat, et devant la demande d un Internet capable de délivrer des services multicast, de nouveaux protocoles firent leurs apparitions pour répondre à ce besoin. Ce document ce propose de présenter une partie de ces protocoles, les protocoles de la famille PIM, Protocole Independant Multicast, en présentant dans un premier temps les besoins auxquels répond le multicast et les technologies qu il nécessite, puis les protocoles de la famille PIM dans leurs deux principales versions ainsi que leurs extensions. Enfin, leurs mises en œuvre dans le cadre d un campus ou d une entreprise, dans l Internet et les problèmes de sécurité qu ils engendrent. Page 4 sur 40

5 1. PRESENTATIONDU MULTICAST 1.1Pourquoi le multicast Le développement d Internet augmente les échanges de données, et souvent, les mêmes données sont demandées par un ensemble d internautes simultanément. L arrivée de nouveaux types de contenu gourmand en bande passante, notamment la vidéo, montre les limites des modes d acheminement actuel Apport du multicast à l existant Dans les réseaux IP traditionnels, il y a principalement deux modes d acheminement des données : L unicast et le broadcast. L unicast est utilisé pour l acheminement de données entre deux hôtes, chacun possède une adresse pour permettre l établissement d une connexion et l acheminement des données. Lorsque plusieurs hôtes sont intéressés par le même contenu simultanément, les données sont envoyées une fois à chaque hôte comme le montre la figure 1. Ceci n est pas très efficace et nécessite de la part de l hôte émetteur une puissance et une bande passante proportionnel au nombre de client. Figure 1 Figure 2 Une alternative est l utilisation de la diffusion ou broadcast. Ce mode d acheminement permet d adresser l ensemble des hôtes d un réseau simultanément. L hôte émetteur n a alors plus qu à envoyer les données qu une seule fois et économise ainsi ses ressources. Par contre, dans ce mode, tous les Page 5 sur 40

6 hôtes du réseau cible reçoivent les données, même ceux qui ne le désirent pas ce qui entraîne une consommation des ressources de ces hôtes pour traiter ces données. De plus, si les hôtes intéressés sont répartis sur plusieurs réseaux, il faut envoyer plusieurs fois les mêmes données pour couvrir l ensemble des réseaux intéressés. Enfin, en pratique le broadcast est inutilisable au-delà du réseau local car les routeurs sont généralement configurés pour ne pas acheminer ces paquets à cause des risques de déni de service qu ils engendrent. Le multicast apporte une solution qui allie le meilleur des deux autres modes sans les inconvénients. Dans ce mode, les données ne sont émises qu une seule fois par l hôte émetteur et c est le réseau qui ce charge d acheminer les données uniquement vers les hôtes intéressés comme le montre la figure 2. Ce mode assure la meilleure utilisation des ressources car les données ne sont acheminées qu une seule fois sur chaque lien et uniquement sur ceux qui relient l hôte émetteur et les hôtes intéressés Les applications du multicast Le multicast répond aux besoins de certains types d applications, celles-ci peuvent être classée en trois catégories selon la fiabilité et le temps de réponse qu elles exigent (Figure 3) : - Les applications temps réel interactives, tel qu une conférence à plusieurs intervenants répartis sur plusieurs sites, nécessitent des temps de réponse très courts pour être utilisables mais supportent quelques pertes de données. - La distribution multimédia, comme par exemple les radios, nécessite une fiabilité de transmission supérieur tout en supportant encore quelques pertes grâce a l utilisation de format capable de les masquer. Ce type d application permet des temps de réponse plus long par l utilisation de tampons au niveau des récepteurs. - La distribution de documents tolère des temps d acheminement assez longs et variables mais nécessite une garantie quant à l acheminement des données. Dans une application comme la distribution de logiciels, la perte d un paquet rend inutilisable l ensemble des données transmises. Page 6 sur 40

7 Figure 3 Ce nouveau mode d acheminement et les nouvelles applications qui l utilisent ne peuvent plus fonctionner avec la couche transport traditionnel : TCP. En effet, l utilisation de TCP entraînerait rapidement la saturation de l émetteur : l émission d un paquet aurait pour conséquence la réception d un paquet d acquittement par client ce qui limiterait sérieusement le nombre de client supporté. Pour cette raison, le multicast s appuie sur UDP accompagné de protocoles supplémentaires tel que, par exemple, RTP/RTCP pour la diffusion de contenu multimédia, ou bien SRM ou RMTP pour les applications nécessitants une fiabilité d acheminement. Ceci n est qu un échantillon des applications du multicast, de nouvelle application du multicast apparaissent régulièrement que se soit pour amélioré l efficacité d applications existante comme le DNS, le temps Internet (NTP), ou bien pour répondre à de nouveaux besoins comme la découverte de services réseaux ou le routage ad hoc dans les réseaux sans-fil. 1.2Adressage Le multicast nécessite de pouvoir adresser un ensemble d hôte simultanément sans connaître leurs adresses IP. Le multicast introduit pour cela la notion de groupe d hôte et utilise un plan d adressage spécifique. Ainsi, dans l acheminement multicast, un paquet n est plus envoyé à un hôte mais à une Page 7 sur 40

8 adresse de groupe, l ensemble des membres d un groupe est dynamique et ceci est géré par les routeurs Plan d adressage Les adresses IP sont découpées en classe, les classes A, B et C sont réservées aux adresses unicast et la classe D est réservée aux groupes multicast. Ces adresses de classe D sont caractérisées par les quatre bits de poids forts positionnés a 1110, ce qui correspond à la plage d adresse à Les adresses au delà correspondent a la classe E et sont réservée a un usage ultérieur. Dans cette plage, un certain nombre de ces adresses sont assignés à un usage particulier. Par exemple, la plage à est réservée aux messages de contrôle locaux et ne traverse pas les routeurs, d autres plages sont réservées aux groupes multicast ayant une portée réduite. Ceci est géré par l autorité d assignation des numéros Internet, l IANA, et l ensemble des assignations est accessible sur leur site Internet à l adresse : Adressage au niveau 2 Le multicast nécessite aussi de pouvoir adresser une même trame à un ensemble de client au niveau de la couche liaison. Le mécanisme utilisé dans l unicast, ARP, ne répond pas à ce besoin. Le multicast utilise un autre mode d acheminement qui consiste à faire correspondre les adresses multicast IP avec des adresses multicast MAC (Cas d Ethernet, des mécanismes différents existent pour d autres protocoles comme Token Ring ou FDDI mais ils ne seront pas traité ici car ils sont très peu implémentés). Les 23 bits de poids faible de l adresse IP sont extraits et combinés à un préfix fixe : 0x01005e (Figure 4). Les clients intéressés par un groupe multicast doivent configurer leur carte réseau pour écouter ces adresses MAC supplémentaires. Page 8 sur 40

9 Figure 4 L utilisation de seulement 23 bits implique qu un hôte peut recevoir des flux non désirés si plusieurs groupes avec des adresses finissant avec les mêmes 23 bits sont diffusés dans le réseau (comme et ). Ce type de collision est résolu par la couche IP Allocation La diffusion multicast nécessite d émettre les données non plus directement vers les destinataires mais vers une adresse de groupe. La plage d adresse étant limitée, il n y a pas d attribution d adresse multicast tel qu en unicast. L utilisation d une adresse aléatoire située en dehors des plages réservée est possible, il suffit de choisir une adresse quelconque et de ce mettre en écoute de ce groupe. Après un délai suffisant sans activité, l adresse peut être considérée libre et utilisable. Cependant, cette méthode entraîne de nombreux problèmes dont : - Le clivage d horizon, les sessions multicast ont une portée plus ou moins grande suivant les besoins, deux groupes peuvent ne pas s entendre et utiliser la même adresse mais être tout les deux entendues par un client. - Les sources discontinues, certaines sources n émettent du trafic que sporadiquement, ce pose alors le problème du choix du délai d attente avant de considérer l adresse libre. - Le besoin en adresse fixe, pour permettre par exemple l attribution d un nom DNS a un groupe. Pour résoudre ces problèmes, l IETF a défini plusieurs protocoles pour gérer l attribution des adresses. La première approche consiste à utiliser SAP. Ce protocole permet d annoncer périodiquement les sessions actives sur des groupes multicast prédéfinis. Chaque site se met en écoute sur ces groupes et, après Page 9 sur 40

10 quelques dizaines de minute, est informé de l ensemble des sessions actives. Il peut ainsi les rejoindre ou se servir de ses informations pour déterminer une adresse libre. Cette approche utilise des groupes multicast spécifique où sont annoncées les sessions. Elle nécessite que toutes les sources et tous les clients soit membre de ces groupes et ne permet pas de ce fait sa généralisation. Pour palier à cette limitation, MADCAP utilise une approche semblable à DHCP pour l unicast. Un serveur MADCAP s attribue une plage d adresse et se charge de la gérer. Cette approche demande à mettre en place une hiérarchie de serveur MADCAP complexe avec des serveurs primaires chargés de s assurer que les plages ne sont utilisées qu une seule fois. Les seules implémentations de ce protocole sont généralement partiel et ne permettent de gérer que des plages locales. La dernière approche répond surtout au besoin en adresse fixe. GLOP utilise une plage d adresse réservée à son usage et permet d attribuer 256 adresses fixes à tous les domaines qui possèdent un numéro de système autonome (les numéros de système autonome sont attribués par l IANA aux domaines qui gèrent leur routage sur Internet, généralement les fournisseurs d accès ou les très gros réseaux). 1.3IGMP Pour permettre aux routeurs de gérer les membres des groupes multicast, il faut tout d abord qu ils puissent communiquer avec les hôtes clients au niveau du réseau local où ils résident pour déterminer les groupes multicast qu ils doivent acheminer. Le protocole de gestion des groupes Internet, IGMP, assure cette fonction. Ce protocole se décline en trois versions qui apportent chacune un jeu de fonctionnalité : - La version 1, définit par la RFC 1112, fournit seulement un mécanisme de base pour la gestion des groupes. Régulièrement, le routeur envoie une requête à l ensemble des hôtes pour déterminer les abonnements aux divers groupes multicast. Un membre de chaque groupe lui répond pour maintenir la diffusion de ce Page 10 sur 40

11 groupe. Lorsque aucune réponse ne parvient au routeur pour un groupe qu il diffuse durant plusieurs requête, celui-ci considère qu il n y a plus de d hôte intéressé pour ce groupe et cesse de le diffuser. - La version 2, définit par la RFC 2236, ajoute la possibilité pour un hôte de se désabonner explicitement pour réduire les temps de latence avant la disparition d un groupe. Elle permet aussi au routeur d émettre des requêtes spécifique à un groupe pour lui permettre de vérifier qu il n y a plus d hôte intéressé avant de cesser l envoie des données. - La version 3, récemment finalisé dans la RFC3376, apporte la possibilité pour un hôte client de définir un filtre sur les sources pour un groupe donné. Par défaut, lorsqu un client s inscrit a un groupe multicast, il reçoit tout le trafic envoyé a ce groupe, quel que soit la source. Cette version d IGMP permet de filtrer les sources selon deux modes, soit l hôte définit les sources qu il désire recevoir pour un groupe, c est le mode include, soit il définit les sources qu il ne désire pas recevoir pour un groupe, c est le mode exclude. Ces fonctionnalités permettent à chaque routeur de maintenir une liste des groupes multicast auquel il doit participer. Dans le cas ou plusieurs routeurs gèrent un même réseau local, un mécanisme d élection est définit dans IGMP pour définir le routeur désigné, DR, pour gérer ce réseau. Ceci ne signifie pas que tout le trafic multicast passe par lui, mais simplement que c est ce routeur qui assure la gestion des groupes. Les autres routeurs se contentent alors d écouter les échanges IGMP pour maintenir leurs listes des groupes multicast. 1.4Routage Le routage dans le multicast consiste principalement à construire un arbre de distribution pour permettre l acheminement des données vers les clients. Les protocoles de routage multicast définissent la façon dont les routeurs échangent les informations nécessaires à la construction de cet arbre et maintiennent les états nécessaires à l acheminement des données. Page 11 sur 40

12 1.4.1Les arbres Les protocoles de routage génèrent deux types d arbre pour acheminer les données : - Les arbres de plus court chemin, SPT, ont leur base à la source et définissent le plus court chemin vers les destinataires. Ils nécessitent la construction d un arbre par source. - Les arbres basés sur un point de rendez-vous, RPT, utilisent une base unique, le point de rendez-vous ou cœur, utilisé par toutes les sources. Les données sont acheminées vers le point de rendez-vous dans un premier temps puis parcourent l arbre ensuite. Ces deux types d arbre ont chacun leurs avantages. Les arbres SPT permettent un temps d acheminement optimum. La figure 5 montre le ratio du délai d acheminement entre les arbres RPT et SPT. Plus le nombre de nœud à traverser est important, plus les performances des arbres RPT se dégradent face aux arbres SPT. Cependant, les arbres SPT nécessitent la construction d un arbre par source ce qui entraîne des problèmes de scalabilité. La figure 6 montre une simulation d un réseau supportant 300 groupes de 40 membres dont 32 sont également des sources. Le nombre de flux supporté par le réseau se dégrade rapidement avec le nombre de nœud à traverser pour les arbres SPT alors qu il diminue très légèrement dans le cas des RPT. Figure 5 Figure 6 Page 12 sur 40

13 Chaque type d arbre a ses avantages et ses inconvénients et sont appropriés à différent type d application selon qu elles nécessitent des temps d acheminement court ou un grand nombre de source Mode dense - Mode épar Les protocoles de routage multicast sont répartis en deux catégories selon qu il fonctionnement selon un mode dense ou un mode épar. Le mode dense par de l hypothèse que les clients sont concentrés dans le domaine de diffusion des données. Il utilise alors un modèle inondation élagage. Le routeur qui reçoit des données d une source diffuse l information à tous les autres routeurs auxquels il est relié et ceux-ci diffusent à leur tour vers leurs voisins excepter vers les routeurs qui remontent vers la source. Lorsqu un routeur n a aucun client ou routeur à qui envoyé l information, il effectue un élagage de l arbre de distribution en informant le routeur montant qu il ne désire plus recevoir cette source. Il en résulte la construction d un arbre de diffusion basé sur la source qui est maintenu à jour en réitérant l inondation élagage périodiquement. Ce mode de diffusion est très indiqué pour la diffusion dans un domaine restreint tel qu une partie d un réseau d entreprise car il est très simple à mettre en œuvre et très efficace s il y a peu ou pas d élagage. Le mode épar au contraire par de l hypothèse que les clients sont disséminés dans le domaine de diffusion. Ce mode utilise un modèle d adhésion explicite c'està-dire que l information n est acheminée que vers les routeurs qui l on explicitement demandés. Il utilise des arbres de distribution basés sur un point de rendez-vous. Lorsqu un hôte client désire rejoindre un groupe, le routeur directement connecté à ce client rejoint l arbre de distribution en envoyant une demande d adhésion au point de rendez-vous. Le mode épar nécessite des mécanismes plus complexes pour la découverte des sources et la gestion des points de rendez-vous qui le rendent plus lourd à administrer. En contrepartie, ce mode peut être utilisé sur des domaines de diffusion large comme Internet. Page 13 sur 40

14 2PIM Les premières mises en œuvre du multicast utilisaient le protocole de routage DVMRP. Ce protocole de mode dense utilisait un mécanisme de calcul des routes de type vecteur de distance similaire à RIP. Ceci impliquait que chaque routeur participant au multicast maintienne une table de routage spécifique et distincte de la table de routage unicast pour prendre leurs décisions de routage. C était suffisant dans le cadre de l expérimentation mais les fournisseurs d accès ont estimé qu il aurait nécessité trop de ressource sur les routeurs pour être généralisé. Le multicast indépendant du protocole, PIM, proposé par Cisco Systems apporte une solution en rendant la décision de routage indépendante du protocole utilisé pour la construction des tables de routage. Indépendant signifie que PIM peut utilisé les tables générées par n importe quel protocole tel que RIP, OSPF ou BGP, mais ne signifie pas qu il fonctionne sans eux. PIM est définit en deux versions. La principale différence entre ces deux versions réside dans le format des paquets. La version 1 utilise des paquets IGMP version 1 avec un type de message 4, alors que la version 2 utilise son propre numéro de protocole IP, le 103. Actuellement, tous les brouillons de l IETF concernant la version 1 ont expiré et cette version n a jamais fait l objet de RFC. 2.1PIM DM Les protocoles de la famille PIM ont deux modes de fonctionnement principaux, un mode dense et un mode épar. Le mode dense assume que quand une source commence à émettre, tous les systèmes souhaitent recevoir les données. Ce mode ne fait l objet d aucune RFC mais est un travail en cours de l IETF. Le dernier brouillon, valide jusqu en Mars 2004, est disponible sur leur site [ADA03] Découverte des voisins Page 14 sur 40

15 Lorsqu un routeur multicast en mode PIM DM est activé, il commence par envoyer un message (HELLO) à un groupe multicast spécifique non routé auquel tous les routeurs PIM participent. Ceux-ci enregistrent l émetteur de ce message et l interface sur laquelle il a reçu. Cette opération est répétée régulièrement et permet aux routeurs de maintenir la liste de leurs interfaces où les sessions multicast doivent être acheminées Inondation A la réception de données d une source qui lui est directement connectée vers un groupe multicast, le routeur utilise l inondation pour construire l arbre de plus court chemin vers les hôtes clients. Pour cela, il se contente de réémettre les données vers toutes les interfaces sauf celle où il a reçu les données. Les routeurs avals font de même jusqu'à inondation complète du réseau. Pour éviter les boucles du au maillage du réseau (Figure 7), le routeur décide s il doit acheminer le paquet en effectuant un test sur le chemin de retour, RPF. Figure 7 Ce mode de fonctionnement est un changement important dans la façon dont fonctionnement les routeurs. En unicast, lorsqu un paquet arrive, le routeur recherche l adresse de destination dans sa table de routage pour déterminer l interface sur laquelle il doit acheminer le paquet. En multicast, le routeur détermine s il doit acheminer le paquet en fonction de l adresse source du paquet. Dans la figure 8, un paquet arrive sur l interface S1 du routeur avec l adresse source , celui-ci fait le test RPF en vérifiant dans sa table de routage quelle interface il devrait utiliser pour envoyer un paquet vers cette adresse. La table de routage indique l interface S1 comme chemin pour accéder a la source, le test est Page 15 sur 40

16 validé et le paquet est acheminé sur les autres interfaces. Si le paquet arrive depuis une interface qui ne conduit pas vers la source comme dans la figure 9, le test RPF n est pas validé et le paquet est simplement rejeté. Table de routage unicast Réseau Interface /8 S /16 S /24 S /24 S4 Figure 8 Figure Elagage et greffe L inondation permet la construction de l arbre de plus court chemin vers tous les hôtes clients potentiels. Les routeurs qui n ont aucuns clients ou routeurs à qui acheminer les paquets effectuent un élagage de l arbre. Dans ce cas, le routeur envoie une demande d élagage (PRUNE) vers le routeur amont pour que celui-ci cesse de lui acheminer les données. Les demandes d élagage spécifient le groupe et la source qui caractérise les sessions non désirées. Le routeur mémorise qu il ne doit plus envoyer ces sessions vers l interface où il a reçu la demande jusqu'à la prochaine inondation. Si celui-ci n a à son tour plus aucune interface où acheminer les données, il réitère l opération. Lorsque plusieurs routeurs sont connectés à cette interface, les autres routeurs ont la possibilité d envoyer un message pour joindre explicitement cette session multicast (JOIN) afin de maintenir la réception des données. C est le seul cas d adhésion explicite dans le mode dense. Une fois l élagage de l arbre effectué, les données ne parviennent plus aux routeurs qui en ont fait la demande. Lorsqu un client émet une demande d adhésion pour une session qui a déjà été élaguée par le routeur, ce routeur a la possibilité de recevoir à nouveau les données en émettant une demande de greffe (GRAFT) à l arbre de distribution de cette session. Cette demande remonte vers la source jusqu'à parvenir a un routeur participant a la session et les données recommencent Page 16 sur 40

17 a parvenir jusqu au routeur qui en a fait la demande. Ce mécanisme permet d éviter d attendre la prochaine inondation Election de l expéditeur désigné Sur les réseaux à média partagé comme Ethernet, un routeur ou un hôte client peuvent recevoir la même information de plusieurs routeurs amont ce qui occasionne une surcharge inutile tant au niveau du réseau qu au niveau du routeur ou du client. Les routeurs amont repères ce cas lorsqu ils reçoivent la session multicast qu ils émettent par la même interface. Les routeurs mettent alors en œuvre un mécanisme d élection pour que seul un routeur continue à émettre les données. Chaque routeur envoie un message (ASSERT) pour s affirmer en tant qu expéditeur désigné (DF) et écoute les messages des autres routeurs. Chaque message contient une métrique que les routeurs comparent et seul le routeur qui a la meilleure métrique continue à émettre les données multicast. 2.2PIM SM Alors que le mode dense utilise l inondation pour informer les routeurs de l existence des sources, le mode épar désigne un point de rendez-vous chargé de maintenir une trace de toutes les sources existante. Ce mode suit un modèle d adhésion explicite, les données ne sont acheminées que vers les routeurs qui l ont demandés. Il est définit par la RFC 2362 et est encore en développement par l IETF dans un travail en cours valide jusqu en Avril 2004 et disponible sur leur site [FEN03] Routeur désigné Dans un réseau à média partagé, plusieurs routeurs peuvent desservir un même réseau local. Cependant, seul un routeur doit assurer les fonctions nécessaires à la gestion des adhésions. Ces fonctions sont assurées par le routeur désigné (DR). Celui-ci est élu grâce aux messages HELLO que les routeurs échangent régulièrement. Ces messages transportent une valeur définissant la Page 17 sur 40

18 priorité du routeur pour être élu et les routeurs se considèrent comme élu tant qu ils ne reçoivent pas de message avec une priorité supérieur. En cas d égalité, c est le routeur avec la plus grande adresse IP qui l emporte. Ce mécanisme est similaire a celui d IGMP mais ne doit pas être confondu, le DR de PIM gère les adhésions PIM SM et le DR d IGMP gère les adhésions IGMP Construction de l arbre partagé PIM SM utilise un arbre de distribution basé sur un point de rendez-vous. Quand un DR reçoit une demande d adhésion à un groupe d un hôte client directement connecté, il est chargé de construire la branche qui rejoint l arbre de distribution de ce groupe. Pour ce faire, le routeur envoie une demande d adhésion (JOIN) au voisin qui remonte au point de rendez-vous. Il utilise pour cela un groupe multicast prédéfini (ALL-PIM-ROUTERS) qui ne traverse pas les routeurs. Le voisin mémorise l interface vers laquelle ce groupe doit être acheminé et réitère l opération en envoyant une demande d adhésion à son voisin montant s il ne fait pas parti de l arbre de distribution. La branche est ainsi construite saut après saut jusqu'à la rencontre d un routeur faisant parti de l arbre ou du point de rendez-vous Enregistrement de la source Lorsqu un DR reçoit des paquets d une session multicast d une source directement connectée vers un groupe, il doit acheminer ce paquet vers le point de rendez-vous pour que ce paquet puisse être distribué aux membres du groupe. Si la source émet pour la première fois, il n existe pas d arbre de distribution de cette source vers le point de rendez-vous, le routeur encapsule alors le paquet dans un message d enregistrement qui est envoyé en unicast vers le point de rendez-vous. Le point de rendez-vous vérifie qu il y a un arbre de distribution pour ce groupe, désencapsule les données et les acheminent vers les interfaces qui participent à l arbre de distribution. Si aucun arbre de distribution n existe pour le groupe multicast (il n y a aucun hôte client intéressé par ce groupe), le point de Page 18 sur 40

19 rendez-vous envoie une demande d arrêt d enregistrement au DR de la source. Celui-ci renvoie périodiquement une demande d enregistrement au point de rendezvous au cas où un hôte client ait manifesté son intérêt pour ce groupe et qu un arbre de distribution existe. Ce mode d acheminement n est pas très efficace car il nécessite des routeurs une encapsulation désencapsulation des données. Le point de rendez-vous peut basculer vers un acheminement en mode natif. Pour cela, il envoie une demande d adhésion (JOIN) vers le DR de la source de la même façon que pour la construction des branches de l arbre RPT pour construire saut après saut l arbre de plus court chemin du DR de la source vers le point de rendez-vous. Les données sont alors acheminées simultanément en unicast et en multicast jusqu'à ce qu elles soit reçues en multicast par le point de rendez-vous. Celui-ci envoie une demande d arrêt d enregistrement au DR qui stoppe l envoie en unicast. Le DR de la source continue à envoyer périodiquement un message d enregistrement vide au point de rendez-vous pour savoir s il doit recommencer l enregistrement Recherche de l arbre du plus court chemin L une des particularités de PIM SM comparé à d autres protocoles épars est qu il permet de passer d un arbre basé sur un point de rendez-vous à un arbre de plus court chemin. Lorsque le DR de l hôte client commence à recevoir les données par le RPT, il bascule vers un arbre SPT lorsqu il atteint un seuil de déclenchement. Ce seuil définit le nombre de paquets qui doivent être reçu pour une session avant de basculer, il est généralement définit à zéro ce qui veut dire que l arbre SPT est construit dès la réception du premier paquet. Certains routeurs permettent cependant de configurer ce seuil différemment. Une fois le seuil franchit, le routeur construit la branche de l arbre SPT vers la source. Pour cela, il envoie une demande d adhésion (JOIN) à son voisin qui remonte vers la source pour construire saut après saut la branche de l arbre SPT entre le DR de l hôte client et le DR de la source. Ce dernier, une fois la branche Page 19 sur 40

20 construite, émet alors les données sur les deux branches simultanément. Quand le DR de l hôte client commence à recevoir les données depuis les deux branches, il envoie une demande d élagage vers le point de rendez-vous pour stopper l émission des données depuis cette branche. Si le point de rendez-vous n a plus aucun client a qui envoyer les données, il effectue a son tour un élagage de la branche vers la source Election de l expéditeur désigné Dans certain cas, lorsque plusieurs routeurs sont interconnectés par un média partagé, une même session multicast peut être acheminée en plusieurs exemplaires sur un tel lien. C est le cas lorsque, par exemple, deux routeurs sur ce lien ont des routes différentes pour accéder à une même source. Quand ces deux routeurs rejoignent l arbre de distribution basé sur la source, ils empruntent des branches différentes et chacun acheminent la même session sur le lien. Tout comme dans le mode dense, ceux-ci repère cette situation lorsqu ils reçoivent la session qu ils émettent par la même interface. Ils mettent alors en œuvre le même mécanisme d élection basé sur les messages ASSERT que dans le mode dense. Ceci est la base du fonctionnement du protocole PIM SM, celui-ci prévoit tous les scénarios possibles et est trop complexe pour que tout les cas soient couverts dans ce document. 2.3Gestion des points de rendez-vous Le mode épar de PIM nécessite de définir un point de rendez-vous où les sources peuvent s enregistrer et les hôtes clients rejoindre l arbre de distribution. Chaque point de rendez-vous est définit pour un ensemble de groupe multicast définit par un préfixe et un masque (par exemple /8 définit tout les groupes dont les 8 premiers bits valent 230, la notation est similaire à celle des masques des adresses unicast) et peut être définit statiquement sur chaque routeur du domaine. Cette méthode à l avantage d être simple mais est très lourde à administrer. Page 20 sur 40

21 Plusieurs méthodes permettent de palier à cette lourdeur en définissant des méthodes de configuration dynamique Auto RP Auto RP est à l origine un mécanisme propriétaire de Cisco Systems pour la gestion dynamique des points de rendez-vous. Auto RP s appuie sur une diffusion en mode dense pour la distribution des messages de contrôle. Il nécessite pour cela que les routeurs fonctionnent en mode épar et dense simultanément. Ce mode de fonctionnement, appelé PIM SDM, est lui aussi propriété de Cisco Systems et sera présenté dans la partie sur les variantes de PIM (2.4). Actuellement, Auto RP et PIM SDM sont implémentés par d autres constructeurs comme Juniper Networks. Auto RP définit trois rôles pour les routeurs, chaque routeur participant au multicast joue l un de ces rôles : - Le point de rendez-vous candidat annonce à intervalle de temps régulier les ensembles de groupe pour lesquels il est candidat pour être le point de rendez-vous. Il envoie ces annonces au groupe multicast CISCO-RP-ANNOUNCE. - L agent de mappage (L agent chargé de définir les correspondances entre point de rendez-vous et ensemble de groupe multicast) écoute les annonces sur le groupe CISCO-RP-ANNOUNCE et détermine quel est le point de rendez-vous actif pour chaque ensemble de groupe. Si plusieurs points de rendez-vous se porte candidat pour les mêmes ensembles d adresses, celui qui à la plus grande adresse IP est déclaré actif. Une fois les points de rendez-vous actifs sélectionnés pour chaque ensemble d adresse, l agent de mappage les annonces sur le groupe CISCO-RP-DISCOVERY. - L agent de découverte écoute sur le groupe CISCO-RP-DISCOVERY et apprend les points de rendez-vous pour chaque ensemble d adresse. Les points de rendez-vous candidat et les agents de mappage écoute également ce groupe. Auto RP permet à tous les routeurs d apprendre dynamiquement l emplacement des points de rendez-vous et il autorise une redondance des routeurs dans les différents rôles ce qui permet de palier aux défaillances. Page 21 sur 40

22 2.3.2PIM Bootstrap PIM Bootstrap a été ajouté à la version 2 de PIM comme standard pour la gestion dynamique des groupes. Au niveau fonctionnel, il est très similaire à Auto RP. Il utilise des routeurs Bootstrap (BSR) qui sont chargés de recueillir les informations concernant les points de rendez-vous candidats. Chaque routeur possède un paramètre qui lui permet de connaître sa priorité dans l élection des BSR, 0 signifie que le routeur n est pas éligible. Pour utiliser PIM Bootstrap, un où plusieurs routeurs doivent être configurés comme candidat. Le mécanisme d élection permet d élire le ou les routeurs BSR qui seront chargés de diffuser les informations sur les points de rendez-vous actifs. Chaque routeur BSR candidat émet à intervalle de temps régulier un message Bootstrap contenant son adresse et sa priorité sur toutes ses interfaces. Les routeurs voisins envoient à leur tour ce message vers toutes leurs interfaces sauf celle d où vient le message. Si le message ne vient pas par l interface qui mène au routeur émetteur, le paquet est éliminé. Lorsqu un routeur candidat reçoit un message avec une priorité plus forte que la sienne, il cesse de s annoncer candidat. Les points de rendez-vous candidats envoient en unicast les groupes pour lesquels ils sont candidats ainsi que leur priorité en tant que point de rendez-vous aux routeurs BSR qui émettent des messages Bootstrap. Ceux-ci intègre ces informations dans les messages Bootstrap pour que l ensemble des routeurs soit informé des points de rendez-vous présent sur le réseau. Chaque routeur peut alors calculer le point de rendez-vous actif pour les différents groupes multicast mais il le fait uniquement pour son usage. PIM Bootstrap apporte de la robustesse dans la gestion dynamique des points de rendez-vous comparé à Auto RP, il permet aussi une répartition de la charge sur plusieurs point de rendez-vous pour un même ensemble de groupe par l utilisation d un mécanisme d élection plus évolué Anycast RP Page 22 sur 40

23 Dans les méthodes précédentes, un groupe multicast ne peut avoir qu un seul point de rendez-vous ce qui ne permet pas de répartir la charge pour un groupe ni d avoir de redondance. Anycast RP apporte une solution à ce problème en utilisant des adresses anycast pour les routeurs. Une adresse anycast signifie que plusieurs routeurs partagent la même adresse, lorsque un paquet est émis vers cette adresse, il est acheminé vers le routeur le plus proche. Si ce routeur tombe en panne, le paquet est acheminé vers le routeur suivant le plus proche. Chaque routeur a ainsi une adresse unicast qui lui est propre et une adresse anycast qu il partage. Dans anycast RP, les routeurs doivent connaître les adresses unicast des routeurs avec lesquels ils partagent l adresse anycast. La figure 6 détaille le fonctionnement d Anycast RP. Les routeurs A, B et C partagent une même adresse anycast, une source commence a émettre vers un groupe multicast, le routeur A a deux hôtes intéressés par ce groupe, le routeur B un et le routeur C aucun. Lorsque de DR de la source reçoit les données, il commence par s enregistrer au point de rendez-vous dont l adresse est l adresse anycast (1). Comme le routeur A est le premier routeur avec l adresse anycast rencontré, il traite l enregistrement et commence à acheminer les données vers les clients dont il est le DR (2). Figure 10 Le routeur envoie alors une demande d enregistrement vers les routeurs qui partage l adresse anycast mais en utilisant son adresse unicast comme adresse source du message d enregistrement (3). Le routeur B traite la demande et commence à acheminer les données vers les clients (4). Le routeur C traite la demande mais comme il n a aucun client, il se contente de retourner une demande d arrêt d enregistrement au routeur A (5). Page 23 sur 40

24 Anycast RP est complètement indépendant des autres mécanismes de configuration des points de rendez-vous, il peut donc être combiné avec n importe lequel d entre eux. 2.4Variantes de PIM PIM SM et PIM DM constituent l essentiel des travaux de l IETF concernant PIM. Cependant, pour répondre à des besoins plus spécifiques, plusieurs variantes de PIM ont vu le jour, que se soit pour répondre a une problématique de mise en œuvre ou pour mieux couvrir certains domaines d application du multicast PIM SDM PIM peut fonctionner dans un mode qui combine le mode dense et le mode épar, PIM SDM, c'est un protocole propriétaire de Cisco Systems. Il n est cependant pas implémenté uniquement par Cisco Systems, d autres équipementiers proposent leur implémentation comme par exemple Juniper Networks. PIM SDM permet au routeur de définir le mode de fonctionnement dense ou épar pour chaque groupe multicast. Les implémentations de PIM SDM varient suivant les équipementiers et fonctionnent selon deux modes. Chez Cisco Systems, PIM SDM permet de définir les groupes qui doivent fonctionner en mode épar, les autres groupes sont considérés par défaut comme fonctionnant en mode dense. Ce fonctionnement pose quelques problèmes, si un routeur perd les correspondances entre groupe et point de rendez-vous, il considère alors que tous les groupes sont denses et inonde le réseau de ses groupes. Juniper Networks propose une autre approche en imposant une configuration explicite des groupes qui fonctionnent en mode dense. Page 24 sur 40

25 PIM SDM est idéal pour l implémentation du multicast dans les réseaux ou les architectes ne sont pas sure de la version de PIM, SM ou DM, qui est la plus adapté. C est cependant un usage marginal et temporaire de PIM SDM, celui-ci continue à être implémenté principalement pour supporter le mécanisme de gestion dynamique des points de rendez-vous Auto RP Bi-directional PIM PIM SM construit des arbres unidirectionnels pour acheminer les données des sessions multicast c'est-à-dire que les données ne peuvent aller que du point de rendez-vous vers les hôtes clients. Lorsqu une source veut émettre des données vers un groupe, elle doit encapsuler ses données pour les diffuser en unicast vers le point de rendez-vous qui les désencapsule. La source a la possibilité de créer un arbre de plus court chemin spécifique à la source vers le point de rendez-vous pour basculer vers un acheminement en mode multicast natif. Ces deux mécanismes posent des problèmes dés que le nombre de source se multiplie, il nécessite des ressources supplémentaires que se soit pour l encapsulation ou pour maintenir des arbres de distribution spécifique à chaque source. Bi-directional PIM dispense de l utilisation de l encapsulation et des arbres spécifique aux sources en permettant aux données d être acheminées vers le point de rendez-vous par un arbre partagée. Pour éviter les boucles dans l acheminement des paquets multicast, ce mode introduit un nouveau mécanisme permettant d élire un expéditeur désigné (DF) pour chaque segment réseau ou lien point à point et établit ainsi un arbre de distribution de plus court chemin virtuel sans boucle basé sur le point de rendez-vous. Le mécanisme d élection s appuie sur le coût contenu dans les tables de routages unicast pour élire le DF, celui qui a la meilleure route unicast vers le point de rendez-vous. En cas d égalité, les routeurs sont départagés par leur adresse IP. Le DF ainsi élue est spécifique au point de rendez-vous et, sur chaque lien, il y a autant de DF que de point de rendez-vous avec des groupes bidirectionnels. Un routeur peut cependant être le DF de plusieurs groupes bidirectionnels. Une fois Page 25 sur 40

26 élue, ce routeur est le seul autorisé à acheminer des données vers le point de rendez-vous. Il prend aussi le rôle du DR pour toutes les opérations de construction de l arbre de distribution vers les hôtes clients, ces opérations restent identiques au fonctionnement de PIM SM. La figure 9 illustre ce mode de fonctionnement, une source commence à émettre des données vers un groupe multicast qui a comme point de rendez-vous le routeur C (1), les données sont acheminées par le routeur A (2) qui est le DF pour ce point de rendez-vous sur ce lien. Le routeur B fait de même (3) mais achemine également les données vers ces clients (4). Les données arrivent alors au point de rendez-vous qui les achemine vers le reste de l arbre de distribution selon le mode de distribution classique. Figure 11 En supprimant les états spécifiques aux sources dans les routeurs, le mode bidirectionnel peut supporter un très grand nombre de source simultanément. Par contre, il nécessite qu un DF soit élue sur chaque lien du réseau et pour chaque point de rendez-vous. Son utilisation doit donc utilisé un nombre limité de point de rendez-vous et ne pas couvrir un domaine trop important. Ce mode peut fonctionné en même temps que les autres modes PIM, pour cela les points de rendez-vous des groupes bidirectionnels annoncent que les groupes multicast qu ils supportent sont bidirectionnels PIM SSM Page 26 sur 40

27 Le modèle original de la diffusion multicast supporte aussi bien une communication d une source vers plusieurs destinataires que plusieurs sources vers plusieurs destinataires. Cette approche est désormais connue sous l appellation ASM, Any-Source Multicast. Pour supporter ce modèle, le réseau doit déterminer les sources pour chaque groupe et acheminer les données vers tous les destinataires. En ASM, cette tache de découverte des sources doit être assumée par le réseau. La première approche adoptée par les protocoles en mode dense est d utiliser l inondation pour informer tous les routeurs du réseau des sources existantes et pour acheminer les données. Cette approche a l avantage d être très simple mais devient vite inefficace dés que le nombre de source devient important et elle est inadaptée pour les diffusions à grande échelle. L approche en mode épar corrige ses limitations mais au prix d une complexité supplémentaire nécessaire pour la gestion des points de rendez-vous qui doit être supporté par le réseau. Dans la perspective d une commercialisation, les approches ASM sont jugées trop complexe dans l immédiat pour une généralisation en vue de fournir des services payants. Une nouvelle approche consiste à laisser aux applications la tache de fournir les sources par un moyen de leur choix comme par exemple en cliquant sur un lien dans une page Web. L hôte client peut alors demandé un couple sourcegroupe (Ce couple s appelle alors un canal) pour obtenir les données de la session multicast qui l intéresse. Cette approche appelée multicast à source spécifique ou SSM répond aux besoins des applications jugées intéressantes par les opérateurs Internet car commercialement viables. De plus, elle nécessite seulement une partie des fonctions des protocoles ASM ce qui permet de déployer des versions alléger de ses protocoles et demande moins d expertise pour sa mise en œuvre. Par sa capacité à construire des arbres de plus court chemin basé sur la source, PIM SM est un candidat idéal pour assurer la diffusion à source spécifique. Les implémentations dans la famille PIM, appelée PIM SSM, ne possèdent que la partie des fonctions de PIM SM qui permettent la construction d un arbre de plus court chemin vers la source sans toutes la gestion des points de rendez-vous. Page 27 sur 40

28 PIM SSM nécessite de définir un canal multicast, les clients ne peuvent plus se contenter de s abonner à un groupe multicast, ils doivent aussi spécifier l adresse de la source. La gestion des abonnements aux groupes des clients est assurée par IGMP, le mode SSM utilise les fonctions de la version 3 d IGMP, le mode include, pour permettre au client de donner une source et un groupe pour spécifier le canal. Les abonnements aux sessions ASM ou SSM demande aux routeurs des actions différentes : dans un cas, ils doivent suivre la procédure d adhésion classique au groupe via le point de rendez-vous, dans l autre, ils doivent directement construire l arbre de plus court chemin vers la source. Pour leur permettre de distinguer ces deux cas, une plage d adresse est attribuée au mode SSM. Toutes les demandes d adhésions pour les groupes situés dans la plage /8 sont considérées comme session SSM par les routeurs, si un client s abonne sans spécifier de source ou une source s enregistre à un point de rendez-vous pour un groupe de cette plage, leur demande est rejetée. Ce mode de fonctionnement a un effet de bord intéressant, les sessions multicast étant définies par un canal, un couple source-groupe, chaque groupe multicast de cette plage peut être utilisé simultanément par plusieurs sources sans collision ce qui permet un nombre quasi illimité de sessions SSM simultanées. De plus, il n est plus nécessaire de gérer l allocation des adresses multicast de façon globale, chaque source se charge de gérer la plage d adresse à son usage propre. PIM SSM est vraisemblablement le protocole qui supportera les premières applications commerciales tel que la télévision sur Internet ou la diffusion de dépêches. Sa simplicité permet d envisager sa généralisation sur Internet et sa compatibilité avec PIM SM ne remet pas en cause les installations existantes. De plus, il permet aux entreprises de se familiariser avec le multicast et préparer la mise en œuvre des modes ASM de PIM. Page 28 sur 40

29 3MISE EN ŒUVRE Toutes les technologies présentée jusque là constitue les briques de bases de la diffusion multicast. La famille PIM est par sa diffusion sur Internet le standard de facto du multicast, sa mise en œuvre nécessite de s assurer de la compatibilité du réseau et requiert des technologies complémentaires pour assurer un fonctionnement optimum et pour palier à quelques manques. 3.1Multicast intra domaine Le multicast intra domaine, c'est-à-dire dans un domaine où l administration du réseau est assurée par une seule entité comme un réseau d entreprise ou un campus, offre le plus large choix dans les options d implémentation. Les équipements actuels permettent aisément de combiner les différentes versions de PIM Les hôtes Pour qu une session multicast ait lieu, il faut avant tout au moins un hôte source qui émet des données et un hôte client pour les écouter. La RFC 1112 qui définit le standard multicast classe les hôtes en trois niveaux selon leur degré de compatibilité avec le multicast : - Le niveau 0 : Les hôtes de ce niveau n ont aucune compatibilité. Il n y a aucune obligation à devoir supporter le multicast pour tous les hôtes pour que celuici fonctionne. En général, les hôtes de ce niveau ne sont pas affectés par trafic multicast. Si des paquets multicast sont acheminés par erreurs sur un hôte de niveau 0, ils sont simplement ignorés car leur adresse de classe D n est pas reconnue par celui-ci. - Le niveau 1 : Les hôtes de ce niveau sont compatible avec le multicast pour l émission vers les groupes multicast uniquement. Ceci implique des modifications de l implémentation de leur pile réseau au niveau 2 et 3. Dans la couche 3, l hôte doit prendre en compte le mode d acheminement différent des paquets multicast, ces Page 29 sur 40

30 paquets doivent être acheminés comme des paquets destinés au réseau local. Habituellement la logique d acheminement des paquets est : SI l adresse de destination des paquets est locale ALORS Envoie du paquet localement à l adresse de destination SINON Envoie du paquet au routeur Une implémentation de niveau 1 demande une logique légèrement modifiée : SI l adresse de destination des paquets est locale OU L adresse de destination est un groupe multicast ALORS Envoie du paquet localement à l adresse de destination SINON Envoie du paquet au routeur Dans la couche 2, ces hôtes doivent aussi être en mesure d effectuer la translation de l adresse multicast IP vers l adresse multicast Ethernet. - Le niveau 2 : Les hôtes de ce niveau sont complètements compatibles avec le multicast, ils peuvent aussi bien envoyer que recevoir des données multicast. Pour cela, en plus d implémenter les spécifications du niveau 1, ils doivent aussi implémenter une version du protocole de gestion des groupes IGMP Les routeurs La configuration des routeurs constitue la tache la plus lourde de la mise en œuvre du multicast et doit faire l objet de quelques précautions. Le protocole IGMP doit être implémenté sur l ensemble des routeurs participants. Ce protocole assure une compatibilité montante entre les versions, un routeur peut supporté des clients avec des versions inférieurs sans difficulté. Par contre, il est fortement conseillé d utiliser la même version sur l ensemble des routeurs. Actuellement, les routeurs supportent généralement tous la version 2 d IGMP, les routeurs qui ne la supportent pas doivent être mis à jour ou exclus du domaine multicast. Certains routeurs tel que certains serveurs d accès distant ne supportent pas IGMP ou PIM, une solution consiste à les configurer en tant que Proxy IGMP, lorsqu ils reçoivent des rapports IGMP, il se contente alors de les relayer vers un routeur capable de les gérer. Cette Page 30 sur 40