Le routage multicast dans Internet - unistra.fr · 2013-09-27 · Le routage multicast dans Internet 17 construits autour d’un nœud distingué : le Core de CBT, le point de rendez-vous

Chapitre 1

Le routage multicast dans Internet

1.1. Introduction et définitions

Le multicast, ou diffusion sélective, consiste à envoyer les mêmes données à plusieurs destinataires. Nous nous plaçons dans le cadre de réseaux à commutation de paquets de type IP. Le multicast consiste donc à envoyer les mêmes paquets de données à n destinataires. De manière générale, les différents types de communications sont souvent distingués par le nombre de destinataires :

– les communications unicast, où les données sont envoyées à un seul destinataire spécifié ;

– les communications en diffusion générale (ou broadcast), où les données sont envoyées à toutes les machines d’un réseau donné. Dans certains cas, la diffusion générale sert à atteindre un seul destinataire, dont on ne connaît pas l’adresse, comme dans le protocole ARP [PLU 82] ;

– les communications multicast déjà mentionnées, où les destinataires forment un sous-ensemble de toutes les machines du réseau ;

– les communications anycast, où les données doivent atteindre un destinataire, et si possible un seul, par exemple le plus proche, parmi un ensemble de destinataires.

Si on s’intéresse maintenant aux expéditeurs des paquets, on distingue généralement le point-à-point (un seul expéditeur et un seul destinataire), le point-à- Chapitre rédigé par Jean-Jacques PANSIOT.

16 Multicast multimédia sur Internet

multipoint (un seul expéditeur et n destinataires), et finalement le multipoint-à-multipoint (m expéditeurs et n destinataires).

La notion de groupe est souvent associée aux communications multicast. Un groupe est un ensemble d’entités (machines, processus, entités applicatives, utilisateurs) participant à une même communication. Suivant les cas, il peut s’agir d’un groupe de destinataires, d’expéditeurs ou des deux.

Les applications utilisant des communications de groupe sont très variées. On peut citer :

– les applications système, par exemple les routeurs utilisant le même protocole de routage sur un même réseau local se découvrent mutuellement et dialoguent au travers d’un groupe (groupe all-ospf-routers par exemple). Ce type d’utilisation est souvent limité à un seul réseau local, et ne nécessite pas d’adhésion explicite : il s’agit d’un remplaçant du broadcast. Celui-ci a d’ailleurs disparu dans IPv6, la nouvelle version du protocole IP ;

– les applications de diffusion d’information, où il y a principalement un émetteur et un nombre éventuellement très élevé de récepteurs. On peut encore distinguer la diffusion d’information de type multimédia (son, vidéo) avec des contraintes temps réel, de la diffusion fiable de données informatiques (cours de bourse, logiciels, …).

– les applications de groupe collaboratives ou coopératives, où la plupart des participants sont à la fois émetteurs et récepteurs (jeux en réseau, travail collaboratif).

Une possibilité pour réaliser un service multicast est de transmettre en unicast depuis la source autant de copies du paquet qu’il y a de destinataires. Cela a pour conséquence de gaspiller la bande passante, en particulier autour de la source, et d’imposer une gestion centralisée à la source des différents récepteurs. Le but principal du multicast au niveau IP est de diminuer la charge réseau en ne transmettant qu’un minimum de copies d’un paquet de la source vers les différents destinataires, et par ailleurs de décentraliser et d’alléger la gestion des récepteurs. En particulier il est souhaité qu’au plus une copie d’un même paquet multicast emprunte un lien du réseau. Si on impose en plus (ce qui n’est pas toujours vérifié en pratique) qu’un nœud du réseau ne reçoive pas le même paquet par plusieurs liens, le graphe parcouru par un paquet multicast forme donc un arbre, souvent appelé arbre multicast ou de diffusion. Dans le cas d’une seule source, il s’agit d’un arbre orienté dont la source est la racine. Dans le cas de plusieurs sources, on peut distinguer des arbres partagés unidirectionnels, comme dans PIM-SM, ou des arbres partagés bidirectionnels, comme dans CBT. Les arbres partagés sont en général

Le routage multicast dans Internet 17

construits autour d’un nœud distingué : le Core de CBT, le point de rendez-vous de PIM-SM.

Le modèle de multicast actuellement proposé sur Internet est basé sur les travaux de Steve Deering [DEE 91], et est parfois appelé modèle de Deering. Il repose sur les principes suivants :

– les paquets IP multicast ont le même format que les paquets IP unicast et n’en diffèrent que par l’adresse destination qui est une adresse multicast (adresse IP de classe D commençant par les bits 1110, voir section 1.2).

– les groupes sont dynamiques, c’est-à-dire que les membres peuvent adhérer ou se retirer du groupe à tout moment.

– les groupes sont ouverts, il n’est pas nécessaire d’appartenir au groupe pour lui envoyer des données, une adresse de groupe repère un ensemble de récepteurs.

Pour la signalisation, deux niveaux sont séparés : le protocole d’adhésion aux groupes (IGMP) et les protocoles de routage multicast proprement dit, qui ont en charge la construction des arbres multicast.

Le modèle de Deering initial, maintenant baptisé modèle ASM (any source multicast) est modifié dans le cas du modèle SSM (voir section 1.10), puisque la notion de groupe est remplacée par celle de canal (groupe à une seule source).

Le modèle de Deering s’inscrit dans le modèle général d’Internet : les paquets sont des datagrammes et donc l’adresse multicast sera utilisée à la fois comme identificateur de groupe et comme localisateur. En particulier une adresse multicast peut avoir une portée globale au niveau d’Internet, ce qui pose des problèmes d’allocation d’adresse.

Dans la suite nous appellerons hôte (host) une machine reliée à un (ou plusieurs) réseau IP et susceptible d’exécuter des applications. Un routeur est une machine connectée à plusieurs réseaux IP et capable de véhiculer des paquets IP entre eux. Cela implique la présence d’une table de routage, construite au moyen d’un ou plusieurs protocoles de routage (comme RIP, OSPF, BGP) ou bien manuellement. Un routeur est multicast s’il peut véhiculer des paquets multicast d’un réseau à un autre. Cela implique la présence d’une table de routage multicast. Aussi bien un routeur qu’un hôte peuvent émettre ou recevoir en multicast.

La plupart des protocoles que nous allons étudier utilisent le principe soft state : les informations obtenues par un nœud N depuis un autre nœud N’ n’ont qu’une durée de validité limitée. Le nœud N’ doit donc retransmettre périodiquement ces informations, sinon elles seront déclarées périmées et éliminées par le nœud N. Ce


principe est connu pour être très robuste en cas de pannes des nœuds ou des liens. Par contre il engendre un trafic cyclique qui peut être important.

Remarque : on peut considérer les protocoles de routage multicast avec construction explicite de l’arbre, comme PIM-SM, comme des protocoles de connexion de niveau réseau, ce qui est une entorse au modèle datagramme. En fait le routage multicast tel que nous l’envisageons dans ce document se décharge sur le routage unicast de tout ce qui concerne la découverte de la topologie du réseau. Par contre, l’adhésion à un groupe crée un état tout le long de la branche menant du récepteur au reste de l’arbre.

Notations : dans la suite, nous noterons généralement S une source de données multicast, r, r1 des récepteurs, R, R1 des routeurs. Sans risque de confusion, ces symboles désigneront aussi l’adresse unicast correspondante. Un groupe (ou l’adresse multicast correspondante) sera noté G.

1.2. L’adressage multicast

Dans le modèle de Deering, une adresse multicast IPv4 est prise dans la classe D : adresses comprises entre 224.0.0.0 et 239.255.255.255, ou en notation préfixe 224.0.0.0/41. Une adresse multicast a plusieurs fonctions :

– identifier un groupe de façon unique pour les applications, y compris à l’échelle d’Internet entier ;

– permettre au routage multicast de construire l’arbre de diffusion ; – permettre aux routeurs d’acheminer (commuter) les paquets.

La complexité de l’allocation d’adresses vient alors : – du fait que les groupes sont créés et détruits dynamiquement, ce qui suppose

une allocation dynamique des adresses ; – de l’indépendance a priori entre groupe et localisation dans le réseau, en

particulier du fait de la dynamique des membres : il est concevable par exemple qu’un groupe soit créé avec quelques membres situés dans une partie du réseau, et qu’au gré des adhésions et des retraits, tous les membres restants soient situés ailleurs dans le réseau. Pour certains protocoles de routage multicast (PIM-SM, BGMP), les adresses multicast doivent permettre de retrouver les informations topologiques nécessaires à la construction des arbres, par exemple la localisation d’un point de rendez-vous ;

1. La notation préfixe X/Y désigne l’ensemble des adresses dont les Y premiers bits sont les mêmes que ceux de X.


– dans IPv4, l’espace d’adressage attribué au multicast est limité à 28 bits, ce qui est peu pour des adresses allouées dynamiquement dans Internet tout entier.

Initialement, l’allocation d’adresses multicast était manuelle : l’initiateur d’une session de groupe choisissait une adresse supposée non utilisée, et diffusait son choix par divers canaux afin d’éviter les conflits. Le protocole SAP (session announcement protocol [HAN 00]) permet d’annoncer les sessions lancées par un utilisateur en les diffusant dans un groupe multicast dédié. Cela permet donc aux autres participants de configurer leurs applications pour participer à la session. Cela permet aussi d’apprendre les adresses multicast utilisées et donc d’en choisir une libre avant de créer une nouvelle session. Bien entendu, cette technique n’est pas extensible même si le concept d’adresses à portée limitée (voir paragraphe 1.2.1) permet de restreindre le nombre d’annonces diffusées en un point donné. Plusieurs propositions ont été faites pour mieux gérer l’allocation d’adresses. Le RFC 3171 [ALB 01] fait le point sur la situation actuelle.

1.2.1. Adressage à portée limitée

Une première solution décrite dans le RFC 2365 [MEY 98] consiste à définir des adresses avec une portée (scope) limitée : cela permet d’une part de réutiliser plusieurs fois les mêmes adresses en des points différents, et d’autre part de simplifier l’allocation puisqu’elle ne doit garantir l’unicité que dans un espace limité. Ces adresses commencent par le préfixe 239.0.0.0/8. Par exemple le préfixe 239.192.0.0/14 désigne les adresses locales à une organisation. Un groupe utilisant une telle adresse ne peut donc pas traverser la frontière entre deux organisations. On peut noter qu’une autre solution pour limiter la portée des groupes avait été proposée et utilisée dans le Mbone (voir paragraphe 1.6.5) : elle se base sur l’utilisation du champ TTL2 du paquet IP plutôt que sur l’adresse multicast. Un paquet ne peut traverser une frontière entre deux niveaux hiérarchiques que si la valeur du TTL est suffisante.

1.2.2. Adressage global GLOP

Une autre solution décrite dans le RFC 3180 [MEY 01], baptisée GLOP, définit statiquement un découpage hiérarchique de l’espace d’adressage. Une adresse GLOP est constituée d’un préfixe de 8 bits (233.0.0.0/8), de 16 bits codant le numéro de système autonome (AS, voir section 1.9), puis de 8 bits codant le numéro de groupe. Chaque AS est donc « propriétaire » de 256 adresses de groupe qui sont globalement uniques dans Internet, ce qui est assez peu.

2. Le TTL (Time to Live) est le nombre de sauts qu’un paquet est autorisé à parcourir.


1.2.3. Adressage dynamique : Malloc

Une solution dynamique qui utilise plus efficacement l’espace d’adressage est donc nécessaire. Les travaux du groupe MALLOC de l’Ietf, décrits dans les RFC 2908 et 2909 [KUM 98, RAD 00, THA 00] proposent une telle architecture. Cette architecture d’allocation dynamique d’adresses multicast globalement uniques repose sur trois niveaux de protocoles et d’allocation d’adresse.

Au niveau 3, le plus élevé, le protocole MASC (RFC 2909) [RAD 00] permet d’allouer des blocs d’adresses multicast à des domaines. L’allocation se fait en créant une hiérarchie de domaines. Chaque domaine dispose d’au moins un serveur Masc, lui-même connecté aux serveurs parents, fils et éventuellement frères. Un domaine peut obtenir un bloc d’adresse de son domaine parent. Il peut à son tour en distribuer tout ou partie à ses domaines fils, et/ou en utiliser une partie pour ses propres besoins. Une allocation se fait pour une durée limitée. Un domaine réclame (claim) un certain bloc d’adresses (sous l’autorité de son domaine père). Si cette demande n’est pas contredite par une autre demande incompatible, elle est réputée acceptée. Sinon une autre demande devra être faite. Il est à noter qu’à ce niveau, l’échelle de temps pour allouer un bloc se chiffre en jours et non pas en secondes ou en minutes : les serveurs Masc doivent anticiper la demande de leurs sous-domaines et de leurs utilisateurs. A défaut de Masc, l’allocation peut être statique en utilisant GLOP.

Le deuxième niveau permet aux serveurs d’adresses multicast (MAAS) d’obtenir des blocs d’adresses parmi ceux alloués au domaine, en interrogeant par exemple les serveurs Masc du domaine. L’une des propositions pour ce niveau, le protocole AAP [HAN 01], consiste à diffuser à tous les serveurs MAAS les blocs d’adresses alloués au domaine. Un serveur MAAS qui a besoin d’une adresse choisit alors une adresse appropriée, en termes de portée et de durée de vie, et diffuse sa demande. En l’absence de message contradictoire, l’adresse est réputée allouée à ce serveur. Dans le cas contraire le processus est recommencé avec une autre adresse. A noter que les travaux de l’Ietf sur ce protocole ont été arrêtés.

Le niveau le plus bas (niveau 1) concerne l’allocation d’adresses multicast aux machines clientes. Le protocole proposé, MADCAP, normalisé dans le RFC 2730 [HAN 99] est assez similaire à DHCP. Il permet à un client de demander une adresse multicast à un serveur MAAS avec éventuellement des paramètres sur la durée de l’allocation et la portée de l’adresse. Il est à noter que cette allocation doit être rapide puisqu’elle peut être déclenchée par un utilisateur en train de lancer une application multicast. Pour cela, le niveau 2 peut demander la pré-allocation d’un ensemble d’adresses pour pouvoir répondre plus rapidement.


On peut constater que l’architecture MALLOC est assez complexe, et que d’autre part l’espace d’adressage restreint (classe D) pourrait être insuffisant. En particulier, le protocole Masc pourrait conduire à une trop grande fragmentation de l’espace d’adressage.

