Exemples : Configuration de PIM RPT et SPT Cutover

Dans une arborescence partagée, la racine de l’arborescence de distribution est un routeur, et non un hôte, et est située quelque part au cœur du réseau. Dans le protocole de routage multicast en mode clairsemé principal, PIM SM (Protocol Independent Multicast Sparse Mode), le routeur central à la racine de l’arborescence partagée est le point de rendez-vous (RP). Les paquets provenant de la source montante et les messages de jonction des routeurs en aval « se donnent rendez-vous » sur ce routeur central.

Dans le modèle RP, les autres routeurs n’ont pas besoin de connaître les adresses des sources pour chaque groupe multicast. Tout ce qu’ils ont besoin de savoir est l’adresse IP du routeur RP. Le routeur RP découvre les sources de tous les groupes de multidiffusion.

Le modèle RP transfère la charge de la recherche des sources de contenu multicast de chaque routeur (la notation (S,G)) au réseau (la notation (*,G) ne connaît que le RP). La façon exacte dont le RP trouve l’adresse IP unicast de la source varie, mais il doit y avoir une méthode pour déterminer la source appropriée pour le contenu multicast pour un groupe particulier.

Prenons l’exemple d’un ensemble de routeurs multicast sans trafic multicast actif pour un groupe donné. Lorsqu’un routeur apprend qu’un destinataire intéressé pour ce groupe se trouve sur l’un de ses sous-réseaux directement connectés, il tente de rejoindre l’arborescence de distribution de ce groupe au RP, et non à la source réelle du contenu.

Pour rejoindre l’arborescence partagée, ou () comme on l’appelle en mode clairsemé PIM, le routeur doit procéder comme suit :

• Déterminez l’adresse IP du RP pour ce groupe. La détermination de l’adresse peut être aussi simple qu’une configuration statique dans le routeur, ou aussi complexe qu’un ensemble de protocoles imbriqués.

• Créez l’arborescence partagée pour ce groupe. Le routeur exécute une vérification RPF sur l’adresse RP dans sa table de routage, ce qui produit l’interface la plus proche du RP. Le routeur détecte maintenant que les paquets multicast de ce RP pour ce groupe doivent être acheminés vers le routeur sur cette interface RPF.

• Envoyez un message de jonction sur cette interface en utilisant le protocole multicast approprié (probablement le mode clairsemé PIM) pour informer le routeur en amont qu’il souhaite rejoindre l’arborescence partagée pour ce groupe. Ce message est un message de jointure (*,G) car S n’est pas connu. Seul le RP est connu, et le RP n’est pas réellement la source des paquets multicast. Le routeur recevant le message de jointure (*,G) ajoute l’interface sur laquelle le message a été reçu à sa liste d’interfaces sortantes (OIL) pour le groupe et effectue également une vérification RPF sur l’adresse RP. Le routeur en amont envoie alors un message de jointure (*,G) de l’interface RPF vers la source, informant le routeur en amont qu’il souhaite également rejoindre le groupe.

Chaque routeur en amont répète ce processus, en propageant les messages de jointure à partir de l’interface RPF, construisant ainsi l’arborescence partagée au fur et à mesure. Le processus s’arrête lorsque le message de jointure atteint l’un des éléments suivants :

• Le RP du groupe que vous rejoignez

• Un routeur le long du RPT qui a déjà un état de transfert multicast pour le groupe qui est joint

Dans les deux cas, la branche est créée, et les paquets peuvent circuler de la source vers le RP et du RP vers le récepteur. Notez qu’il n’y a aucune garantie que l’arborescence partagée (RPT) soit l’arborescence du chemin le plus court vers la source. Il est fort probable que ce ne soit pas le cas. Cependant, il existe des moyens de « migrer » une arborescence partagée vers un SPT une fois que le flux de paquets a commencé. En d’autres termes, l’état de transfert peut passer de (*,G) à (S,G). La formation des deux types d’arbres dépend fortement du fonctionnement de la vérification RPF et de la table RPF. Pour plus d’informations sur la table RPF, reportez-vous à la section Présentation du transfert de chemin inverse multicast.

Le RPT est le chemin entre le RP et les récepteurs (hôtes) dans un groupe multicast (voir Figure 1). Le RPT est construit au moyen d'un message de jonction PIM à partir de la DR d'un destinataire :

1. Un destinataire envoie une demande pour rejoindre le groupe (G) dans un rapport d’appartenance à l’hôte IGMP (Internet Group Management Protocol). Un routeur PIM en mode clairsemé, le DR du récepteur, reçoit le rapport sur un sous-réseau directement connecté et crée une branche RPT pour le groupe multicast d’intérêt.

