Les rencontres GERET sur le MBone
Bernard Rapacchi
CNRS/UREC, CNRS/SHS
Il faut bien l’admettre, de nombreux congrès vous intéressent. Vous êtes allés à celui de l’IETF à Montréal, InterOp à Atlanta où la conférence sur l’Ethernet Gigabit était très intéressante, l’an dernier le congrès W3 à Paris vous a passionnés ; sans compter les réunions périodiques du groupe GERET. Malheureusement, les frais de missions s’en ressentent et, l’âge venant, vous avez de plus en plus de mal à supporter le décalage horaire. Pour éviter ces déplacements, il vous faut connaître le MBone et les divers événements qui s’y déroulent.
Qu’est ce que le MBone ?
L’acronyme MBone simplifie le nom de " Virtual Internet Backbone for Multicast IP ". Il est appelé aussi Multicast Backbone. C’est une implémentation physique sur l’Internet utilisant la technologie multicast IP. Mais essentiellement, c’est un prototype permettant l’utilisation des outils multimédia et de travail collaboratif sur l’Internet. " Multimédia " : le mot est lancé. C’est probablement le mot le plus utilisé actuellement dans la littérature proche de l’informatique. Il se peut même qu’en ouvrant votre journal local vous y trouviez aussi ce mot. Encensé par certains : la première fois que j’ai entendu ce mot, il y a 5 ans, c’était par un illuminé qui pensait qu’on pouvait reconvertir un Centre de Calcul en Centre Multimédia. Honni par d’autres : le multimédia ne sert qu’à faire " du porno ". Ils ont tort. Le multimédia sert aussi à faire " du porno ". Une petite anecdote : le réflecteur CU-SeeMe, permettant de faire de la visioconférence sur Internet, que nous avions installé était très utilisé certains week-ends. Jusqu’à ce qu’un Directeur d’unité se connecte sur le réflecteur un dimanche et s’aperçoive que la vidéo qui y était diffusée était très suggestive. Inutile de vous précipiter, des filtres ont été rapidement installés et, de plus, le réflecteur en question n’existe plus.
Qu’est ce que le multimédia ?
Représentation de l’information :
Adoptons une définition qui permettra d’éclairer la suite. " multimédia " : " multi ", plusieurs ; " média ", intermédiaires. Etymologiquement, l’adjectif multimédia qualifie une technique utilisant plusieurs intermédiaires entre une source d’informations et vos sens. Si on s’arrête à cette définition, beaucoup de techniques seraient multimédia. Il faut toujours penser qu’une technique " multimédia " est avant tout " numérique " ; l’information source est sous forme numérisée, intégrée à un système informatique et l’accès à cette information doit se faire de manière interactive. Dans le monde de l’information numérique, une technique multimédia met en jeu des intermédiaires de type texte, graphique, image, animation, son. La réalité virtuelle apporte en plus le toucher. Nous n’en sommes pas encore à utiliser des odeurs, mais certains y travaillent... Vu ainsi, le multimédia, nom générique pour désigner l’ensemble des techniques multimédias, serait une forme de mariage de l’informatique et de l’audiovisuel.
Transmission de l’information :
Mais de plus en plus, " multimédia " sous entend des techniques multimédia distribuées, utilisant donc des réseaux pour véhiculer l’information. Le multimédia dont il sera question ici se situe à la croisée des chemins de l’informatique, de l’audiovisuel et des télécommunications mettant ainsi en jeu diverses compétences complémentaires.
Quels sont les problèmes de communication ?
Suivant les techniques utilisées, les contraintes en terme de communication ne seront pas les mêmes. Ainsi pour le Web, si on se contente de décharger une page d’information, le gros problème sera le temps de transfert des fichiers d’informations, problème qui met principalement en jeu le niveau du débit d’information. Mais pour des techniques en " temps réel " (en mode synchrone), plusieurs facteurs de " qualité de service " doivent être pris en compte. La transmission d’une information sonore ne peut supporter de coupures ; dans le cas d’une information de type vidéo, il doit y avoir synchronisation de l’image et du son... On peut penser facilement à d’autres problèmes de ce type qui devront être résolus.
Il faut bien l’avouer, actuellement l’Internet n’est pas fait pour garantir cette quqlité de service. Plusieurs travaux dans le domaine des réseaux s’emploient à mettre en oeuvre des solutions. L’histoire d’Internet est jalonnée de diverses évolutions dues à l’apparition de nouvelles applications : la première est bien évidemment le courrier électronique, une autre est l’arrivée du World Wide Web. On peut imaginer que la prochaine sera l’utilisation des applications multimédias synchrones de type visioconférences ou travail collaboratif.
Oui, mais qu’est ce que le MBone ?
Le MBone est un terrain d’expérimentation pour mettre au point, valider et préciser les diverses techniques de communication nécessaires au bon fonctionnement des applications multimédia synchrones. Le MBone désigne deux parties complémentaires :
Un des points importants à noter au sujet du réseau MBone est qu’initialement, il n’est ni géré ni opéré par des opérateurs réseaux. Il est basé essentiellement sur le volontariat et la coopération. Le résultat est qu’il est actuellement dessiné en fonction des intérêts portés à ces techniques par des personnes plus qu’en considération des flux d’informations, mais la situation évolue. De plus, les technologies multicast, disponibles à l’origine uniquement que sur des stations Unix, n’ont pas incité les opérateurs réseaux traditionnels à se préoccuper de ces techniques. Mais là encore, la situation évolue.
Qu’est ce que le multicast ?
Le trafic ordinaire sur IP est unicast. Ceci signifie que pour une source donnée, il existe une seule destination. Quand une source envoie un paquet unicast à une destination, le trafic traverse un ensemble d’aiguillages (" routeurs ") pour arriver à sa destination finale. Seul le noeud de destination récupère et garde le paquet ; les autres hôtes ne sont pas concernés.
Une autre forme de trafic IP est dit broadcast. Pour une source donnée, la destination est " tout le monde sur le réseau local ". Le trafic broadcast permet ainsi d’envoyer un paquet à plusieurs destinataires. Le problème est que même ceux qui ne veulent pas recevoir ce paquet le reçoivent quand même. Cette appellation broadcast a une analogie dans le monde de la télévision : un émetteur envoie une information et tous les postes allumés la reçoivent. Pour les réseaux informatiques, les paquets broadcast ne pouvant pas traverser les routeurs, restent confinés dans le réseau local (domaine de broadcast).
Le trafic multicast permet d’envoyer un paquet vers plusieurs destinations sans le dupliquer. Deux notions sont à avoir :
Le MBone, au niveau physique du réseau, est constitué de l’ensemble des routeurs multicast reliés entre eux par des " tunnels " permettant la retransmission des paquets marqués " multicast ". Si le système se cantonnait à cet ensemble, il se poserait un problème de " fin de vie " des paquets multicast. Pour éviter que les paquets, répliqués de routeur en routeur, ne circulent indéfiniment, un temps de vie (Time-To-Live : TTL) est attribué à chaque paquet. A chaque passage dans un routeur multicast, le TTL du paquet est decrémenté de une unité. A chaque tunnel entre deux routeurs est associé un seuil (threshold). Si le TTL d’un paquet est plus petit que ce seuil, le paquet n’est pas redistribué vers le tunnel et donc vers un autre routeur.
L’utilisation de routeurs spécifiques multicast (la plupart du temps des stations Unix ayant des programmes spécifiques à cet effet) doit tendre à disparaître. La possibilité de routage multicast apparaît maintenant nativement dans les routeurs de réseaux locaux, en particulier dans les routeurs Cisco. L’utilisation de tunnels pour relier deux routeurs multicast aura tendance à disparaître, de fait, quand tous les routeurs auront cette fonctionnalité.
Que dois-je faire pour être sur le MBone ?
Voici une configuration la plus simple possible pour " exister " sur le MBone.
Tout d’abord, il faut disposer d’un routeur multicast. Si votre routeur est un Cisco avec une version au moins 11.0, celui-ci fait du routage multicast en utilisant le protocole PIM. J’aurai peut-être l’occasion de revenir plus amplement sur cette solution.
Installation du routeur multicast :
A l’heure actuelle, dans la majorité des cas, c’est une station Unix qui fera office de routeur multicast en utilisant un programme spécifique appelé " mrouted ". Ce programme, existant pour plusieurs plates-formes (Solaris, SGI, HP,...), basé sur un protocole de routage appelé DVMRP, permet d’utiliser l’encapsulation des paquets multicast dans des paquets unicast. Deux routeurs mrouted vont donc communiquer entre eux à travers un tunnel et s’envoyer des messages unicast contenant des paquets multicast, en encapsulant de l’IP dans de l’IP... mrouted modifie souvent une partie du système voire du noyau Unix.
Chercher une source MBone :
Il faut établir un tunnel avec un autre " mrouteur " déjà connecté au MBone. Pour trouver votre " partenaire source ", vous pouvez envoyer un message à la liste :
mbone-fr@inria.fr
ou contacter le coordonateur du MBone en France :
Christian.Donot@inria.fr
pour vous permettre de trouver le routeur le plus proche de vous. Une fois le contact établi avec lson administrateur, celui-ci vous donnera l’adresse IP de ce routeur (ex: 129.88.45.84) et le seuil associé à votre tunnel (ex: 16).
Configuration du routeur :
Pour tirer le tunnel entre votre routeur (d’adresse IP 130.190.62.2 par exemple) et celui de votre source, vous devez écrire votre configuration dans le fichier :
/etc/mrouted.conf
par la ligne :
tunnel 130.190.62.2 129.88.44.84 metric 1 threshold 16
En supposant que votre interlocuteur ait fait l’opération équivalente de son côté, votre réseau local est sur le MBone.
Quel matériel supplémentaire ?
Bien sûr, en ces temps difficiles, vous vous posez la question du coût des équipements supplémentaires nécessaires pour utiliser les outils applicatifs du MBone. Il y a deux réponses qui peuvent être faites : rien et pas beaucoup...
Si vous voulez recevoir seulement les événements qui se déroulent sur le MBone, une station Unix ordinaire, un PC sous Windows 95 et une carte son ou un Macintosh suffisent. Il n’y a aucun équipement matériel à ajouter. C’est la première réponse.
Si vous voulez participer, il vous faudra bien sûr au moins un microphone pour envoyer du son. Un petit conseil : prenez un micro " cardioïde " (ou unidirectionnel). Ce type de micro a une sensibilité maximale dans une seule direction. Il est ainsi peu sensible aux bruits ambiants et permet d’éviter les phénomènes d’écho entre votre haut-parleur et votre micro. La plupart des " vraies " stations Unix ont déjà l’équipement pour faire de l’acquisition audio. Le Mac a tout ce qu’il faut. Une carte son pour un PC ne coûte pas une fortune...
L’acquisition de la vidéo est bien sûr plus coûteuse. Il faut une carte d’acquisition et une caméra. Vous avez eu la bonne idée d’acheter une station Indy de Silicon Graphics, tout est compris. Sun vend un kit du même ordre pour ses stations pour moins de 15 KF hors taxes. La qualité des caméras proposées n’est pas exempte de reproche mais on n’en est pas encore à faire de la télévision haute définition sur le MBone. Si vous avez un caméscope (PAL de préférence...), la plupart des cartes d’acquisition vidéo ont une entrée, dite composite, pour le brancher voire une entrée S-Vidéo pour une numérisation de meilleure qualité.
Et les outils applicatifs ?
Beaucoup d’outils applicatifs existent pour utiliser les technologies et les protocoles du MBone. Il me semble que, plutôt qu’une liste longue et fastidieuse mais certainement pas exhaustive, il est préférable de donner ceux qui me semblent indispensables pour une bonne prise en main des techniques. Certains ne seront pas cités, probablement plus à jour et plus dynamiques... En particulier, je ne présente pas les outils, efficaces et performants, développés dans l’Hexagone.
Le son :
Sous Unix et PC, il faut avoir vat. Visual Audio Tool est développé au Lawrence Berkeley Laboratories en Californie. Vat est un programme pour recevoir et envoyer de l’audio sur le MBone; " visuel " car l’interface est visuelle mais il ne sert pas à la vidéo...
Vat permet aussi des communications privées en point à point sans utiliser le MBone tout aussi bien que des audioconférences à plusieurs. Il propose plusieurs formats de compression de l’audio. Il a l’avantage d’être compatible avec d’autres programmes pour PC ou MacIntosh, en particulier avec CU-SeeMe qui a la faveur des journaux grand public actuellement.
La vidéo :
Sous Unix et PC, il faut avoir vic. Video Conference est aussi développé au LBL. Il permet de recevoir et d’émettre, si on a les moyens, de la vidéo sous plusieurs formats dont H.261 et JPEG. De plus, il est relativement bien intégré avec vat, car une fenêtre de vidéo de vic peut commuter en fonction de la personne qui parle en utilisant l’application vat. Ceci est très pratique dans le cas d’une visioconférence multiple pour savoir qui parle, mais, pas d’illusion, il n’y a pas encore de synchronisation entre la parole et le mouvement des lèvres. Sur PC, il faut prendre une version spéciale de vic, si vous utilisez une caméra Quickcam de Connectix. Cette caméra bon marché, environ 1000 F, se branche sur le port parallèle du PC et existe en deux versions noir et blanc ou couleur.
Dans le cadre de la vidéo, il faut, sous Unix, avoir aussi nv. Network Video est développé au Centre de Recherche de Xerox à Palo Alto. Le codage de la vidéo n’est pas aussi élaboré que dans vic, mais il a l’avantage d’avoir un codage CU-SeeMe permettant ainsi de faire de la visioconférence en utilisant les réflecteurs de ce logiciel.
Le partage de document :
wb (whiteboard) permet le partage de tableau blanc sur des postes de travail éloignés. Il est le plus souvent utilisé comme une aide visuelle pour accompagner sur le MBone les diverses communications de type conférence. Il lit également des fichiers PostScript permettant ainsi des créer les transparents utilisés dans la conférence. Mais la taille des fichiers PostScript est limitée aussi d’autres options de présentation de transparents sont prises maintenant. Il est plus utilisé pour présenter l’ordre du jour d’une conférence et pour le retour des impressions des personnes qui reçoivent la conférence. wb travaille sur des images.
nt, enfin, permet le partage de fichiers de texte. Il est développé dans le cadre du projet MERCI en Grande-Bretagne. Contrairement à wb, il travaille sur du texte.
Le répertoire des sessions :
Enfin, le dernier outil absolument nécessaire pour connaître, créer, participer aux événements du MBone est sdr. sdr veut dire Session Directory. Comme son nom l’indique, il permet d’avoir un répertoire des diverses sessions programmées sur le MBone avec l’indication de la date et de l’heure. Il permet de se connecter automatiquement sur une session avec l’ouverture directe de tous les outils nécessaires à une bonne participation. Il vous permet aussi de créer vous mêmes vos propres événements. Attention toutefois aux TTL attribués à vos sessions : elles ne doivent pas polluer le monde entier pour annoncer une conférence de test locale... Un des autres avantages de sdr est qu’il permet de faire des demandes de connexion avec une personne de même que des appels téléphoniques. Vous pouvez laisser tourner sdr en tâche de fond et attendre que quelqu’un vous appelle sur votre station plutôt que par le téléphone. Le coût de la communication n’est naturellement pas comparable puisqu’elle est gratuite sur le MBone.
La vie du MBone.
Il y a deux vies sur le MBone.
Les événements qui ont lieu sont souvent diffusés depuis les Etats-Unis. Avec le décalage horaire, vous devez travailler tard le soir pour y participer... Quand, en plus, l’événement a lieu le soir aux Etats-Unis, il faut passer la nuit devant votre station. Mais de plus en plus d’événements se créent depuis l’Europe, comme des séminaires du CERN, et depuis la France comme la retransmission des rencontres GERET. Vous pouvez aussi écouter les nouvelles en provenance d’une radio canadienne ou assister en direct de l’espace aux évolutions des astronautes américains dans la navette spatiale (images superbes garanties) ou assister à une partie d’un concert des Rolling Stones...
La deuxième vie du MBone, c’est le changement de version des outils. Comme je l’ai signalé, le MBone est un outil expérimental pour les nouvelles technologies sur IP. Si certains protocoles sont bien finalisés, il faut quand même expérimenter les applications et s’adapter aux nouvelles normes. Certains outils n’évoluent plus : c’est le cas de wb. D’autres évoluent lentement comme vic. D’autres changent de sous-version tous les mois. Et en plus parfois les versions sont incompatibles car elles apportent des nouvelles fonctionnalités aux versions précédentes. C’est le cas surtout de sdr et nt qui sont encore en cours de développement dans le projet MERCI. Ne soyez pas découragés pour autant, l’information circule, le MBone est fait pour ça.
Il faut pra-ti-quer !
A part écrouler Renater, cet article n’a d’autre but que de vous sensibiliser à l’existence et à l’utilisation du MBone et de ses outils. Bien entendu vous n’en verrez les bénéfices qu’en l’utilisant vous-même et en créant vos propres événements. C’est par l’apprentissage que vous rencontrerez les divers problèmes sous-jacents de l’utilisation de ces outils.
Le premier exemple est l’utilisation de la caméra. Nous ne sommes pas Patrick Poivre d’Arvor et nous n’avons pas l’habitude de parler face à une caméra. Notre attitude consiste souvent à regarder l’écran davantage que la caméra car nous regardons d’abord l’image de nos interlocuteurs. Pour pallier ce problème, il est utile de mettre la caméra au-dessus de l’écran (elles sont toutes petites) et la fenêtre de notre interlocuteur juste en dessous de la caméra.
Le deuxième exemple est l’utilisation des coupures de son. Par défaut, vat se met dans un mode où celui qui parle coupe la parole aux autres. C’est bien pratique dans certaines conditions mais parfois l’interlocuteur attend un bon moment que la personne se taise et l’interactivité n’existe plus. De plus, après un silence, il faut un certain délai pour que l’application s’aperçoive que quelqu’un a pris la parole ce qui résulte en la perte du début de la phrase. Une solution est d’utiliser le mode full duplex. Ce mode permet la communication en réception et en émission simultanément. Si celui-ci avantage l’interactivité, il apporte des phénomènes d’écho. La personne qui parle entend sa voix en retour des hauts parleurs de ses interlocuteurs. C’est pourquoi je préconise l’utilisation de microphones cardioïdes évitant ce phénomène de retour.
L’événement GERET sur le MBone.
Il n’est pas utile de présenter le groupe GERET (Groupe d’Exploitation des Réseaux Ethernet sous TCP/IP) animé par Jean-Luc Archimbaud de l’UREC. Depuis la réunion de juin 1996 à Lyon consacrée aux " nouveaux développements autour du Web ", il a été décidé que les réunions de travail seraient diffusées sur le MBone. Nous utilisons les dernières versions disponibles des outils décrits plus haut pour la visioconférence. Le tableau blanc permet le suivi des réactions des spectateurs du MBone et des problèmes : en particulier, pour suivre les problèmes de qualité du son ou des personnes qui posent des questions sans micro... Ceci nécessite donc la présence d’une personne à proximité du lieu de la conférence en charge des aspects techniques de la diffusion. Nous avons pris le parti de ne diffuser que l’image de l’intervenant sans avoir recours à un spécialiste de l’audiovisuel et de la manipulation d’une caméra.
En revanche, nous demandons aux intervenants de préparer leur support de présentation pour le Web en HTML. Ceci permet aux personnes connectées sur le MBone de suivre les conférences sans avoir recours à la diffusion d’une autre image vidéo pour la diffusion des transparents. Elles utilisent un butineur sur leur propre poste de travail pour accéder au support de transparent disponible sur le serveur Web de GERET. L’intervenant doit néanmoins prendre le soin de préciser à chaque fois qu’il change de " transparent ". Notre expérience montre que même s’il oublie de le préciser, le suivi se fait sans problème majeur dans la plupart des cas. Un autre avantage d’avoir le support de transparent en HTML est sa mise à disposition sur le serveur Web de GERET, donc celui de l’UREC, pour des consultations ultérieures.
Les commentaires positifs des spectateurs du MBone nous ont incités à renouveler les diffusions de GERET sur le MBone.
Les rencontres GERET sur le Web.
Pour aller encore plus loin sur la diffusion de ces rencontres GERET, nous avons décidé de mettre disponibles sur le serveur Web de GERET, la présentation sonore de quelques interventions " remarquables " de la rencontre sur les développements du Web. Sans aucune objectivité, nous avons choisi les présentations de Claude Gross (de l’UREC) sur les nouvelles versions de HTML et le tutorial Java de Serge Chaumette et Alain Miniussi (du LABRI).
Toutes les interventions ont été enregistrées par les soins de l’équipe audiovisuelle de l’Ecole Normale de Lyon. Quelques soucis aux moments des changements de cassettes font qu’il manque certains morceaux des conférences.
La numérisation du son s’est faite sur une Indy avec les outils standard du système et les sons convertis en format µ-law mono sur 8 bits échantillonné à 8 kHz. Ce format, de suffixe .au, est celui venant de Sun et Next et est sans doute le plus utilisé sur le Web. Les interventions ont été découpées par morceaux, pour des problèmes de changements de cassettes et de taille.
Si vous utilisez Netscape comme butineur, et s’il est correctement configuré, le déchargement du fichier son et l’écoute de celui-ci se font automatiquement l’un après l’autre en utilisant le " player " appelé naplayer livré avec Netscape depuis la version 2. D’autres programmes " joueurs " de fichiers sons de Sun existent. Les plus connus sont pour PC wplany (Windows Play Any) et pour MacIntosh, Sound Machine.
Les trois présentations sont découpés en une dizaine de fichiers sons qui ont été " récupérés " 350 fois dans le premier mois.
Et l’avenir ?
L’avenir à court terme du MBone est principalement le contrôle de la topologie : deux organisations peuvent sans aucune restriction, " tirer un tunnel " entre elles alors qu’un autre chemin peut être plus judicieux. Un autre aspect est l’attribution d’adresses multicast spécifiques permettant des conférences dans une organisation " distribuée ". Les adresses IP multicast ont leur premier octet compris entre 224 et 239 (classe D). Les adresses 239 sont réservées à cet effet et l’IANA, qui gère les adresses, doit définir leur utilisation.
Le MBone n’a pas d’avenir à long terme. Et c’est heureux. Comme je l’indique plus haut, le routage multicast apparaît au niveau des routeurs. Quand tous les routeurs de l’Internet auront cette fonctionnalité, les stations " mrouteurs " actuelles n’auront plus lieu d’exister, les tunnels non plus et le MBone sera l’Internet dans son entier. Cette fonctionnalité est prévue, à terme, dans le cahier des charges de la prochaine évolution de Renater.
Les rencontres GERET seront toujours diffusées sur le MBone et certaines conférences disponibles sur le Web. Le premier essai effectués montre qu’en restant au niveau de la France, le son passe bien. Il faut toutefois signaler que les conférences venant d’outre Atlantique n’ont pas cette qualité de son et qu’il est souvent difficile de les suivre en entier.
On pourrait écrire un livre sur le MBone. D’ailleurs, il en existe (voir plus loin). On pourrait expliquer les protocoles de routage utilisés (DVMRP, PIM), les protocoles de participation à un groupe (IGMP), les protocoles de transport et de réservation (RSVP, RTP, etc ), faire une description plus détaillée des configurations des routeurs, aller plus loin dans la description des outils, faire une liste des outils plus élaborée, expliquer les formats de codage et de compression, les techniques proposées dans IPv6 pour pallier les insuffisances de IP dans ces domaines. Il y aurait encore beaucoup de choses à dire sur l’audio et la vidéo à la demande.
Cet article n’est destiné qu’à sensibiliser aux futurs développements des techniques multimédia. Il ne suffit pas d’avoir de très hauts débits pour résoudre les problèmes de transport des applications multimédia en temps réel et les protocoles doivent prendre en compte les demandes différentes de qualité de service suivant les diverses applications.
Pour plus d’information.
Les livres sur le MBone :
Des livres plus généralistes, plus techniques :
Des listes de distributions :
Sur le Web, on ne peut pas tout citer, mais restons en à de bonnes adresses de départ :
et bien sûr, Geret :
Les outils :
la caméra QuickCam :