Vue d’ensemble du multicast

Comparaison du multicast à l’unicast

Le processus de protocole de routage du système d’exploitation Junos® (Junos OS) prend en charge une grande variété de protocoles de routage. Ces protocoles de routage transportent des informations réseau entre les périphériques de routage non seulement pour les flux de trafic unicast envoyés entre une paire de clients et de serveurs, mais également pour les flux de trafic multicast contenant de la vidéo, de l’audio ou les deux, entre une source de serveur unique et de nombreux récepteurs clients. Les protocoles de routage utilisés pour le multicast diffèrent à bien des égards des protocoles de routage unicast.

Les informations sont transmises sur un réseau par trois méthodes de base : unicast, broadcast et multicast.

Les différences entre unicast, broadcast et multicast peuvent être résumées comme suit :

• Unicast : un à un, d’une source à une destination.

• Diffusion : Un à tous, d’une source vers toutes les destinations possibles.

• Multicast : un-à-plusieurs, d’une source vers plusieurs destinations exprimant un intérêt à recevoir le trafic.

  Note:

  Cette liste n’inclut pas de catégorie spéciale pour les applications plusieurs-à-plusieurs, telles que les jeux en ligne ou la vidéoconférence, où il existe de nombreuses sources pour le même récepteur et où les récepteurs servent souvent de sources. Many-to-many est un modèle de service qui utilise de manière répétée le multicast un-à-plusieurs et ne nécessite donc aucun protocole unique. La spécification multicast d’origine, RFC 1112, prend en charge à la fois le modèle ASM (any-source multicast) many-to-many et le modèle un-to-many SSM (source-specific multicast).

Avec le trafic unicast, de nombreux flux de paquets IP qui transitent sur les réseaux partent d’une source unique, telle qu’un serveur de site Web, vers une destination unique, telle qu’un PC client. Le trafic unicast reste la forme la plus courante de transfert d’informations sur les réseaux.

Le trafic de diffusion est acheminé d’une source unique vers toutes les destinations possibles accessibles sur le réseau, qui est généralement un réseau local. La diffusion est le moyen le plus simple de s’assurer que le trafic atteint ses destinations.

Les réseaux de télévision utilisent la radiodiffusion pour distribuer de la vidéo et de l’audio. Même si le réseau de télévision est un système de télévision par câble (CATV), le signal source atteint toutes les destinations possibles, ce qui est la principale raison pour laquelle le contenu de certaines chaînes est brouillé. La diffusion n'est pas possible sur Internet en raison de l'énorme quantité d'informations inutiles qui arriveraient constamment à l'appareil de chaque utilisateur final, de la complexité et de l'impact du brouillage et des problèmes de confidentialité connexes.

Le trafic multicast se situe entre les extrêmes de l’unicast (une source, une destination) et de la diffusion (une source, toutes les destinations). Le multicast est une méthode de distribution du trafic « une source, plusieurs destinations », ce qui signifie que seules les destinations qui indiquent explicitement qu’elles ont besoin de recevoir les informations d’une source particulière reçoivent le flux de trafic.

Sur un réseau IP, étant donné que les destinations (les clients) ne communiquent pas souvent directement avec les sources (serveurs), les équipements de routage entre la source et la destination doivent être en mesure de déterminer la topologie du réseau du point de vue de l’unicast ou du multicast afin d’éviter un routage aléatoire du trafic. Les dispositifs de routage multicast répliquent les paquets reçus sur une interface d’entrée et envoient les copies sur plusieurs interfaces de sortie.

Dans le multicast IP, la source et la destination sont presque toujours des hôtes et non des périphériques de routage. Les dispositifs de routage multicast distribuent le trafic multicast sur le réseau, de la source aux destinations. Le dispositif de routage multicast doit trouver les sources multicast sur le réseau, envoyer des copies des paquets sur plusieurs interfaces, empêcher les boucles de routage, connecter les destinations intéressées à la source appropriée et réduire au minimum le flux de paquets indésirables. Les protocoles de routage multicast standard offrent la plupart de ces capacités, mais certaines architectures de routeur ne peuvent pas envoyer plusieurs copies des paquets et ne prennent donc pas en charge le multicast directement.

Utilisations multicast IP