2. Le DR du récepteur envoie un message de jointure PIM à son voisin RPF, à l’adresse de saut suivant dans la table RPF ou à la table de routage unicast.

3. Le message de jointure PIM remonte dans l’arborescence et est multicast vers le groupe ALL-PIM-ROUTERS (224.0.0.13). Chaque routeur de l’arborescence trouve son voisin RPF à l’aide de la table RPF ou de la table de routage unicast. Cette opération est effectuée jusqu’à ce que le message atteigne le RP et forme le RPT. Les routeurs le long du chemin configurent l’état de transfert multicast pour transférer le trafic multicast demandé vers le récepteur.

Figure 1 : construction d’un RPT entre le RP et le récepteur

Le RPT est une arborescence unidirectionnelle, permettant au trafic de descendre du RP vers le récepteur dans une direction. Pour que le trafic multicast atteigne le récepteur à partir de la source, une autre branche de l'arborescence de distribution, appelée arborescence du chemin le plus court, doit être créée à partir de la DR de la source vers le RP.

L’arborescence du chemin le plus court est créée de la manière suivante :

1. La source devient active et envoie des paquets multicast sur le réseau local auquel elle est rattachée. La reprise après sinistre de la source reçoit les paquets et les encapsule dans un message de registre PIM, qu’elle envoie au routeur RP ( voir Figure 2).

2. Lorsque le routeur RP reçoit le message de registre PIM de la source, il renvoie un message de jointure PIM à la source.

   Figure 2 : échange d’un message de registre PIM et d’un message de jonction PIM

3. La récupération d’urgence de la source reçoit le message de jonction PIM et commence à envoyer du trafic sur le SPT vers le routeur RP (voir Figure 3).

4. Une fois que le trafic est reçu par le routeur RP, il envoie un message d’arrêt de registre à la récupération d’urgence de la source pour arrêter le processus d’enregistrement.

   Figure 3 : trafic envoyé de la source au routeur RP

5. Le routeur RP envoie le trafic multicast le long du RPT vers le récepteur (voir Figure 4).

   Figure 4 : Trafic envoyé du routeur RP vers le récepteur

L’arbre de distribution utilisé pour le multicast est enraciné à la source et constitue également l’arbre SPT (Shortest Path Tree). Prenons l’exemple d’un ensemble de routeurs multicast sans trafic multicast actif pour un groupe donné (c’est-à-dire qu’ils n’ont pas d’état de transfert multicast pour ce groupe). Lorsqu’un routeur apprend qu’un destinataire intéressé pour ce groupe se trouve sur l’un de ses sous-réseaux directement connectés, il tente de rejoindre l’arborescence de ce groupe.

Pour rejoindre l’arborescence de distribution, le routeur détermine l’adresse IP unicast de la source pour ce groupe. Il peut s’agir d’une simple configuration statique sur le routeur ou d’un ensemble complexe de protocoles.

Pour créer le SPT pour ce groupe, le routeur exécute une vérification RPF (Reverse Path Forwarding) sur l’adresse source dans sa table de routage. La vérification RPF produit l’interface la plus proche de la source, c’est-à-dire l’endroit où les paquets multicast de cette source pour ce groupe doivent affluer vers le routeur.

Le routeur envoie ensuite un message de jonction sur cette interface en utilisant le protocole multicast approprié pour informer le routeur en amont qu’il souhaite rejoindre l’arborescence de distribution de ce groupe. Ce message est un message de jonction (S,G) car S et G sont connus. Le routeur recevant le message de jointure (S,G) ajoute l’interface sur laquelle le message a été reçu à sa liste d’interfaces de sortie (OIL) pour le groupe et effectue également une vérification RPF sur l’adresse source. Le routeur en amont envoie ensuite un message de jonction (S,G) sur l’interface RPF vers la source, informant le routeur en amont qu’il souhaite également rejoindre le groupe.

Chaque routeur en amont répète ce processus, propageant les joints sur l’interface RPF, construisant le SPT au fur et à mesure. Le processus s’arrête lorsque le message de jointure effectue l’une des deux opérations suivantes :

• Atteint le routeur directement connecté à l’hôte qui est la source.

• Atteint un routeur qui a déjà l’état de transfert multicast pour cette paire source-groupe.

Dans les deux cas, la branche est créée, chacun des routeurs dispose d’un état de transfert multicast pour la paire source-groupe, et les paquets peuvent circuler le long de l’arbre de distribution de la source au récepteur. La vérification RPF à chaque routeur permet de s’assurer que l’arborescence est bien un SPT.

