Mon blog

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 RFC 3913 ou RFC 1584 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 (RFC 4601), 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 RFC 4760) permettent de distribuer l'information multicast, ou bien d'IGP comme OSPF (RFC 4915).

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 (RFC 3376) en IPv4 et MLD (RFC 3810) 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 (RFC 4541) permettent de réduire cette diffusion aux seuls ports menant à une machine intéressée.