La multidiffusion permet à un réseau IP de prendre en charge plus que le modèle unicast de transmission de données qui prévalait aux débuts d’Internet. Le multicast, défini à l’origine comme une extension d’hôte dans la RFC 1112 de 1989, fournit une méthode efficace pour fournir des flux de trafic qui peuvent être caractérisés comme un-à-plusieurs ou plusieurs-à-plusieurs.

Le trafic unicast ne se limite pas strictement aux applications de données. Les conversations téléphoniques, sans fil ou non, contiennent des échantillons audio numériques et peuvent contenir des photographies numériques ou même des vidéos et circuler toujours d’une source unique à une destination unique. De la même manière, le trafic multicast n’est pas strictement limité aux applications multimédias. Dans certaines applications de données, le flux de trafic provient d’une source unique vers de nombreuses destinations qui nécessitent des paquets, comme dans le cas d’un service d’actualités ou de téléscripteur boursier fourni à de nombreux PC. Pour cette raison, le terme récepteur est préféré à celui d’écouteur pour les destinations multicast, bien que les deux termes soient courants.

Les applications réseau qui peuvent fonctionner avec l’unicast mais qui sont mieux adaptées au multicast comprennent le groupware collaboratif, la téléconférence, la livraison périodique ou « push » de données (cotations boursières, résultats sportifs, magazines, journaux et publicités), la réplication sur serveur ou sur site Web, et la simulation interactive distribuée (DIS) telle que les simulations de guerre ou la réalité virtuelle. Tout réseau IP soucieux de réduire la surcharge des ressources réseau pour les applications de données ou multimédias un-à-plusieurs ou plusieurs-à-plusieurs avec plusieurs récepteurs bénéficie du multicast.

Si la monodiffusion était utilisée par des services de radio ou de téléscripteur d’actualités, chaque radio ou PC devrait avoir une session de trafic distincte pour chaque auditeur ou téléspectateur sur un PC (c’est en fait la méthode pour certains services Web). La charge de traitement et la bande passante consommées par le serveur augmentent de façon linéaire à mesure que davantage de personnes se connectent au serveur. C’est extrêmement inefficace face à l’échelle mondiale d’Internet. L’unicast fait peser la charge de la duplication des paquets sur le serveur et consomme de plus en plus de bande passante dorsale à mesure que le nombre d’utilisateurs augmente.

Si la diffusion était utilisée à la place, la source pourrait générer un seul flux de paquets IP à l’aide d’une adresse de destination de diffusion. Bien que la diffusion élimine le problème de duplication des paquets du serveur, ce n’est pas une bonne solution pour IP, car les diffusions IP ne peuvent être envoyées qu’à un seul sous-réseau et les périphériques de routage IP isolent normalement les sous-réseaux IP sur des interfaces distinctes. Même si un flux de paquets IP pouvait être adressé pour aller littéralement partout, et qu’il n’y aurait pas besoin de « syntoniser » une source quelconque, la diffusion serait extrêmement inefficace en raison de la pression sur la bande passante et de la nécessité pour des hôtes non intéressés de rejeter un grand nombre de paquets. La diffusion fait peser le rejet de paquets sur chaque hôte et consomme au maximum la bande passante de la dorsale.

Pour le trafic des stations de radio ou des téléscripteurs d’actualités, la multidiffusion fournit le résultat le plus efficace et le plus efficient, sans les inconvénients et tous les avantages des autres méthodes. Une source unique de paquets multicast est acheminée vers chaque destinataire intéressé . Comme pour la diffusion, l’hôte émetteur ne génère qu’un seul flux de paquets IP, de sorte que la charge reste constante, qu’il y ait un récepteur ou un million. Les périphériques de routage réseau répliquent les paquets et les livrent aux récepteurs appropriés, mais seul le rôle de réplication est nouveau pour les périphériques de routage. Les liaisons menant à des sous-réseaux constitués de récepteurs totalement indifférents ne transportent pas de trafic multicast. La multidiffusion réduit la charge qui pèse sur l’émetteur, le réseau et le destinataire.

Terminologie multicast IP

Le multicast a son propre ensemble de termes et d’acronymes qui s’appliquent aux périphériques et aux réseaux de routage multicast IP. La figure 1 illustre certains des termes couramment utilisés dans un réseau multicast IP.