Un autre point à considérer pour l’adressage multicast est qu’une adresse peut aussi servir à la construction de l’arbre de diffusion. Dans les protocoles de routage avec construction explicite (comme PIM-SM ou CBT), les messages d’adhésion sont envoyés dans une direction (celle du RP) qui dépend de l’adresse multicast. La correspondance entre adresse multicast et adresse du RP est apprise explicitement (mécanisme du BSR par exemple, voir paragraphe 1.8.2), ce qui n’est pas extensible à grande échelle. Aussi des mécanismes (extensions de BGP et BGMP : voir paragraphe 1.9.2) ou des modifications du modèle de Deering (voir paragraphe 1.10, modèle SSM) ont été proposés pour faciliter cette correspondance, et pour pouvoir passer à l’échelle inter-domaine.

1.3. Structure d’un routeur multicast

Un routeur multicast implante généralement plusieurs protocoles de routage, et maintient plusieurs structures de données. Bien entendu, l’implantation effective de ces éléments peut être très variable.

1.3.1. La table de routage unicast pour le multicast (MRIB)

Un routeur multicast doit connaître la route vers l’adresse unicast de certains nœuds comme une source ou la racine de l’arbre de diffusion pour construire une branche de l’arbre. Cette route, empruntée par des paquets multicast n’est pas nécessairement la même que la route empruntée par les paquets unicast. Un processus de routage unicast doit donc permettre d’apprendre et d’annoncer des routes vers des adresses unicast utilisées pour le multicast. Ces routes seront stockées dans la MRIB (multicast routing information base). Cette table peut être construite explicitement par un protocole de routage unicast qui sait gérer plusieurs topologies, comme MBGP [BAT 00] ou M-IS-IS [PRZ 04]. Ou bien elle peut être construite par un protocole spécifique pour le multicast (DVMRP, MOSPF). Finalement, en faisant l’hypothèse que la topologie soit la même pour l’unicast et le multicast, elle peut être déduite de la table de routage unicast ordinaire (RIB). Notons que certains protocoles de routage unicast actuellement utilisés ne


permettent pas de gérer une double topologie, ce qui peut nécessiter un routage statique ou des tunnels3.

1.3.2. La table d’information sur les arbres (TIB)

Les protocoles de routage multicast utilisent la MRIB (ou à défaut la RIB) pour construire des arbres de diffusion. Un arbre est en général identifié par un couple formé d’une source S et d’un groupe G s’il s’agit d’un arbre par source, noté (S,G) ou simplement par une adresse de groupe s’il s’agit d’un arbre partagé par les sources, noté (*,G). Par exemple, un routeur PIM qui reçoit une adhésion pour l’arbre (S,G) cherche dans la MRIB le prochain saut vers S, vers lequel il propage le message d’adhésion. Les différentes informations concernant les arbres sont stockées dans la TIB (tree information base). Pour chaque arbre, elle contient la liste des interfaces y appartenant, leur état (par exemple en cours d’adhésion ou en cours de retrait), les délais de garde pour les messages de maintenance de l’arbre. Notons que, dans la plupart des protocoles, ces informations sont soft state et disparaissent donc si elles ne sont pas validées régulièrement. De plus, tout changement de la MRIB peut provoquer un changement de la TIB. Par exemple si le prochain saut vers une source S change, un routeur PIM-SM doit se désabonner par l’ancienne interface menant à S et se réabonner par la nouvelle. La nature des informations contenues dans la TIB dépend fortement du protocole de routage multicast utilisé. Un routeur implémentant plusieurs protocoles de routage multicast (voir paragraphe 1.9.3) pourrait gérer plusieurs TIB.

La TIB contient également les informations sur les groupes qui ont des récepteurs appartenant à des réseaux directement connectés (obtenues grâce à IGMP), et sur les éventuelles applications locales abonnées à un groupe, car un routeur multicast peut lui-même participer à un groupe.

1.3.3. La table de propagation multicast (MFIB)

Finalement, une table extraite de la TIB, la MFIB (multicast forwarding information base) contient les informations nécessaires au traitement des paquets de données multicast. Cette table doit être implantée de façon très efficace car elle est consultée à chaque arrivée de paquet multicast. Par exemple dans PIM-SM, une entrée de cette table contient au minimum :

3. Un tunnel consiste à encapsuler un paquet dans un autre paquet afin de lui permettre de traverser des routeurs qui ne pourraient pas le traiter. Par exemple un tunnel peut relier deux routeurs multicast séparés par un ou plusieurs routeurs unicast.


– un identificateur d’arbre de la forme (S,G) ou (*,G) ; – une interface d’entrée, déduite de la MRIB lors de la construction de l’arbre ; – une liste d’interfaces de sortie, déduite des adhésions au groupe.

M-IS-IS MBGP PIM-SM

RIB MRIB TIB

Figure 1.1. Exemple de structure d’un routeur multicast

Lors de l’arrivée d’un paquet : – l’entrée de la MFIB la plus spécifique est choisie, c’est-à-dire (S,G) avant

(*,G) par exemple. Si le paquet est arrivé par l’interface d’entrée de cet arbre, il est propagé par chacune des interfaces de sortie : duplication et propagation du paquet ;

– sinon, si le paquet vient d’une source directement connectée, une nouvelle entrée (S,G) est créée dans la MFIB (et dans la TIB), avec comme interface d’entrée celle de la source, et comme unique interface de sortie celle d’un tunnel vers le RP (messages register) ;

– sinon, le paquet est ignoré.

MFIBFIB

signalisation

commutation

Commutationunicast

Commutation multicast


La commutation multicast apporte une difficulté supplémentaire par rapport à la commutation unicast : un paquet de données peut ne correspondre à aucune entrée de la table, mais doit être commuté et provoque des mises à jour des tables (TIB, MFIB).

1.4. Relation avec les autres couches de protocoles

Le multicast doit être pris en compte aussi bien dans les couches inférieures, la couche liaison notamment, que dans les couches supérieures.

1.4.1. Lien avec la couche inférieure

La situation dépend de la nature de la couche liaison. On peut distinguer trois types principaux : les liaisons point-à-point, les liaisons à diffusion comme Ethernet, et les liaisons à accès multiple sans diffusion, comme ATM.

Les liaisons point-à-point, fréquemment utilisées pour interconnecter des routeurs, ne posent pas de problème particulier, et ne demandent pas d’adressage spécifique pour le multicast.

Les liaisons à diffusion sont utilisées aussi bien pour raccorder les hôtes au réseau (accès par réseau local), que pour interconnecter localement des routeurs, par exemple dans des points d’interconnexion d’opérateurs. Par définition, la diffusion (broadcast) existe nativement dans ces réseaux, et le multicast est obtenu par filtrage des trames en réception. Par exemple dans l’adressage IEEE 802, le premier bit de l’adresse destination indique s’il s’agit d’une trame multicast ou non4. Lorsque des paquets IP multicast sont transmis sur un réseau Ethernet, l’adresse IP multicast permet de construire automatiquement les 48 bits de l’adresse Ethernet correspondante : elle est formée des 25 premiers bits de l’adresse de base 01-00-5E-00-00-00, suivis des 23 derniers bits de l’adresse IP multicast. On peut observer que plusieurs adresses IP correspondent à la même adresse Ethernet, et donc qu’en réception le filtrage devra être fait non seulement au niveau Ethernet mais aussi au niveau IP.

Dans les réseaux à diffusion étendus avec des ponts, les trames multicast et broadcast sont a priori envoyées partout. Des extensions (IEEE 802.1p, maintenant incorporé dans IEEE 802.1D [IEE 98]) permettent aux ponts d’apprendre sur quelles interfaces envoyer des trames destinées à une adresse Ethernet multicast donnée.

4. Dans Ethernet, les octets sont envoyés bit de poids faible en tête, le premier octet d’une adresse multicast est donc impair.


Dans le cas particulier, mais fréquent, de trafic IP multicast, des propositions ont été faites pour que les ponts puissent découvrir automatiquement où sont les membres d’un groupe IP donné. Ces techniques sont basées sur l’espionnage (snooping) des paquets IGMP (voir paragraphe 1.5) et d’autres paquets de signalisation circulant sur le réseau [BIS 04]. Cette méthode a l’inconvénient de violer l’indépendance des couches MAC et réseau, et d’être assez gourmande en traitement sur les ponts. Des protocoles propriétaires comme CGMP ont aussi été définis.

Les réseaux à diffusion nécessitent aussi quelques adaptations des protocoles de routage multicast, par exemple :

– pour éviter des réponses multiples et quasi-simultanées à une requête (voir paragraphe 1.5.1) ;

– pour éviter des messages de contrôle redondants dans le cas de plusieurs routeurs multicast sur le même réseau (voir paragraphe 1.5.2) ;

– pour déterminer, dans le même cas, quel routeur multicast doit propager les paquets de ou vers ce réseau (voir par exemple la notion de propagateur désigné au paragraphe 1.8.5).

Les réseaux à accès multiple sans diffusion native (NBMA, non broadcast multiple access) posent des problèmes plus complexes, du fait non seulement de l’absence de diffusion, mais aussi au moins pour ATM, du mode connecté, et de l’absence de circuits multipoint-à-multipoint. L’architecture proposée pour le multicast IP sur ATM [ARM 96] peut se résumer comme suit :

– un serveur Mars (multicast address resolution server) enregistre la liste des adresses ATM des nœuds ATM (hôtes ou routeurs) membres de chaque groupe IP multicast ;

– tout changement de cette liste peut être notifié aux nœuds intéressés via un circuit ATM point-à-multipoint ;

– un nouvel adhérent à un groupe IP interroge le serveur Mars pour connaître la liste des nœuds ATM membres du groupe ;

– compte tenu de l’absence de circuit multipoint-à-multipoint, deux modes de fonctionnement sont définis :

- un mode avec serveur, où chaque membre établit un circuit point-à-point vers le serveur multicast du groupe qui rediffuse vers tous les membres au moyen d’un seul circuit point-à-multipoint,

- un mode mesh, où chaque membre construit (et met à jour) son propre circuit point-à-multipoint vers tous les autres membres.

On peut noter que la première solution nécessite un traitement coûteux dans le serveur, alors que la seconde peut entraîner la création d’un très grand nombre de circuits.


1.4.2. Lien avec les couches supérieures

La couche transport utilisée doit être compatible avec le multicast IP. Cela élimine donc le protocole TCP qui a été conçu uniquement pour le point-à-point. Le transport couramment utilisé est donc UDP, protocole aux fonctionnalités très réduites, hormis un total de contrôle permettant d’éliminer les datagrammes erronés, et des numéros de port permettant de multiplexer les applications.

Pour les applications de type multimédia avec des contraintes de temps, les protocoles RTP et RTCP [SCH 03] permettent d’identifier les sources, de donner des estampilles temporelles aux données, et de connaître l’état des récepteurs via RTCP. Ce protocole nécessite actuellement un canal multipoint-à-multipoint (voir section 1.10).

Le multicast fiable est un sujet très vaste, et qui donne lieu à certaines interrogations communes avec le routage multicast : rôles respectifs des hôtes et des routeurs, extensibilité aux très grands groupes. On peut observer que le modèle de Deering, où tout est fait pour éviter la connaissance explicite des récepteurs d’un groupe, ne facilite pas les mécanismes de fiabilité qui nécessitent généralement une connaissance exhaustive des récepteurs. Pour des petits groupes, la fiabilité peut être entièrement réalisée dans les hôtes émetteurs et récepteurs, comme c’est le cas en point-à-point, dans TCP par exemple. Pour de très grands groupes, le problème majeur est de contrôler la prolifération des acquittements positifs ou négatifs. Dès lors, si une fiabilité totale est recherchée, une structure de contrôle des acquittements est nécessaire. Elle peut se baser par exemple sur l’arbre de diffusion multicast construit par le routage multicast. Une étude comparative des principales méthodes est donnée dans [OBR 98]. Au niveau de la normalisation, l’Ietf, à travers son groupe RMT, s’oriente vers une architecture modulaire, donnant lieu non pas à un seul protocole mais plutôt à une famille de protocoles, voir le RFC 3048 [WHE 01]. Les chapitres 4 et 5 traitent de ce problème.

1.5. Appartenance aux groupes : IGMP

La première composante du routage multicast est constituée de la signalisation entre les hôtes et les routeurs. Elle a pour but d’informer les routeurs, pour chacune de leurs interfaces, sur les groupes qui ont des membres (récepteurs) présents. Dans le modèle de Deering, la connaissance exhaustive des récepteurs n’est pas utile, seule l’existence d’au moins un récepteur a besoin d’être connue. Le protocole normalisé dans le RFC 2236 [FEN 97] pour cette signalisation est IGMP (internet group management protocol). Ses principes de base reposent sur des états soft state et une minimisation du trafic de signalisation, en particulier sur les liens partagés


comme Ethernet. Les événements IGMP sont déterminés par les adhésions et les retraits des hôtes locaux aux différents groupes. L’adhésion d’une application à un groupe G entraîne, si l’hôte n’est pas déjà membre de G :

– une demande pour que le système accepte désormais les paquets entrants destinés à G ;

– l’envoi d’un message IGMP sur le réseau pour qu’un routeur multicast voisin sache qu’il y a un hôte intéressé par G sur ce réseau.

1.5.1. IGMP version 1

Dans la première version d’IGMP décrite dans le RFC 1112 [DEE 89], il n’y a que deux messages :

– un message de requête (IGMP Query) envoyé cycliquement (toutes les minutes par exemple) par le routeur à une adresse multicast correspondant à tous les systèmes ;

– un message de rapport (IGMP Report) envoyé par un hôte soit en réponse à une requête, soit spontanément lors de l’adhésion à un groupe. Ce message contient l’adresse G d’un groupe auquel l’hôte adhère, et est envoyé à l’adresse G. Il est donc reçu par tous les autres membres locaux de G.

Pour éviter les réponses multiples et synchronisées, deux mécanismes sont implémentés par les hôtes :

– attente d’un temps aléatoire avant d’envoyer un rapport, ce qui évite les rafales de réponses. Typiquement ce temps est tiré dans un intervalle de 10 s ;

– pendant l’attente, si un rapport pour le même groupe est reçu, l’hôte annule sa propre réponse. Cela permet de n’avoir qu’une seule réponse par groupe.

Si, pour un groupe présent, aucun rapport n’est reçu en réponse à plusieurs requêtes successives, le routeur considère que le groupe n’a plus de récepteur sur cette interface (principe soft state). Dans cette première version de IGMP la seule façon de quitter un groupe est donc implicite : l’état dans le routeur disparaît sur délai de garde.


La version 2 d’IGMP décrite dans le RFC 2236 [FEN 97] apporte quelques améliorations, en particulier un message de départ (IGMP leave group). Quand un hôte quitte un groupe G, et qu’il avait envoyé un rapport pour G lors de la dernière requête, alors il envoie un message de départ. Le routeur vérifie qu’il n’y a plus de


