Multicast

Multicast – Le Multicast est un mode de fonctionnement particulier de l’Internet, en mode diffusion. Il optimise
les flux à travers le réseau lorsque plusieurs utilisateurs doivent partager, en temps réel, des données qui
circulent dans le réseau. C’est le cas, par exemple, pour l’image et la voix d’une session de visioconférence :
tous les participants doivent les recevoir simultanément.
En Multicast (ou diffusion), le réseau fonctionne de point à multipoint. Le poste émetteur envoie des paquets
avec une adresse de destination Multicast qui est en fait un identifieur de session Multicast, ou groupe Multicast
(l’équivalent d’un numéro de canal en diffusion télévision hertzienne). Au niveau de ses routeurs IP, le réseau
réplique les paquets de telle sorte que tous les postes récepteurs abonnés à cet instant à ce groupe Multicast,
et uniquement eux, en reçoivent chacun une copie (chaque paquet sera répliqué le plus tard possible en
fonction de la topologie du réseau) : vu sous cet angle, le Multicast IP est bien plus évolué qu’une diffusion de

télévision (câble, hertzien ou satellite), qui « inonde » tout le monde sans distinction.
Il s’agit en fait d’applications entre une source et plusieurs destinataires, à la différence suivante : En multipoint
« classique », le nombre de connexions est égal au nombre de récepteurs, en Multicast le nombre de connexions
est inférieur au nombre de récepteurs.
Cela peut sembler une banalité, mais il est à noter que la réception de paquets Multicast par une station du
réseau est conditionnée par sa capacité à écouter. Par défaut, le coupleur réseau d’une station écoute (en
réception) son adresse Ethernet (fixée en PROM) et l’adresse de Broadcast (FF…FF). Pour le Multicast, il lui
faut aussi écouter au minimum l’équivalent Ethernet de 224.0.0.1 (tous les hôtes Multicast du LAN) et la classe
D (224.0.0.0 à 239.255.255.255 – voir généralités sur l’adressage en multicast).

En terme de bande passante, l’envoi en unicast vers tous les clients devant recevoir l’émission multimédia n’est
pas ce qu’il y a de mieux. Le Multicast offre une meilleure solution, surtout si tous les clients sont localisés hors
du sous-réseau qui est à l’origine de l’émission. Le Multicast permet d’économiser la bande passante, les
ressources des routeurs, les ressources de la source,…
Par opposition, l’utilisation la plus commune de IP est dite unicast. Elle fonctionne en point à point : le poste
émetteur envoie des paquets IP dont chacun porte une adresse de destination explicite. Le réseau transporte le
paquet vers ce destinataire, et uniquement vers lui.
Le choix des identifieurs de groupe Multicast est généralement automatique au niveau des applications
lorsqu’elles démarrent une nouvelle session. La mise en place d’une nouvelle session, ainsi que le
raccordement d’un nouvel abonné à une session préexistante, sont fait automatiquement par le réseau en
quelques secondes. Il n’y a pas de limite (autre que la capacité du réseau) au nombre de sessions simultanées.
Dans chaque session, chaque abonné peut à son tour devenir émetteur, et tous les autres abonnés de la même
session reçoivent alors les données qu’il émet.