Dans un réseau multicast, l’élément clé est le périphérique de routage, qui est capable de répliquer les paquets et est donc capable de multicast. Les périphériques de routage du réseau multicast IP, qui a exactement la même topologie que le réseau unicast sur lequel il est basé, utilisent un protocole de routage multicast pour construire une arborescence de distribution qui relie les récepteurs (préférés aux implications multimédias des écouteurs, mais les auditeurs sont également utilisés) aux sources. Dans la terminologie multicast, l’arbre de distribution est enraciné à la source (la racine de l’arbre de distribution est la source). L’interface sur le périphérique de routage menant à la source est l’interface en amont , bien que les termes moins précis d’interface entrante ou entrante soient également utilisés. Pour réduire au minimum l’utilisation de la bande passante, il est préférable qu’une seule interface en amont sur le périphérique de routage reçoive les paquets multicast. L’interface sur le périphérique de routage menant aux récepteurs est l’interface en aval , bien que les termes moins précis d’interface sortante ou sortante soient également utilisés. Il peut y avoir de 0 à N–1 interfaces en aval sur un périphérique de routage, où N est le nombre d’interfaces logiques sur le périphérique de routage. Pour éviter la bouclage, l’interface en amont ne doit jamais recevoir de copies des paquets multicast en aval.

Figure 1 : Terminologie multicast dans un réseau IP

Les boucles de routage sont désastreuses dans les réseaux multicast en raison du risque de réplication répétée des paquets. L’une des complexités des protocoles de routage multicast modernes est la nécessité d’éviter les boucles de routage, paquet par paquet, beaucoup plus rigoureusement que dans les protocoles de routage unicast.

Transfert de chemin inverse pour la prévention des boucles

L'état de transfert multicast du périphérique de routage s'exécute de manière plus logique en fonction du chemin inverse, du récepteur à la racine de l'arbre de distribution. En RPF, chaque paquet multicast reçu doit passer un contrôle RPF avant de pouvoir être répliqué ou transféré sur une interface.

Lorsqu’un routeur reçoit un paquet multicast sur une interface, il vérifie l’adresse source . Le routeur vérifie ensuite si la même adresse peut être utilisée comme destination adresse pour revenir à la source via une route unicast. Si l’interface sortante trouvée dans la table de routage unicast est la même interface que celle sur laquelle le paquet multicast a été reçu, le paquet passe la vérification RPF.

Les paquets multicast qui échouent à la vérification RPF sont abandonnés, car l’interface entrante n’est pas sur le chemin le plus court pour revenir à la source. Les périphériques de routage peuvent construire et gérer des tables distinctes à des fins RPF.

Arbre du chemin le plus court pour la prévention des boucles

L’arborescence de distribution utilisée pour le multicast est enracinée à la source et constitue l’arborescence SPT (Shortest Path Tree), mais ce chemin peut être long si la source se trouve à la périphérie du réseau. La mise en place d’un shared tree sur la dorsale sous forme d’arborescence de distribution permet de localiser la source multicast plus au centre du réseau. Les arbres de distribution partagés ayant des racines dans le réseau central sont créés et maintenus par un dispositif de routage multicast fonctionnant comme un point de rendez-vous (RP), une fonctionnalité des protocoles multicast en mode clairsemé.

Portée administrative pour la prévention des boucles

La définition de la portée limite les périphériques de routage et les interfaces qui peuvent transmettre un paquet multicast. La portée multicast est administrative dans le sens où une plage d’adresses multicast est réservée à des fins de portée, comme décrit dans la RFC 2365, Administratively Scoped IP Multicast. Les dispositifs de routage à la frontière doivent filtrer les paquets multicast et s’assurer qu’ils ne s’égarent pas au-delà de la limite établie.

Terminologie des branches et des branches multicast

Chaque sous-réseau avec des hôtes sur le périphérique de routage qui a au moins un récepteur intéressé est une feuille sur l’arbre de distribution. Les périphériques de routage peuvent avoir plusieurs feuilles sur différentes interfaces et doivent envoyer une copie du paquet multicast IP sur chaque interface avec une branche. Lorsqu’un nouveau sous-réseau leaf est ajouté à l’arborescence (c’est-à-dire que l’interface du sous-réseau hôte n’avait reçu aucune copie des paquets multicast), une nouvelle branche est construite, la branche leaf est jointe à l’arborescence et les paquets répliqués sont envoyés sur l’interface. Le nombre de quittances sur une interface particulière n’affecte pas le périphérique de routage. L’action est la même pour une feuille ou une centaine.