membre en envoyant plusieurs requêtes spécifiques pour G (une requête spécifique est envoyée au groupe G). Cela permet donc à un routeur de détecter plus rapidement le départ du dernier membre d’un groupe et de ne plus envoyer inutilement le trafic du groupe sur l’interface.

Un autre mécanisme concerne l’élection d’un interrogateur (querier). Dans un réseau local comportant plusieurs routeurs multicast, celui de plus petite adresse est élu interrogateur et est chargé d’émettre les requêtes périodiques. Notons que pour un groupe donné, l’interrogateur n’est pas forcément le routeur qui propagera le trafic de ou vers ce réseau. Cette version d’IGMP est celle qui est la plus généralement déployée actuellement.


Une troisième version d’IGMP [CAI 02] a été normalisée. Elle permet aux récepteurs de pouvoir sélectionner les sources pour un groupe donné. Deux modes de sélection sont définis : le mode inclusif où l’hôte précise la liste des sources désirées pour G (et donc implicitement toute autre source est non désirée), et le mode exclusif où l’hôte précise la liste des sources indésirables (toutes les autres sources étant implicitement désirées). Il est à noter qu’un rapport IGMPv2 est équivalent à un rapport IGMPv3 en mode exclusif avec une liste de source vide. De même, un message de départ IGMPv2 est équivalent à un rapport IGMPv3 en mode inclusif avec une liste vide. Le rôle du routeur est plus complexe, puisqu’il doit pour un groupe G faire la synthèse des listes inclusives et exclusives envoyées par les différents hôtes. Le principe est que les paquets d’une source demandée implicitement ou explicitement par au moins un hôte soient transmis. Si les Li

désignent des listes de sources, on a donc :

INCLUDE L1 ∧ INCLUDE L2 INCLUDE L1 U L2

EXCLUDE L1 ∧ EXCLUDE L2 EXCLUDE L1 ∩ L2

INCLUDE L1 ∧ EXCLUDE L2 EXCLUDE L2 \ L1

Notons que ce type de synthèse doit aussi être effectué par un hôte si plusieurs applications locales joignent le même groupe avec des modes ou des listes de sources différentes. Par contre les hôtes n’écoutent plus les rapports envoyés par les autres hôtes. Il y a donc autant de réponses à une requête générale qu’il y a d’hôtes


IGMPv3 adhérant à au moins un groupe. Un seul rapport, envoyé à l’adresse 224.0.0.26 (tous les routeurs IGMPv3), peut annoncer l’appartenance à autant de groupes que possible, contrairement aux rapports IGMPv1 ou IGMPv2 qui ne concernaient qu’un seul groupe. Cette version d’IGMP est donc sensiblement plus complexe que les versions précédentes, d’autant qu’elle doit aussi traiter les problèmes de compatibilité avec celles-ci. Ses fonctionnalités sont intéressantes pour plusieurs raisons.

D’abord, dans le modèle de Deering, n’importe quel nœud peut émettre vers un groupe. Le mode inclusif permet de fonctionner avec un groupe fermé de sources. Le mode exclusif permet d’interdire explicitement des sources non voulues, par exemple éliminer une source vidéo non intéressante dans une visioconférence ou des émetteurs indésirables. Il est à noter que le gain de trafic en filtrant des sources est essentiellement local, ces filtres n’étant pas nécessairement propagés en amont par les protocoles de routage actuels.

Une autre application intéressante d’IGMPv3 est l’implantation du modèle SSM, une adhésion à un groupe en mode inclusif avec une seule source correspondant à l’adhésion à un canal SSM (voir section 1.10).

1.6. Le routage en mode inondation-élagage et le RPF

Grâce à IGMP, les routeurs connaissent pour chacune de leurs interfaces les groupes qui ont des récepteurs. Le routage multicast doit permettre aux routeurs d’envoyer de proche en proche les paquets multicast aux routeurs intéressés. La première technique procède par inondation et élagage. Le problème principal est d’éviter que des paquets multicast ne bouclent dans le réseau. Une boucle de routage multicast est potentiellement plus grave qu’une boucle de routage unicast car un paquet peut se dupliquer lors de son tour de boucle. S’il y a plusieurs boucles, il peut y avoir prolifération exponentielle de paquets. Ce même problème apparaît aussi dans la couche 2 des réseaux à diffusion comme Ethernet dans le cas de l’utilisation de ponts, où il est traité par la construction d’arbres de recouvrement [PER 85].

1.6.1. Propagation par le chemin inverse ou RPF check

Au niveau IP, l’algorithme principal pour éviter les boucles est le RPF (reverse path forwarding) check ou propagation par le chemin inverse, introduit par Dalal et Metcalf [DAL 78]. Le principe est le suivant : un paquet multicast de source S n’est propagé que s’il est arrivé par l’interface menant vers S. Dans le cas de l’inondation


par RPF, le paquet est alors propagé par toutes les interfaces sauf celle d’entrée. Deux remarques importantes peuvent être faites :

– le chemin menant vers la source est typiquement une information de routage unicast, extraite de la MRIB par exemple ;

– le chemin emprunté par un paquet multicast entre S et r correspond au chemin emprunté par un paquet unicast pour aller de r à S, ou chemin inverse.

Si le routage unicast est cohérent (sans boucle), on peut montrer qu’avec le RPF un paquet ne peut pas parcourir de boucle. En effet, si un paquet a été propagé par la suite de routeurs R1, R2, …, Rn, R1 cela veut dire qu’il y a une route unicast vers S passant par R1, Rn, Rn-1, …, R1, donc une boucle unicast. On peut noter que le RPF seul n’évite pas qu’un même paquet soit reçu deux fois par deux interfaces différentes ou non. Le RPF permet de réaliser une inondation (reverse path flooding), tout routeur du réseau obtient le paquet au moins une fois. On appelle interface RPF (pour S et G) celle par laquelle le routeur accepte les paquets venant de S.

Une première amélioration peut être apportée en évitant que plusieurs copies d’un paquet ne soient émises sur le même réseau. Pour cela, les divers routeurs connectés à un réseau doivent détecter leur présence mutuelle et décider qui va émettre les paquets venant d’une source donnée vers ce réseau, en échangeant des informations de routage (unicast, en principe extraites de la MRIB) et en élisant l’un d’entre eux. On parle alors de diffusion par le chemin inverse (reverse path broadcasting). A ce stade, l’adresse du groupe n’est pas utilisée, ni a fortiori la localisation de ses membres.

1.6.2. Elagage

Une deuxième amélioration consiste à éviter que des paquets n’atteignent des routeurs non intéressés. Cela met en œuvre une technique d’élagage (pruning). Pour chaque couple (S,G), un routeur maintient la liste des interfaces où il doit propager les paquets venant de S pour G (information obtenue par IGMP par exemple), et l’interface par laquelle il reçoit les paquets de S. Si la liste de sortie est vide, le routeur envoie un message d’élagage par l’interface d’entrée pour le couple (S,G). A réception d’un tel message par une interface, celle-ci est retirée de la liste des interfaces de sortie, ce qui provoque éventuellement la propagation du message d’élagage, et la suppression d’une branche de l’arbre.


On parle alors de multicast par le chemin inverse ou RPM : reverse path multicasting [DEE 90]. Un problème reste à résoudre : comment ajouter des membres à l’arbre élagué ? Deux mécanismes complémentaires sont proposés :

– les routeurs mémorisent les messages d’élagage envoyés. Lors de l’adhésion d’un nouveau membre à un groupe G, si des messages d’élagage pour des couples (S, G) ont été envoyés, des messages symétriques de greffe sont émis qui auront pour effet de reconstituer les branches élaguées. Ce mécanisme est rapide, par contre il ne traite pas les cas où aucun message d’élagage n’a été envoyé, comme par exemple dans une partie de réseau qui n’était pas précédemment connectée à la source. D’où le deuxième mécanisme ;

– à intervalle régulier T, les informations d’élagage sont supprimées, ce qui a pour effet de diffuser le prochain paquet dans tout le réseau comme pour le premier paquet. C’est aussi ce mécanisme qui permet de supprimer les informations sur les sources qui ne sont plus actives (principe soft state).

Le choix du paramètre T est un compromis : de petites valeurs permettent de s’adapter plus rapidement à des changements de topologie, mais provoquent un surcoût en terme de trafic inutile (inondation périodique du réseau par des données, messages d’élagage).

1.6.3. Coût du protocole

Tout routeur doit maintenir des informations dans sa TIB pour chaque couple (S,G) où S est une source active de G, et cela quelle que soit la localisation ou même l’existence de récepteurs : il mémorise soit une entrée de routage, soit une entrée d’élagage. De plus, tout routeur reçoit à intervalle T des paquets de tout couple (S,G) actif. On peut donc remarquer que ce protocole a un coût très faible si la plupart des routeurs sont intéressés par la plupart des couples (S,G), situation que l’on nomme généralement mode dense. A l’inverse, si la plupart des routeurs ne sont pas intéressés par la plupart des couples (S,G) (situation correspondant au mode épars), le coût devient important en signalisation (élagage), en nombre d’états (élagage) et en trafic inutile (inondation). Il est à noter que plus un réseau est grand et plus il y a de groupes, plus la situation se rapproche du mode épars.

1.6.4. DVMRP

L’algorithme RPM a été le premier à être effectivement implanté, dans le protocole DVMRP (distance vector multicast routing protocol), décrit dans le RFC 1075 [WAI 88]. Ce protocole a la particularité de contenir son propre protocole de routage unicast, de type vecteurs de distance et semblable à RIP. Ce protocole


unicast ne sert pas pour router les paquets unicast, mais à construire la MRIB qui est utilisée pour déterminer l’interface RPF pour une source. Un inconvénient de cette architecture, outre la lourdeur de faire tourner un protocole de routage unicast supplémentaire, est lié aux défauts du routage par vecteur de distance (lenteur de convergence, risques de boucles). L’avantage est de permettre des topologies différentes pour l’unicast (RIB) et le multicast (MRIB). Par exemple si un certain routeur n’implante pas le multicast, la route RPF vers la source ne devra pas emprunter ce routeur.

1.6.5. Le Mbone

Les premières expérimentations du multicast sur Internet ont nécessité la mise en place du Mbone : il s’agit d’un réseau virtuel au-dessus d’Internet. Les îlots multicast, zones composées de routeurs multicast, sont reliés par des liens virtuels traversant des routeurs non multicast. En pratique, ces liens virtuels peuvent être implémentés soit en utilisant le routage par la source, soit de façon plus fréquente par des tunnels : le routeur d’entrée du tunnel insère les paquets multicast dans des paquets IP unicast destinés à l’autre extrémité du tunnel. DVMRP se prête bien à cette architecture, les tunnels étant considérés comme des liens DVMRP. Bien entendu, l’usage de tunnels n’est pas très efficace, les routes empruntées étant en général non optimales, et l’encapsulation consommant de la bande passante et du temps de calcul.

1.6.6. PIM en mode dense : PIM-DM

Un autre protocole utilisant l’algorithme RPM a été défini par la suite, dans le cadre de l’architecture PIM [DEE 94] : PIM-DM (PIM dense mode) [ADA 04] (voir section 1.8). Contrairement à DVMRP, PIM n’inclut pas son propre protocole de routage unicast, mais utilise la table de routage unicast sous-jacente, ou plus précisément une MRIB qui est par défaut dérivée de la table de routage unicast. Cela pose un problème si les topologies unicast et multicast diffèrent.

1.7. Le routage par état des liens et MOSPF

De même que DVMRP est lié à un routage unicast par vecteurs de distance, MOSPF (multicast extensions to OSPF), décrit dans le RFC 1584 [MOY 94] est lié à un protocole de routage unicast par état des liens, OSPF [MOY 98].


1.7.1. Principe de MOSPF

Par rapport à OSPF, deux types d’informations supplémentaires permettent de mettre en œuvre MOSPF :

– une option permet de spécifier dans les différents messages si un lien ou un routeur est capable de transporter le multicast. Cela permet donc de gérer des configurations où le multicast n’est pas déployé partout (MRIB) ;

– un nouveau type d’annonce d’états des liens (group membership LSA) permet de spécifier quels sont les groupes présents sur chaque lien.

Le principe de MOSPF est le suivant : – lorsqu’un routeur apprend un changement dans la liste des groupes ayant un

membre sur un lien adjacent, par exemple via IGMP, il forme un nouvel état des liens qui est inondé vers tous les routeurs ;

– lorsqu’un routeur R reçoit un paquet multicast (S,G) et s’il ne dispose pas d’une entrée (S,G) dans sa table, il calcule, en utilisant l’algorithme de Dijkstra déjà utilisé par OSPF, l’arbre des plus courts chemins de S (et non pas de lui-même) vers tous les membres de G. Ce calcul est effectué dans le graphe des liens supportant le multicast. Si R appartient à cet arbre, il crée une entrée (S,G) où l’interface d’entrée est celle menant vers S dans l’arbre calculé, et les interfaces de sortie mènent vers les fils dans l’arbre ;

– le paquet est propagé suivant cette entrée, qui est conservée pour les paquets suivants ;

– une entrée (S,G) n’est supprimée que si la topologie du réseau ou la localisation des membres changent.

L’arbre des plus courts chemins pour un couple (S,G) et une métrique donnée n’est pas nécessairement unique, il est donc essentiel que tous les routeurs utilisent exactement le même algorithme pour calculer le même arbre. La capacité de calculer plusieurs plus courts chemins (multipath) qui existe dans OSPF ne doit pas être utilisée.

1.7.2. MOSPF inter-zones

Dans le cas d’un domaine comportant plusieurs zones OSPF, plusieurs mécanismes supplémentaires sont mis en œuvre pour éviter que toutes les annonces d’état des liens soient annoncées partout. Rappelons que dans OSPF il y a une zone particulière, appelée backbone, qui interconnecte toutes les autres zones, via des routeurs interzones qui appartiennent donc à plusieurs zones. Un routeur interzones opère comme suit :


– il se déclare membre de tous les groupes (wildcard multicast receiver) à l’intérieur des zones non backbone auxquelles il appartient. De ce fait il recevra le trafic de toutes les sources appartenant à ces zones ;

– pour tout groupe G qui a des membres présents dans une zone non backbone à laquelle il appartient, il diffuse dans la zone backbone une annonce résumée d’appartenance au groupe G.

Ces routeurs servent donc de point de rendez-vous entre sources et récepteurs situés dans des zones différentes.