Détails sur le Multicast IP :
Généralités sur l’adressage :
L’espace des adresses IP est distribué en trois groupes de classes d’adresses. Les classes d’adresses A, B et
C. Il en existe une quatrième (Classe D) réservée pour les adresses Multicast. Les adresses IPv4 entre
224.0.0.0 et 239.255.255.255 appartiennent à cette classe.
Adressage de groupe :
o Unicast :
Classes A, B, C
Classe A : 127 réseaux, 16 millions hôtes/réseau
Classe B : 16384 réseaux, 65534 hôtes/réseau
Classe C : 2 millions de réseaux, 254 hôtes/réseau
o Multicast :
Une adresse IPmc de la couche 3 correspond à une seule adresse fonctionnelle où à l’adresse de diffusion)
Classe D : Adresses Multicast : Ce type d’adresse permet d’appeler un groupe spécifique d’hôtes (interfaces)
dans un sous réseau. Une adresse Multicast ne peut être que destinataire. Les sources (émetteurs) sont
connues par leur adresse Unicast. Etre membre d’un groupe est indépendant d’envoyer à ce groupe (une
source n’est pas obligatoirement membre du groupe Multicast auquel elle envoie des données).
Adresse commençant par les 4 bits 1110 – Les 4 bits les plus significatifs de l’adresse IP autorisent des valeurs
comprises entre 224 et 239. Les autres 28 bits, moins significatifs, sont réservés à l’identificateur du groupe
Multicast.
Plage d’adresses de 224.0.0.0 à 239.255.255.255 28 bits d’adresses utiles soit 250 millions d’adresses
disponibles
Au niveau du réseau, les adresses Multicast IPv4 doivent être « mappées » sur des adresses physiques du type
de réseau utilisé. Dans le cas d’une session unicast, l’obtention des adresses physiques associées est réalisée
en utilisant le protocole ARP. Dans le cas des adresses Multicast, ARP ne peut pas être utilisé et les adresses
physiques doivent être obtenues d’une autre manière. Une RFC décrit la correspondance des adresses
Multicast IPv4 (RFC 1112 – Host Extension for IP Multicasting).
Dans les réseaux Ethernet et FDDI les plus étendus, le « mappage » est effectué en fixant les 24 bits les plus
significatifs de l’adresse Ethernet à 01: 00 : 5E. Le bit suivant est fixé à 0 et les 23 bits les moins significatifs
utilisent les 23 bits les moins significatifs de l’adresse Multicast IPv4. En Token-Ring, c’est l’adresse de diffusion
qui sera utilisé (ff.ff.ff.ff.ff.ff). Par exemple, l’adresse Multicast IPv4 224.0.0.5 correspondra à l’adresse physique
Ethernet 01:00:5E:00:00:05.
Il existe quelques adresses Multicast IPv4 particulières :
L’adresse 224.0.0.1 identifie tous les hôtes Multicast d’un LAN (un groupe). Tous les hôtes ayant des capacités
Multicast dans un sous réseau doivent faire partie de ce groupe.
L’adresse 224.0.0.2 identifie tout routeur Multicast dans un réseau (LAN).
L’adresse 224.0.0.4 identifie tous les routeurs DVMRP d’un réseau (LAN).

L’adresse 224.0.0.9 identifie tous les routeurs RIPv2 d’un réseau (LAN).
L’adresse 224.0.0.13 identifie tous les routeurs PIM d’un réseau (LAN).
Le champ d’adresse 224.0.0.0 – 224.0.0.255 est alloué pour les protocoles bas niveau. Les datagrammes
envoyés dans cette plage d’adresse ne seront pas routés par des routeurs Multicast.
La plage d’adresse 232.0.0.0 – 232.255.255.255 est réservée pour PIMSSM utilisant IGMPv3
La plage d’adresse 233.0.0.0 – 233.255.255.255 est réservée pour GLOP (allocation dynamique d’adresses de
groupe).
La plage d’adresse 239.0.0.0 – 239.255.255.255 est allouée à des fins administratives. Les adresses sont
allouées localement pour chaque organisation mais elles ne peuvent exister à l’extérieur de celle-ci. Les
routeurs de l’organisation ne doivent pas pouvoir router ces adresses à l’extérieur du réseau de l’entreprise.
Portée des adresses Multicast :

• Global scope : 224.0.1.0 – 238.255.255.255

• Limited scope : 239.0.0.0 – 239.255.255.255

• Site-local scope : 239.253.0.0 /16

• Organisation local scope : 239.192.0.0 /14

Avec le Multicast IPv4, le TTL a une double signification. Il contrôle la durée de vie d’un datagramme dans le
réseau pour éviter toute boucle infinie dans le cas de tables de routage mal configurées. En travaillant avec le
Multicast, la valeur TTL définit aussi le champ d’activité du datagramme, par exemple, jusqu’où il circulera au
sein du réseau. Ceci permet une définition de champ d’activité basée sur la catégorie du datagramme.
Il existe plusieurs systèmes d’allocation d’adresse de groupe :

• Dynamique

o Session Annoucement Protocol, (SAP), ID,
o MADCAP, RFC 2730 (Multicast Address Dynamic Client Allocation Protocol).

• Manuelle