Lorsqu’une branche ne contient pas de feuilles parce qu’il n’y a pas d’hôtes intéressés sur l’interface du périphérique de routage menant à ce sous-réseau IP, la branche est élaguée de l’arborescence de distribution et aucun paquet multicast n’est envoyé à cette interface. Les paquets sont répliqués et envoyés à plusieurs interfaces uniquement là où l’arbre de distribution se ramifie au niveau d’un périphérique de routage, et aucune liaison ne transporte jamais de flux de paquets en double.

Les ensembles d’hôtes recevant tous le même flux de paquets IP, généralement à partir de la même source multicast, sont appelés groupes. Dans les réseaux multicast IP, le trafic est transmis à des groupes multicast en fonction d’une adresse multicast IP ou d’une adresse de groupe. Les groupes déterminent l’emplacement des branches, et les branches déterminent les branches sur le réseau multicast.

Adressage multicast IP

La multidiffusion utilise la plage d’adresses IP de classe D (224.0.0.0 à 239.255.255.255). Les adresses de classe D sont communément appelées adresses multicast , car l’ensemble du concept d’adresse de classe est obsolète. Les adresses multicast ne peuvent jamais apparaître comme l’adresse source dans un paquet IP et ne peuvent être que la destination d’un paquet.

Les adresses multicast ont généralement une longueur de préfixe de /32, bien que d’autres longueurs de préfixe soient autorisées. Les adresses multicast représentent des regroupements logiques de récepteurs et non des collections physiques de périphériques. Les blocs d’adresses multicast peuvent toujours être décrits en termes de longueur de préfixe en notation traditionnelle, mais seulement pour des raisons de commodité. Par exemple, la plage d’adresses multicast comprise entre 232.0.0.0 et 232.255.255.255 peut être écrite sous la forme 232.0.0.0/8 ou 232/8.

Les fournisseurs d’accès à Internet (FAI) n’allouent généralement pas d’adresses multicast à leurs clients, car les adresses multicast se rapportent au contenu et non aux périphériques physiques. Les destinataires ne se voient pas attribuer leurs propres adresses multicast, mais doivent connaître l’adresse multicast du contenu. Les sources ne doivent se voir attribuer des adresses multicast que pour produire le contenu, et non pour identifier leur place dans le réseau. Chaque source et récepteur a toujours besoin d’une adresse IP unicast ordinaire.

L’adressage multicast fait le plus souvent référence aux récepteurs, et la source du contenu multicast n’est généralement même pas membre du groupe multicast pour lequel il produit du contenu. Si la source a besoin de surveiller les paquets qu’elle produit, la surveillance peut être effectuée localement et il n’est pas nécessaire de faire transiter les paquets par le réseau.

De nombreuses applications se sont vu attribuer une plage d’adresses multicast pour leur propre usage. Ces applications attribuent des adresses multicast aux sessions créées par cette application. Vous n’avez généralement pas besoin d’attribuer une adresse multicast de manière statique, mais vous pouvez le faire.

Adresses multicast

Les adresses de groupe hôte multicast sont définies comme étant les adresses IP dont les quatre bits d’ordre supérieur sont 1110, ce qui donne une plage d’adresses allant de 224.0.0.0 à 239.255.255.255, ou simplement 224.0.0.0/4. (Ces adresses sont également appelées adresses de classe D.)

L’Internet Assigned Numbers Authority (IANA) tient à jour une liste des groupes de multicast IP enregistrés. L’adresse de base 224.0.0.0 est réservée et ne peut être attribuée à aucun groupe. Le bloc d’adresses multicast de 224.0.0.1 à 224.0.0.255 est réservé à une utilisation filaire locale. Les groupes de cette plage sont affectés à diverses utilisations, notamment les protocoles de routage et les mécanismes de découverte locaux.

La plage comprise entre 239.0.0.0 et 239.255.255.255 est réservée aux adresses de portée administrative. Étant donné que les paquets adressés à des adresses multicast délimitées administrativement ne franchissent pas les limites administratives configurées et que les adresses multicast délimitées administrativement sont attribuées localement, ces adresses n’ont pas besoin d’être uniques au-delà des limites administratives.

Trames de couche 2 et adresses multicast IPv4