Remarque : dans un tel cas, pour calculer l’arbre de diffusion d’un groupe G, un routeur considère comme membre de G les membres locaux à la zone, les routeurs « wildcard » (s’il se trouve dans une zone non backbone), et les routeurs qui envoient des annonces résumées pour G (s’il se trouve dans la zone backbone). Pour calculer l’arbre depuis S vers ces membres, si la source S est dans une zone adjacente, il peut utiliser sa base d’état des liens pour calculer les plus courts chemins depuis S. Si par contre S est dans une autre zone, la seule information disponible est un état des liens résumés indiquant à quelle distance S est située d’un routeur interzones L’arbre calculé n’est donc pas nécessairement un arbre des plus courts chemins depuis S dans le cas de liens dissymétriques.

1.7.3. Coût de MOSPF

OSPF construit un arbre par source, qui est (en intra-zone) un arbre des plus courts chemins. Il n’y a pas d’inondation de paquets de données. Le déploiement de MOSPF peut être partiel, le calcul de l’arbre ne prenant en compte que les routeurs MOSPF, donc capables de multicast. Les routeurs qui ne sont pas sur l’arbre (S,G) n’utilisent pas de ressources (état, signalisation) pour le flux (S,G). Par contre, l’ajout ou le retrait de membres provoque l’inondation du réseau par la signalisation de mise à jour d’états des liens : tout routeur MOSPF mémorise la localisation des membres de tous les groupes, même s’il n’y a aucune source active.

1.8. Le routage avec construction explicite : PIM-SM et CBT

Dans les sections 1.6 et 1.7, un arbre est construit pour chaque source, et sa construction est implicite, dirigée par les données. En 93 et 94 deux nouvelles architectures sont proposées. Elles reposent sur des arbres partagés construits explicitement par des messages d’adhésion : CBT [BAL 93] et PIM [DEE 94]. Dans les deux cas, des messages d’adhésion explicite sont envoyés depuis les récepteurs vers un point central racine de l’arbre de diffusion. Ce point est le Core de CBT, le


point de rendez-vous de PIM (RP). Ces deux architectures ont été présentées comme applicables à grande échelle, voire en inter-domaine.

L’architecture PIM introduit explicitement la notion de routage multicast indépendant du protocole unicast sous-jacent, contrairement à ce qui se passe avec DVMRP ou MOSPF. PIM a simplement besoin d’accéder à une table de routage (la MRIB si elle existe, sinon la RIB) pour connaître le prochain saut vers une adresse unicast (celle du RP ou d’une source). PIM a été décliné en deux variantes qui partagent le principe d’accès au routage unicast sous-jacent, ainsi que quelques messages communs : PIM-DM pour le mode dense (déjà vu au paragraphe 1.6.6) et PIM-SM pour le mode épars.

1.8.1. Principes de PIM en mode épars : PIM-SM

Quand un routeur PIM reçoit une demande d’adhésion à un groupe G pour lequel il n’a pas d’état, il envoie un message d’adhésion PIM (PIM-join) au prochain saut vers le RP. Ce message va donc créer une branche de l’arbre multicast jusqu’au premier routeur possédant une entrée pour G ou, à défaut, jusqu’au RP. Ce message crée des entrées (*,G) dans les routeurs intermédiaires. Une branche peut être supprimée soit par un message d’élagage PIM explicite (PIM-prune), soit si aucun message d’adhésion PIM n’est reçu pendant un certain temps. Depuis la version du RFC 2362 [EST 98], il n’y a pas d’acquittement des messages d’adhésion/retrait. Les messages d’adhésion sont envoyés cycliquement suivant le principe soft state.

L’arbre construit est un arbre unidirectionnel partagé : un paquet multicast émis par une source vers un groupe G est intercepté par le premier routeur (dit routeur désigné (DR, designated router) qui l’encapsule dans un message unicast d’enregistrement (PIM-register) envoyé au RP de G. Le RP décapsule le paquet et le propage dans l’arbre vers les récepteurs.

En plus des arbres partagés (*,G), PIM-SM permet des arbres ou des branches par source, correspondant à des entrées (S,G). Un routeur ayant des membres de G directement attachés, lorsqu’il reçoit des paquets venant d’une source, peut décider de créer une branche (S,G) en envoyant un message PIM-join(S,G) vers S. Le premier routeur où la route vers S et celle vers le RP divergent recevra donc les paquets (S,G) en double : une fois de l’arbre partagé et une fois de l’arbre spécifique à S. Pour éviter ces doublons, il envoie un message PIM-prune(S,G) vers le routeur amont dans l’arbre partagé dès qu’il reçoit des données de l’arbre par source.

Une branche (S, G) peut aussi être créée par le RP pour éviter les encapsulations de données depuis la source. Pour cela, le RP envoie un message PIM-join(S,G) au


DR de la source. Au premier paquet venant de S sans être encapsulé dans un message PIM-register, le RP envoie un message PIM-register-stop au DR, qui n’encapsulera donc plus les données émises par S.

Trois stratégies peuvent être proposées pour le passage à un arbre par source : soit la transition est déclenchée sur un seuil de débit suffisant venant de S, soit elle n’est jamais déclenchée, soit elle est déclenchée par le premier paquet venant de S, technique parfois baptisée mode sparse-dense. Cette dernière technique n’utilise donc l’arbre partagé que pour apprendre l’existence des sources actives, les routeurs des sources et ceux des récepteurs ayant en commun de connaître les RP. Notons que le passage à une branche par source est décidé par les routeurs et non par les récepteurs ; de plus, les routeurs peuvent appliquer des stratégies différentes.

H1 R1 R2 RP

Figure 1.2. Construction d’un arbre multicast avec PIM

Cela nous amène à la question suivante : comment les routeurs déterminent-ils le RP d’un groupe ? Une configuration manuelle de tous les routeurs est difficilement applicable à grande échelle et peu robuste en cas de panne. La principale solution

R5 R3 R4

H5

H2

H3 H4

PIM-register PIM-join(*,G) IGMP-report

i2 i1

i4 i3

PIM-join(H1,G)


proposée et normalisée est basée sur les routeurs d’amorçages (BSR : Boot Strap Router) [EST 99].

Scénario PIM-SM avec le réseau de la figure 1.2 1) H2 adhère au groupe G, envoie un IGMP-report 2) R3 reçoit le report, crée une entrée (*,G) dans sa table et envoie un PIM-join vers le RP de G, donc vers R4 3) R4 reçoit le PIM-join, crée une entrée (*,G) et propage le PIM-join vers le RP 4) Le RP reçoit le PIM-join et crée un entrée (*,G) 5) H3 adhère au groupe G, envoie un IGMP-report 6) R3 reçoit le report, mais ne change pas d’état car il y a déjà un membre de G sur la même interface 7) H5 adhère au groupe G, envoie un IGMP-report 8) R5 reçoit le report, crée une entrée (*,G) et envoie un PIM-join vers le RP de G 9) R4 reçoit le PIM-join, ajoute l’interface vers R5 dans l’entrée (*,G) et ne propage pas le PIM-join A ce stade, des PIM-join périodiques circulent entre R3 et R4, R5 et R4, R4 et le RP 10) H1, qui n’est pas nécessairement récepteur de G, envoie un paquet à G 11) R1 reçoit le paquet, constate que H1 est une source directement connectée, crée une entrée (H1,G) dans sa table, encapsule le paquet de données dans un paquet unicast PIM-register à destination du RP 12) Le RP reçoit le paquet PIM-register, extrait le paquet de donnée multicast, et le propage vers les interfaces de sorties indiquées dans l’entrée (*,G), donc vers R4 14) R4 propage le paquet vers les interfaces de sortie, donc vers R3 et R5 15) De même, R3 propage le paquet vers l’interface qui mène à H2 et H3 et R5 le propage vers H5 Si, par exemple, le routeur R3 décide de passer à un arbre par source pour H1, on a : 16) R3 crée une entrée (H1,G) et envoie un PIM-join(H1,G) vers H1,donc vers R4 17) R4 crée une entrée (H1,G) et propage le PIM-join(H1,G) vers R2 18) R2 crée une entrée (H1,G) et propage le PIM-join(H1,G) vers R1 19) R1 met à jour son entrée (H1,G) A la prochaine émission de paquet de H1 vers G : 20) R1 reçoit le paquet et en propage une copie vers le RP comme en 11), et une copie vers R2 21) R2 propage le paquet vers R4 22) R4 constate que l’entrée (H1,G) est maintenant effective et envoie un PIM-prune(H1,G) vers le RP. A ce stade, la table de R4 contient deux lignes : - une ligne (*,G) avec entrée par i2 et sorties par i3 et i4 - une ligne (H1,G) avec entrée par i1 et sorties par i3 et i4

Exemple 1.1. Un scénario de construction d’arbre PIM-SM


1.8.2. Découverte des RP : les routeurs d’amorçage (BSR)

Chaque routeur est configuré pour être ou non candidat BSR d’une part, et pour être ou non candidat RP pour un bloc d’adresses multicast d’autre part. Les candidatures BSR et RP sont inondées de proche en proche vers tous les autres routeurs du domaine. Le candidat BSR qui a la meilleure adresse est élu BSR. Il synthétise alors toutes les candidatures pour les RP et diffuse une liste de RP par bloc d’adresses multicast. Cette liste est donc connue de tous les routeurs. Chaque routeur qui a besoin de connaître le RP d’un groupe G utilise alors un hachage dans la liste de RP pour le bloc d’adresses auquel appartient G. La fonction de hachage doit bien sûr être la même pour tous les routeurs. Elle permet de répartir les groupes entre les RP d’un même bloc sans connaître à l’avance les groupes effectivement utilisés.

La liste des RP pour un ensemble d’adresses peut varier en fonction de l’ajout ou du départ de candidats RP (pannes, coupures réseau). A chaque fois que cette liste change, un routeur PIM doit recalculer la fonction de hachage pour chaque groupe actif G. Si le RP obtenu change, l’arbre doit être reconstruit par élagage vers l’ancien RP et adhésion vers le nouveau RP.

Le principe du BSR n’est pas applicable à très grande échelle, et en particulier à l’échelle d’Internet, car il suppose une inondation du réseau. Une autre difficulté avec cette méthode vient du fait que le RP est a priori placé indépendamment de la localisation des récepteurs, ce qui peut engendrer un arbre loin de l’optimal. Une solution à ce problème a été proposée dans [KIM 03]. Elle consiste à utiliser plusieurs RP ayant la même adresse anycast. Pour un groupe, il se forme autant d’arbres que de RP, un récepteur est attaché au RP le plus proche. Les RP sont interconnectés à la source en utilisant MSDP [FEN 03] (voir section 1.9.5 et chapitre 7). Par ailleurs, plusieurs études ont été faites sur le placement des centres ou sur la possibilité d’avoir plusieurs centres actifs simultanément [ZAP 02].

1.8.3. Maintenance de l’arbre PIM-SM

La maintenance de l’arbre PIM-SM repose sur deux mécanismes : des messages PIM-hello périodiques permettent de connaître les voisins PIM actifs, indépendamment de tout groupe. Par ailleurs, tout changement du routage unicast (MRIB ou à défaut RIB) amène à vérifier si le prochain saut vers le RP (ou S suivant le cas) n’a pas changé, auquel cas un message d’élagage est envoyé vers l’ancienne interface, et un message d’adhésion vers la nouvelle. Il s’agit là d’une forme de RPF check, les données multicast empruntent le chemin utilisé dans l’autre sens par les données unicast. Par ailleurs, pour chaque arbre, un routeur PIM envoie


cycliquement un message d’adhésion au routeur amont. En l’absence de ce message celui-ci peut donc supprimer l’interface de sortie correspondante.

1.8.4. Core Based Trees : CBT

Le protocole CBT (core based trees) ([BAL 93, 97a, 97b]) partage avec PIM-SM la notion d’arbre partagé construit explicitement. Les principales différences sont les suivantes :

– l’arbre est bidirectionnel : une source qui est membre de l’arbre diffuse directement dans l’arbre sans passer au préalable par le centre (core). Une source qui est non-membre émet ses paquets encapsulés en unicast vers le centre. Quand le paquet atteint le centre, il est propagé dans l’arbre bidirectionnel.

– les messages Join sont acquittés par le premier routeur sur l’arbre ou à défaut le centre. Un routeur sait donc si le Join a réussi, ce qui n’est pas le cas avec PIM. Il y a également la possibilité de supprimer un sous-arbre (flush) en cas de changement du routage par exemple. Cela permet éventuellement d’accélérer la reconstruction de l’arbre.

A noter que la version initiale de CBT [BAL 93] autorisait plusieurs centres par groupe. Cela posait des problèmes de boucles (voir OCBT, [SHI 97]). La deuxième version, CBTv2 [BAL 97a] n’autorise qu’un seul centre par groupe. La technique du BSR a été aussi adoptée pour sélectionner le centre en intra-domaine. CBT est présenté comme une solution possible dans le cas inter-domaine, mais en n’utilisant pas le mécanisme BSR pour désigner le centre.

1.8.5. PIM bidirectionnel

Une variante de PIM a été proposée en 1999 par Estrin et Farinacci et ensuite améliorée par Kouvelas [HAN 04] pour utiliser des arbres bidirectionnels partagés. Cette variante n’utilise pas d’arbre par source. Le principe est le suivant :

– pour chaque sous-réseau et chaque RP, il y a élection d’un routeur appelé propagateur désigné (DF, designated forwarder) : il s’agit du routeur connecté à ce réseau qui a la meilleure route unicast (MRIB) vers le RP.

– de plus, chaque routeur a une et une seule interface RPF pour un RP donné.

Pour un groupe G associé à un certain RP, les interfaces d’entrées possibles sont donc l’interface RPF (paquet downstream venant du RP), et les interfaces DF (paquet upstream allant vers le RP). Un paquet est accepté par un routeur s’il est reçu par l’une des entrées possibles. Les interfaces de sorties possibles sont celles


déterminées par IGMP, PIM (comme dans PIM-SM) plus l’interface RPF. Un paquet accepté est retransmis sur toutes les sorties possibles sauf l’interface d’entrée.

Exemple de PIM bidirectionnel avec le réseau de la figure 1.2 Pour le routeur R4, i2 est l’interface RPF, i3 et i4 sont des interfaces DF. Si H2, H3, H4 et H5 ont adhéré à G, l’arbre (*,G) est le même que pour PIM-SM. 1) H1 envoie un paquet à G : il circule upstream vers le RP en passant par R1 et R2 2) Arrivé au RP par une interface DF, il est envoyé à R4 (interface apprise via PIM) 3) R4 le propage vers R3 et R5 (interfaces apprises par PIM) 4) Si H5 envoie un paquet à G, il circule upstream vers R5 puis R4 5) Le paquet arrive en R4 par une interface DF, il est donc retransmis downstream vers R3 (interface apprise par PIM) et upstream vers le RP (interface RPF) 6) Arrivé au RP le paquet est accepté (interface DF) mais n’est pas propagé dans ce cas car il n’y a pas d’autre sortie possible