o GLOP, RFC 2770

• RFC 2365 (Administratively Scoped IP Multicast)

Enfin, il est aussi possible d’adresser un réseau Multicast en utilisant des tunnels pour définir une structure
logique faisant abstraction de la topologie sous-jacente du réseau (on encapsule les paquets Multicast dans des
paquets Unicast). Voir RFC 1075.
Protocoles Multicast :
Les protocoles Stations – Routeurs
Adresses Multicast de la couche MAC (liaison)
Adresses IP de groupe comprises entre 224.0.0.0 et 239.255.255.255
Adresses de classe D (bits de poids forts à 1110)
Inconvénient de l’adressage Multicast au niveau MAC : Les systèmes non destinataires recevront quand même
les messages. Des algorithmes spécifiques permettent de limiter les impacts sur les commutateurs et routeurs
centraux, notamment certaines fonctions propriétaires liées au Multicast).
Pour limiter la diffusion la diffusion Multicast au niveau 2, il existe les solutions suivantes (liste non exhaustive) :

• 802.1 GMRP (Garp Multicast Registration Protocol) – Standard du comité IEEE 802.1, il requiert le

changement de la longueur maximale de la trame Ethernet IEEE 802.3 (1518 octets étendus à 1522 octets).
Les ordinateurs et les commutateurs doivent être mis à jour pour GMRP, IGMP est toujours requis sur
l’ordinateur.

• IGMP Snooping – Ce mécanisme donne au commutateur une capacité de niveau 3, il examine chaque paquet

pour savoir si c’est un message IGMP (rejoindre ou quitter), découvre dynamiquement les routeurs et les
sources Multicast, inter opère avec les commutateurs utilisant CGMP. IGMP Snooping peut être traité par le
hardware de certains commutateurs (moindre altération des performances).

• CGMP (Cisco Group Management Protocol) – Utilise les adresses Multicast de la couche standard MAC pour

limiter le trafic Multicast, transparent pour les ordinateurs, CGMP programme dynamiquement les
commutateurs en fonction des messages IGMP, il économise les ressources (bande passante du réseau,
charge CPU) et offre les performances de la commutation de niveau 2. CGMP est destiné aux communications
inter équipements du LAN, RGMP est destiné aux routeurs connectés à un commutateur.

• IGMP v1 (Internet Group Management Protocol v1 – RFC 1112). Adresse de groupe abstraite : pas de notion

de machine ni de réseau. Le groupe est dynamique : de 0 à une quasi-infinité de membres. Les membres d’un
groupe sont indépendants d’une localisation physique. Un membre doit envoyer un rapport à l’adresse
224.1.1.1 pour rejoindre le groupe. Le routeur envoie périodiquement des requêtes générales à l’adresse

224.0.0.1 pour déterminer l’appartenance aux groupes. Pour maintenir le groupe, un membre (par groupe et
par sous réseau) rapporte au routeur, les autres membres annulent leur rapport. Les ordinateurs quittent le
groupe sans en référer au routeur. Si pas de réponse aux requêtes périodiques du routeur, le groupe disparaît
sur temporisation.

• IGMP v2 (Internet Group Management Protocol v2 – RFC 2236). Compatibilité descendante avec IGMP v1 +

Requête spécifique à un groupe – Le routeur vérifie que le dernier récepteur intéressé a quitté un groupe avant
de cesser l’envoi de ses données sur un sous réseau. Message pour quitter explicitement un groupe – Un
ordinateur envoie un message de résiliation s’il quitte le groupe et s’il est le dernier membre (réduit le temps de
latence de disparition d’un groupe par rapport au IGMP v1). Mécanisme d’élection du routeur requérant – Sur
les réseaux multi accès, un routeur requérant IGMP est élu sur la base de la plus petite adresse IP. Seul le
routeur requérant envoie des requêtes générales. Requêtes Générales – Intervalle de temps de réponse – Les
requêtes générales spécifient le temps de réponse maximum imparti aux ordinateurs pour répondre
(amélioration de la réactivité des ordinateurs).

• IGMP v3 & 4 (Internet Group Management Protocol v3 & 4 – en cours d’élaboration). Autoriseront l’écoute