La multidiffusion sur un réseau local est un bon point de départ pour étudier la multidiffusion au niveau de la couche 2. Au niveau de la couche 2, le multicast traite les trames et les adresses MAC (Media Access Control) au lieu des paquets et adresses IPv4 ou IPv6. Prenons l’exemple d’un réseau local unique, sans équipement de routage, avec une source de multidiffusion envoyant à un certain groupe. Le reste des hôtes sont des récepteurs intéressés par le contenu du groupe multicast. Ainsi, l’hôte source multicast génère des paquets avec son adresse IP unicast comme source et l’adresse du groupe multicast comme destination.

Quelles adresses MAC sont utilisées sur la trame contenant ce paquet ? L’adresse source du paquet, c’est-à-dire l’adresse IP unicast de l’hôte à l’origine du contenu multicast, se traduit facilement et directement par l’adresse MAC de la source. Mais qu’en est-il de l’adresse de destination du paquet ? Il s’agit de l’adresse du groupe multicast IP. Quelle adresse MAC de destination pour la trame correspond à l’adresse du groupe multicast du paquet ?

Une option pour les LAN consiste simplement à utiliser l’adresse MAC de diffusion LAN, ce qui garantit que la trame est traitée par chaque station sur le LAN. Cependant, cette procédure va à l’encontre de l’objectif même du multicast, qui est de limiter la circulation des paquets et des trames vers les hôtes intéressés. En outre, les hôtes peuvent avoir accès à de nombreux groupes multicast, ce qui multiplie la quantité de trafic vers des destinations non intéressées. Diffuser des trames au niveau du LAN pour prendre en charge des groupes multicast n’a aucun sens.

Cependant, il existe un moyen simple d’utiliser efficacement les images de couche 2 à des fins de multidiffusion. L’adresse MAC a un bit qui est défini sur 0 pour unicast (le terme LAN est adresse individuelle) et défini sur 1 pour indiquer qu’il s’agit d’une adresse multicast. Certaines de ces adresses sont réservées à des groupes multicast de fournisseurs spécifiques ou à des protocoles de niveau MAC. Les applications multicast Internet utilisent la plage 0x01-00-5E-00-00-00-00 à 0x01-00-5E-FF-FF-FF. Les récepteurs multicast (hôtes exécutant TCP/IP) écoutent les trames avec l’une de ces adresses lorsque l’application rejoint un groupe multicast. L’hôte cesse d’écouter lorsque l’application se termine ou qu’il quitte le groupe au niveau de la couche paquet (couche 3).

Cela signifie que 3 octets, ou 24 bits, sont disponibles pour mapper des adresses multicast IPv4 au niveau de la couche 3 à des adresses multicast MAC au niveau de la couche 2. Cependant, toutes les adresses IPv4, y compris les adresses multicast, ont une longueur de 32 bits, ce qui laisse 8 bits d’adresse IP restants. Quelle méthode de mappage des adresses multicast IPv4 aux adresses multicast MAC minimise le risque de « collisions » (c’est-à-dire que deux groupes multicast IP différents au niveau de la couche paquet sont mappés à la même adresse multicast MAC au niveau de la couche trame) ?

Tout d’abord, il est important de réaliser que toutes les adresses multicast IPv4 commencent par les mêmes 4 bits (1110), il n’y a donc vraiment que 4 bits de problème, pas 8. Un réseau local ne doit pas perdre les derniers bits de l’adresse IPv4, car il est presque garanti qu’il s’agit de bits d’hôte, selon le masque de sous-réseau. Mais les bits de poids fort, les bits d’adresse les plus à gauche, sont presque toujours des bits de réseau, et il n’y a qu’un seul LAN (pour l’instant).

Un autre bit des 24 bits d’adresse MAC restants est réservé (un 0 initial indique une adresse multicast Internet), de sorte que les 5 bits suivant le 1110 initial dans l’adresse IPv4 sont supprimés. Les 23 bits restants sont mappés, un par un, dans les 23 derniers bits de l’adresse MAC. Un exemple de ce processus est illustré à la figure 2.

Figure 2 : conversion d’adresses MAC en adresses multicast

Notez que ce processus signifie qu’il existe 32 (2⁵) adresses multicast IPv4 qui peuvent être mappées aux mêmes adresses multicast MAC. Par exemple, les adresses IPv4 multicast 224.8.7.6 et 229.136.7.6 se traduisent par le même adresse MAC (0x01-00-5E-08-07-06). C’est une réelle préoccupation, et parce que l’hôte pourrait être intéressé par les trames envoyées à ces deux groupes multicast, le logiciel IP doit rejeter l’un ou l’autre.

