Ce RFC tente de mettre un peu d'ordre dans la galaxie des
protocoles Internet liés au
multicast en indiquant
lesquels sont aujourd'hui encore en utilisation et lesquels doivent
être considérés comme abandonnés.
Ce RFC ne mérite pas tout à fait son titre. Il ne présente pas une
vision de haut niveau du
multicast aujourd'hui,
simplement une liste des protocoles qui concourent à la diffusion
multicast, avec les recommandations
associées. Ainsi, les techniques normalisées dans les ou sont officiellement indiquées comme
abandonnées. Gérer un réseau multicast a en effet
nécessité une grande souplesse, les techniques ayant souvent changé.
Comme IPv6, le
multicast n'a jamais connu de déploiement
significatif sur Internet (certains réseaux privés, en revanche,
l'utilisent intensivement, par exemple pour la diffusion de chaînes de
télévision). Il existe un grand contraste entre l'intérêt que suscite
le multicast chez les experts, le nombre étonnant de RFC sur le sujet,
son enseignement massif à l'Université,
les analyses de consultant prévoyant son déploiement massif,
et son peu d'utilisation dans le monde réel. Une des raisons est que
le multicast est surtout adapté aux cas où un grand
nombre de gens veulent le même contenu pile en même temps (cas des
chaînes de télévision traditionnelles) et pas au cas où les demandes
sont décalées dans le temps (cas de la vidéo à la demande), même si les demandes sont proches (cas de la
distribution d'un nouveau gros logiciel, où
BitTorrent domine).
Pour diffuser en multicast, il faut plusieurs
familles de protocoles et la section 2 du RFC est découpée selon ces
familles. Ainsi, la section 2.1 est consacrée à la distribution de
l'état d'aiguillage (forwarding), c'est-à-dire les
règles qui permettent à chaque routeur de savoir où envoyer un flot
multicast donné. Le protocole dominant ici est
PIM-SM (), l'ancêtre DVRMP
ayant été largement abandonné.
La section 2.2, elle, se consacre aux protocoles qui permettent de
distribuer l'information topologique, pour que les routeurs apprennent
leurs liaisons (en raison des tunnels, la topologie
multicast n'est pas forcément
congruente à la topologie unicast). C'est aujourd'hui le domaine de
BGP dont les extensions multi-protocoles
(décrites dans le ) permettent de distribuer
l'information multicast, ou bien
d'IGP comme OSPF ().
Il existe encore d'autres familles de protocoles pour les
routeurs
multicast, dans les sections suivantes. La section
2.6, elle, passe aux interactions avec les machines finales, comme les
protocoles permettant à celles-ci de signaler leur désir de joindre un
groupe multicast, pour recevoir les flots
associés. Ces protocoles sont IGMP () en IPv4 et MLD () en IPv6.
La section 2.7, elle, parle en détail de la réduction de la
diffusion sur le réseau local. Si un commutateur réseau reçoit un paquet multicast, il
doit en théorie l'expédier sur tous ses ports, même si aucune machine
finale n'y écoute le flot. Diverses techniques comme l'« espionnage »
des messages IGMP () permettent de réduire cette
diffusion aux seuls ports menant à une machine intéressée.