d’un sous-ensemble de participants au groupe Multicast.
Les protocoles Routeurs – Routeurs :
Préambule : l’adresse de destination IP dans un datagramme Multicast est l’adresse du groupe Multicast (mais
on ne peut pas router d’une source vers une destination virtuelle). Le routage Multicast est à l’envers du routage
unicast : le routage unicast détermine où le paquet va (on route en fonction de la destination), le routage
Multicast détermine d’où le paquet vient (on route en fonction de la source).
Le rôle du protocole de routage Multicast est de construire et maintenir les arbres de distribution et de fournir un
mécanisme pour informer les routeurs des sources actives et des groupes.
Le routage Multicast est basé sur la source, ce qui implique une connaissance des sources dans chaque routeur
ou un mécanisme pour fournir cette connaissance sur demande.
Le routage Multicast utilise le « Reverse Path Forwarding » (RPF = diffuser dans le sens inverse de la source)
pour construire les arbres de distribution et s’assurer que les paquets arrivent par la bonne interface. Les arbres
de distribution Multicast sont de deux types : arbre source (Source -> Groupe = S, G) et arbre distribué (tous ->
Groupe = *,G). Un protocole de routage unicast est utilisé pour déterminer ce « chemin inverse » qui est le
meilleur chemin unicast du récepteur vers la source.
Les arbres de distribution sont construits de proche en proche, en déterminant le meilleur chemin vers la source
unicast émettant sur un groupe particulier. Dans un arbre de diffusion, la source (l’émetteur) est la racine de
l’arbre de diffusion, toutes les branches correspondent aux diverses chemins où sont connectées les membres
du groupe Multicast. L’arbre est en constante évolution, chaque branche pouvant être coupé (élaguée), puisque
ne sont maintenues que les branches utiles.
Après que le meilleur chemin soit déterminé, les informations sont envoyées vers l’interface RPF, ou l’interface
avec la plus courte distance administrative vers la source, ce qui construit l’arbre du récepteur vers la source. Le
contrôle RPF consiste à chercher l’adresse source du datagramme Multicast dans la table de routage utilisé
pour le Multicast. Si le datagramme est arrivé sur l’interface spécifiée dans la table de routage pour l’adresse
source, le contrôle RPF réussit. Un paquet n’est jamais renvoyé vers l’interface RPF.
Il existe deux types de protocoles de routage Multicast :

• Dense : On diffuse tant qu’on ne nous demande pas d’arrêter. Un état est crée en permanence pour chaque

source sur tous les routeurs. Le mode Dense offre le support pour les arbres dont la racine est la source (ou
arbre du court chemin).

• Sparse : (clairsemé) : On diffuse quand on le demande explicitement. Le mode Sparse offre le support pour

les arbres partagés et les arbres sources.
Les caractéristiques nécessaires d’un protocole de routage Multicast sont d’être indépendant du routage
unicast, supporter une distribution dense de participants, être extensible au routage Multicast inter domaine, et
enfin être largement déployé (maturité) et correctement définit (RFC).
Les Protocoles en mode Dense :

• DVMRP (Distance Vector Multicast Routing Protocol v1, v2 & v3) – RFC 1075. Echange des informations de

routage entre routeurs voisins (inspiré de RIP). Dépendant d’un protocole de routage Unicast, il requiert son
propre protocole de routage unicast intégré (similaire à RIP). DVMRP construit un arbre de distribution séparé
pour chaque source / Groupe. Il utilise le Reverse Path Forwarding pour propager et élaguer (propagation =
diffuser les paquets sur toutes les interfaces de sortie de l’arbre de diffusion, en supposant au départ que
chaque branche mène à des membres du groupe) (élaguer = Eliminer les branches de l’arbre sans membre du
groupe multicast, coupant la transmission sur les LANs sans récepteur intéressé, élague aussi les chemins
redondants non optimaux de chaque récepteur vers la source). Tous les routeurs ont la même vue de la
topologie Multicast. Il est possible de paramétrer certains paramètres en DVMRP : Le nombre de sauts (hops),
les métriques et les seuils (threshold). Le seuil indique si un datagramme Multicast peut être réémis. Il y a
échange des tables de routage entre routeurs DVMRP : Destination : ce sont les adresses Unicast des sources