Une fois que l'adresse MAC du groupe multicast est déterminée, le système d'exploitation de l'hôte ordonne à la carte d'interface LAN de rejoindre ou de quitter le groupe multicast. Une fois joint à un groupe multicast, l’hôte accepte les trames envoyées à l’adresse multicast ainsi que l’adresse unicast de l’hôte et ignore les trames des autres groupes multicast. Bien sûr, il est possible pour un hôte de rejoindre et de recevoir du contenu multicast de plus d’un groupe en même temps.

Listes d’interfaces multicast

Pour éviter les boucles de routage multicast, chaque périphérique de routage multicast doit toujours connaître l’interface qui mène à la source de ce contenu de groupe multicast par le chemin le plus court. Il s’agit de l’interface montante (entrante), et les paquets ne doivent jamais être redirigés vers une source multicast. Toutes les autres interfaces sont des interfaces potentielles en aval (sortantes), en fonction du nombre de branches sur l’arbre de distribution.

Les périphériques de routage surveillent de près l’état des interfaces entrantes et sortantes, un processus qui détermine l’état du transfert multicast. Un périphérique de routage avec un état de transfert multicast pour un groupe multicast particulier est essentiellement « activé » pour le contenu de ce groupe. Les interfaces figurant dans la liste des interfaces sortantes du périphérique de routage envoient des copies des paquets du groupe reçus dans la liste des interfaces entrantes de ce groupe. Les listes d’interfaces entrantes et sortantes peuvent être différentes pour différents groupes de multidiffusion.

L’état de transfert multicast dans un périphérique de routage est généralement écrit en notation (S,G) ou (*,G). Ceux-ci se prononcent respectivement « ess virgule » et « étoile virgule gee ». Dans (S,G), le S fait référence à l’adresse IP unicast de la source du trafic multicast, et le G fait référence à l’adresse IP du groupe multicast particulier pour lequel S est la source. Tous les paquets multicast envoyés à partir de cette source ont S comme adresse source et G comme adresse de destination.

L’astérisque (*) dans la notation (*,G) est un caractère générique indiquant que l’état s’applique à toute source d’application multicast envoyant au groupe G. Ainsi, si deux sources proviennent exactement du même contenu pour le groupe multicast 224.1.1.2, un périphérique de routage peut utiliser (*,224.1.1.2) pour représenter l’état d’un périphérique de routage transférant le trafic des deux sources au groupe.

Protocoles de routage multicast

Les protocoles de routage multicast permettent à un ensemble de périphériques de routage multicast de créer (joindre) des arbres de distribution lorsqu’un hôte d’un sous-réseau directement connecté, généralement un réseau local, souhaite recevoir le trafic d’un certain groupe multicast, élaguer les branches, localiser les sources et les groupes et empêcher les boucles de routage.

Il existe plusieurs protocoles de routage multicast :

• Distance Vector Multicast Routing Protocol (DVMRP) : le premier des protocoles de routage multicast, entravé par un certain nombre de limitations qui rendent cette méthode peu attrayante pour une utilisation Internet à grande échelle. DVMRP est un protocole en mode dense uniquement, et utilise la méthode d’inondation et d’élagage ou de jointure implicite pour distribuer le trafic partout, puis déterminer où se trouvent les récepteurs non intéressés. DVMRP utilise des arbres de distribution basés sur les sources sous la forme (S,G) et construit ses propres tables de routage multicast pour les vérifications RPF.

• Multicast OSPF (MOSPF) : étend l’OSPF pour le multicast, mais uniquement pour le Dense Mode. Cependant, MOSPF dispose d’un message de jonction explicite, de sorte que les périphériques de routage n’ont pas à inonder l’ensemble de leur domaine de trafic multicast provenant de toutes les sources. MOSPF utilise des arbres de distribution basés sur les sources sous la forme (S,G).

