Page principale - S'identifier - Contact

Téléchargez gratuitement mes conseils personnalisés

 Cliquez sur le type votre communauté (ou le type de communauté que vous souhaiteriez créer) et téléchargez un document de 40 pages avec des questions et des conseils (un peu comme les livres dont vous êtes le héro)
Communauté territoriale : votre communauté est ouverte à tous et se runit principalement en présentiel
Communauté thématique :votre communauté est ouverte à tous et échange principalement à distance (visios, réseaux sociaux, forums...)
Communauté transversale : votre communauté est réservée aux membres de votre organisation pour faciliter la transversalité
Communauté de client : Votre communauté est réservée aux clients de vos produits ou services pour faciliter leur engagement (par exemple une formation en ligne)

Le multicast : la diffusion radio et TV sur l'internet est-elle pour demain ?

Version imprimable

Par Jean-Michel Cornu

Ce document publié par la Fing est une synthèse de deux présentations données dans le cadre de la troisième journée sur les technologies et les standards de l'internet le 20 octobre 2003 (http://www.isoc-gfsi.org/gfsi/reunions/journee-francaise-IETF-3.html) :
· "Les standards du multicast (IPv4 et IPv6) et l’état du déploiement" par Christian Jacquenet de France Télécom longue distance : http://www.isoc-gfsi.org/gfsi/reunions/IETF-3/Christian_Jacquenet/Slidesmulticast-v01-CJ/index.htm
· "Quelques thèmes de recherches universitaires sur le multicast" par Mickael Hoerdt de l’université Louis Pasteur à Strasbourg : http://www.isoc-gfsi.org/gfsi/reunions/IETF-3/present_Hoerdt.html


Sommaire

Deux étapes dans le multicast
Tout est prêt mais le multicast n’a pas décollé
Quel multicast demain ?

Le multicast a été développé dès 1989 lorsque l'internet était essentiellement accessible à la recherche académique américaine, pour permettre à un très grand nombre de personnes de recevoir un même contenu au même moment. Avec le mode de transmission unicast (celui utilisé majoritairement sur l'Internet), si on souhaite envoyer des données à un grand nombre d'endroits (de l'audio, de la vidéo, des programmes…), il est nécessaire d'envoyer autant de flux de données qu'il y a de destinataires. Le multicast permet de n’envoyer qu'un seul flux de données qui se ramifie pour atteindre chaque destinataire "abonné" à ce flux. On parle "d'arbre de distribution". Une bande passante importante est sauvée en particulier en sortie du serveur. La cible privilégiée des services qui tirent parti du multicast (diffusion de programmes de télévision ou de radio, diffusion événementielle, télé-enseignement...) est celle du marché grand public.

Deux étapes dans le multicast
Il existe en fait deux modèles de services multicast :
· ASM (Any Source multicast model) qui permet à toutes les personnes abonnées d'envoyer et de recevoir un flux multicast. Ce modèle "de plusieurs à plusieurs" est particulièrement adapté à la vidéoconférence ;
· SSM (Source Specific multicast model) qui ne permet la diffusion qu'à partir d'une source vers plusieurs destinataires ("de un vers plusieurs"). Le modèle SSM est plus particulièrement destiné à la diffusion en direct (par exemple de radios ou de télévisions sur l'internet).

Le modèle ASM date de 1985, mais depuis l’internet a fortement grossit pour atteindre 800 000 terminaux en 1991 et bien plus encore à la suite de l'explosion due au web en 1994. Ce protocole permet de résoudre de manière élégante une partie des problèmes rencontrés : les paquets multicast transportés ne sont plus identifiés seulement par leur adresse multicast de destination (l'adresse de groupe) mais aussi par l'adresse de la source à laquelle les destinataires peuvent s'abonner, ce qui résout par exemple le problème de l'interconnexion des domaines multicast (il s’agit d'un modèle qui s'appuie sur la notion de "canaux" où l’adresse de groupe joue un rôle de sélecteur de canal).

Par rapport à ASM, le modèle SSM ne permet plus la diffusion "de plusieurs à plusieurs". En contre-partie, il est bien plus simple à mettre en oeuvre que le modèle ASM et résiste mieux aux attaques par déni de service grâce à des capacités de filtrage.

Pour en savoir plus

Il existe plusieurs protocoles pour le multicast sous IPv4 :

  • PIM-SM (Protocol Independant multicast – Sparse Mode, RFC 2362) est un standard de fait. Il fut par exemple utilisé dans la première version du FMbone, le service multicast déployé sur Renater-1, le réseau français de l’éducation et de la recherche ;
  • MSDP (multicast Source Discovery Protocol, RFC 3618) est également un standard de fait. Il fut ajouté sur le FMbone-2, la nouvelle version du service multicast de Renater ;
  • IGMP (Internet Group Management Protocol). Il en existe trois versions toutes supportées par les routeurs : RFC 1112, RFC 2236 et RFC 3376, respectivement pour les versions 1, 2 et 3.