Exemple 1.2. Commutation d’un paquet avec PIM bidirectionnel

On peut noter qu’avec PIM bidirectionnel, un routeur n’a pas besoin de mémoriser d’état par source, et que les paquets se propageant d’une source vers le RP ne sont pas encapsulés, contrairement à PIM-SM ou CBT. Cette variante peut coexister avec PIM-SM (ou PIM-SSM) en utilisant des plages d’adresses disjointes. Elle reprend le concept d’arbres bidirectionnels partagés de CBT, tout en utilisant des éléments de protocole existants (et implantés) de PIM, ce qui rend son déploiement plus facile. Notons également que le RP ne joue aucun rôle particulier dans l’acheminement des paquets et peut donc être un routeur virtuel, ce qui améliore la robustesse. Par contre, ce protocole souffre, comme PIM-SM, des limitations du modèle ASM en ce qui concerne la détermination des RP, ce qui le rend difficilement utilisable seul en inter-domaine.

1.8.6. Coût des méthodes explicites

En terme d’états à mémoriser, seuls les routeurs appartenant à un arbre (*,G) ou (S,G) doivent mémoriser des informations pour G. De plus, les arbres partagés permettent de n’avoir qu’une seule entrée de table par groupe, au détriment d’un chemin de données indirect via le RP. Il n’y a pas d’inondation cyclique du réseau par les données, contrairement à PIM-DM ou DVMRP. Il n’y a pas non plus d’inondation d’information sur les membres des groupes, contrairement à MOSPF. Les données peuvent être encapsulées avant d’atteindre l’arbre (message PIM-register). Les arbres partagés impliquent généralement une route non optimale entre


une source et un récepteur puisque les paquets passent par le RP. De plus, la méthode du BSR génère une diffusion cyclique de messages de contrôle.

1.9. Le routage multicast inter-domaine

Internet est constitué d’un ensemble de domaines de routage ou autonomous systems (AS). Chaque domaine est en général géré par une seule entité et utilise un seul protocole de routage unicast (et multicast). Les domaines sont reliés entre eux via des routeurs frontières qui exécutent un protocole de routage unicast inter-domaine, essentiellement BGP4 [REK 95] à l’heure actuelle. Le routage multicast inter-domaine pose deux séries de questions :

– celles liées à l’aspect inter-domaine proprement dit : indépendance des domaines, politique de routage, sécurité ;

– celles liées à la taille d’Internet (extensibilité).

Bien entendu, les deux types de questions doivent être résolus simultanément pour permettre le déploiement du multicast à l’échelle d’Internet.

Les architectures CBT et PIM-SM avaient initialement été présentées comme extensibles à Internet, principalement car elles ne provoquaient pas d’inondation et réduisaient le nombre d’états en créant des arbres partagés. En fait, au moins trois problèmes demeurent : comment allouer des adresses multicast uniques sur Internet, comment fixer le point de rendez-vous en inter-domaine, et comment le trouver à partir de l’adresse du groupe.

1.9.1. L’architecture MASC /BGMP

Une architecture globale, MASC/BGMP a été proposée à l’Ietf [KUM 98]. Elle est basée sur :

– l’architecture d’adressage Masc déjà vue au paragraphe 1.2.3 [RAD 00] ; – une extension du protocole de routage unicast inter-domaine BGP [BAT 00] ; – un modèle de routeur multicast frontière, qui traite en particulier l’interaction

entre routage multicast intra et inter-domaines [THA 99] ; – un protocole de routage multicast inter-domaine : BGMP [THA 04].

Les idées principales sont les suivantes : – chaque domaine peut utiliser son propre routage multicast intra-domaine, qui

doit être interfacé avec le routage inter-domaine. Cela reprend le modèle utilisé avec succès dans le routage unicast ;


– les arbres de diffusion inter-domaines sont construits explicitement vers une racine suivant un principe analogue à celui de PIM-SM ou CBT. L’arbre BGMP peut être vu comme un arbre de domaines enraciné en un domaine racine ;

– comme la technique du BSR ne peut être généralisée à Internet, l’association entre une adresse de groupe et le domaine racine est connue grâce à des informations de routage supplémentaires véhiculées par une extension de BGP et stockées dans la GRIB.

1.9.2. Les extensions multi protocoles de BGP

Le protocole BGP a été initialement conçu pour annoncer l’accessibilité d’adresses (ou plus généralement de préfixes d’adresses) unicast IPv4. Les extensions multi protocoles de BGP [BAT 00], parfois dénommées MBGP ou BGP4+, permettent de prendre en compte d’autres types d’adresse. En particulier, un champ AFI (address family identifier) décrit la famille de protocoles concernée (typiquement IPv4 ou IPv6), et un deuxième champ SAFI (subsequent address family identifier) précise le type d’adresse (ou plutôt son utilisation). Le SAFI 1 indique ainsi une adresse utilisée pour le routage unicast, alors que le SAFI 2 indique une adresse utilisée pour le routage multicast. D’autres SAFI ont été proposés, par exemple pour les VPN. Le SAFI 3 (= 1 + 2) indique une annonce utilisable aussi bien pour le routage unicast que multicast.

Pour le SAFI 2 (routage multicast), deux utilisations existent : – soit il s’agit d’une adresse (ou d’un préfixe) unicast qui sera utilisée pour un

RPF check. C’est le cas par exemple de la construction d’une branche vers une source avec MSDP ou PIM-SSM. Ce type d’information est mémorisé dans la MRIB ;

– soit il s’agit d’une adresse (ou d’un bloc d’adresses) multicast G qui sera utilisée par un protocole comme BGMP pour construire une branche inter-domaine vers le domaine racine (celui qui a obtenu le bloc d’adresses G au moyen du protocole Masc par exemple). Ce type d’informations est mémorisé dans la GRIB (Group RIB).

Remarque : il est important de pouvoir distinguer des annonces d’adresses unicast avec SAFI 1 et SAFI 2. En effet, les topologies du réseau pour les communications unicast et multicast peuvent être différentes pour plusieurs raisons :

– certains routeurs ou domaines peuvent ne pas avoir de routage multicast activé (ni même disponible) ;

– un opérateur peut refuser de véhiculer le trafic multicast de certains domaines,


– un opérateur peut répartir différemment les trafics unicast et multicast pour optimiser l’utilisation de son réseau.

Les informations de la GRIB et de la MRIB sont annoncées aux routeurs voisins après sélection de la meilleure route et application de la politique de routage (filtrage, …). Par exemple, ne pas annoncer une adresse G vers un domaine voisin V revient à interdire le transit des paquets multicast de G vers V.

1.9.3. Interaction avec le routage intra-domaine

Le RFC 2715 [THA 99] décrit un modèle d’interaction entre différents protocoles de routage multicast intra ou inter domaine. Chaque interface du routeur frontière (MBR, multicast border router) est sous la responsabilité d’une entité qui implante un de ces protocoles. Une entité fédératrice permet de coordonner ces entités, en particulier sous forme d’alertes. Une alerte est un événement généré par une entité et qui doit être traité par une autre. Par exemple, un message d’adhésion PIM reçu par l’entité PIM-SM peut provoquer une alerte pour la création d’une branche BGMP, ou réciproquement.

Il est aussi nécessaire que le routeur frontière soit au courant des événements à l’intérieur du domaine, ce qui peut nécessiter la modification des protocoles de routage multicast intra-domaine comme par exemple les entrées (*,*,G) de PIM-SM, ou bien l’utilisation d’un protocole supplémentaire permettant d’informer le MBR des groupes qui ont des récepteurs dans le domaine, comme les domain wide reports proposés pour compléter les protocoles à inondation [FEN 01].

1.9.4. BGMP

BGMP (border gateway multicast protocol) [THA 04] (à ne pas confondre avec MBGP qui désigne parfois les extensions multi protocoles de BGP [BAT 00]) est un protocole à construction explicite d’un arbre de routage inter-domaine. Il construit un arbre de domaines, enraciné sur le domaine racine (celui qui possède l’adresse du groupe). Il s’agit d’un arbre partagé bidirectionnel. Typiquement, le déroulement est le suivant :

– un message d’adhésion (*,G) arrive au routeur frontière R, venant soit d’un voisin BGMP d’un autre domaine, soit d’un voisin intra-domaine via un PIM-join par exemple ;

– en examinant sa GRIB (construite grâce aux extensions de BGP), le routeur détermine que le prochain saut vers le domaine racine de G est un voisin externe R1.


R envoie alors à R1 un message BGMP-join (*,G), et note que l’interface d’entrée pour G est celle menant à R1 ;

– R1 détermine de même le prochain saut vers G. Si c’est un routeur extérieur R2, il procède comme R. Si c’est un routeur interne, le protocole intra-domaine est alerté. Par exemple, s’il s’agit de PIM-SM, un PIM-join est envoyé vers le RP de G. La signalisation de BGMP est donc relayée par la signalisation intra-domaine. Elle peut traverser le domaine pour réactiver un autre routeur BGMP, ou bien rester dans le domaine si celui-ci est le domaine racine pour G.

Des arbres unidirectionnels par source peuvent aussi être construits. Le principe est le même, sauf que BGMP calcule le prochain saut vers la source plutôt que vers le domaine racine de G, en utilisant cette fois la MRIB.

Une difficulté supplémentaire vient de la nature ouverte des groupes : une source peut émettre vers un groupe alors qu’elle est dans un domaine qui ne fait pas partie de l’arbre BGMP de G. Dans ce cas, le routeur frontière est alerté par le routage intra-domaine. Si aucune entrée pour G n’existe, il envoie le paquet nativement (sans encapsulation) au voisin BGMP vers le domaine racine, tel qu’indiqué par la GRIB. Lorsque le paquet atteint un domaine où une entrée (*,G) existe, il est propagé vers tous les voisins dans l’arbre bidirectionnel.

Cette description succincte montre bien la très grande complexité de l’architecture Masc/BGMP. D’ailleurs, BGMP a été publié en RFC informationnel [THA 04] et va sans doute être arrêté. Plusieurs alternatives ont été étudiées et parfois implémentées. Certaines, comme MSDP (paragraphe suivant) ont un rôle essentiellement transitoire. D’autres, comme Express, Simple ou LAR, visent à définir un autre modèle.

1.9.5. La solution PIM-SM et MSDP

Quand l’architecture MASC/BGMP a été présentée, il a été rapidement évident qu’elle était très complexe et qu’elle ne pourrait être déployée avant d’avoir mis au point les nombreuses briques nécessaires. Comme une solution satisfaisante et opérationnelle existe au niveau intra-domaine avec PIM-SM, il a été proposé une solution, a priori provisoire, pour permettre à des sources d’émettre vers des récepteurs hors de leur domaine. Cette solution est appelée MSDP (multicast source discovery protocol) [FEN 03, MCB 04].

Le principe de MSDP est le suivant : – chaque domaine participant exécute un protocole de routage multicast intra-

domaine, a priori PIM-SM. Le (ou les) routeur jouant le rôle de point de rendez-


vous pour des groupes acceptant des sources externes exécute en plus le protocole MSDP (nœud MSDP) ;

– chaque nœud MSDP établit une connexion TCP avec au moins un autre nœud MSDP, formant ainsi un graphe connexe de domaines utilisant MSDP ;

– lorsqu’un nœud MSDP apprend l’existence d’une source locale à son domaine, par exemple via un PIM-register, il forme un message d’annonce de source, et l’envoie aux nœuds MSDP voisins ;

– un nœud MSDP qui reçoit une annonce de source la propage aux autres nœuds MSDP en utilisant une inondation par le chemin inverse. Il peut de plus la conserver dans un cache. Ainsi, tout nœud MSDP reçoit toutes les annonces de sources ;

– les annonces de source sont diffusées à intervalles réguliers (principe soft state) ;

– un nœud MSDP qui reçoit une annonce de source S pour un groupe G vérifie s’il possède une entrée (*,G) indiquant que des récepteurs du groupe sont présents dans son domaine ;

– dans l’affirmative, ce nœud envoie un message d’adhésion PIM-join(S,G) à destination de la source. Comme S n’est pas a priori dans le même domaine, le message sera propagé vers S à travers les frontières en utilisant la MRIB des routeurs frontières BGP ;

– le message d’adhésion est propagé à travers un ou plus plusieurs domaines jusqu’à atteindre un routeur possédant déjà une entrée (S,G).

Globalement, il se crée donc un arbre inter-domaine (S,G) reliant des RP (nœuds MSDP) à la source. PIM-SM ayant déjà les mécanismes pour construire des branches par source, peu de modifications sont nécessaires, à part l’interaction avec MSDP quand une annonce arrive. Il faut aussi exécuter MBGP sur les routeurs frontières.

Le problème principal avec cette solution vient du fait que toute source provoque une inondation régulière des nœuds MSDP. Cela n’est donc pas extensible à un grand nombre de sources actives, surtout si elles n’intéressent qu’un petit nombre de domaines. Par ailleurs, cette solution est assez sensible aux attaques de type DDoS.

1.10. Le modèle de multicast spécifique à une source : SSM

1.10.1. Express

Le modèle SSM est né de l’architecture Express proposée par Holbrook et Cheriton [HOL 99]. Dans Express, la notion de groupe est remplacée par celle de canal (channel). Un canal a un seul émetteur, la source, ce qui est particulièrement


adapté à des applications de type diffusion de canaux vidéo ou audio. Un tel canal est essentiellement unidirectionnel. Une telle architecture présente plusieurs avantages :

– comme il y a une seule source par canal et que l’identificateur du canal contient l’identificateur de la source, il n’y a plus de problème de contrôle des émetteurs dans un groupe ;

– de même, l’adresse d’un canal est dérivée de celle de la source, donc il n’y pas de problème d’allocation distribuée d’adresses multicast ;

– les arbres étant unidirectionnels enracinés en la source (et l’adresse de la source étant connue), il n’y a pas besoin de mécanisme de point de rendez-vous ;

– il n’y a pas de routage triangulaire source-RP-récepteur, ce qui évite la dépendance à un réseau tiers (third party dependancy).

En plus de ces nouveaux concepts, [HOL 99] présente un nouveau protocole qui réalise à lui seul trois fonctions : l’adhésion aux groupes (à la place de IGMP), la construction et la maintenance de l’arbre (en tant que protocole de routage multicast), et un mécanisme de comptage permettant en particulier de savoir combien de récepteurs sont abonnés au canal. Ce dernier mécanisme n’existe pas en tant que tel dans le routage multicast classique, et doit être émulé à un niveau supérieur, par exemple au niveau transport (RTP/RTCP) [SCH 03].