• Mode PIM bidirectionnel : une variante de PIM. Le PIM bidirectionnel crée des arborescences partagées bidirectionnelles qui sont enracinées à une adresse de point de rendez-vous (RP). Le trafic bidirectionnel ne bascule pas vers les arbres de chemins les plus courts comme dans PIM-SM et est donc optimisé pour la taille de l’état de routage plutôt que pour la longueur du chemin. Cela signifie que la latence de bout en bout peut être plus longue qu’en mode clairsemé PIM. Les routes PIM bidirectionnelles sont toujours des routes source génériques (*,G). Le protocole élimine le besoin de routes (S,G) et d’événements déclenchés par les données. Les arborescences de groupes bidirectionnelles (*,G) transportent le trafic à la fois en amont des émetteurs vers le RP et en aval du RP vers les récepteurs. Par conséquent, les règles strictes basées sur le transfert de chemin inverse (RPF) que l’on trouve dans d’autres modes PIM ne s’appliquent pas au PIM bidirectionnel. Au lieu de cela, le PIM bidirectionnel (*,G) achemine le trafic vers l’avant à partir de toutes les sources et du RP. Les dispositifs de routage PIM bidirectionnels doivent avoir la capacité d’accepter du trafic sur de nombreuses interfaces entrantes potentielles. Le PIM bidirectionnel est bien évolutif car il n’a pas besoin d’état spécifique à la source (S,G). Le PIM bidirectionnel est recommandé dans les déploiements comportant de nombreuses sources et récepteurs dispersés.

• PIM Dense Mode : dans ce mode de PIM, l’hypothèse est que presque tous les sous-réseaux possibles ont au moins un récepteur souhaitant recevoir le trafic multicast d’une source, de sorte que le réseau est inondé de trafic sur toutes les branches possibles, puis réduit lorsque les branches n’expriment pas d’intérêt à recevoir les paquets, explicitement (par message) ou implicitement (délai d’expiration). Il s’agit du Dense Mode du fonctionnement multicast. Les réseaux locaux sont des réseaux adaptés à un fonctionnement en mode dense. Certains protocoles de routage multicast, en particulier les plus anciens, ne prennent en charge qu’un fonctionnement en mode dense, ce qui les rend inappropriés pour une utilisation sur Internet. Contrairement au DVMRP et au MOSPF, le mode PIM Dense Mode permet à un équipement de routage d’utiliser n’importe quel protocole de routage unicast et effectue des vérifications RPF à l’aide de la table de routage unicast. Le PIM Dense Mode a un message de jointure implicite, de sorte que les périphériques de routage utilisent la méthode d’inondation et d’élagage pour acheminer le trafic partout, puis déterminer où se trouvent les récepteurs non intéressés. Le PIM Dense Mode utilise des arbres de distribution basés sur les sources sous la forme (S,G), comme tous les protocoles en mode dense. Le PIM prend également en charge le mode clairsemé-Dense Mode, avec un mélange de groupes clairsemés et denses, mais il n’existe pas de notation spéciale pour ce mode opérationnel. Si le Dense Mode clairsemé est pris en charge, le protocole de routage multicast permet à certains groupes multicast d’être clairsemés et à d’autres groupes d’être denses.

• Mode clairsemé PIM : dans ce mode de PIM, l’hypothèse est que très peu de récepteurs possibles veulent des paquets de chaque source, de sorte que le réseau établit et envoie des paquets uniquement sur les branches qui ont au moins une branche indiquant (par message) un intérêt pour le trafic. Ce protocole multicast permet à un périphérique de routage d’utiliser n’importe quel protocole de routage unicast et d’effectuer des vérifications RPF (Reverse-Path Forwarding) à l’aide de la table de routage unicast. Le mode clairsemé PIM dispose d’un message de jointure explicite , de sorte que les dispositifs de routage déterminent où se trouvent les récepteurs intéressés et envoient des messages de jonction en amont à leurs voisins, en créant des arbres entre les récepteurs et le point de rendez-vous (RP). Le mode clairsemé PIM utilise un dispositif de routage RP comme source initiale du trafic de groupe multicast et construit donc des arbres de distribution sous la forme (*,G), comme le font tous les protocoles en mode clairsemé. Le mode clairsemé PIM migre vers une arborescence basée sur la source (S,G) si ce chemin est plus court que celui qui passe par le RP pour le trafic d'un groupe de multicast particulier. Les WAN sont des réseaux appropriés pour un fonctionnement en mode clairsemé, et en effet, une directive courante en matière de multicast est de ne pas exécuter le Dense Mode sur un WAN en aucune circonstance.

• Arbres basés sur les cœurs (CBT) : partage toutes les caractéristiques du mode clairsemé PIM (mode clairsemé, jointure explicite et arbres partagés (*,G)), mais serait plus efficace pour trouver des sources que le mode clairsemé PIM. La TCC est rarement rencontrée en dehors des discussions universitaires. Il n’y a pas de déploiements à grande échelle de la TCC, qu’elle soit commerciale ou autre.

