L'Internet est comme son nom l'indique une interconnexion de réseaux sous la direction d'entités administratives différentes (AS : Autonomous System) qu'on appelle domaines. Il faut définir des mécanismes qui permettent à ces domaines de dialoguer, tout en préservant leur autonomie. Ces mécanismes sont déjà pleinement déployés pour l'unicast, mais sont encore en plein développement pour ce qui concerne le multicast.

Aujourd'hui, les protocoles multicast interdomaine pour IPv4 sont considérés comme non extensibles comme on le verra dans la section suivante sur MSDP. Ainsi pour IPv6, de nouveaux mécanismes ont été définis, prenant en compte l'existence de deux modèles de diffusion pour les applications : ASM et SSM. Alors que le modèle ASM interdomaine était implémenté par MSDP en IPv4, la solution qui semble privilégiée aujourd'hui est embedded-RP. Pour le modèle SSM, l'utilisation du protocole MLDv2 est indispensable afin d'informer le réseau des sources d'intérêt pour la construction des arbres. Dans cette partie, nous présentons deux solutions qui pourraient être déployées à grande échelle pour le multicast IPv6 : PIM-SM associé à embedded-RP pour l'ASM et PIM-SSM associé à MLDv2 pour SSM.

ASM

En IPv4, un domaine PIM correspond à un ensemble de routeurs PIM gérés par une même entité. Tous les routeurs du domaine PIM sont configurés avec le même ensemble de points de rendez-vous qui appartiennent aussi à ce domaine. Pour permettre à des sources et des récepteurs répartis sur différents domaines de participer à une session multicast, un protocole été standardisé et déployé : il s'agit de MSDP (Multicast Source Discovery Protocol) [RFC 3618].

Des peerings MSDP sont déployés entre les RP des différents domaines PIM comme indiqué sur la See Peering MSDP. Ils permettent aux RP de s'échanger les informations quant aux sources actives dans les différents domaines. Chaque RP envoie à ses peers MSDP les sources qui émettent et les groupes destinataires.

Des filtres peuvent être appliqués sur les peerings pour permettre les annonces de certaines sources pour certains groupes uniquement.

Ce protocole classé expérimental ne permet pas une utilisation massive de la technologie multicast puisque les RP doivent s'échanger toutes les sources actives sur l'Internet. De plus, il s'agit d'un protocole compliqué, peu implémenté et difficile à administrer. Aussi, depuis plusieurs années, l'IETF recommande l'utilisation du modèle SSM afin de rendre le modèle plus simple, même si le service rendu est différent avec SSM. Pour toutes ces raisons MSDP n'est pas défini pour IPv6 et il n'existe pas de protocole équivalent.

Embedded-RP

En l'absence de MSDP, la construction de l'arbre multicast avec PIM-SM nécessite que tous les routeurs PIM soient configurés avec le même ensemble de RP. Un groupe doit correspondre à un seul RP unique dans tout l'Internet puisque les RP ne peuvent pas s'échanger les informations sur les sources actives en IPv6.

Il est difficile d'imaginer un protocole permettant d'échanger les informations sur les RP existants et les adresses multicast qu'ils gèrent. Un tel protocole ne serait pas meilleur que MSDP.

Une proposition simple a émergé : embarquer l'adresse du RP dans l'adresse multicast (ou embedded-RP). Ceci semble impossible car les deux adresses ont une taille identique (de 128 bits). Cependant, en faisant certaines hypothèses sur l'identifiant d'interface du RP, il est possible de parvenir à cette solution. La méthode de construction d'une adresse embedded-RP est décrite figure les adresses multicast "Embedded-RP" [RFC 3618] définit une méthode pour inclure l'adresse du RP (Point de Rendez-Vous servant à la construction de l'arbre multicast) dans l'adresse multicast IPv6. Le schéma suivant montre la structure d'une telle adresse, aussi appelée adresse "embedded-RP" :

Cette technique impose quelques changements :

• Modifications sur le protocole PIM SM.

Embedded-RP [RFC 3618] nécessite une modification de l'algorithme de correspondance entre les adresses multicast et les RP (ou group-to-RP mapping). Pour un paquet à destination d'une adresse dérivée du préfixe FF70::/12, l'adresse du RP doit être retrouvée à l'aide des mécanismes décrits See les adresses multicast "Embedded-RP" [RFC 3618] définit une méthode pour inclure l'adresse du RP (Point de Rendez-Vous servant à la construction de l'arbre multicast) dans l'adresse multicast IPv6. Le schéma figure 11-4 montre la structure d'une telle adresse, aussi appelée adresse "embedded-RP" :

Embedded-RP doit être supporté sur tous les routeurs de l'arbre partagé, le RP et le DR des sources et des récepteurs. Le support d'embedded-RP sur l'arbre centré sur la source et sur les routeurs entre la source et le RP n'est pas nécessaire puisque ce sont des messages PIM (S,G) prune/join qui sont utilisés. Cependant, il est à noter qu'une implémentation sur tous les routeurs PIM SM du réseau simplifie l'utilisation et la gestion de la technologie embedded-RP.

• Impact sur le modèle multicast.

L'interdomaine multicast en IPv6 apparaît donc très différent de ce qui est réalisé en IPv4. Notamment la notion de domaine PIM disparaît et le terme interdomaine multicast ne correspond plus vraiment. L'Internet IPv6 multicast est un unique domaine PIM dans lesquels sont configurés des multiples points de rendez-vous (cf. See Le modèle embedded-RP).

Il est encore difficile à la date de rédaction de ce chapitre de déterminer si ce modèle va être adopté. Si des tests ont montré que la technologie embedded-RP fonctionnait, il reste néanmoins des questions sur les impacts causés par les différences avec le modèle connu et déployé à ce jour pour IPv4.

Déploiement de SSM sur plusieurs domaines

Le modèle SSM, implémenté par PIM-SSM constitue un sous-ensemble simplifié du modèle ASM. En effet, il a été défini historiquement pour répondre aux problèmes de l'interdomaine ASM n'ayant pas été résolus en IPv4. Par conséquent, les mécanismes permettant de réaliser l'interdomaine SSM en IPv6 sont très similaires à ceux utilisés en IPv4.

Au niveau du protocole PIM-SSM, il n'y a aucune disposition à prendre pour permettre à ce protocole de fonctionner entre plusieurs domaines. Les messages PIM Join sont acheminés de routeur en routeur entre les DR des récepteurs et les sources spécifiées par les récepteurs. Peu importe donc que les sources soient dans le même domaine que les récepteurs.

Le problème du déploiement du protocole de construction d'arbre multicast PIM-SSM sur plusieurs domaines se situera donc au niveau du routage.