Face aux difficultés pour déployer un routage multicast à grande échelle, le modèle Express a été adapté au multicast classique sous le nom de modèle SSM (source specific multicast), le modèle initial de Deering étant rebaptisé modèle ASM (any source multicast). Les deux modèles ne sont pas incompatibles et peuvent coexister facilement en se partageant l’espace d’adressage.

Il est à noter que le modèle SSM (et en particulier son intégration dans PIM-SM) ne reprend pas toutes les propositions d’Express. En particulier, pour des raisons évidentes de compatibilité avec l’existant, la séparation entre routage (PIM) et adhésion aux groupes (IGMP) a été maintenue. De ce fait, le mécanisme de comptage des récepteurs n’a pas été implanté.

1.10.2. Le modèle SSM et PIM-SM

Comme PIM-SM comportait déjà les mécanismes pour construire des branches par source, peu de modifications ont été nécessaires pour intégrer le modèle SSM, en dehors de l’interfaçage avec IGMPv3 [CAI 02]. Le principe est le suivant :

– une plage d’adresses multicast, correspondant au préfixe 232.0.0.0/8, est réservée pour les canaux SSM. Un canal SSM est identifié par l’adresse de la source


et une adresse SSM (numéro de canal). Deux sources peuvent utiliser sans dommage le même numéro de canal, il n’y a donc pas besoin de protocole d’allocation d’adresses ;

– le protocole IGMPv3 est utilisé en mode inclusif pour demander l’abonnement à un canal (S,G), où S est l’adresse de la source et G une adresse SSM ;

– un routeur recevant une demande d’abonnement à un canal (S,G), où G est une adresse SSM, met à jour l’entrée (S,G) de la table de routage multicast si elle existe. Si elle n’existe pas, elle est créée, et un message PIM-join(S,G) est envoyé en direction de S, sans qu’une entrée (*,G) soit créée au préalable, contrairement au cas ASM. Un routeur recevant un message PIM-join (S,G) le traite comme dans le mode ASM. Un routeur recevant un message PIM-join (*,G), où G est une adresse SSM, ignore ce message.

Le modèle SSM est maintenant pleinement intégré dans les spécifications de PIM-SM [FEN 04].

1.10.3. Limitations de PIM-SSM

La principale limitation de PIM-SSM découle de son principe de base : il n’y a qu’un seul émetteur par canal. Pour les applications de groupe avec plusieurs sources, il faut donc soit créer autant de canaux que de sources, soit centraliser les émissions via un réflecteur (relais), ce qui nécessite des adaptations au-dessus de la couche IP.

Si on utilise un service réseau SSM pour des applications utilisant le service ASM (découverte implicite des sources), un mécanisme de découverte dynamique des sources doit être mis en place. Ce mécanisme peut être intégré dans l’application elle-même ou bien sous forme d’une couche intermédiaire (middleware) qui émule le service ASM au dessus de SSM. C’est par exemple la solution proposée dans SSMSDP [BEC 03, HOE 04] : une session ASM (au dessus de SSM) est désignée par un canal de contrôle (C,G). Les récepteurs s’abonnent au canal de contrôle. Les sources s’annoncent auprès du contrôleur qui propage ces annonces sur le canal de contrôle. Les récepteurs peuvent alors s’abonner aux canaux de chaque source. Une telle solution est en cours de discussion à l’Ietf [BEC 03, LEH 04].

Même s’il y a une seule source de données applicatives, un modèle multipoint-à-multipoint peut aussi servir aux récepteurs de données pour émettre des informations de contrôle. Par exemple, les rapports RTCP [SCH 03] sont normalement envoyés au groupe et donc reçus par tous, ce qui permet à chacun de connaître l’état de la transmission. Dans [CHE 04], deux mécanismes sont proposés pour continuer à utiliser RTCP avec un canal SSM :


– soit les rapports RTCP sont envoyés en unicast à la source, qui les réémet tels quels dans le canal ;

– soit les rapports RTCP sont synthétisés par la source avant d’être réémis, ce qui décharge le canal RTCP mais diminue la précision de l’information et augmente la charge de traitement de la source s’il y a beaucoup de récepteurs. L’article [ALM 01] étudie d’autres problèmes d’intégration des modèles ASM et SSM.

Une autre limitation est liée au nombre d’états créés dans le réseau. D’une part il n’y pas d’arbre partagé, donc si n nœuds veulent être à la fois émetteurs et récepteurs multicast, alors n arbres doivent être créés. Par ailleurs, dans PIM-SM d’origine (modèle ASM), une branche spécifique à une source S n’est créée que si au moins un paquet est émis par S. Avec PIM-SSM, le récepteur s’abonne d’emblée au canal (S,G), même si la source n’émet pas encore ou n’existe pas. Cela peut donc créer un grand nombre d’états inutiles dans les routeurs et peut donc être une source potentielle d’attaque par déni de service distribué (DDoS).

1.11. Multicast et IPv6

L’arrivée d’IPv6 [CIZ 02], la nouvelle version du protocole IP, a été l’occasion de chercher de nouvelles solutions au problème du multicast. De ce point de vue, IPv6 apporte des nouveautés principalement du fait de son espace d’adressage beaucoup plus grand, et de la plus grande facilité pour introduire de nouveaux mécanismes grâce aux extensions d’en-tête. De plus, le protocole d’adhésion au groupe a été intégré dans ICMP.

1.11.1. Adressage multicast IPv6

Les adresses IPv6 sont codées sur 128 bits [HIN 03]. Les adresses broadcast n’existent plus. Le format de base des adresses multicast est composé d’un préfixe de 8 bits valant FF, de 4 bits représentant des drapeaux (flags), de 4 bits indiquant la portée, puis de 80 bits dont la signification dépend des flags (et donc nuls si les flags sont à zéro), et finalement de 32 bits de numéro de groupe, le Gid. La correspondance entre adresse multicast IPv6 et adresse multicast IEEE802 consiste à prendre les 32 derniers bits de l’adresse IPv6 (le Gid) et à les faire précéder du préfixe hexadécimal 3333. Deux Gid différents auront donc deux adresses Mac différentes.

La portée peut prendre les valeurs prédéfinies 1 (locale au nœud), 2 (locale au lien), 5 (locale au site), 8 (locale à l’organisme) et E (globale). Les 4 bits de drapeau xyzt de flags désignent une adresse permanente si t = 0 ou transitoire si t = 1. Par


exemple FF02:0::D représente une adresse permanente de portée locale au lien (tous les routeurs PIM du lien), et FF05:0::1:3 est l’adresse permanente locale au site de tous les serveurs dhcp. L’adresse FF1E::7777 représenterait le groupe global transitoire de Gid 7777. Du fait de la grande taille des adresses, les 80 bits inutilisés dans le format de base ont permis de créer de nouveaux moyens d’allouer des adresses multicast. Le flag z à 1 indique une adresse basée sur un préfixe unicast [HAB 02]. Dans ce cas les 80 bits sont découpés en 8 bits réservés (à 0), 8 bits de longueur de préfixe plen et 64 bits de préfixe prefix. La signification est que cette adresse a été allouée (« appartient ») au réseau d’adresse prefix/plen. Par exemple l’adresse FF3E:40:2001:660:220:102::7777 est une adresse transitoire globale appartenant au réseau de préfixe 2001:660:220:102/64. Il y a possibilité de créer 232 adresses de groupe dans ce réseau. Avec ce codage il devient assez facile d’allouer des adresses globales uniques. Notons que si une telle adresse appartient au réseau de préfixe correspondant, elle est néanmoins globale et peut être utilisée en émission ou réception partout dans Internet : cela n’est en aucun cas un mécanisme de contrôle sur l’utilisation.

Un cas particulier concerne les adresses SSM : elles correspondent à des adresses basées sur un préfixe unicast de longueur nulle (plen = 0), donc au préfixe FF3x::/96. Par exemple FF3E::7777 correspond au canal global 7777 associé à la source du paquet.

1.11.2. Protocole d’adhésion aux groupes : MLD

Dans l’architecture IPv6, le protocole IGMP a été intégré dans le protocole ICMPv6. Les messages correspondant à IGMP forment le (sous-)protocole MLD (multicast listener discovery). La première version [DEE 99] dérive directement de IGMPv2 [FEN 97], alors que la deuxième version MLDv2 [VID 04] qui intègre le filtrage de sources et permet l’utilisation du service SSM correspond à IGMPv3 [CAI 02].

1.11.3. Mécanisme RP-embedded

Un dernier cas particulier des adresses basées sur le préfixe unicast est appelé RP-embedded (adresse du RP intégrée) [SAV 04]. Dans ce cas, les flags valent 0111 et les 80 bits réservés se décomposent en 4 bits à zéro, 4 bits RPad, 8 bits plen et 64 bits de préfix. L’idée est qu’une adresse unicast complète (du RP) peut être reconstituée sous la forme préfixe/len ::rpad. Cette adresse unicast sera utilisée comme celle du RP correspondant au groupe. Par exemple FF7E:540:2001:660:220:102::7777 intègre l’adresse de RP 2001:660:220:102::5. Ce codage permet donc de créer 16 RP par


lien, chaque RP pouvant gérer théoriquement 232 groupes. Notons que ces adresses de RP ne sont pas créées par le mécanisme d’autoconfiguration habituel d’IPv6.

Nous pouvons conclure qu’avec IPv6, l’allocation d’adresses IPV6 est grandement simplifiée et des protocoles comme MASC et AAP ne seront pas utiles. Par ailleurs, le problème de la détermination d’un RP unique pour un groupe ASM semble pouvoir être résolu avec le mécanisme RP-embedded, ce qui ouvre la porte au routage ASM inter-domaine en n’utilisant que PIM-SM. Le protocole MSDP n’a d’ailleur pas été porté en IPv6. En ce qui concerne l’utilisation de PIM bidirectionnel avec RP-embedded, le problème est plus complexe car dans ce cas les routeurs ne connaissent pas à l’avance tous les RP possibles et ne peuvent donc pas calculer les interfaces DF. Le mécanisme actuel d’élection des routeurs DF est trop long pour être effectué à la volée lors de la réception d’un paquet de données.

1.12. Autres propositions de routage multicast

Plusieurs alternatives au modèle classique de routage multicast ont été proposées, en particulier quand l’architecture MASC/BGMP a montré ses limites. Elles cherchaient à résoudre certaines limitations des protocoles existants, comme la détermination du point de rendez-vous d’un groupe et l’allocation d’adresses multicast (simple multicast) ou la construction d’arbre des plus courts chemins (et non pas d’arbres des plus courts chemins inverses) (Reunite, HBH, LAR). En effet, les routes dans Internet sont fortement dissymétriques [PAX 97], et avec la plupart des protocoles de routage actuels (en particulier avec PIM-SSM ou avec PIM-SM/MSDP), la route empruntée pour aller d’une source S (ou un RP) à un récepteur D sera la route qu’emprunterait un paquet unicast pour aller de D à S. Si ces deux routes sont différentes, il est possible que :

– la route inverse soit moins bonne, sinon elle aurait été préférée à la route directe ;

– la politique de routage unicast interdise (ou pénalise) la route directe. Cette politique se trouve donc violée par le trafic multicast.

1.12.1. Simple Multicast

Proposé en 1998-99 [PER 99], Simple Multicast repose sur le principe qu’un groupe est identifié par un couple d’adresses : celle du centre de l’arbre C (core) et un numéro de groupe G. De ce fait, le numéro de groupe doit simplement être unique pour un centre donné, ce qui élimine le besoin d’une architecture d’allocation d’adresses complexe à la MASC. Cela suppose bien sûr que le couple (C,G) soit appris par un moyen externe. L’adhésion à un groupe doit aussi spécifier C et G.


L’arbre construit est bidirectionnel, et le couple (C,G) est contenu dans un champ supplémentaire, par exemple une option IP.

On peut remarquer que plusieurs principes de cette architecture ont été repris dans PIM-SSM, en particulier l’identification du groupe par un couple d’adresses. De plus, la nouvelle version d’IGMP permet d’adhérer à un couple (S,G), ce qui est très proche syntaxiquement d’une adhésion au groupe (C,G). Un problème non résolu est le choix du centre. L’avantage par rapport à PIM-SSM est de ne construire qu’un seul arbre par groupe, au détriment d’un routage moins optimal, et d’une encapsulation des données (sous forme de l’option IP supplémentaire). Cette encapsulation pourrait permettre un déploiement partiel en créant des tunnels à travers des routeurs n’utilisant pas Simple Multicast.

1.12.2. Adressage et Routage logiques : LAR

Le principe de LAR [GRA 95], [PAN 98b], [PAN 00] est d’utiliser deux niveaux d’adressage : un niveau d’adressage logique indépendant de la localisation (groupes, mobiles, …) au-dessus d’un adressage réseau classique. Une grande différence avec les architectures précédentes est que l’arbre (par défaut partagé bidirectionnel) est construit depuis la racine vers les récepteurs. Le principe est le suivant :

– le candidat membre apprend l’adresse logique du groupe et l’adresse du créateur du groupe par des moyens externes (serveur de noms, …) ;

– le candidat envoie une demande d’adhésion au gestionnaire du groupe ; – le gestionnaire, après une éventuelle phase d’authentification et d’autorisation,

transmet la demande à la racine de l’arbre. Cette demande se propage le long de l’arbre jusqu’au point où une nouvelle branche doit être greffée vers le nouveau membre.

Le fait que les demandes d’adhésions passent par le gestionnaire présente deux avantages :

– une branche n’est créée que si le groupe existe effectivement et si le candidat membre est autorisé à adhérer. Cela supprime les problèmes de création inutile d’état dans le réseau ;

– l’arbre est construit dans le bon sens, c’est-à-dire le chemin direct de la racine vers les récepteurs au lieu du chemin inverse.

Il y a aussi un inconvénient potentiel pour les très grands groupes, puisque les demandes d’adhésions convergent vers le gestionnaire.


Le fait qu’il y ait un double niveau d’adressage, et donc une encapsulation, présente un surcoût pour les données, mais cela permet de créer des arbres réduits [PAN 98a], c’est-à-dire où les nœuds intermédiaires qui ont un seul fils dans l’arbre (nœuds relais) n’ont pas besoin de maintenir d’état pour le groupe. Une idée similaire a été proposée dans [TIA 98]. De plus, ces tunnels permettent un déploiement incrémental.

1.12.3. Reunite

Une autre architecture, appelée Reunite, qui s’écarte fortement du modèle classique a été proposée dans [STO 00]. Ses principes généraux sont les suivants :

