Multicast : pour une diffusion mul­ti­point

Pour la re­trans­mis­sion ra­dio­té­lé­vi­sée, le nombre d’uti­li­sa­teurs connectés et désireux de recevoir le programme ne joue aucun rôle. Les choses se passent de manière com­plè­te­ment dif­fé­rente lors de la diffusion d’in­for­ma­tions au sein d’un réseau IP. Par exemple, si plusieurs uti­li­sa­teurs dif­fé­rents sou­hai­tent se connecter à un flux de streaming, la com­mu­ni­ca­tion unicast classique via IP sup­po­se­rait que le poste émetteur diffuse sé­pa­ré­ment les paquets cor­res­pon­dants à chaque adresse. C’est parce que cette con­fi­gu­ra­tion utilise très ra­pi­de­ment toute la bande passante dis­po­nible que la technique du routage multicast (ou multicast IP) a été dé­ve­lop­pée et mise en place assez tôt. Elle permet à un émetteur de diffuser si­mul­ta­né­ment en une fois des flux de données IP vers un grand nombre de ré­cep­teurs.

Le protocole IP (pour Internet Protocol) est le protocole standard utilisé pour les com­mu­ni­ca­tions au sein d’un réseau d’or­di­na­teurs. Que ce soit sur Internet ou sur un réseau local, la diffusion d’in­for­ma­tions élec­tro­niques à l’aide d’adresses IP ne peut pas être exclue dans les réseaux modernes. La pile de protocole TCP/IP utilisée, qui est au­jour­d'hui la norme, met à dis­po­si­tion toute une série de pro­to­coles et de méthodes per­met­tant de répondre aux exigences les plus diverses.

Les modes de com­mu­ni­ca­tion dis­po­nibles jouent à ce titre un rôle fon­da­men­tal. C’est en par­ti­cu­lier le cas de ce qu’on appelle le multicast, qui revêt une im­por­tance gran­dis­sante. Ce concept, également connu sous le nom de multicast IP, permet de diffuser des in­for­ma­tions depuis un point donné vers plusieurs ré­cep­teurs. C’est pour cela qu’on qualifie aussi les liaisons multicast de liaisons point à mul­ti­point.

En offrant la pos­si­bi­lité d’envoyer un seul flux de données vers plusieurs des­ti­na­taires, le multicast se distingue ra­di­ca­le­ment de la norme unicast, selon laquelle les paquets IP sont transmis via une liaison directe entre les systèmes com­mu­ni­cants. Le multicast IP diffère également du broadcast en ce sens que les flux de données ne sont pas émis vers tous les uti­li­sa­teurs du réseau, mais uni­que­ment vers ceux qui se sont annoncés auprès de l’émetteur et font ainsi partie du groupe multicast cor­res­pon­dant. L’émetteur peut dès lors diffuser le flux de données au groupe en utilisant une adresse multicast assignée. Dans la version IPv4 du protocole Internet, le champ d’adresse alloué était compris entre 224.0.0.0 et 239.255.255.255. Dans la version IPv6, les adresses multicast com­men­cent par FF00::/8.

L’adressage de groupe que nous avons évoqué est une des ca­rac­té­ris­tiques es­sen­tielles du multicast IP. C’est un élément fon­da­men­tal pour le fonc­tion­ne­ment de ce concept de com­mu­ni­ca­tion. Il prévoit la pos­si­bi­lité d’un adressage statique, qui permet par exemple d’établir une liaison avec un serveur multicast pour recevoir le service cor­res­pon­dant. D’autre part, les adresses multicast peuvent aussi être utilisées de façon dynamique, puisque les groupes multicast ne sont pas supposés y être associés à titre permanent. Cela permet ainsi à des groupes privés d’être alimentés sans problème et d’être dissous tout aussi fa­ci­le­ment. In­dé­pen­dam­ment du caractère statique ou dynamique de l’adressage, dans les réseaux IP, le champ d’adresse déjà évoqué compris entre 224.0.0.0 et 239.255.255.255 (ou com­men­çant res­pec­ti­ve­ment par FF00::/8), également désigné comme adresse de classe D, est réservé à cet effet.

