Introduction
Nous avons parlé de la multidiffusion IP. Ce mois-ci, je vais commencer à couvrir le mode PIM Sparse. Articles précédents qui pourraient vous intéresser :
- Les protocoles de la multidiffusion IP
- Mode dense PIM
Sparse Versus Dense Mode
Rappelons que le mode dense PIM est utilisé (en principe) lorsque la multidiffusion est souhaitée dans la plupart des endroits. Ainsi, les paquets multicast initiaux sont inondés partout, l’élagage coupant le trafic vers les emplacements qui n’ont pas besoin de l’alimentation multicast. Jusqu’à récemment, le mode dense PIM souffrait d’une réinjection périodique toutes les 3 minutes, mais dans la version 12.1(5)T, la fonction de rafraîchissement de l’état du mode dense PIM a permis d’y remédier. Grâce à cette fonctionnalité, le mode dense PIM convient sans doute à une mise en œuvre simple de la multidiffusion. En particulier lorsque le contrôle supplémentaire de PIM Sparse Mode n’est pas nécessaire, et lorsque l’inondation « accidentelle » occasionnelle ne serait pas très nuisible.
PIM Sparse Mode utilise une approche de demande explicite, où un routeur doit demander l’alimentation de multidiffusion avec un message PIM Join. PIM Sparse Mode est indiqué lorsque vous avez besoin d’un contrôle plus précis, notamment lorsque vous avez de gros volumes de trafic de multidiffusion IP par rapport à votre bande passante. Le mode PIM Sparse s’adapte plutôt bien, car les paquets ne vont que là où ils sont nécessaires, et parce qu’il ne crée de l’état dans les routeurs qu’en fonction des besoins. Pour cette raison, il a été écrit comme un protocole expérimental Internet.
Le prix que nous payons pour ce contrôle supplémentaire est une légère complexité supplémentaire. Le mode PIM Sparse utilise un routeur spécial appelé point de rendez-vous (RP) pour connecter la source de flux ou l’arbre de multidiffusion au routeur voisin du wannabe récepteur. Le RP n’est généralement utilisé que temporairement, comme nous le verrons ci-dessous.
Il peut y avoir différents RP pour différents groupes de multidiffusion, ce qui est une façon de répartir la charge. Il y a généralement un RP par groupe de multidiffusion. La redondance des RP’s est un sujet avancé, et nécessite une expertise un peu plus approfondie. Une façon de le faire est avec le protocole MSDP (possible article ultérieur dans la série).
Rappelons qu’un message Join de PIM est envoyé vers une Source (ou pour PIM-SM, éventuellement vers un RP), basé sur le routage unicast. Le message Join dit en effet « nous avons besoin d’une copie des multicast ici ». Il connecte l’expéditeur du message Join et les routeurs intermédiaires à tout arbre multicast existant, jusqu’à la cible du Join si nécessaire. Un message Prune dit en fait « nous n’avons plus besoin de ce groupe ici ». Un routeur recevant un message Prune vérifie s’il a d’autres interfaces nécessitant le flux multicast et, si ce n’est pas le cas, envoie son propre message Prune. Une technique avancée consiste à disposer d’une copie séparée et peut-être différente des informations de routage unicast uniquement à des fins de multicast. Cela permet de « diriger » les messages Join. MultiProtocol BGP, MBGP, pour la multidiffusion, est une façon de le faire (possible article ultérieur dans la série).
Point de rendez-vous de base (RP)
Nous avons vu jusqu’ici que PIM-SM utilise un point de rendez-vous (RP), pour connecter la source et les récepteurs. Il ne peut y avoir qu’un RP par groupe de multidiffusion, et la mise en œuvre la plus simple utilise un RP pour tous les groupes de multidiffusion.
Parlons des bases de l’utilisation du RP. Supposons que la source commence à envoyer avant qu’il y ait des récepteurs. Si les choses se passent dans l’autre sens, certains détails changent légèrement, mais ce n’est pas très différent.
Donc : la source de multidiffusion commence à envoyer. Comme nous l’avons déjà noté, il n’y a pas de protocole ou quoi que ce soit pour enregistrer les sources avec le multicast IP. La source envoie et c’est au(x) routeur(s) voisin(s) de faire ce qu’il faut. Avec PIM-SM, le routeur voisin connaît le RP. (Le routeur voisin transmet les données de multidiffusion au RP en les encapsulant dans un ou plusieurs messages de registre unicast. Le routage normal délivre le registre au RP. Le RP désencapsule la multidiffusion et transmet des copies dans n’importe quel arbre partagé (il y a un arbre pré-construit s’il y avait des récepteurs inscrits avant que la source ne commence à envoyer). S’il y a des récepteurs (interfaces sortantes de l’état de l’arbre partagé), le RP envoie un Join PIM vers la source. Ceci connecte la source au RP avec un arbre source, le Shortest Path Tree (SPT) (S, G). Lorsque le RP reçoit des multidiffusions le long de ce SPT, il envoie un Register-Stop pour indiquer au routeur de la source qu’il doit cesser d’envoyer des paquets Register. La raison de ce comportement est qu’aucun paquet multicast n’est perdu, s’il y a des récepteurs déjà présents.
En passant, s’il n’y a pas de récepteurs présents, le message Register-Stop est envoyé. Ensuite, lorsqu’un récepteur se manifeste ultérieurement (IGMP vers le routeur voisin, PIM Join du routeur voisin vers le RP), alors le RP envoie le PIM Join à la source à ce moment-là.
La figure suivante suppose qu’il y a une source et des récepteurs actifs (non représentés). Le récepteur représenté envoie un rapport IGMP au routeur D. Le routeur D envoie alors un Join PIM vers le RP. Puisqu’il y a d’autres récepteurs, le RP est déjà joint à l’arbre source (indiqué en bleu) et reçoit le flux multicast. Il transmet les paquets de flux de l’arbre source via l’arbre partagé, indiqué en vert.
Bien, maintenant nous avons les paquets allant de la source au RP le long de l’arbre source (arbre du plus court chemin, SPT), et du RP au récepteur le long de l’arbre partagé. Lorsque le débit binaire global (*, G) des paquets (provenant de toutes les sources) dépasse un seuil en Kbps, cela déclenche le routeur le plus proche du récepteur pour essayer de rejoindre l’arbre source. Il envoie un Join vers la source du flux multicast. Notez que le Join précédent qu’il a envoyé était vers le RP. Le Join vers la source va routeur par routeur vers la source jusqu’à ce qu’il rencontre un routeur qui est déjà dans l’arbre source. Cela ajoute le routeur près du récepteur à l’arbre source. Lorsqu’un paquet est effectivement reçu le long de cet arbre, un Prune est envoyé vers le RP. En effet, « merci, mais je reçois maintenant mon multicast en gros, et non au détail », puisque ce processus coupe le RP au milieu.
La figure suivante montre comment cela fonctionne. Les flèches rouges en haut à gauche montrent le Join vers la source. Cela met en route le flux bleu supérieur, les paquets étant transmis le long de l’arbre source. Les flèches rouges en bas à droite sont ensuite les Prunes, puisque le flux de l’Arbre Partagé n’est plus nécessaire (représenté par la ligne pointillée verte). Notez que les paquets de l’Arbre Source arrivent au Récepteur par un chemin plus direct, généralement avec une latence plus faible.
Au fait, nous contrôlons le seuil. Il est configurable. La valeur par défaut est de zéro Kbps : recevoir un paquet, et basculer sur l’arbre des sources. Si nous avons de nombreuses sources pour un groupe multicast particulier (pensez à la conférence téléphonique, VoIP), alors il y a une entrée (S, G) Source Tree pour chacune d’entre elles. Si nous réglons le seuil pour qu’il ne soit jamais activé, alors tous les paquets passent par le RP (un peu comme un pont de conférence téléphonique), en utilisant uniquement l’arbre partagé (*, G). Le seuil est également utilisé pour le retour en arrière ainsi que pour le basculement. Les arbres sources à faible débit (S, G) sont basculés vers l’arbre partagé. Le volume de trafic est vérifié toutes les minutes.
Si un récepteur souhaite se joindre, et que son routeur voisin est sur le SPT (Arbre Source), alors l’entrée de l’Arbre Partagé de l’interface sortante est copiée sur l’entrée de l’Arbre Source, ce qui protège contre le fait d’avoir à envoyer le trafic vers le RP et ensuite « revenir » au routeur sur le SPT.
Au fait, vous vous demandez peut-être, quel est l’intérêt d’avoir le RP ici ? En raison du mécanisme de seuil, le RP nous donne un moyen d’utiliser l’arbre partagé et de contrôler la création explosive d’informations d’état dans les routeurs si de nombreux récepteurs se joignent en même temps.
Arbres partagés contre arbres sources
PIM Sparse Mode (PIM-SM) peut utiliser à la fois les arbres partagés (passant par le RP) et les arbres sources (pour une livraison directe efficace le long du chemin le plus « court » de la source au récepteur). En général, il peut utiliser les deux. Si la livraison efficace est moins importante pour vous, et que la diminution de la quantité d’informations d’état conservées par les routeurs est plus importante, alors PIM peut être configuré pour n’utiliser qu’un arbre partagé.
Lorsqu’un routeur PIM-SM reçoit un paquet de multidiffusion, il vérifie l’arbre source pour cette adresse source particulière et cette adresse de groupe de multidiffusion (destination). Si aucune entrée n’est présente, il vérifie ensuite l’existence d’une entrée Shared Tree (*, G) pour le groupe de multidiffusion. Si des entrées sont présentes pour les deux arbres, l’interface entrante indique au routeur l’arbre à utiliser. Si les deux arbres ont la même interface entrante, alors le bit RP pour une entrée (S, G) empêche les paquets en double : cela indique que l’interface RPF se trouve le long de l’arbre partagé.
Pour un flux de multidiffusion avec au moins un récepteur actif, le chemin entre la source et le RP fera partie de l’arbre source. (Notez que « le chemin entre » est un peu vague ici, j’essaie de ne pas donner trop de détails.)
Les entrées de l’Arbre Partagé connecteront le RP à certains des récepteurs. L’interface RPF pour l’arbre partagé (*, G) est l’interface dans la direction du RP, pas la source du groupe multicast. C’est pourquoi il existe la possibilité que les arbres partagés (S, G) Source et (*, G) aient des interfaces RPF différentes.
Les entrées de l’arbre partagé (*, G) montrent les interfaces où une jointure au RP a été reçue, ou les interfaces avec des membres du groupe directement connectés (configurés ou reçus par IGMP). Les entrées de l’arbre source (S, G) montrent où un Join ou un Prune ou un Register a été reçu.
Configuration du mode PIM Sparse
La partie de base de ce dont vous avez besoin est:
ip multicast-routing
interface ethernet 0
adresseip 10.1.1.1 255.255.255.0
ip pim sparse-mode
interface ethernet 1
ip address 10.1.2.1 255.255.0
ip pim sparse-mode
Vous devez également indiquer à chaque routeur le RP, soit pour tous les groupes, soit pour des groupes sélectionnés (en utilisant des listes d’accès pour spécifier quel RP pour quels groupes). Cela peut être fait statiquement avec :
ip pim rp-address 1.2.3.4
Nous examinerons les autres options de gestion des RP dans le prochain article.
En conclusion
Le mois prochain, nous examinerons les différentes façons de travailler avec les points de rendez-vous. Nous pourrions également aborder légèrement quelques autres sujets plus avancés sur le multicast IP.