(émetteurs des datagrammes Multicast), masque : c’est le masque associé de la destination, métrique : c’est le
nombre de routeurs Multicast à franchir pour atteindre la source (distance). DVMRP est plus efficace pour les
distributions denses de récepteurs Multicast, a été largement utilisé sur le MBONE (réseau Multicast Européen
// Internet), mais induit des facteurs significatifs de facteur d’échelle (convergence lente comme RIP dont il
s’inspire), beaucoup d’informations d’état sur le routage Multicast maintenues sur les routeurs, partout
(Sources, Groupe), ne supporte pas les arbres partagés, n’est pas adapté sur des architectures avec un
nombre de saut supérieur à 32. DVMRP est inapproprié pour les grands réseaux avec peu de récepteurs
intéressés due au mécanisme propager et élaguer et/ou dans le cas de groupes faiblement représentés sur un
WAN.

• PIM Mode Dense (Protocol Independent Multicast) – Ce protocole n’a jamais été standardisé par l’IETF.

Protocole développé par CISCO, mode dense (DM) – Indépendant de tout protocole, il supporte tous les
protocoles de routage Unicast : Statique, RIP, IGRP, EIGRP, IS-IS, BGP et OSPF. PIM utilise le Reverse Path
Forwarding pour la propagation dans le réseau et l’élagage basé sur l’information d’appartenance à un groupe.
C’est un protocole de routage Multicast plutôt approprié aux petites implémentations et aux réseaux pilotes. Le
protocole de routage PIM Dense Mode est plus efficace pour les distributions denses de récepteurs Multicast,
facile à configurer (2 commandes), il utilise un mécanisme simple de propagation et d’élagage, ce qui induit
une certaine facilité à le comprendre et à le debugger. Ce protocole génère un faible overhead pour les
groupes denses. Problèmes potentiels : Propagation et élagage sur le WAN, pas de support pour les arbres
partagés.

• MOSPF (Multicast extension Open Shortest Path First) – RFC 1584. Extension du protocole de routage OSPF

(OSPF = Protocole de routage Unicast – Les routeurs utilisent des annonces d’état de lien (Link Stat
Advertisement – LSA) pour connaître toutes les liaisons disponibles du réseau (route et chemin au moindre
coût)). MOSPF inclut une information Multicast dans l’annonce de l’état de lien OSPF pour construire les arbres
de distribution Multicast. Les LSAs d’appartenance à un groupe sont propagés dans l’ensemble du domaine de
routage OSPF, afin que les routeurs MOSPF puissent calculer les listes des interfaces de sortie. MOSPF utilise
l’algorithme Dijkstra pour calculer l’arbre du plus court chemin. Un calcul séparé est requit pour chaque couple
« source/groupe ». MOSPF ne propage pas partout le trafic Multicast pour créer les états, ce protocole utilise les
LSAs et la base de données d’états des liens. Par conséquent, ce protocole ne peut fonctionner qu’en
présence du protocole de routage OSPF sur un réseau. L’algorithme Dijkstra tourne pour tous les couples
multicast (S, G), ce qui génère des problèmes significatifs d’échelle, comme le fait que ce protocole ne
supporte pas les arbres partagés. MOSPF est inapproprié pour les grandes interconnexions de réseaux avec
beaucoup de sources et de récepteurs.
Les protocoles en mode Sparse (clairsemé) :
Ces protocoles fonctionnent pour les groupes clairsemés ou denses. Ils sont optimisés pour les groupes à faible
densité de membres. Basés sur une demande explicite (suppose que personne ne veut les paquets à moins
qu’il ne le demande explicitement) les protocoles en mode clairsemé utilisent des arbres de distribution source
ou partagés. Les demandes (JOIN) sont propagées du récepteur vers le Point de Rendez-vous (RP) ou vers les
sources. Les sources sont connues par une propagation au préalable par l’arbre partagé.

• PIM SM (Protocol Independent Multicast Sparse mode). Protocole développé par CISCO, mode clairsemé