L’adhésion à un groupe multicast obéit aux règles de fonc­tion­ne­ment du rouleur réseau concerné et de l’Internet Group Ma­na­ge­ment Protocol (IGMP). Pour cela, le protocole ap­par­te­nant à la famille de pro­to­coles Internet met à dis­po­si­tion dif­fé­rents types d’in­for­ma­tions qui per­met­tent aux hôtes d’informer le routeur local de la volonté d’adhérer au groupe. Le routeur peut alors trans­mettre en retour les flux de données multicast cor­res­pon­dants. La com­mu­ni­ca­tion IGMP commence toujours via le routeur par l’in­ter­mé­diaire duquel l’émetteur multicast est lié au réseau. C’est l’émetteur lui-même qui transfère en une seule fois les paquets d’un flux de données. Il indique comme adresse du récepteur l’adresse du groupe multicast. Il n’a pas con­nais­sance du nombre de postes ainsi atteints.

Dans le cadre du multicast, le routage, c’est-à-dire le transport des paquets multicast à travers les dif­fé­rents routeurs et réseaux, obéit à des pro­to­coles spé­ci­fiques. Ces pro­to­coles fonc­tion­nent sur la base de dif­fé­rents al­go­rithmes dans le but de diffuser le plus ef­fi­ca­ce­ment et ra­pi­de­ment possible le flux de données vers tous les membres des groupes multicast cor­res­pon­dants. Il n’existe pas à cet effet de protocole standard, car les pro­to­coles existants ont été conçus pour d'autres tâches. Certains fonc­tion­nent ainsi au mieux lorsque les membres d’un même groupe se trouvent à proximité les uns des autres, tandis que d’autres sont plus à leur avantage quand les ré­cep­teurs sont aussi éloignés que possible les uns des autres. En outre, il existe dif­fé­rents al­go­rithmes de routage en fonction desquels peut se mettre en œuvre une technique de reverse path for­war­ding (RPF) ou de truncated reverse path for­war­ding (TRPF).

Le reverse path for­war­ding est une méthode qui garantit que les paquets multicast IP sont trans­fé­rés sans qu’aucun hôte ne soit visité à plusieurs reprises. L'adresse source du flux de données joue dans ce cadre un rôle décisif dans son transfert, de même que l’interface de réseau utilisée. Aussitôt qu’un paquet multicast atteint l’interface d’un routeur, celui-ci ajuste les deux au moyen d’un tableau de routage. Cette procédure était au­pa­ra­vant gérée au­to­ma­ti­que­ment par broadcast ou con­fi­gu­rée ma­nuel­le­ment. S’il existe pour cette adresse source une entrée confirmée par l’interface de réseau utilisée, la vé­ri­fi­ca­tion RPF est réussie : le routeur diffuse alors le flux multicast vers toutes les autres in­ter­faces dis­po­nibles. Dans le cas contraire, les paquets sont rejetés.

Le RPF vérifie également, en sens inverse, le chemin suivi par le paquet. Pour in­ter­con­nec­ter les routeurs suivant le chemin le plus court possible, des processus de routage unicast sont aussi utilisés. Le schéma de routage est également désigné sous le nom d’arbre multicast, où l’émetteur (ou son routeur) se trouve à la place des racines et re­pré­sente par con­sé­quent le point de départ du routage.

Le Truncated Reverse Path For­war­ding re­pré­sente un élar­gis­se­ment du concept du RPF, où les paquets multicast sont uni­que­ment transmis à des routeurs qui servent au minimum un membre du groupe multicast. La vé­ri­fi­ca­tion normale et en sens inverse de l’adresse source et de l’interface d’accueil est d’abord effectuée. Ensuite, le TRPF réexamine dans l’ordre quelles in­ter­faces sont les plus proches et décide quelles places seront servies. Le critère décisif est rempli si une interface donnée héberge bien les hôtes qui sont en­re­gis­trés dans le groupe multicast auquel s’adresse le flux de données. Si c’est le cas, les paquets sont trans­fé­rés.

Pour le multicast IP, il n’existe aucun protocole de routage standard. En arrière-plan, on trouve le rayon de dis­tri­bu­tion et le nombre de postes de réception qui ont une influence mesurable sur la base de protocole. On fait donc la dis­tinc­tion entre les deux approches, en « mode dense » (les ré­cep­teurs sont « adjacents ») et en « mode dispersé » (les ré­cep­teurs sont largement « dispersés »). Toutefois, les pro­to­coles se dif­fé­ren­cient aussi par d’autres aspects. C’est ce qu’illustre l’existence des pro­to­coles DVMRP, MOSPF et PIM, présentés ci-dessous.