Le protocole IPv6 intègre le multicast comme une extension. On trouve une version v6 de PIM et l'équivalent IPv6 d'IGMP est MLDv1 (Multicast Listener Discovery) décrit dans le RCF 3590 (voir la fiche d’expertise "IPv6 et l’adressage" : http://www.fing.org/index.php?num=1894,2)
Voir également la première expérience de cohabitation IPv4/IPv6 en multicast : http://www.fing.org/index.php?num=3004,2


Tout est prêt mais le multicast n’a pas décollé
Les outils existent pour mettre en œuvre le multicast : le noyau de Windows intègre le multicast depuis Windows 95 et les grandes applications sont compatibles avec le mode de transmission muticast (Real Player, Windows Media ou encore IP/TV ou CUSeeMe). Beaucoup de routeurs supportent le multicast. Même s’il est nécessaire de traverser des parties du réseau qui contient des routeurs qui n'activent pas de fonctions de traitement de trafic multicast, il est toujours possible de faire des tunnels. 20 fournisseurs d'accès internet français revendiquent le support du multicast et la plupart font du peering MSDP pour permettre l'échange d'informations relatives à des sources de diffusion multicast actives dans le réseau Internet.

Pourtant, l'utilisation du multicast est restée marginale. Seuls 2 à 3 000 groupes sont utilisés dans le monde. Outre les difficultés techniques pour déployer un réseau multicast (les routeurs les plus proches des utilisateurs - xDSL, FTTx ou Wi-Fi - ne supportent pas toujours le multicast), cela est principalement dû au manque de modèles économiques fiables qui empêchent les opérateurs de lancer une mise en oeuvre à grande échelle. De tels modèles devraient prendre en compte les interactions entre les trois acteurs : le fournisseur de contenu, le fournisseur d'accès et les utilisateurs finaux. Une des difficultés vient de ce qu'une source de diffusion multicast ne connaît ni le nombre ni l'emplacement des récepteurs intéressés à recevoir le trafic qu'elle émet à un instant donné (le flux de données est émis globalement comme en radio par exemple et non plus envoyé séparément à chaque destinataire comme en unicast).

De nouvelles propositions pourraient permettre d'améliorer le service multicast tout en lui permettant de trouver son modèle économique : estimation ou qualification du nombre de récepteur (proposition MSNIP), accessibilité quelque soit le point de raccordement sur Internet (proposition AMT), confidentialité des informations véhiculées (groupe msec et proposition GDOI), identification et authentification des abonnés par le fournisseur de service comme c’est le cas déjà pour la télévision (par exemple avec Canal plus ou bien encore les bouquets satellitaires), filtrage et protection contre divers types d'attaques, outil de comptage et de facturation de flux multicast... .

Quel multicast demain ?
Le modèle SSM de multicast passe mal à l’échelle. Il fonctionne bien actuellement de façon marginale sur IPv4 et plus complètement sur le réseau IPv6 mais ce dernier ne comprend aujourd’hui qu’environ 3 000 routeurs. Il ne semble pas facile de le déployer complètement sur un réseau très grand (en particulier sur les portions d'accès du réseau) à moins de limiter le nombre de sources (et donc le nombre d'arbres de distribution).

Lorsque l'on a de nombreux flux multicast qui circulent sur un très grand réseau, on constate que quelques routeurs dans les cœurs de réseaux doivent encaisser la majorité des flux multicast et créent des goulots d'étranglement. Les nœuds saturés ne sont pas toujours les mêmes et dépendent d'applications dont on ne connaît pas encore l'impact sur le réseau (car elles n'existent pas encore !). Les travaux de recherche continuent pour mieux gérer ces aspects (par exemple l'agrégation des différents flux multicast dans un même routeur ou l'agrégation dans des tunnels).

Il semble cependant que même avec IPv6, le multicast ne devrait pouvoir se mettre en œuvre à grande échelle qu'avec un nombre de sources limitées (réservées à quelques grands médias ?). Pour les autres, les routeurs terabits dans les coeurs de réseaux et l'augmentation régulière de la bande passante disponible devrait apporter une solution, mais les très nombreuses petites sources devront peut être se contenter de l'unicast, plus cher que le multicast en bande passante consommée. A moins que les recherches en agrégation de flux ne permettent de faire une place pour les petits médias (radios locales, télévisions participatives…) dans le "Paysage audiovisuel multicast".

 


Merci à Mickael Hoerdt et Christian Jacquenet pour leur relecture attentive et leurs corrections.