• PIM source-specific multicast (SSM) : amélioration du mode clairsemé PIM qui permet à un client de recevoir du trafic multicast directement de la source, sans l’aide d’un RP. Utilisé avec IGMPv3 pour créer une arborescence du chemin le plus court entre le récepteur et la source.

• IGMPv1 : protocole d’origine défini dans la RFC 1112, Extensions d’hôte pour le multicast IP. IGMPv1 envoie un message de jonction explicite au périphérique de routage, mais utilise un délai d’expiration pour déterminer quand les hôtes quittent un groupe. Trois versions du protocole IGMP (Internet Group Management Protocol) sont exécutées entre les hôtes récepteurs et les périphériques de routage.

• IGMPv2 : défini dans la RFC 2236, Internet Group Management Protocol, version 2. Entre autres fonctionnalités, IGMPv2 ajoute un message de départ explicite au message de rejoindre.

• IGMPv3 : défini dans la RFC 3376, Internet Group Management Protocol, version 3. Entre autres fonctionnalités, IGMPv3 optimise la prise en charge d’une source unique de contenu pour un groupe multicast, ou multicast spécifique à la source (SSM). Utilisé avec PIM SSM pour créer une arborescence du chemin le plus court entre le récepteur et la source.

• Routeur d’amorçage (BSR) et point de rendez-vous automatique (RP) : permettent aux protocoles de routage en mode clairsemé de trouver des RP dans le domaine de routage (système autonome ou AS). Les adresses RP peuvent également être configurées de manière statique.

• Multicast Source Discovery Protocol (MSDP) : permet aux groupes situés dans un domaine de routage multicast de trouver des RP dans d’autres domaines de routage. MSDP n’est pas utilisé sur un RP si tous les récepteurs et sources se trouvent dans le même domaine de routage. S’exécute généralement sur le même périphérique de routage que PIM en mode clairsemé RP. Cela ne convient pas si tous les récepteurs et toutes les sources se trouvent dans le même domaine de routage.

• SAP (Session Announcement Protocol) et SDP (Session Description Protocol) : affichent les noms des sessions multicast et les mettent en corrélation avec le trafic multicast. SDP est un protocole d’annuaire de sessions qui annonce les sessions de conférence multimédia et communique les informations de configuration aux participants qui souhaitent rejoindre la session. Un client utilise généralement SDP pour annoncer une session de conférence en multidiffusant périodiquement un paquet d’annonce vers une adresse multicast et un port bien connus à l’aide de SAP.

• PGM (Pragmatic General Multicast) : couche de protocole spéciale pour le trafic multicast, qui peut être utilisée entre la couche IP et l’application multicast pour renforcer la fiabilité du trafic multicast. PGM permet à un récepteur de détecter les informations manquantes dans tous les cas et de demander des informations de remplacement si l’application du récepteur l’exige.

Les différences entre les protocoles de routage multicast sont résumées dans le Tableau 1.

Il est important de savoir que les retransmissions dues à un taux élevé d’erreur binaire sur une liaison ou à un périphérique de routage surchargé peuvent rendre le multicast aussi inefficace que l’unicast répété. Par conséquent, dans de nombreuses applications multicast, il existe un compromis concernant la prise en charge des sessions fournie par le protocole TCP (Transmission Control Protocol) (mais TCP renvoie toujours les segments manquants), ou la simple stratégie d’abandon et de continuation du service de datagramme UDP (User Datagram Protocol) (mais la réorganisation peut devenir un problème). Le multicast moderne utilise presque exclusivement le protocole UDP.

Performances multicast du routeur T Series

Les routeurs centraux Juniper Networks T Series répondent aux exigences extrêmes de réplication de paquets multicast avec une charge de routeur minimale. Chaque composant de mémoire réplique un paquet multicast deux fois au maximum. Même dans le pire des cas impliquant une distribution maximale, lorsque 1 port d’entrée et 63 ports de sortie ont besoin d’une copie du paquet, la plate-forme de routage T Series ne copie un paquet multicast que six fois. La plupart des arbres de distribution multicast sont beaucoup plus clairsemés, de sorte que dans de nombreux cas, seules deux ou trois réplications sont nécessaires. En aucun cas, l’architecture de la T Series n’a d’impact sur les performances multicast, même avec les exigences de fan-out multicast les plus importantes.