Les SPT sont toujours le chemin le plus court, mais ils ne sont pas nécessairement courts. En d’autres termes, les sources et les récepteurs ont tendance à se trouver à la périphérie d’un réseau de routeurs, et non sur la dorsale, et les arbres de distribution multicast ont tendance à s’étendre sur presque tous les routeurs du réseau. Étant donné que le trafic multicast peut submerger une interface lente et qu’un paquet peut facilement atteindre des centaines ou des milliers de paquets de l’autre côté de la dorsale, il est logique de fournir une arborescence partagée en tant qu’arbre de distribution afin que la source multicast puisse être située plus au centre du réseau, sur la dorsale. Ce partage d’arbres de distribution ayant des racines dans le réseau central est réalisé par un point de rendez-vous multicast. Pour plus d’informations sur les RP, reportez-vous à la section Présentation des points de rendez-vous multicast, des arborescences partagées et des arborescences de points de rendez-vous.

Au lieu de continuer à utiliser le SPT vers le RP et le RPT vers le récepteur, un SPT direct est créé entre la source et le récepteur de la manière suivante :

1. Une fois que le DR du récepteur reçoit le premier paquet multicast de la source, le DR envoie un message de jonction PIM à son voisin RPF ( voir Figure 5).

2. La récupération d’urgence de la source reçoit le message de jointure PIM, et un état supplémentaire (S,G) est créé pour former le SPT.

3. Les paquets multicast provenant de cette source particulière commencent à provenir de la DR de la source et s'écoulent le long du nouveau SPT vers la DR du récepteur. La DR du récepteur reçoit désormais deux copies de chaque paquet multicast envoyé par la source, l’une du RPT et l’autre du nouveau SPT.

   Figure 5 : la DR du récepteur envoie un message de jonction PIM à la source

4. Pour arrêter les paquets multicast dupliqués, le DR du récepteur envoie un message d’élagage PIM au routeur RP, l’informant que les paquets multicast provenant de cette source particulière provenant du RPT ne sont plus nécessaires (voir Figure 6).

   Figure 6 : Le message d’élagage PIM est envoyé du DR du récepteur vers le routeur RP

5. Le message d’élagage PIM est reçu par le routeur RP et cesse d’envoyer des paquets multicast jusqu’au DR du récepteur. La reprise après sinistre du récepteur reçoit des paquets multicast uniquement pour cette source particulière sur le nouveau SPT. Cependant, les paquets multicast de la source arrivent toujours de la récupération d’urgence de la source vers le routeur RP ( voir Figure 7).

   Figure 7 : le routeur RP reçoit le message d’élagage PIM

6. Pour arrêter les paquets multicast inutiles à partir de cette source particulière, le routeur RP envoie un message d’élagage PIM à la DR de la source (voir Figure 8).

   Figure 8 : Le routeur RP envoie un message d’élagage PIM à la DR source

7. Le DR du récepteur reçoit désormais des paquets multicast uniquement pour la source particulière du SPT (voir Figure 9).

   Figure 9 : La reprise après sinistre de la source arrête d’envoyer des paquets multicast dupliqués vers le routeur RP

Dans certains cas, le routeur de dernier saut doit rester sur l’arborescence partagée vers le RP et ne pas passer à un SPT direct vers la source. Vous ne souhaitez peut-être pas que le routeur de dernier saut effectue la transition lorsque, par exemple, un flux multicast à faible bande passante est transféré du RP vers un routeur de dernier saut. Tous les routeurs entre le dernier saut et la source doivent maintenir et actualiser l’état SPT. Cela peut devenir une activité gourmande en ressources qui n’améliore pas grand-chose l’efficacité du réseau pour une paire particulière d’adresses de groupe source et multicast.

Dans ce cas, vous configurez une stratégie de seuil SPT sur le routeur de dernier saut pour contrôler la transition vers un SPT direct. Un seuil de basculement SPT à l’infini appliqué à une paire d’adresses source-groupe signifie que le routeur de dernier saut ne passera jamais à un SPT direct. Pour toutes les autres paires d’adresses source-groupe, le routeur de dernier saut passe immédiatement à un SPT direct rooté au niveau de la DR source.

Cet exemple montre comment configurer le délai d’expiration d’un redirecteur d’assertion PIM.

Cet exemple montre comment appliquer une stratégie qui supprime la transition de l’arborescence des points de rendez-vous (RPT) enracinée au niveau du RP vers l’arborescence du chemin le plus court (SPT) enracinée à la source.