– il n’y a pas d’adressage multicast. Un groupe est repéré par l’adresse de la source et un numéro de port (S,p) ;

– un arbre de diffusion est construit récursivement avec des branches menant à une adresse unicast de récepteur ;

– deux types de table sont nécessaires : - la table de propagation multicast (MFT, multicast forwarding table), qui

n’est présente que dans les nœuds branchants. Si un routeur a n fils dans l’arbre, la table contient l’adresse unicast d’un récepteur dans chacun des n sous-arbres,

- la table de contrôle (MCT, multicast control table) qui est présente dans les nœuds relais de l’arbre et permet de repérer sur quelle branche de l’arbre se trouve le nœud.

Un paquet « multicast » est envoyé à l’adresse unicast d’un des récepteurs, typiquement le premier qui a adhéré. Il traverse de façon transparente les nœuds relais. Au passage dans un nœud branchant, le paquet est réémis autant de fois qu’il y a d’adresses dans la MCT, en changeant à chaque fois l’adresse unicast de destination.

La construction et la maintenance de l’arbre nécessitent deux types de messages : un message d’adhésion envoyé cycliquement des récepteurs vers la racine, et qui s’arrête au premier routeur appartenant déjà à l’arbre (c’est-à-dire possédant une entrée soit dans sa MFT soit dans sa MCT pour cet arbre), et un message tree qui marque la nouvelle branche de l’arbre, dans le sens allant de l’arbre au récepteur. Le principe de construction est alors le suivant :

– un récepteur r du groupe (C,p) envoie un message d’adhésion en direction du centre C ;

– le premier routeur possédant une entrée pour (C,p) dans sa MFT ou sa MFT intercepte le message, et s’il n’a pas déjà r comme récepteur dans sa MFT :


- s’il n’a pas d’entrée pour (C,p) dans sa MFT, il en crée une à la place de l’entrée (C,p) dans la MCT,

- ajoute l’adresse du récepteur dans l’entrée (C,p), - désormais les paquets à destination de (C,p) reçus par ce routeur seront

envoyés à r par la route directe unicast, – tout routeur ayant une entrée (C,p) dans sa MFT envoie cycliquement des

messages tree vers chacune des destinations unicast indiquées dans cette entrée, – tout routeur qui reçoit un message tree pour le groupe (C,p) :

- s’il a déjà une entrée pour ce groupe, la valide (principe soft state), - sinon, il crée une nouvelle entrée dans sa MCT avec comme arbre (C,p) et

comme destination r, - le message est ensuite propagé au routeur suivant.

Cette architecture a l’avantage de ne pas nécessiter d’adresse multicast, et ne pose donc pas de problème d’allocation d’adresse. De plus il n’y a pas besoin de points de rendez-vous, les arbres étant a priori spécifiques à une source. Dans ce cas il n’y pas non plus d’encapsulation. Ces avantages sont similaires à ceux de SSM. De plus, un avantage présenté par les auteurs est que les données circulent d’un routeur branchant à un récepteur en utilisant le plus court chemin direct et non pas inverse comme dans la plupart des protocoles de routage multicast.

Néanmoins, cette architecture présente plusieurs problèmes potentiels : – le fait de changer à la volée l’adresse destination d’un paquet peut être coûteux,

et peut être incompatible avec des mécanismes de protection comme le total de contrôle TCP par exemple, ceci est un problème bien connu dans le cadre de la mobilité ;

– le chemin emprunté n’est pas vraiment le plus court chemin direct car le message d’adhésion est intercepté par le premier routeur de l’arbre rencontré dans le sens inverse ;

– comme montré dans [COS 01], ce mécanisme peut créer des boucles ; – la technique de réflecteur proposée pour partager un arbre semble peu

convaincante car elle ne permet pas de transmettre l’identification de l’émetteur ; – finalement, cette solution remet en cause beaucoup de principes du modèle

actuel, ce qui rendrait son implémentation difficile.

1.12.4. Routage multicast saut par saut : HBH

La proposition de Costa, Fdida et Duarte, Hop by Hop Multicast Routing (HBH) [COS 01] reprend certains concepts du modèle SSM (arbre par source identifié par


l’adresse de la source et une adresse multicast) ainsi que de Reunite pour la méthode de construction. La construction nécessite trois messages de signalisation :

– les nœuds de l’arbre (S,G) contiennent soit une MFT (nœud branchant), soit une MCT comme dans Reunite ;

– l’adresse destination d’un paquet est une adresse unicast. Il s’agit ici de l’adresse du prochain routeur branchant (connu dans la MFT) et non pas celle d’un récepteur, d’où une meilleure stabilité que pour Reunite ;

– le premier message d’adhésion remonte jusqu’à la source, la branche créée vers un nouveau membre est donc bien le plus court chemin direct, comme avec LAR et contrairement à Reunite ;

– trois messages sont nécessaires pour la construction de l’arbre : en plus de deux messages similaires à ceux de Reunite, un troisième message (fusion) permet de déplacer les points branchants dans l’arbre.

Bien que ce ne soit pas explicité dans [COS 01], les données sont encapsulées puisqu’elles doivent transporter à la fois une adresse destination unicast (utilisée par le routage, comme dans Reunite), et une adresse multicast (pour rester compatible avec le modèle SSM). Cette encapsulation permet aussi d’utiliser aisément le multicast natif sur des réseaux feuille, contrairement à Reunite.

1.13. Comparaison des différents protocoles

Il y a beaucoup de critères de comparaison possibles concernant les protocoles de routage multicast. Ces critères doivent être divisés en deux grandes catégories, portant d’une part sur la qualité de la diffusion du point de vue des utilisateurs, et d’autre part sur les ressources nécessaires dans le réseau. Un troisième point concerne la facilité de déploiement, en particulier le déploiement incrémental.

1.13.1. Qualité des arbres de diffusion

Ici, deux critères principaux interviennent : – le chemin des données d’une source vers un récepteur passe-t-il ou non par un

nœud central (arbre partagé) ou bien est-ce un chemin direct (arbre par source) ? – le chemin est-il un plus court chemin (pour une certaine métrique utilisée par le

routage unicast), ou bien est-ce un plus court chemin inverse construit par RPF ? On peut noter que cet aspect a été peu traité dans les protocoles réellement implémentés, alors que le fait d’utiliser un plus court chemin inverse peut être plus pénalisant que de passer par un centre [COS 01, FAL 98].


Diverses combinaisons sont possibles, par exemple dans PIM-SM, les paquets de données peuvent aller par le chemin direct au RP puis par le chemin inverse aux destinataires. Notons SPT un arbre des plus courts chemins, RSPT un arbre RPF, DC un chemin direct vers un point intermédiaire (centre ou autre nœud de l’arbre), et RC un chemin inverse vers un intermédiaire. Le tableau 1.1 synthétise les caractéristiques des arbres construits.

Type d’arbre

Chemin vers l’arbre

Chemin dans l’arbre

Remarques

DVMRP Par source - RSPT

PIM-DM Par source - RSPT

MOSPF Par source -

-

SPT

SPT « approché »

intra zone

interzones

PIM-SM (ASM) Partagé

Partagé

Par source

DC

RC

-

RSPT

RSPT

RSPT

PIM-register vers RP

Après PIM-register-stop

CBT Partagé DC RSPT

PIM bidirectionnel

Partagé DC RSPT DC vers l’amont puis RSPT vers l’aval

BGMP Partagé

Par source

DC

-

RSPT

RSPT

PIM-SSM Par source - RSPT

Simple Partagé DC RSPT

LAR Par source

Partagé

-

RC

SPT

SPT

Reunite Par source - SPT Pas exactement SPT

HBH Par source - SPT SPT Initialement

Tableau 1.1. Qualité des chemins de données

1.13.2. Coût des protocoles

Le coût du protocole dépend de plusieurs paramètres : – le surcoût en bande passante pour les données (inondations, encapsulations) ; – le coût en bande passante de signalisation ;


– le coût en états à mémoriser dans les routeurs ;

– le coût en traitement dans les routeurs.

Un récapitulatif est donné dans le tableau 1.2.

Surcoût en bande

passante

(données)

Signalisation hors arbre

Etats hors arbres

Etats : nombre

d’arbres par groupe

Etats dans les nœuds

relais

DVMRP inondation Elagage périodique

élagage 1 par source active

oui

PIM-DM inondation Elagage périodique

élagage 1 par source active

oui

MOSPF données vers les routeurs interzones

Diffusion de l’état des liens

Base d’états des liens

1 par source active

oui

PIM-SM Encapsulation vers le RP

Annonces BSR

- 1 par groupe + 1 par source active

oui

CBT Encapsulation vers le centre

Annonces BSR

- 1 par groupe oui

PIM

bidirect.

- Annonces BSR

- 1 par groupe oui

BGMP - Annonces MBGP

GRIB 1 par groupe + 1 par source active

oui

PIM-SSM

- - - 1 par source active ou non

oui

Simple encapsulation - - 1 par groupe oui

LAR encapsulation - - 1 par groupe non

Reunite Encapsulation si réflecteur

- - 1 par groupe MCT

HBH encapsulation - - 1 par groupe MCT

Tableau 1.2. Coût pour le réseau


1.14. Alternatives au routage multicast

Le routage multicast mettant beaucoup de temps à arriver à maturité et à être déployé, diverses alternatives ont été proposées et parfois mises en œuvre, ne nécessitant pas de protocole multicast de niveau réseau.

1.14.1. Connexions Unicast multiples

Une première solution, utilisée depuis longtemps, consiste à créer autant de connexion point-à-point qu’il y a de destinataires. Cela présente l’avantage supplémentaire de permettre l’utilisation de connexions TCP garantissant la fiabilité des transferts et le contrôle de flux. Bien entendu cette solution n’est pas viable pour des très grands groupes. Afin d’éviter n(n – 1)/2 connexions pour connecter les n membres d’un groupe, une solution consiste à passer par un serveur, parfois baptisé réflecteur. On retrouve cette idée pour partager un arbre unidirectionnel, ou bien pour accueillir des nœuds ne permettant pas le multicast.

1.14.2. Multicast pour petit groupes

Le multicast général est indispensable pour les très grands groupes, au prix d’une signalisation et d’états à maintenir dans les routeurs. Mais par ailleurs un très grand nombre de sessions multicast comportant un petit nombre de participants est envisageable : vidéoconférences, applications collaboratives, jeux. Des solutions ont été proposées pour éviter que ces nombreuses sessions ne surchargent le réseau. Elles reposent en général sur le principe que l’émetteur d’un paquet connaît les récepteurs, et en indique la liste, sous une forme éventuellement condensée, dans le paquet lui-même. Voir par exemple la proposition Xcast [BOI 04]. Cet aspect est développé dans le chapitre 8.

1.14.3. Multicast de niveau applicatif

Une autre solution actuellement étudiée de façon intensive [CHU 00, MAT 02] est de réaliser le multicast au niveau applicatif, c’est-à-dire que les hôtes membres du groupe s’organisent suivant un arbre de diffusion, et procèdent collectivement à la diffusion de proche en proche des paquets. Cette approche présente plusieurs avantages :

– elle peut être déployée, y compris en inter-domaine, sans demander de mécanismes de routage multicast dans le réseau ;


– elle permet de tenir compte des contraintes spécifiques de l’application, en particulier en termes de fiabilité et de qualité de service.

Cette approche comporte aussi un certain nombre de difficultés : – la construction d’un arbre de diffusion efficace nécessite une connaissance de

la topologie sous-jacente, qui ne peut être accessible que par des mesures ; – un arbre dont les sommets sont des hôtes est moins stable qu’un arbre de

routeurs ; – si chaque groupe multicast engendre ses propres mesures pour construire

l’arbre, il peut en résulter une forte consommation de la bande passante pour la signalisation. Les adaptations des arbres n’étant pas forcément concertées, elles peuvent conduire à des oscillations ;

– pour certaines topologies, l’arbre obtenu peut être sensiblement moins efficace qu’un arbre de niveau réseau.

1.15. Conclusion

De nombreux travaux ont porté sur le routage multicast dans Internet depuis une quinzaine d’années, visant à résoudre les problèmes d’allocation d’adresses, de contrôle des sources, et de routage proprement dit, y compris à l’échelle d’Internet entier. A l’heure actuelle, avec l’abandon programmé de BGMP et MASC, et du fait que MSDP n’est pas extensible, il semble qu’en IPv4 la seule solution de niveau IP viable à grande échelle soit l’utilisation de PIM en mode SSM. Diverses solutions permettant d’implanter le modèle de service ASM au dessus d’un service SSM sont à l’étude. Dans le cadre d’IPv6, le mécanisme RP-embedded pourrait permettre d’utiliser directement le modèle ASM, si les problèmes de contrôle de source et de fiabilité au niveau du RP sont résolus.

D’autres limitations au déploiement du multicast au niveau IP portent sur le contrôle de congestion (voir chapitre 6) et sur la fiabilité. Pour la fiabilité, les propositions modulaires de l’Ietf devraient permettre de trouver des solutions adaptées à la plupart des cas, en particulier en termes de taille de groupes, voir les chapitres 4 et 5.

1.16. Bibliographie

[ADA 04] ADAMS A., NICHOLAS J., SIADAK W., « Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) », draft-ietf-pim-dm-new-v2-05, 2004.

[AGU 84] AGUILAR L., « Datagram Routing for Internet Multicasting », ACM Symposium on Communications, Architectures and Protocols, CCR, vol. 14, n° 2, 1984.


[ALB 01] ALBANNA Z., ALMEROTH K., MEYER D., SCHIPPER M., « IANA Guidelines for IPv4 Multicast Address Assignments », RFC 3171, BCP 51, 2001.

[ALM 01] ALMEROTH K.C., BHATTACHARRYA S., DIOT C., « Challenges of Integrating ASM and SSM IP Multicast Protocol Architectures », 3rd Tyrrhenian International Workshop on Digital Communication, Springer Verlag, LNCS 2170, p. 343, Taormina, Italie, 2001.

[ARM 96] ARMITAGE G., « Support for Multicast over UNI 3.0/3.1 based ATM Networks », RFC 2022, standard proposé, 1996.

[BAL 93] BALLARDIE A., FRANCIS P., CROWCROFt J., « Core Based Trees (CBT). An Architecture for scalable Inter-domain Multicast Routing », SIGCOMM 93, San Francisco, p. 85-95, 1993.

[BAL 97a] BALLARDIE, A., « Core Based Trees (CBT version 2) Multicast Routing », RFC 2189, expérimental, 1997.

[BAL 97b] BALLARDIE, A., « Core Based Trees (CBT) Multicast Routing Architecture », RFC 2201, expérimental, 1997.