(RFC 2362 – v2) – Supporte les arbres sources et partagés, utilise un Point de Rendez-vous (RP). Les sources
s’enregistrent auprès du RP et envoient les données aux récepteurs connus via ce RP. Le RP est la racine de
l’arbre de diffusion Multicast partagé, il est configuré statiquement ou connu dynamiquement par Auto-RP ou
« candidate RP » (PIMv2). Sur un même réseau, il peut y avoir plusieurs RP, mais un groupe n’est enregistré
qu’auprès d’un seul RP. PIM SM est approprié pour les déploiements à large échelle pour groupe à faible ou
forte densité, où il est très efficace. C’est le choix optimal pour les groupes clairsemés avec peu de récepteurs,
surtout si les récepteurs sont séparés par des liaisons WAN coûteuses. Le trafic n’est envoyé que sur les
branches depuis lesquelles on a reçu une demande (Join), on peut commuter dynamiquement sur les arbres
source optimaux pour les sources à fort trafic. Indépendant de tout protocole, il supporte tous les protocoles de
routage Unicast : Statique, RIP, IGRP, EIGRP, IS-IS, BGP et OSPF, il offre aussi de bonnes bases pour les
protocoles de routage Multicast inter domaine.

• PIM Sparse Dense (Protocol Independent Multicast Sparse Dense) – Non standardisé IETF. Protocole

développé par CISCO, mode Clairsemé Dense – PIM utilise le Reverse Path Forwarding pour la propagation
dans le réseau et l’élagage basé sur l’information d’appartenance à un groupe, il supporte les arbres sources et
partagés, utilise un Point de Rendez-vous (RP). Les sources s’enregistrent auprès du RP et envoient les
données aux récepteurs connus via ce RP. PIM Sparse Dense fonctionne en mode Dense pour les groupes
Multicast sans Point de rendez-vous actif et en mode Sparse pour les groupes avec Point de Rendez-vous
actif. Ce mixte est recommandé pour les déploiements initiaux, à utiliser d’abord sans RP (mode Dense), il
suffit ensuite d’ajouter des RPs pour basculer en mode Sparse.

• Mixage PIM <-> DVMRP. En utilisant PIM SDM (Sparse Dense Mode), il est possible d’interconnecter des

nuages DVMRP à des domaines PIM. Le routage vers la source (RPF) peut être extrait des tables DVMRP ou
PIM, voire des mroutes statiques. Il est plutôt conseillé d’utiliser sur les LANs sans récepteur de groupe des
tunnels. La commande ip dvmrp unicast routing permet de forcer l’échange des tables de routage DVMRP.
Recommandations :
Comme avec les protocoles de routages Unicast, un mixage de protocoles en Multicast peut générer des
problèmes de routage (boucles, …).
Les règles d’ingénierie et d’architecture doivent être respectées à la lettre. Par exemple ne jamais mettre en
oeuvre deux protocoles Multicast PIM sur une même interface de routeur, utiliser à cette fin PIM SDM. Toujours
chercher à déployer un protocole de routage Multicast unique (PIM SDM détermine automatiquement le mode
approprié au groupe Multicast) et auto RP discovery protocol (évite les configurations manuelles et statiques du
RP).
Créer des îlots de protocoles homogènes et les étendre progressivement, interconnecter ces îlots par un routeur
frontière, et pour des situations complexes en cas d’interconnexion lourde (dans le cas d’un ISP par exemple)
utiliser MBGP (description ci-après).
Pour simplifier la gestion, il faut limiter la mise en oeuvre de tunnels pour interconnecter les domaines de

Multicast.
L’implication de l’équipe technique en charge du réseau à l’initiative du projet Multicast est impérative. Cette
équipe doit participer aux différents réglages sur le réseau et les applications (réglages des débits et seuils) et
surveiller les équipements.
Les protocoles de routage inter domaine (PIM):
Un domaine Multicast est un (ou un ensemble) de Point de Rendez-vous (RP), ou une frontière vis-à-vis des
autres domaines (notamment en PIM).
On utilise le routage inter domaine dans le cas où l’on souhaite administrer ses propres ressources (RP) ou
confiner le trafic des sources locales à un seul domaine.

• MBGP (Multicast Border Gateway Protocol ou Multiprotocol extension for BGP4) – RFC 2283. MBGP permet