Le Distance Vector Multicast Routing Protocol (DVMRP) a été créé en 1988 dans la RFC 1075 à titre de solution ex­pé­ri­men­tale pour la question du routage des paquets multicast en réseau IP. Le DVMRP a été développé par un groupe de travail de l’Uni­ver­sité de Stanford ; c’est le Routing In­for­ma­tion Protocol (RIP), un protocole de routage unicast, qui a servi de base à la création du vecteur de distances.

Pour calculer le trajet des paquets, l’équipe a mis en place une technique de Reverse Path For­war­ding. C’est là-dessus que s’appuie un routeur multicast pour générer au­to­ma­ti­que­ment son propre tableau de routage, où il mémorise pour tous les autres routeurs du réseau ce fameux vecteur de distances. Cette entrée contient des in­di­ca­tions sur les coûts liés à la trans­mis­sion des données, à leurs routeurs res­pec­tifs (p. ex. un retard de transfert éventuel ou le nombre de stations in­ter­mé­diaires sur le trajet), ainsi que des in­for­ma­tions sur l’identité du routeur voisin vers lequel le paquet doit être transmis afin d’atteindre son serveur cible. C’est l’IGMP qui est utilisé comme protocole d’in­for­ma­tion pour les échanges entre les dif­fé­rents routeurs.

Le Multicast Open Shortest Path First (MOSPF) est une extension du protocole de routage OSPF qui permet d’effectuer le routage multicast sur un réseau OSPF. Dans ce cadre, chaque routeur ad­mi­nistre une base de données complète portant sur l’entière topologie du réseau (dis­po­si­tion des appareils et des câbles). Grâce à de nouvelles annonces d’état de lien d’ap­par­te­nance au groupe, cette base de données peut également contenir des entrées portant sur la lo­ca­li­sa­tion de tout adhérent à un groupe multicast IP. La détection des adhésions se fait par l’in­ter­mé­diaire du routeur, qui recourt pour cela à des in­for­ma­tions IGMP. En partant du routeur, derrière lequel se trouve l’émetteur multicast, il est possible de générer sans problème une structure ar­bo­res­cente qui indique le chemin le plus court pour chaque paquet.

Le Protocol In­de­pen­dent Multicast (PIM) est une famille de pro­to­coles de routage qui ne fournit aucun mécanisme de gé­né­ra­tion de tableau de routage. Pour en obtenir un, le PIM a recours aux in­for­ma­tions données par les pro­to­coles de routage unicast actifs sur le réseau. L’identité du protocole en jeu ne joue aucun rôle en la matière ; c’est pourquoi le PIM peut être utilisé in­dif­fé­rem­ment sur des réseaux à forte ou faible densité de clients. C’est là que les deux modes dense (PIM-DM) et dispersé (PIM-SM) évoqués plus haut sont mis à con­tri­bu­tion.

Dans le premier cas, les flux de données multicast sont envoyés à tous les routeurs du réseau, jusqu’à ce que ces derniers quittent l’arbre multicast (en raison de l’absence de membres du groupe). Au contraire, en mode dispersé, un routeur dit « point de rendez-vous » sert de centrale de dis­tri­bu­tion pour la gestion des liaisons multicast. Il reçoit des no­ti­fi­ca­tions multicast et transmet les paquets à tous les routeurs de­man­deurs dont le sous-réseau compte au minimum un membre du groupe multicast.

Dans la mesure où un broadcast s'adresse toujours à tous les des­ti­na­taires d’un réseau, aucun champ d'adresse étendu n’est né­ces­saire, con­trai­re­ment à ce qui se passe avec un multicast. Tout broadcast classique présente toujours l’adresse IP cible 255.255.255.255, qui a été réservée pour ce processus. Il est également possible de procéder à des broad­casts directs (ou broad­casts locaux) en men­tion­nant le masque de sous-réseau. Le broadcast est plus in­té­res­sant lorsque les adresses des ré­cep­teurs sont inconnues, par exemple pour le partage de données et d’im­pri­mantes sur un réseau, ou en cas d'al­lo­ca­tion d’adresse IP via DHCP. Toutefois, le processus exige bien plus de res­sources qu’un multicast, ce qui entraîne un certain gas­pil­lage de bande passante.