[BAT 00] BATES T., REKHTER Y., CHANDRA R., KATZ D., « Multiprotocol Extensions for BGP-4 », RFC 2858, standard proposé, 2000.

[BEC 03] BECK F., HOERDT M., PANSIOT J.-J., « Source Discovery Protocol in SSM Networks », draft-beck-mboned-ssm-source-discovery-protocol-03.txt, juin 2003.

[BIS 04] BISWAS S., CAIN B., HABERMAN B., « IGMP Multicast Router Discovery », draft-ietf-idmr-igmp-mrdisc-11.txt, 2004.

[BOI 04] BOIVIE R., IMAI Y., LIVENS W., OOMS D., PARIDENs O., « Explicit Multicat (Xcast) Basic Specification », draft-ooms-xcast-basic-spec-06.txt, 2004.

[CAI 02] CAIN B., DEERING S., FENNER B., KOUVELAS I., THYAGARAJAN A., « Internet Group Management Protocol, Version 3 », RFC 3376, standard proposé, 2002.

[CHE 04] CHESTERFIELD J., SCHOOLER E., OTT J., « RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback », draft-ietf-avt-rtcpssm-07.txt, 2004.

[CHU 00] CHU Y., RAO S. ZHANG H., « A Case For End System Multicast », Proceedings of ACM SIGMETRICS, p. 1-12, Santa Clara, CA, 2000.

[CIZ 02] CIZAULT G., Ipv6, théorie et pratique, O’Reilly, 3e édition, Paris, 2002.

[COS 01] COSTA L. H. M. K., FDIDA S., DUARTE O. C. M. B., « Hop By Hop Multicast Routing Protocol », ACM SIGCOMM 2001, 2001.

[DAL 78] DALAL Y.K., METCALF R.M., « Reverse path forwarding of broadcast packets », Communications of the ACM, vol. 21, n° 12, p. 1040-1048, 1978.

[DEE 85] DEERING S., CHERITON D., « Host groups: A multicast extension to the Internet Protocol », RFC 966, 1985.

[DEE 89] DEERING S., « Host extensions for IP multicasting », RFC 1112, standard, 1989.

[DEE 90] DEERING S., CHERITON D, « Multicast Routing in Datagram Internetworks and Extended LANs », ACM Transactions on Computer Systems, vol. 8, n° 2, 1990.


[DEE 91] DEERING, S., « Multicast Routing in Datagram Internetwork », PhD thesis, Stanford University, 1991.

[DEE 94] DEERING S., ESTRIN D., FARINACCI D., JACOBSON V., LIU C., WEI L., « An architecture for wide-area multicast routing », ACM SIGCOMM 94, Londres, p. 126-135, 1994.

[DEE 99] DEERING S., FENNER B., HABERMAN B., « Multicast Listener Discovery (MLD) for IPv6 », RFC 2710, standard proposé, 1999.

[EST 98] ESTRIN, D., FARINACCI, D., HELMY, A., THALER, D., DEERING, S., HANDLEY, M., JACOBSON, V., LIU, C., SHARMA, P., WEI, L., « Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification », RFC 2362, expérimental, 1998.

[EST 99] ESTRIN D., HANDLEY., HELMY A., HUANG P., THALER D., « A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast Routing », IEEE Infocom 99, New York City, 1999.

[FAL 98] FALOUTSOS M., BANERJEA A., PANKAJ R., « QoSMIC: Quality of Service sensitive Multicast Internet protoCol », ACM SIGCOMM, p. 144-153, Vancouver, 1998.

[FEN 97] FENNER W., « Internet Group Management Protocol, Version 2 », RFC 2236, standard proposé, 1997.

[FEN 01] FENNER W., « Domain Wide Multicast Group Membership Reports », draft-ietf-idmr-membership-reports-06.txt, 2001.

[FEN 03] FENNER B., MEYER D., « Multicast Source Discovery Protocol (MSDP) », RFC 3618, expérimental, 2003.

[FEN 04] FENNER B., HANDLEY M., HOLBROOK H., KOUVELAS I, « Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) », draft-ietf-pim-sm-v2-new-10.txt, 2004.

[FUH 00] FUHRMANN T., « Protocol-Independent Multicast and Asymmetric Routing », Technical Report 00-001, Department of Computer Science, University of Mannheim, 2000, (disponible à l’adresse http://www.informatik.uni-mannheim.de/techberichte/2000/ TR-00-001.html).

[GRA 95] GRAD D., MARC-ZWECKER S., PANSIOT J.-J., « Towards a Logical Addressing and Routing sublayer for internet multicasting », Proms 95, Salzbourg, 1995.

[HAB 02] HABERMAN B., THALER D., « Unicast-Prefix-based IPv6 Multicast Addresses », RFC 3306, standard proposé, 2002.

[HAN 99] HANNA S., PATEL B., SHAH M., « Multicast Address Dynamic Client Allocation Protocol (MADCAP) », RFC 2370, standard proposé, 1999.

[HAN 00] HANDLEY M., PERKINS C., WHELAN E., « Session Annoucement Protocol », RFC 2974, expérimental, 2000.

[HAN 01] HANDLEY M. et HANNA S., « Multicast Address Allocation Protocol (AAP) », draft-ietf-malloc-aap-05.txt, 2001.


[HAN 04] HANDLEY M., KOUVELAS I., SPEAKMAN T., VICISANO L., « Bi-directional Protocol Independent Multicast (BIDIR-PIM) », draft-ietf-pim-bidir-06.txt, 2004.

[HIN 03] HINDEN B., DEERING S., « IP Version 6 Addressing Architecture », RFC 3513, standard proposé, 2003.

[HOE 04] HOERDT M., BECK F., MAGONI D., PANSIOT J.-J., « Source Discovery Protocol for ASM Applications in SSM Networks », Proceedings of the 3rd International Conferenceon Networking, Pointe-à-Pitre, 2004.

[HOL 99] HOLBROOK H., CHERITON D., « IP Multicast Channels: EXPRESS Support for Large-scale Single-source Applications », ACM SIGCOM 99, Cambridge, Massachusetts, 1999.

[IEE 98] Media Access Control (MAC) Bridges, ANSI/IEEE Std 802.1D, 1998 (Également ISO/IEC 15802-3, p. 373, 1998).

[KIM 03] KIM D., MEYER D., KILMER H., FARINACCI D., « Anycast RP mechanism using PIM and MSDP », RFC 3446, informationnel, 2003.

[KUM 98] KUMARY S., P. RADOSLAVOV P., THALER D., ALAETTINOGLU C., ESTRIN D., HANDLEY M., « The MASC/BGMP architecture for inter-domain multicast routing », ACM SIGCOMM 98, p. 93-104,Vancouver, 1998.

[LEH 04] LEHTONEN R., « Dynamic Multi-Source Discovery for SSM using MSDP », draft-lehtonen-mboned-multissm-01.txt, 2004.

[MAT 02] MATHY L., « Le multicast applicatif », Ecole d’été RHDM 2002, Autrans, 2002.

[MCB 04] MCBRIDE M., MEYLOR J., MEYER D., « Multicast Source Discovery Protocol Deployment Scenarios, Best Current Practice », draft-ietf-mboned-msdp-deploy-06.txt, 2004.

[MEY 97] MEYER D., « Some Issues for an inter-domain Multicast Routing Protocol », draft-ietf-mboned-imrp-some-issues.03.txt, 1997.

[MEY 98] MEYER D., « Administratively Scoped IP Multicast », RFC 2365, 1998.

[MEY 01] MEYER D., LOTHBERG P., « GLOP Addressing in 233/8 », RFC 3180, BCP0053, 2001.

[MOY 94] MOY J., « Multicast Extensions to OSPF », RFC 1584, standard proposé, 1994.

[MOY 98] MOY J., « OSPF Version 2 », RFC 2328, standard, 1998.

[OBR 98] OBRACZKA K., « Multicast Transport Protocols: A Survey and Taxonomy », IEE Communications, vol. 36, n° 1, 1998.

[PAN 98a] PANSIOT J-J., GRAD D., « On Routes and Multicast Trees in the Internet », ACM SIGCOMM Computer Communication Review, vol. 28, n° 1, p. 41-50, 1998.

[PAN 98b] PANSIOT J.-J., GRAD D., NOEL T., ALLOUI A., « Logical addressing and routing for multicasting(LAR) », draft-pansiot-logical-addressing-00.txt, 1998.


[PAN 00] PANSIOT J.-J., ALLOUI A., NOËL T., GRAD D., « A new architecture for sparse-mode inter-domain multicasting », sixième EUNICE Open European Summer School, Twente, Pays-Bas, 2000.

[PAX 97] PAXSON V., « End-to-End Routing Behavior in the Internet », IEEE/ACM Transactions on Networking, vol. 5, n° 5, p. 601-615, 1997.

[PER 85] PERLMAN R., « An algorithm for distributed computation of a spanning tree in an extended LAN », SIGCOMM 1985, p. 44-53, 1985.

[PER 99] PERLMAN R., LEE C-Y., BALLARDIE A., CROWCROFT J., WANG Z., MAUFER T., DIOT C., THOO J., GREEN M., « Simple Multicast: A Design for Simple, Low-Overhead Multicast », draft-perlman-simple-multicast-03.txt, 1999.

[PLU 82] PLUMMER D., « An Ethernet Address Resolution Protocol », RFC 826, 1982.

[PRZ 04] PRZYGIENDA T., SHEN N., SHETH N., « M-ISIS: Multi Topology (MT) Routing in IS-IS », draft-ietf-isis-wg-multi-topology-07.txt, 2004.

[RAD 00] RADOSLAVOV P., ESTRIN D., GOVINDAN R., HANDLEY M., KUMAR D., THALER D., « The Multicast Address-Set Claim (MASC) Protocol », RFC 2909, expérimental, 2000.

[REK 95] REKHTER Y., LI T., « A Border Gateway Protocol 4 (BGP-4) », RFC 1771, draft standard, 1995.

[SAV 04] SAVOLA P., HABERMAN B., « Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address », RFC 3956, 2004.

[SCH 03] SCHULZRINNE H., CASNER S., FREDERICK R., JACOBSON V., « RTP: A Transport Protocol for Real-Time Applications », RFC 3550, standard, 2003.

[SHI 97] SHIELDS C., GARCIA-LUNA-ACEVES J.J., « The Ordered Core Based Tree Protocol », IEEE INFOCOM 97, Kobe, Japon, 1997.

[SHI 98] SHIELDS C., GARCIA-LUNA-ACEVES J.J., « The HIP Protocol for Hierarchical Multicast Routing », PODC 98, Puerto Vallarta, Mexique, 1998.

[SHI 99] SHIELDS C., GARCIA-LUNA-ACEVES J.J., « KHIP - A Scalable Protocol for Secure Multicast Routing », ACM SIGCOMM 99, Cambridge, Massachusetts, 1999.

[SOL 98] SOLA M., OHTA M., MAENO T., « Scalability of Internet Multicast Protocols », INET 98, Genève, 1998.

[STO 00] STOICA I., NG T. S. E., ZHANG H., « REUNITE: A recursive unicast approach to multicast », IEEE INFOCOM 2000, 2000.

[THA 99] THALER D., « Interoperability Rules for Multicast Routing Protocols », RFC 2715, informationnel, 1999.

[THA 00] THALER D., HANDLEY M., ESTRIN D., « The Internet Multicast Address Allocation Architecture », RFC 2908, informationnel, 2000.

[THA 04] THALER D., ESTRIN D., MEYER D., « Border Gateway Multicast Protocol (BGMP): Protocol Specification », RFC 3913, informationnel, 2004.


[TIA 98] TIAN J., et NEUFELD G., « Forwarding State Reduction for Sparse Mode Multicast Communication », IEEE INFOCOM 98 vol. 2, p. 711-719, San Francisco, CA, 1998.

[VID 04] VIDA R., COSTA L., « Multicast Listener Discovery Version 2 (MLDv2) for IPv6 », RFC 3810, standard proposé, 2004.

[WAI 88] WAITZMAN D., DEERING S., PARTRIDGE C., « Distance-Vector Multicast Routing Protocol », RFC 1075, expérimental, 1988.

[WHE 01] WHETTEN B., VICISANO L., KERMODE R., HANDLEY M., FLOYD S., LUBY M., « Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer », RFC 3048, informationnel, 2001.

[ZAP 02] ZAPPALA D., FABBRI A., LO V., « An Evaluation of Shared Multicast Trees with Multiple Cores », Journal of Telecommunication Systems, Kluwer Academic Press, vol. 19, n° 3-4, 2002.

1.17. Lexique des acronymes

AAP : Address Allocation Protocol ARP : Address Resolution Protocol AS : Autonomous System ASM : Any Source Multicast BGMP : Border Gateway Multicast Protocol BGP : Border Gateway Protocol BSR : Boot Strap Router CBT : Core Based Trees CGMP : Cisco Group Management Protocol DDoS : Distributed Denial of Service DF : Designated Forwarder DHCP : Dynamic Host Configuration Protocol DR : Designated Router DVMRP : Distance Vector Multicast Routing Protocol FIB : Forwarding Information Base GRIB : Group Routing Information Base ICMP : Internet Control Message Protocol IETF : Internet Engineering Task Force IGMP : Internet Group Management Protocol MAAS : Multicast Address Allocation Server MADCAP : Multicast Address Dynamic Client Allocation Protocol MARS : Multicast Address Resolution Server MASC : Multicast Address Set Claim Mbone : Multicast Backbone MBGP : Multiprotocol extensions for BGP-4


MBR : Multicast Border Router MCT : Multicast Control Table MFIB : Multicast Forwarding Information Base MFT : Multicast Forwarding Table MLD : Multicast Listener Discovery MOSPF : Multicast extensions to OSPF MRIB : Multicast Routing Information Base MSDP : Multicast Source Discovery Protocol NBMA : Non Broadcast Multiple Access OSPF : Open Shortest Path First PIM : Protocol Independent Multicast PIM-DM : PIM Dense mode PIM-SM : PIM Sparse Mode RIB : Routing Information Base RP : Rendez-vous Point (dans PIM) RPF : Reverse Path Forwarding RPM : Reverse Path Multicasting RSPT : Reverse Shortest Path Tree (S,G) : désigne suivant le contexte un paquet multicast de source S, et de destination G, ou bien une entrée de table de routage multicast, ou bien un canal (*,G) : désigne une entrée de table de routage pour un arbre partagé SPT : Shortest Path Tree SSM : Source Specific Multicast TIB : Tree InformationBase

Documents

Le routage multicast dans Internet - unistra.fr · 2013-09-27 · Le routage multicast dans Internet 17 construits autour d’un nœud distingué : le Core de CBT, le point de rendez-vous