de router les réseaux des sources Multicast au sein d’un domaine PIM (iMBP) ou entre domaines PIM distincts
(eMBGP). Il fonctionne en établissant des « peerings » MBGP (comme en BGP4). Il permet de récupérer les
routes annoncées par d’autres protocoles Multicast et de les réinjecter vers d’autres protocoles de routage
Multicast.

• MSDP (Multicast Source Discovery Protocol) – Internet Draft msdp-06.txt. MSDP permet d’échanger la

connaissance des sources entre plusieurs RP, en établissant des « peerings » MSDP.

• Le protocole de routage PIM SSM. Devant la trop grande complexité dans la mise en oeuvre des réseaux

Multicast, les difficultés de maîtrise de la supervision de ces réseaux, et pour pouvoir mettre en oeuvre
simplement Internet TV pour tous les usagers, un protocole de routage dénommé PIM SSM (PIM Source
Specific Multicast) a été élaboré selon les caractéristiques suivantes :
o S’appuyer sur IGMPv3 pour sélectionner la source dont on veut récupérer les données,
o Sur le routage de PIM pour accéder directement à la source,
o Sans avoir besoin de passer par un RP,
o Adapté à la diffusion Multicast 1 -> n (mais inadapté à la diffusion m -> n (interactivité)).
Des expériences sont en cours avec des implantations d’IGMP3 (FreeBSD, Cisco) et des applications adaptées
à IGMPv3, ainsi que des applications de vidéoconférence pour IPv6.
Exemples d’utilisation du Multicast :
Le Multicast est un excellent support pour :
o Le routage Dynamique en IPv4 (OSPF utilise des adresses Multicast pour diffuser les « hello packet »),
o La visioconférence,
o Le travail collaboratif,
o Le téléenseignement et le télé séminaire,
o Les transferts de données (miroirs, cache,…).
o La découverte de ressources réseau au niveau local…

La visioconférence sur IP se prête fort bien au téléenseignement interactif, et le Multicast IP est à la base de
plusieurs réalisations de pointe en France dans ce secteur : cours partagés entre DESS à travers la France,
conférences et séminaires virtuels …
Les services Multicast ou leurs utilisations ont évolués au cours des années. Utilisé à l’origine au sein de
groupes fermés, dans des applications très spécifiques telles que le téléenseignement et le routage dynamique,
ces services nécessitaient une bande passante importante pour pouvoir fonctionner correctement (les
raccordements hauts débit étaient encore très chers il y a 5 ans).
La démocratisation du haut débit, mais aussi les baisses de prix des équipements d’interconnexion (routeurs
puissants), cumulées à l’intégration native des fonctionnalités Multicast dans les équipements de commutation
permettent de proposer des services Multicast à moindre coût aujourd’hui.
Mbone / TEN-155 / FMbone-2 :
A la fin des années 80 a été installée la première expérimentation Multicast sur le réseau DARTnet. Cette
expérimentation deviendra par la suite le réseau Mbone, qui dans sa dernière version offrait le routage Multicast
sur plusieurs Points de Présence dans le monde (environ 20 pays, environ 901 routeurs, de 1 à plusieurs points
de présence par pays).
En 1992 a eu lieu la première implémentation Unix sur un routeur IP Multicast.
En 1992 toujours la première diffusion audio Multicast d’une réunion de l’IETF.
En 1993 la première diffusion vidéo Multicast depuis l’IETF.
A ce jour, le réseau Mbone est en perte de vitesse, le Multicast étant maintenant installé en mode natif au
niveau mondial, et le service Multicast est proposé par la majorité des ISP.
Au niveau Européen, il existe une réseau Multicast : TEN-155. Basé sur des routeurs Cisco et Juniper, il fournit
un service Multicast vers et de Internet. TEN-155 est basé sur les protocoles PIM SM, MBGP et MSDP.
En France, Le réseau Renater FMbone en est à la version 2 (FMbone-2). Ce réseau est basé sur un modèle
hiérarchisé clairsemé (Sparse Mode). Il utilise des routeurs Cisco, les protocoles MBGP et MSDP. Ce réseau
est connecté au réseau TEN-155.
Il est à noter que les expérimentations de diffusions vidéo nécessitent une bande passante comprise entre 1
Mbits par seconde en Streaming (avec une compression idoine…) et 3,5 Mbits par seconde (et plus) en codage
de type MPEG2