Multidiffusion indépendante du protocole

Le protocole PIM ( Protocol-Independent Multicast ) est une famille de protocoles de routage multidiffusion pour les réseaux IP ( Internet Protocol ) qui fournissent une distribution de données de type un-à-plusieurs et plusieurs-à-plusieurs sur un réseau local , un réseau étendu ou Internet . Il est qualifié d'indépendant du protocole car le protocole PIM n'inclut pas son propre mécanisme de découverte de topologie , mais utilise à la place les informations de routage fournies par d'autres protocoles de routage . Le protocole PIM ne dépend pas d'un protocole de routage unicast spécifique ; il peut utiliser n'importe quel protocole de routage unicast utilisé sur le réseau. Le protocole PIM ne crée pas ses propres tables de routage . Le protocole PIM utilise la table de routage unicast pour la transmission par chemin inverse .

Il existe quatre variantes de PIM :

• Le mode PIM Sparse (PIM-SM) construit explicitement des arbres partagés unidirectionnels enracinés à un point de rendez-vous (RP) par groupe et crée éventuellement des arbres de chemin le plus court par source. Le mode PIM-SM s'adapte généralement assez bien pour une utilisation sur une zone étendue.
• Le mode dense PIM (PIM-DM) construit implicitement des arbres de chemin le plus court en inondant le trafic multicast sur l'ensemble du domaine, puis en élaguant les branches de l'arbre où aucun récepteur n'est présent. Le mode dense PIM (PIM-DM) est simple à mettre en œuvre mais présente généralement de faibles propriétés de mise à l'échelle. Le premier protocole de routage multicast, DVMRP, utilisait le routage multicast en mode dense. Voir RFC 3973.
• Le PIM bidirectionnel (Bidir-PIM) crée explicitement des arbres bidirectionnels partagés. Il ne crée jamais d'arbre de chemin le plus court, il peut donc avoir des délais de bout en bout plus longs que le PIM-SM, mais il s'adapte bien car il n'a pas besoin d'état spécifique à la source. Voir RFC 5015.
• PIM Source-Specific Multicast (PIM-SSM) construit des arborescences qui sont enracinées dans une seule source, offrant un modèle plus sécurisé et évolutif pour un nombre limité d'applications (principalement la diffusion de contenu). Dans SSM, un datagramme IP est transmis par une source S à une adresse de destination SSM G, et les récepteurs peuvent recevoir ce datagramme en s'abonnant au canal (S, G). Voir la RFC 3569 informative.

PIM-SM est couramment utilisé dans les systèmes IPTV pour acheminer les flux multidiffusion entre les VLAN , les sous-réseaux ou les réseaux locaux.

Il existe deux versions de PIM. Les versions ne sont pas directement compatibles mais peuvent coexister sur le même réseau. L'équipement réseau peut implémenter les deux versions. PIMv2 présente les améliorations suivantes par rapport à PIMv1 : un seul RP est utilisé par groupe. La découverte RP est réalisée par un routeur Bootstrap (BSR). Les groupes sont en mode clairsemé ou dense ; les interfaces peuvent être l'un ou l'autre. Améliorations générales de la flexibilité et de l'efficacité du protocole.

Le protocole Protocol Independent Multicast - Sparse-Mode ( PIM-SM ) est un protocole permettant de router efficacement les paquets IP ( Internet Protocol ) vers des groupes de multidiffusion pouvant couvrir des réseaux Internet étendus et inter-domaines . Le protocole est appelé protocole indépendant car il ne dépend d'aucun protocole de routage monodiffusion particulier pour la découverte de la topologie, et mode clairsemé car il convient aux groupes où un très faible pourcentage de nœuds (et de leurs routeurs ) s'abonneront à la session de multidiffusion. Contrairement aux protocoles de routage multidiffusion en mode dense antérieurs tels que DVMRP et le routage multidiffusion dense qui inondaient les paquets sur le réseau puis élaguaient les branches où il n'y avait pas de récepteurs, PIM-SM construit explicitement une arborescence de chaque expéditeur aux récepteurs du groupe de multidiffusion.

Un routeur reçoit des messages explicites Join/Prune de la part des routeurs voisins qui ont des membres de groupe en aval.

• Pour rejoindre un groupe de multidiffusion, G, un hôte transmet ses informations d'appartenance via le protocole de gestion de groupe Internet (IGMP).
• Le routeur transmet ensuite les paquets de données adressés à un groupe de multidiffusion G uniquement aux interfaces sur lesquelles des jointures explicites ont été reçues.
• Un routeur désigné (DR) envoie des messages d'adhésion/d'élagage périodiques vers un point de rendez-vous (RP) spécifique au groupe pour chaque groupe pour lequel il possède des membres actifs.
  • Notez qu'un routeur sera automatiquement ou statiquement désigné comme point de rendez-vous (RP), et tous les routeurs doivent explicitement se joindre via le RP.
• Chaque routeur le long du chemin vers le RP crée un état générique (toute source) pour le groupe et envoie des messages Join/Prune vers le RP.
  • Le terme entrée de route est utilisé pour désigner l’état maintenu dans un routeur pour représenter l’arbre de distribution.
  • Une entrée d'itinéraire peut inclure des champs tels que :
    • adresse source
    • l'adresse du groupe
    • l'interface entrante à partir de laquelle les paquets sont acceptés
    • la liste des interfaces sortantes vers lesquelles les paquets sont envoyés
    • minuteries, bits d'indicateur, etc.
  • L'interface entrante de l'entrée de route générique pointe vers le RP
  • Les interfaces sortantes pointent vers les routeurs voisins en aval qui ont envoyé des messages Join/Prune vers le RP ainsi que vers les hôtes directement connectés qui ont demandé l'adhésion au groupe G.
• Cet état crée une arborescence de distribution partagée, centrée sur RP, qui atteint tous les membres du groupe.

• Lorsqu'une source de données envoie pour la première fois à un groupe, son routeur désigné (DR) diffuse des messages d'enregistrement au point de rendez-vous (RP) avec les paquets de données de la source encapsulés à l'intérieur.
• Si le débit de données est élevé, le RP peut renvoyer des messages Join/Prune spécifiques à la source vers la source et les paquets de données de la source suivront l'état de transfert résultant et voyageront non encapsulés vers le RP.
• Qu'ils arrivent encapsulés ou de manière native, le RP transmet les paquets de données décapsulés de la source dans l'arbre de distribution centré sur le RP vers les membres du groupe.
• Si le débit de données le justifie, les routeurs dotés de récepteurs locaux peuvent rejoindre un arbre de distribution de chemin le plus court spécifique à la source et élaguer les paquets de cette source de l'arbre partagé centré sur RP.
• Pour les sources à faible débit de données, ni le RP ni les routeurs de dernier saut n'ont besoin de rejoindre un arbre de chemin le plus court spécifique à la source et les paquets de données peuvent être livrés via l'arbre RP partagé.

Une fois que les autres routeurs qui doivent recevoir ces paquets de groupe se sont abonnés, le RP se désabonne de ce groupe de multidiffusion, à moins qu'il ne doive également transférer des paquets vers un autre routeur ou nœud. De plus, les routeurs utiliseront la transmission par chemin inverse pour garantir qu'il n'y a pas de boucles pour la transmission de paquets entre les routeurs qui souhaitent recevoir des paquets de multidiffusion.

Le mode multicast dense est un mode que le multicast peut utiliser pour construire une arborescence permettant d'envoyer des paquets aux abonnés multicast. Il s'agit d'une alternative au mode sparse.

Le mode dense repose sur l'hypothèse de base selon laquelle le flux de paquets multicast a des récepteurs dans la plupart des emplacements. Le mode clairsemé suppose un nombre relativement réduit de récepteurs. Le mode dense est idéal pour les groupes dans lesquels de nombreux nœuds s'abonnent pour recevoir les paquets multicast, de sorte que la plupart des routeurs doivent recevoir et transmettre ces paquets (groupes à haute densité).

Cette différence apparaît dans le comportement et les mécanismes initiaux des deux protocoles. Le mode dense utilise une approche assez simple pour gérer le routage multicast IP . La source diffuse initialement vers chaque routeur qui lui est directement connecté. Ces routeurs voisins transmettent ensuite les données à leurs voisins. Lorsqu'un routeur ne souhaite pas recevoir les données de ce groupe (si aucun autre routeur PIM voisin n'est présent et qu'aucun hôte n'est intéressé par le groupe), il envoie un message Prune pour indiquer son manque d'intérêt. À la réception d'un message Prune, le routeur modifiera son état afin de ne pas transmettre ces paquets à cette interface . Si chaque interface d'un routeur est élaguée, le routeur sera également élagué.

Dans les versions antérieures de Cisco IOS, PIM-DM réinjectait tout le trafic de multidiffusion toutes les 3 minutes. Cela convient parfaitement aux flux de multidiffusion à faible volume, mais pas aux flux de paquets de multidiffusion à bande passante plus élevée. Les versions plus récentes de Cisco IOS prennent en charge une nouvelle fonctionnalité appelée PIM Dense Mode State Refresh, depuis la version 12.1(5)T. Cette fonctionnalité utilise des messages d'actualisation d'état PIM pour actualiser l'état Prune sur les interfaces sortantes. Un autre avantage est que les changements de topologie sont reconnus plus rapidement. Par défaut, les messages d'actualisation d'état PIM sont envoyés toutes les 60 secondes.

De plus, les routeurs utiliseront la transmission par chemin inverse pour garantir qu'il n'y a pas de boucles pour la transmission de paquets entre les routeurs qui souhaitent recevoir des paquets de multidiffusion. Lorsqu'un paquet de données est reçu sur une interface non RPF, un mécanisme est nécessaire pour empêcher les boucles. Si l'interface non RPF est un LAN, un message Assert est envoyé. Les routeurs non-Forwarder envoient ensuite un Prune sur leur interface RPF s'ils n'ont pas besoin du flux de multidiffusion. Un seul Prune de ce type est envoyé, au moment de la transition vers l'absence d'interfaces dans la liste des interfaces sortantes (OILIST). Le récepteur LAN Prune retarde son action pendant 3 secondes, de sorte que si un autre routeur LAN a toujours besoin du flux de multidiffusion, il peut envoyer un message PIM Join pour contrecarrer (annuler) le Prune. (« Ce routeur n'en a pas besoin, mais moi j'en ai quand même besoin ! »)

Supposons qu'un routeur a effectué un élagage et qu'un récepteur demande plus tard le flux multicast avec un message IGMP. Le routeur envoie alors un message Graft. En fait, cela signifie : « Hé, j'ai besoin de ce flux multicast ici maintenant ».