Université Paris 7 Denis Diderot UFR d INFORMATIQUE

Transcription

1 Université Paris 7 Denis Diderot UFR d INFORMATIQUE DESS Applications des Réseaux et de la Télématique Christophe Herviaux Multidiffusion et services avancés en IPv6 Mémoire soutenu en septembre 2004 Directeur des études : Gilbert Sol Directeur du mémoire : Yves Legrandgérard Tuteur en entreprise : Jacques Prévost Deux exemplaires de ce mémoire sont déposés et librement consultables au secrétariat du DESS «Applications des Réseaux et de la Télématique» Toute reproduction en est interdite sans accord écrit de l auteur et du directeur des études

2 Remerciements Je tiens tout d abord à remercier M. Jacques Prévost qui a su me conseiller, me guider et m apporter les réponses nécessaires au bon déroulement de mon stage et pour m avoir accepté en tant que stagiaire Aristote. Je remercie pour leur formation et leurs conseils, Yves Legrandgérard, mon directeur de mémoire, Gilbert Sol, mon directeur d étude au DESS Applications des Réseaux et de la Télématique ainsi que Bernard Tuy, responsable de IPv6 au GIP RENATER. Je remercie les personnes du GIP RENATER : Jérôme Durand, Simon Muyal, Kostya Kortchinsky, Siby Harouna pour leur aide technique très précieuse. Je tiens à remercier également le directeur du GIP RENATER, M. Dany Vandromme, d avoir donné son autorisation à ma venue. Je remercie l ensemble de l équipe du GIP Renater, le SSO et le secteur administratif pour leur bonne humeur et cette ambiance agréable de travail. Page : 2 / 136

3 Sommaire 1. Introduction Contexte de travail L association Aristote Le réseau Renater et le GIP Renater Le Réseau National des Télécommunications pour la Technologie, l Enseignement et la recherche Le GIP Renater Le GN Des actions de téléenseignement Le projet ATHENA Les cours DIM Les séminaires Aristote Les Causeries de Renater La grille de Conférences Cadre et objectifs Les technologies employées IPv Un plus grand nombre d adresses IP Une hiérarchisation des adresses Auto configuration des stations Le routage Le serveur de nom La sécurité La métrologie La visioconférence RTP (Real-Time Transport Protocol), RTCP (Real-Time Transport Control Protocol) : les protocoles de transport de trafic temps réel La vidéo numérique, les formats Le multicast Généralités Rappels sur les adresses IPv Adressage IPv Les protocoles IPv Cohabitation avec IPv M6Bone Le protocole H Généralités Architecture Etablissement de la communication Historique Inconvénients du protocole H Des applications pour la visioconférence Vic Vic GC (Grand CIF) Rat VideoLAN Isabel Passerelle IPv4 - IPv6...3 Page : 3 / 136

4 4. Mises en œuvre Etude et déploiement de systèmes de visioconférence Mise en œuvre d une passerelle IPv4 multicast - IPv6 multicast Etude Réalisation Développement des fonctionnalités des outils de visioconférence pour le téléenseignement interactif Fonctionnement interne de VIC VIC CG - haute résolution (4CIF) Participation de Renater au «Workshop d Isabel» du 26 mai Présentation Utilisation Bilan La plate-forme de démonstration IPv6 du GN Elaboration du design Réseau Définition du projet Collecte d information Proposition d une topologie réseau IPv Premier pas Choix des distributions et activation de la pile IPv Architecture Routage Configuration du routage interne avec Zebra Configuration du routeur 6wind Procédures de tests du routage Le multicast IPv Raccordement au M6Bone avec le 6wind Configuration du routeur Unix avec PIM Procédure de tests du service multicast IPv Ajout du service de DNS (Domain Name Server) Le service DNS avec BIND Procédure de tests du service DNS Ajout du service de Serveur Web Etude Le service Web avec Apache Procédure de tests du service Web Administration du réseau IPv Métrologie avec MRTG Ajout de services de visioconférence IPv Configuration d un client H323 avec GnomeMeeting Configuration d un pont MCU avec OpenMCU Transfert de connaissances Conclusion Annexes...3 Annexe 1. Les partenaires du projet ATHENA... 3 Annexe 2. Les logiciels de visioconférence... 3 Manuel d utilisation de VIC...3 Manuel d utilisation de VIC-GC...3 Manuel d utilisation de RAT...3 Manuel d utilisation de VideoLAN...3 Page : 4 / 136

5 Annexe 3. Le routage... 3 Fichier /etc/rc.conf...3 Fichier /usr/local/etc/zebra.conf...3 Fichier /usr/local/etc/ripngd.conf...3 Fichier /etc/dhcpd.conf...3 Fichier de configuration du 6wind...3 Annexe 4. Le DNS... 3 Fichier /etc/resolv.conf...3 Fichier /etc/host...3 L arborescence des fichiers...3 Fichier /etc/dns/etc/named.conf...3 Fichier /etc/dns/forward/localhost...3 Fichier /etc/dns/forward/gn6.renater.fr...3 Fichier /etc/dns/reverse/localhost-rev...3 Fichier /etc/dns/reverse/localhost-rev...3 Fichier /etc/dns/etc/rndc.conf...3 Annexe 5. Le serveur Web... 3 Installation de MySQL...3 Installation de Apache...3 Installation de PHP4...3 Installation de SPIP...3 Installation de PHPMyAdmin...3 Détection de l utilisation du protocole IPv6 par un navigateur Web...3 Interface graphique du site Web...3 Annexe 6. Bibliographie... 3 Page : 5 / 136

6 1. Introduction L association Aristote est impliquée dans la mise en œuvre et la retransmission en multicast d évènements à caractère pédagogique tels que les cours DIM, les Causeries de Renater et les séminaires Aristote. L emploi des logiciels de visioconférence en multicast dans le cadre de ces retransmissions a permis de révéler des besoins quant aux fonctionnalités offertes par ces outils. C est dans cette optique que le projet VIC-GC a vu le jour courant de l année VIC- GC est un projet portant sur les modifications du logiciel utilisé pour émettre et recevoir de la vidéo en multicast afin de lui permettre de transmettre les transparents de l orateur lors d un cours ou d une présentation. Après une première phase de recherche et de création de ce projet dans l environnement Unix conduite par Aurélien Amacker, alors stagiaire du DESS ART durant l année scolaire 2002/2003, ma mission a été de porté ce logiciel à l environnement Windows. Cette phase de développement du projet intégrait la pérennisation des techniques déjà utilisées. D autre part, le GIP Renater, partenaire de l association Aristote, participe au processus de transition du protocole IPv4 vers IPv6 en proposant à la communauté académique un service de passerelle IPv4 IPv6 multicast et c est dans ce contexte que j ai été chargé du passage de l exploitation pilote à la mise en production. En effet l association Aristote est concernée par le développement du protocole IPv6 qui, outre les nombreuses fonctionnalités innovantes qu il apporte, permettra à de nombreux pays oubliés par les nouvelles technologies de l Information et de la Communication de bénéficier d un nombre d adresses IP nécessaire au déploiement de leurs réseaux et ainsi d accéder aux ressources pédagogiques contenues sur le réseau Internet, c est pourquoi l association Aristote encourage ses partenaires du projet ATHENA à mettre en œuvre des réseaux IPv6 et IPv6 multicast. Pour aider de nombreux organismes et les accompagner tout au long de la démarche de transition IPv4 vers IPv6, le GIP RENATER a mis en place avec eux le Groupe des Néophytes IPv6 : le GN6. C est dans ce cadre que le projet de création d une plate-forme IPv6 a été initié. Différents partenaires dont l association Aristote ont mis à disposition les ressources nécessaires pour promouvoir les activités de recherche, de téléenseignements et de télétravail. J ai été chargé de mettre en place cette vitrine technologique IPv6. Page : 6 / 136

7 2. Contexte de travail 2.1. L association Aristote Créée de manière informelle en 1984 par l'inria, le CEA, EDF et le CNES, formalisée en 1988, l'association Aristote regroupe de grands organismes ou entreprises français intéressés comme acteurs ou comme utilisateurs à l'évolution des télécommunications de transmissions de données. L'objectif d'aristote se situe dans le domaine des techniques, moyens, outils et services de communication informatique, notamment : mettre en commun des efforts de prospective, d'étude et d'information faits par ses membres. promouvoir l'élaboration et la mise en service de nouveaux produits, systèmes et services d'intérêt général au bénéfice de ses partenaires. Cette activité se déroule dans le cadre des groupes de travail techniques d'aristote. organiser ou encourager des actions avancées d'information ou de formation : séminaires d'intérêt général, séminaires de formation technique, journées d'étude thématiques. L association Aristote est un acteur important dans le développement et dans la diffusion de connaissances concernant les nouvelles technologies de l information et de la communication. Pour en savoir plus : Le réseau Renater et le GIP Renater Le Réseau National des Télécommunications pour la Technologie, l Enseignement et la recherche RENATER (Réseau National de Télécommunications pour la Technologie, l Enseignement et la Recherche) a été créé dans les années 1990 dans le but de fédérer et d organiser les infrastructures de télécommunications pour l Education, la Recherche et l Enseignement. Aujourd hui, plus de 600 sites sont raccordés au réseau RENATER. Ceci leur permet de communiquer entre eux, d accéder aux centres de recherche publique et privés, aux établissements d enseignement du monde entier via l Internet. Le réseau RENATER est composé d une infrastructure métropolitaine et de liaisons internationales à haut débit. Des points de présence de RENATER sont également implantés dans les départements d Outre Mer. RENATER est basé sur une architecture distribuée : il comprend une épine dorsale nationale à haut débit multi-gbit/s - RENATER 3 - qui fédère des réseaux de collecte régionaux développés avec le soutien des collectivités territoriales dans le cadre de l aménagement du territoire. Page : 7 / 136

8 La liaison entre le réseau RENATER et le réseau GEANT est à 10Gbit/s. Grâce à cette liaison le réseau RENATER est relié aux réseaux de la Recherche européens et nordaméricains. La communication avec l Internet, en France, est réalisée par le SFINX, un point d échange entre les opérateurs, auquel RENATER est relié à 1 Gbit/s. La communication avec l Internet dans le reste du monde est assurée par le raccordement de RENATER à 2.5 Gbit/s à l épine dorsale Internet mondiale OpenTransit de France Télécom. Avec la version 3 de RENATER, les débits des liaisons de l épine dorsale sont presque partout de 2,5 Gbit/s. Ces liaisons sont presque partout organisées en boucle : ceci augmente la disponibilité en cas d incident il y a toujours un chemin de secours disponible et facilite la mise en place de liaisons de voisinage entre régions. Le réseau Ile de France est un réseau maillé avec des liens pouvant atteindre 2,5Gbit/s. Voici la carte de RENATER 3 : Page : 8 / 136

9 Au niveau des points d'accès régionaux de son épine dorsale, RENATER 3 propose de nombreux services : un service IPv4 permettant d accéder aux communautés de la recherche et de l enseignement, nationales et internationales ainsi qu à l Internet un service de diffusion IPv4 (IP multicast), utilisée pour la visioconférence et le téléenseignement interactif un service IPv6, utilisé par les universités pour préparer la migration de IPv4 vers IPv6, ainsi que par de nombreux projets de recherche et développement. IPv6 est la nouvelle version du protocole IP de l Internet. En Europe, les réseaux de la recherche sont très actifs pour préparer et commencer cette migration, et proposer un service IPv6 pour les expérimentations des premiers utilisateurs. RENATER est au premier plan de cette évolution : dans RENATER 3, il y a un service IPv6 natif, c est à dire placé sur le même plan que le service IPv4. IPv6 est conçu pour s affranchir des limitations d IPv4 (pénurie d adresse IPv4, explosion des tables de routage ), mais aussi pour prendre en compte les avancées issues des recherches sur les réseaux, comme l auto configuration, la mobilité, le multicast ou encore la sécurité. Pour en savoir plus : Le GIP Renater Le GIP 1 RENATER réunit de grands organismes de recherche et d'enseignement, ainsi que le ministère en charge de l'education Nationale, de la recherche et de la technologie, pour développer et faire fonctionner le réseau RENATER. Un GIP (groupement d'intérêt public) est un organisme à but non lucratif, réunissant des administrations de l'etat et des organismes publics pour une activité définie : dans le cas du GIP RENATER il s'agit du réseau RENATER. Le GIP RENATER est le maître d'ouvrage de la partie commune de RENATER, constituée de son épine dorsale RENATER 3, des liaisons internationales, de ses actions pilotes, et du service SFINX, qui est un GIX (Global Internet exchange), point d'échange de trafic Internet entre prestataires de services Internet, ou opérateurs de télécommunications qui veulent échanger du trafic, sans transit et sans passer par des infrastructures internationales Le GIP RENATER est également le coordinateur technique et opérationnel global de l'ensemble du réseau RENATER y compris ses éléments régionaux. Il représente le réseau RENATER auprès des institutions françaises et étrangères, et notamment auprès des autres réseaux de la Recherche. Le directeur du GIP RENATER est M. Dany Vandromme, professeur des universités ; L'équipe du GIP RENATER comprend aujourd'hui un peu moins de 30 personnes : ingénieurs, techniciens et personnel administratif répartis entre Paris et Montpellier. 1 GIP : Groupement d Intérêt Public. Page : 9 / 136

10 2.3. Le GN6 De nombreux organismes de la communauté des utilisateurs de RENATER désirent actuellement démarrer de petits réseaux IPv6 dans leurs organismes : cela leur permettra d acquérir l expertise nécessaire, et d étudier concrètement divers aspects techniques et opérationnels de l introduction de IPv6. Ainsi, ils pourront ensuite planifier dans de bonnes conditions le passage de IPv4 vers IPv6. Pour les aider et les accompagner tout au long de cette démarche, le GIP RENATER a mis en place avec eux le Groupe des Néophytes IPv6 : le GN6. Le GN6 est un groupe de travail qui met ensemble des acteurs «réseau» des organismes de la communauté RENATER : organismes utilisateurs de RENATER, réseaux de collecte de RENATER, réseaux ou organismes étrangers qui ont une convention de coopération avec le GIP RENATER. Ses objectifs sont notamment : permettre de s initier à la mise en œuvre de IPv6 et de ses applications de base, faciliter, par des échanges d information et des retours d expérience systématiques, le démarrage de réseaux pilotes IPv6 qui pourront être connectés au service IPv6 de RENATER - dans les organismes, faciliter, dans les mêmes conditions, la participation aux actions pilotes menées par le GIP RENATER et/ou le G6, par exemple IPv6 multicast ou DNSsec. faciliter l accès aux connaissances des experts, notamment ceux du GIP RENATER et de l Association G6. Démarré mi-2002, le GN6 comporte déjà une vingtaine de personnes, et se réunit tous les deux mois. Certains de ses membres, éloignés de quelques milliers de kilomètres, participent régulièrement aux réunions en visioconférence sur IPv6. Pour en savoir plus : Page : 10 / 136

11 2.4. Des actions de téléenseignement Le projet ATHENA Actions pour des Transmissions Harmonieuses et des Echanges de Natures Académiques ATHENA est un projet mis en œuvre par l association Aristote en association avec différents partenaires pour l étude et la validation de processus d échanges académiques via des transmissions réseau de contenus scientifiques entre sites académiques francophones. ATHENA a pour objectif de contribuer au développement d échanges académiques à travers les NTIC (Nouvelles Technologies de l Information et de la Communication) entre le réseau Renater et les milieux universitaires de ces pays. A la différence d autres expériences il ne s agit pas de mettre à la disposition des partenaires des supports multimédia (cédéroms ou vidéocassettes par exemple), l intérêt est de mettre en place un dispositif d échanges en temps réel (interactif) à travers les outils modernes de communications et en particulier à l aide de la visioconférence. D où le besoin d une analyse de la faisabilité technique avec l étude des moyens de communications dont disposent les futurs partenaires : ordinateurs, équipements de visioconférence, connectivité Internet, réseaux analogiques, numériques, hertziens Les premiers tests sont validés par : des essais de visioconférence en point à point avec les partenaires, la diffusion en direct d évènements, l ambition étant de faire du temps réel, l accent mis sur l interactivité ne supposant pas l ignorance d autres dispositions notamment la mise, par chaque partenaire, à la disposition de l ensemble du réseau constitué, des documents scientifiques à contenus consultables via Internet. Ces échanges de contenu à caractères scientifiques avec les pays de l Afrique francophone contribuent à une homogénéisation des connaissances dans les secteurs des télécommunications, réseaux Cette mise en partage des connaissances à pour objectif de donner aux étudiants africains le même savoir que celui dispensé aux étudiants européens. La carence de personnel et de salles de cours dans beaucoup de pays africains pourrait être compensée par cet enseignement à distance. Le projet ATHENA a été initié par l apprenti du DESS ART au GIP Renater de la promotion 2000/2001, M. Harouna Siby, qui a prospecté et trouvé des contacts en Afrique et plus précisément au Sénégal, puis ce projet a vu arriver de nouveaux partenaires en Inde, en Tunisie et au Maroc avec le travail de M. Lionel David, apprenti du DESS ART au GIP Renater lors de l année scolaire 2001/2002. Les nombreux partenaires du projet ATHENA sont listés en annexe (cf. Annexe 1. Les partenaires du projet ATHENA.). Le projet ATHENA constitue pour l association Aristote un moyen de nouer des partenariats et de partager des connaissances et des savoir-faire avec des partenaires académiques du monde entier. Page : 11 / 136

12 Les cours DIM DIM (Diplômes d'ingénierie Multimédia): c'est le nom d'un projet commun à plusieurs DESS ou enseignements équivalents de technologies d'informatique et de réseau. DIM leur permet d'organiser régulièrement des cours communs, partagés en interactif grâce à la visioconférence et à des outils de travail coopératif sur Renater. Ces enseignements sont dispensés à : L Université d'evry Val d'essonne (UEVE) L Institut National des télécommunications à Evry (INT) L Université Paris VII sur le campus de Jussieu L Université de Valenciennes et du Hainaut-Cambrésis (UVHC) L Ecole Supérieure Multinationale de Télécommunications de Dakar (ESMT) La Faculté Polytechnique de Mons Le GIP Renater apporte sa contribution au support technique de DIM : réseau et service IP multicast, technologies de vidéo numérique sur IP. DIM a démarré en Octobre Voici une vue de la salle du DESS ART à Paris VII, lors de la réception du premier cours DIM émis par le DESS IDM à Evry : Figure 1 : à gauche se trouvent les transparents de l orateur, à droite l image de l orateur. Les élèves peuvent poser des questions grâce aux micros qui se trouvent sur les tables. Les cours sont dispensés à tour de rôle par un enseignant de chacune des cinq formations concernées. Les cours DIM constituent une expérience grandeur nature de l usage de la visioconférence dans le cadre du téléenseignement interactif, en effet en plus de voir et d entendre l orateur les étudiants peuvent poser des questions pendant le cours. Page : 12 / 136

13 Les séminaires Aristote Dans le cadre de ses activités de diffusion de la connaissance auprès de ses membres, l'association Aristote organise régulièrement des séminaires de haut niveau : les séminaires Aristote. Ils sont groupés en cycles de 6 séminaires d'une journée chacun par année scolaire. Ces séminaires se déroulent le plus souvent dans un amphithéâtre de l'ecole Polytechnique. Ils sont principalement destinés aux utilisateurs évolués, aux administrateurs de réseaux et d'ordinateurs, et aux responsables et décideurs. Chaque séminaire est consacré à un thème précis, choisi dans le domaine des technologies des réseaux et de leurs applications de base. Il en aborde divers aspects: principes et état de l'art, produits et réalisations industrielles et/ou opérationnelles; compte rendus d'expériences ou de stratégies d'utilisateurs. Il fait intervenir des orateurs de haut niveau : experts internationaux, spécialistes des organismes d'aristote, représentants des industriels et des fournisseurs de produits Les Causeries de Renater Les Causeries de Renater sont des conférences virtuelles d une demi-journée à une journée disponibles sur Renater. Elles se déroulent entièrement en télé présence, grâce aux possibilités de visioconférence permises par les performances de Renater. Les orateurs et les auditeurs sont dans des salles de réunion équipées pour le multimédia, ou parfois simplement dans leurs bureaux : ces lieux sont réunis en une vaste salle de conférence virtuelle par le réseau RENATER et les autres réseaux de la recherche : certains sont en effet à l étranger. Tous les participants peuvent voir et entendre l orateur, interagir et poser des questions, puis participer au débat. Au total, et suivant le sujet de la Causerie, il y a de 10 à 50 points d écoute, pouvant représenter plus d une centaine de personnes. Chaque Causerie est dédiée à un thème précis. Il est traité par un ou plusieurs orateurs de haut niveau : membres de l équipe du GIP Renater, responsables réseaux des Centres de Ressources Informatiques des universités, professeurs de DESS d informatique, experts reconnus, utilisateurs compétents etc. Certains des thèmes retenus jusqu ici concernent le réseau Renater: déploiement, opération, technologies. D'autres abordent des applications avancées ou innovantes rendues possibles par Renater. Les Causeries sont ouvertes à toute la communauté des utilisateurs de Renater. Les organisateurs des Causeries sont actuellement : Guy Bisiaux (Université de Valenciennes) et Jacques Prévost (GIP Renater). Page : 13 / 136

14 La grille de Conférences La Grille de Conférences est le plus récent des projets dans lequel est impliquée l association Aristote, il s agit de proposer une normalisation du mode opératoire des techniques utilisées pour la visioconférence et la retransmission en multicast d évènements à caractère pédagogique. La Grille de Conférences réunit sur Renater (et ailleurs) un ensemble de noeuds (points d'écoute et de participation) de visioconférence, équipés et opérés de manière cohérente et coordonnée. La Grille permet de réaliser aisément des conférences virtuelles, avec des groupes d'auditeurs situés à chaque noeud. La Grille sépare totalement l'organisation de la virtualité, qui est du domaine des animateurs des noeuds, et l'organisation du contenu, qui est du domaine de l'animateur de chaque conférence : celui-ci peut préparer sa conférence ou son séminaire pratiquement sans avoir à se soucier de la virtualisation et en bénéficiant d'auditeurs à distance, capables de poser des questions et de participer aux débats, et aussi en programmant, s'il le désire, des intervenants à distance : il suffit qu'ils se rendent au noeud de la Grille le plus proche. La Grille de Conférences, c'est : Une technologie de pointe pour la visioconférence dans chaque noeud Un mode opératoire commun bien défini Des interconnexions réseau de qualité entre les noeuds Un accueil et une mise en oeuvre dans chaque noeud Actuellement on trouve des nœuds de la grille de conférence à Caen, Dakar, Paris, Montpellier et Toulouse. La Grille s'efforce d'intégrer les technologies validées par les utilisations à grande échelle de ces derniers temps, notamment DIM, Causeries de Renater et séminaires Aristote, ainsi que les conclusions des retours d'expérience de ces utilisations pilotes et notamment leurs suggestions d'améliorations. Page : 14 / 136

15 2.5. Cadre et objectifs Ma formation au sein du DESS Applications des Réseaux et de la Télématique à l université de Paris VII effectuée en alternance, s est déroulée dans le cadre d un partenariat entre l association Aristote et le GIP Renater. Le stage a été effectué dans les locaux du GIP Renater. Mes tuteurs durant ce stage étaient : Jacques Prévost (Association Aristote) chargé des applications avancées (visioconférences ) et Bernard Tuy, responsable des technologies IPv6 et IP multicast au sein du GIP Renater. Le sujet du stage comportait deux axes principaux : La mise en place et le développement de nouvelles fonctionnalités dans le domaine de la visioconférence orientée téléenseignement (transmission de séminaires et de conférences), notamment en IPv6, L étude et le déploiement d autres modes de visioconférences dans le cadre d une plateforme de démonstration IPv6. La première partie sur le multicast IPv6 s inscrit dans la continuité de ce qui a été fait par mon prédécesseur du DESS ART, Aurélien Amacker. Le but était de contribuer au développement de fonctionnalités demandées par l utilisateur et de l interactivité des actions de téléenseignement mises en œuvre par l association Aristote et de nombreux autres utilisateurs. La mise en place d une plate-forme de démonstration IPv6 s inscrit dans le cadre de prestation de services et de communication qui permet de promouvoir le protocole IPv6 tout en montrant des plateformes de production mettant en œuvre des services associés à ce nouveau protocole. Page : 15 / 136

16 3. Les technologies employées 3.1. IPv6 IPv4 a été initialement conçu pour un réseau comprenant une centaine d'ordinateurs. Avec le web, Internet a vu son utilisation augmenter de manière exponentielle si bien que la saturation du réseau a été initialement prévue pour Des solutions comme le NAT (translation d'adresses) et le CIDR (Classless InterDomain Routing - RFC ) ont permis de ralentir considérablement l'explosion du réseau et ont permis de mettre au point un nouveau protocole Internet appelé IPv6. IPv6 est conçu pour remédier aux limitations de IPv4 et en même temps répondre à de nouvelles exigences techniques apparues au niveau des réseaux ou des applications. La normalisation du protocole arrive aujourd'hui en bout de cycle. Voici une explication synthétique des fonctionnalités principales du protocole IPv6 : Un plus grand nombre d adresses IP Les adresses IPv4 ont presque toutes été allouées et IPv6 a pour première mission d'apporter un plus grand nombre d'adresses. Une adresse IPv6 est composée de 128 bits contre 32 bits pour IPv4. Le nombre d'adresses IPv6 disponibles a été estimé entre et adresses par mètre carré (océans compris). On peut donc considérer le nombre d'adresse IPv6 comme illimité. La représentation textuelle d'une adresse IPv6 se fait en découpant le mot de 128 bits de l'adresse en 8 mots de 16 bits séparés par le caractère ":", chacun d'eux étant représenté en hexadécimal (la casse des symboles n'a pas d'importance). Par exemple : fedc:0000:0000:0000:0400:a987:6543:210f Dans un champ, il n'est pas nécessaire d'écrire les 0 placés en tête et plusieurs champs nuls consécutifs peuvent être abrégés par "::". Ce symbole ne peut apparaître qu'une seule fois dans une adresse. L'adresse précédente s'écrit donc en fait : fedc::400:a987:6543:210f Une hiérarchisation des adresses L'objectif principal d'ipv6 a été de hiérarchiser les adresses pour permettre de plus grands agrégats et une réduction de la taille des tables de routage des routeurs de backbone (épine dorsale). Voici le schéma d'une adresse IPv6 : bits TLA 13 bits stla 13 bits Res 6 bits NLA 13 bits SLA 16 bits Interface ID 64 bits Topologie publique Topologie privée 2 RFC : Request For Comment Page : 16 / 136

17 Chaque partie est réservée à un usage précis. Il est à noter que la partie publique de l'adresse peut être encore amenée à certaines modifications. La partie privée quant à elle gardera définitivement cette structure. - Les 3 premiers bits 001 sont utilisés pour identifier le format d'adresse IPv6 agrégé (aggregatable global unicast addresses). - Le TLA (Top Level Aggregator) est réservé pour numéroter des opérateurs de transit. Il n'existe pas aujourd'hui d'opérateur de transit IPv6 et cette partie n'est utilisée que pour différencier certains types spécifiques d'adresses (adresses de test, adresses officielles, 6to4...) - Le stla (sub TLA) permet de numéroter les différents fournisseurs d'accès IPv6. Chaque Internet Registry 3 possède une partie du subtla pour numéroter les providers de sa zone géographique. Quand l'espace d'adressage assigné est épuisé, l'internet Registry se voit confier un nouvel espace par l'iana. - Les 6 bits suivants sont réservés pour pouvoir étendre la partie stla ou NLA en fonction des évolutions futures. - Le NLA (Network Level Aggregator) est la partie réservée aux providers pour numéroter leurs différents clients et gérer la hierarchie au sein de leur réseau. - Le SLA (Site Level Aggregator) est la partie réservée aux sites pour permettre de hiérarchiser le réseau en créant d'éventuels sous-réseaux. Les 16 bits du SLA permettent un découpage du site en sous-réseaux ce qui permet de n'allouer, même à des sites de très grande taille qu'un seul NLA-ID (identifiant de NLA) Cette structure hiérarchique permet de pallier un des problèmes majeurs du protocole IPv4 à savoir l'explosion de la taille des tables de routage des routeurs de backbone. Par exemple, Renater compte aujourd'hui environ 4000 routes qui sont agrégées en un peu plus de 140 agrégats IPv4 et il ne suffit que de 2 préfixes IPv6 pour annoncer l'ensemble du pilote IPv6 (le préfixe de production et le préfixe de test) sur le réseau Internet IPv Auto configuration des stations Un autre objectif a été de supprimer les commandes manuelles à fournir en IPv4 (adresse IP, passerelle par défaut) pour que la connexion au réseau devienne "plug-and-play" sans avoir à configurer de serveurs supplémentaires comme les serveurs DHCP. Les 64 bits de poids fort de l'adresse IPv6 correspondent à un identifiant de réseau et les 64 bits restants sont l'identifiant d'interface qui peut être déterminé automatiquement en fonction de l'adresse physique de la machine. L autoconfiguration est réalisée par une politique de découverte des voisins («neighbor discovery» RFC 2461) : une station qui démarre va émettre un paquet "router sollicitation" pour faire savoir au routeur du LAN qu'elle a besoin du préfixe du LAN pour calculer son adresse IPv6. Ce dernier répondra par un paquet "router advertisement" contenant le préfixe du LAN ainsi que d'autres informations comme la passerelle par défaut. Une station configurera son adresse IPv6 en concaténant le préfixe reçu et son identifiant d'interface qu'elle a calculé à partir de son adresse physique. 3 Un Internet Registry a la mission d'allouer des blocs d'adresses IP et des préfixes IPv6 dans sa zone géographique. Les Internet Registries aujourd'hui sont l'arin pour l'amérique du Nord ( l'atnic pour l'amérque du Sud ( RIPE-NCC pour l'europe, l'afrique du Nord et le centre de l'asie ( l'apnic pour l'asie Pacifique ( L'ICANN assure la coordination des Internet Registries ( Page : 17 / 136

18 Les différentes étapes de l algorithme «neighbor discovry» (RFC 2461) : La toute première étape consiste à créer l adresse lien local. L adresse de lien local est valide uniquement sur un même espace de lien sans routeur intermédiaire. Un routeur ne route pas ce type d adresse. L interconnexion par un commutateur de niveau MAC représente cet espace lien. Voici le schéma d'une adresse de lien local IPv6 de préfixe fe80::/10 : F E ID Interface 10 bits 54 bits 64 bits Une fois l unicité de cette adresse vérifiée grâce à l algorithme DAD (détection d adresses dupliquées), la machine est en mesure de communiquer avec les autres machines du lien. A la fin de cette étape la station va émettre un paquet «routeur sollicitation» pour faire savoir au routeur du LAN qu'elle a besoin du préfixe du LAN pour calculer son adresse IPv6 Ce dernier répondra par un paquet «router advertisement» contenant le préfixe du LAN ainsi que d'autres informations comme la passerelle par défaut. La machine doit chercher à acquérir un message d annonce du routeur pour déterminer la méthode d obtention de l adresse Unicast globale et de connaître la route par défaut (dans le cas d une autoconfiguration sans état). Cette étape permet à la machine de connaître le ou les préfixes du réseau qui sont annoncés par les routeurs. Ce préfixe a une longueur de 64 bits. La machine ajoute son identifiant d interface (déduit à partir de son adresse IEEE 802.3) pour construire son adresse IPv6. S il y a un routeur sur le lien local, la machine doit appliquer la méthode indiquée par le message d annonce du routeur, à savoir : l autoconfiguration sans état ou l autoconfiguration avec état. En l absence de routeur sur le lien local, la machine doit essayer d acquérir l adresse Unicast globale par la méthode d autoconfiguration avec état. Si la tentative échoue, c est terminé. Les communications de feront uniquement au niveau du lien local. Une station configurera son adresse IPv6 en concaténant le préfixe reçu et son identifiant d'interface qu'elle a calculé à partir de son adresse physique. Page : 18 / 136

19 Le routage Le routage IPv6 offre très peu de différences avec IPv4. Les protocoles de routage IPv6 les plus connus sont RIPng adaptation de RIPv2, OSPFv3, ISIS pour IPv6 et BGP Le serveur de nom Comment fonctionne le DNS? Le service de résolution de noms (RFC 1034) permet la correspondance d une adresse IP à un nom et inversement. Ce service est une base de donnée répartie, ceci permet un contrôle local de segments de la base de données globale. La structure de la base de données du DNS est décrite comme un arbre inversé avec le nœud racine au dessus (étiquette nulle). Chaque nœud dans l arbre a une étiquette, qui identifie de manière unique le nœud relativement à son parent. On garantit ainsi l unicité d un nom dans une structure arborescente. L exemple suivant illustre les deux points précédents : "" renater fr Le domaine de la plate-forme est une simple sous division de renater.fr, on parle ainsi de délégation du serveur de noms gérant la zone renater.fr au serveur de noms secondaire gérant la zone gn6. gn6 Ainsi le serveur de noms routegn6 gère sa propre zone gn6.renater.fr. pc3ipv6 Le RFC 1886 décrit les extensions apportées à ce service pour prendre en compte le protocole IPv6. Le choix du nom de domaine de la plate-forme Pour une dénomination claire de toutes les machines participant à la plate-forme de démonstration IPv6 du GN6, le choix du nom de domaine a été gn6.renater.fr. Ainsi toutes machines ayant pour serveur de noms celui de la plate-forme aura comme nom exemple.gn6.renater.fr, exemple fera partie de la plate-forme du GN6 hébergée par Renater. Ce choix n est donc pas anodin de plus il faut vérifier son unicité auprès du serveur de noms primaire. Page : 19 / 136

20 Les fichiers de Zone La correspondance adresse IP et nom s effectue à l aide d enregistrements (RR, «Ressource Record») au niveau du fichier (RFC 1912) gn6.renater.fr de notre serveur de noms. Il existe différents type d enregistrement RR dont celui de type SOA (Start Of Authority), c est l enregistrement qui indique la zone dans laquelle le DNS se trouve : gn6.renater.fr. D autres types de RR peuvent définir (listes non exhaustives cf. manuel d utilisation de bind généré à l installation de ce serveur de nom) : - les adresses IPv4 du domaine : c est le type A. - les adresses IPv6 domaine : c est le type AAAA (ou A6 obsolète). - le nom du serveur de noms d une zone : c est le type NS. - le courriel : c est le type MX - les alias : c est le type CNAME. - l adresse IP inverse : c est le type PTR. Les «résolveurs» Les «résolveurs» (RFC 1034) sont des programmes qui interfacent les applications utilisateur aux serveurs de noms de domaines. Dans le cas le plus simple, un résolveur reçoit une requête provenant d'une application (ex., certaines applications de visioconférences). Le résolveur est situé sur la même machine que l'application recourant à ses services, mais devra par contre consulter des serveurs de noms de domaines sur d'autres hôtes. Les résolveurs sont souvent de simples routines qui créent des requêtes et des envois à travers un réseau au serveur de noms. Le DNS et IPv6 Le RFC 3596 décrit les modifications à apporter au niveau des DNS pour qu'ils puissent supporter les adresses IPv6. La résolution nom adresse est décrite au travers d'un enregistrement AAAA. La machine exemple.gn6.renater.fr sera enregistrée sur le DNS du domaine gn6.renater.fr comme il suit : exemple IN AAAA 2001:770:4001:5024:200:39ff:fe4e:a9f6 La correspondance adresse nom est faite par un enregistrement de classe IN et de type PTR dans un domaine de nom spécial ip6.arpa. La notation de l'adresse est de type nibble : on renverse tous les symboles de l'adresse en hexadécimal par demi-octet, séparés par des points. La correspondance adresse nom de l'exemple précédent est écrite comme il suit dans le DNS : 6.f.9.a.e.4.e.f.f.f ip6.arpa IN PTR exemple.gn6.renater.fr Page : 20 / 136

21 La sécurité La sécurité est assurée par deux mécanismes : IPsec qui permet la confidentialité des échanges de données entre les usagers et les access-lists qui permettent de protéger les réseaux contre les intrusions. - Le protocole IPv6 permet l'authentification et le chiffrement des données (AH et ESP pour IPsec). La sécurité doit être obligatoirement gérée sur toutes les piles IPv6 afin de pouvoir échanger entre tous les nœuds des informations confidentielles. - La sécurité est aussi gérée en filtrant certains protocoles qui peuvent être utilisés pour attaquer le réseau. Le problème est que l'implémentation des access-lists sur les routeurs n'est pas toujours réalisée La métrologie La métrologie est aujourd'hui utilisée dans la plupart des réseaux, qu'ils soient locaux, métropolitains, nationaux ou internationaux. Elle permet de superviser le réseau, d'analyser les flux (afin d'obtenir une aide au diagnostic) et de vérifier le bon dimensionnement de l'architecture. C'est également un outil pour la sécurité puisqu'elle permet la détection des incidents et de certaines attaques. Les entités de gestion émettent des requêtes vers les nœuds supervisés pour vérifier les valeurs de certaines variables. Les agents sont des modules logiciel qui compilent d'abord des informations sur les dispositifs hôtes contrôlés, puis stockent ces informations dans une base de données de gestion, et la fournissent finalement (proactivement ou réactivement) aux entités de gestion par l'intermédiaire d'un protocole de gestion de réseau. La structure de l information de gestion définie par l ISO est basée sur la collecte d objets. Ces objets sont stockés dans des bases de données de gestion appelée MIB (Management Information Base). Ces objets vont alors permettre de décrire le comportement et offrir des points de contrôles des systèmes managés et optionnellement des actions que le manageur peut alors solliciter. Pour ce faire chaque objet offre un ensemble d attributs, de comportements et d actions et doivent pouvoir être créés et effacés. Les variables que l on cherche à gérer à distance doivent être identifiées de façon unique. Des règles normalisées ont été proposées pour autoriser l utilisation de ces numéros d identificateur. L ISO a décidé de se baser sur les identificateurs d objets (OID) qui reposent sur un arbre d enregistrement unique. Un protocole simple de gestion de réseaux, SNMP (Simple Network Management Protocol) a été développé par l IETF dans le cadre de la définition d un système de gestion pour les réseaux utilisant les protocoles TCP/IP. De fait, SNMP est très répandu aussi bien dans le domaine des réseaux locaux, que celui des réseaux métropolitains ou des réseaux WAN 4. 4 Les réseaux WAN (Wide Area Network), couvrent les communications mondiales. Page : 21 / 136

22 3.2. La visioconférence RTP (Real-Time Transport Protocol), RTCP (Real-Time Transport Control Protocol) : les protocoles de transport de trafic temps réel Les applications en temps réel n'ont pas les mêmes besoins que les applications de transfert de données. En effet, lors de la diffusion d'une vidéo sur IP, si certains paquets se perdent il est inutile de les émettre à nouveau et la caractéristique "temps réel" de ce type d'application est due au fait qu'il est ici plus important de recevoir les données au bon moment que de recevoir toutes les données. Un protocole de transport a donc été défini pour cette tâche : RTP (Real Time Transport Protocol, protocole temps réel). Celui-ci fait partie des protocoles qu'on appelle de "nouvelle génération" car adapté tout spécialement à un type d'application : la diffusion d'informations multimédia interactives sur l'internet. Ainsi RTP propose des services particuliers comme le transport d'information compressée sous différents formats, le numérotage d'une séquence de paquets, l'estampillage et une surveillance de bonne réception de données multimédia. Quant à RTCP, il s agit d un protocole destiné à assurer le contrôle du trafic. Il permet à l émetteur de récolter des informations au sujet de la qualité de la transmission. Chacun de ces deux protocoles utilise un port séparé d'une paire de ports. RTP utilise le port pair et RTCP le port impair immédiatement supérieur RTP RTP (RFC 3550) est un protocole de transport de données multimédia ou temps réel. Il ne fournit aucune garantie de qualité de service et se place généralement au dessus d'udp 5 pour fonctionner. Ainsi RTP ne garantie pas une diffusion ordonnée des données mais aide l'application à reconstruire une séquence de données multimédia grâce à ses fonctions de numérotage et d'estampillage. Il est important de savoir que RTP est destiné à transporter un seul type d'information à la fois, par exemple lors de la diffusion d'une vidéo, la vidéo et le son utiliseront deux flux de données RTP différents et le multiplexage d'informations diverses devra plutôt être assuré par un protocole sous-jacent (le port destination dans UDP par exemple).voici quelques définitions qui permettront de mieux comprendre ce protocole. - Données RTP : Il s'agit des informations transportées par le protocole, par exemple du son ou de la vidéo encodée de différentes manières. - Paquet RTP : Un paquet RTP contient une entête fixe RTP, une liste pouvant être vide des sources participant au paquet et les données RTP. Typiquement un paquet du protocole sous-jacent (UDP) contient un seul paquet RTP. 5 User Datagram Protocol, protocole de datagrammes en mode utilisateur. Page : 22 / 136

23 - Port : L'abstraction permettant à un protocole de transport de différencier des destinations multiples au sein d'un même ordinateur. - SSRC : "Synchronization source", il s'agit de l'identifiant unique d'un flux de données RTP afin d'être indépendant de l'adresse réseau du protocole sous-jacent. - CSRC : "Contributing source", certaines applications qui sont appellées des mixers combinents plusieurs flux de données RTP en un seul, pour savoir d'ou proviennent les différents flux, une liste de sources ayant contribué au flux est insérée dans l'en-tête du paquet RTP. Le format d'un paquet RTP est le suivant : V=2 2 bits P 1 bit X 1 bit CC 4 bits M 1 bit Horodate 32 bits Identificateur SSRC 32 bits Identificateurs CSRC 32 * (0-15) bits Données PT 7 bits Numéro de séquence 16 bits Chaque ligne fait 32 bits, les 12 premiers octets sont toujours présents dans un paquet RTP alors que la liste des CSRC est seulement présente si elle a été insérée par un mélangeur. La signification des différents champs est la suivante : - Version (V) : identifie la version de RTP, la dernière étant la numéro 2. L'utilitaire vat (ancêtre de Vic) utilisait la version 0 de RTP et le premier draft (brouillon) sur RTP définissait la version 1 de RTP. - padding (P) : si ce bit est posé alors le paquet RTP contient un ou plusieurs octets de remplissage à la fin du paquet qui ne font pas partie des données, le dernier octet du padding (bourrage) indique la taille de celui-ci. - extension (X) : si ce bit est posé alors l'entête fixe RTP est suivie d'une entête d'extension qui peut être définie par l'utilisateur. - CSRC Count (CC) : indique le nombre d'identifiants CSRC qui suivent l'entête fixe RTP. - marker (M) : l interprétation de ce bit est laissé à l'application, par exemple elle peut servir à définir le moment ou l'on change d'image lors de la diffusion d'une vidéo - payload type (PT) : indique le format des données RTP et donc leur interprétation par l'application. - Numéro de séquence : ce numéro est incrémenté de un à chaque paquets de données RTP envoyé, il peut être utilisé pour détecter des pertes ou reconstruire une séquence de paquets. - Horodate : l'estampille contenue dans le paquet RTP indique l'instant auquel le premier octet de données à été encapsulé dans le paquet RTP. Elle doit être dérivée d'une horloge et doit augmenter de façon monotone et linéaire pour permettre une synchronisation. - SSRC : identifie de façon unique la source sur laquelle il faut se synchroniser. - liste de CSRC : le nombre de CSRC est donné par le champs CC. les CSRC sont insérés par les mixers. Page : 23 / 136

24 Le format des paquets RTP doit rester simple et il est déconseillé d'essayer de faire du multiplexage sur les différents formats de données pour les raisons suivantes : Si deux flux de données partagent le même paquet RTP et donc le même identificateur SSRC et qu'il faille changer le type d'encodage de l'un des flux de données il ne sera pas possible d'identifier quel flux de données a changé son encodage Par définition un identificateur SSRC est relatif à un seul espace-temps et une seule numérotation des paquets. Si on multiplexe plusieurs types de données il faudrait disposer de plusieurs temporisations et plusieurs numérotations pour pouvoir identifier le flux de données ayant subit des pertes. Comme on va le voir plus loin, les rapports de réception RTCP sont relatif qu'à un seul timing et une seule numérotation par SSRC et ne précisent par le type de flux de données. Un mixer ne sait mixer qu'un seul type de données. Un paquet RTP contenant plusieurs types de données rendrait difficile : l'utilisation possible de différentes ressources réseau en envoyant par exemple les paquets contenant de la vidéo sur un lien différent de ceux contenant du son, le choix de la réception d'un sous ensemble des données multimédia (seulement le son par exemple) Ainsi l'utilisation d'une SSRC unique par média permet de remédier aux trois premiers points. On voit que la partie qui transporte les données du protocole RTP est assez simple, en effet toute sa complexité se situe dans le contrôle "temps réel" de ses données RTCP RTCP (RFC 3550) est un protocole qui permet d'obtenir des informations diverses sur une session RTP en cours : nombre de participants, qualité de réception, départ ou arrivée d'un nouveau participant. C'est donc un protocole de Feedback qui se doit d'être extensible par rapport au nombre participants à une session, qu'ils soient dix ou quelques millions. Ainsi RTCP transmet périodiquement des paquets de contrôle à tous les partic ipants d'une session. RTCP a quatre rôles : La fonction première de RTCP est de fournir un retour sur la qualité de la distribution des données. Ce retour peut être utile pour l'adaptation dynamique de l'encodage lors d'une transmission et permet par exemple de déterminer si une mauvaise réception est globale ou locale à une session. Le protocole RTCP permet de transporter un identificateur qu'on nomme CNAME pour "canonical name". En effet SSRC peut changer lors d'une session par exemple si l'on se rend compte d'une collision de SSRC alors que CNAME ne change pas. Les deux premières fonctions nécessitent que tous les participants à une session RTP doivent envoyer des paquets RTCP ainsi la bande passante utilisée par les messages RTCP doit être extensible avec le nombre de participants à une session. Si chaque participant a une session envoie des paquets RTCP aux autres, il est possible de connaître le nombre de participants et ensuite de calculer le débit auquel il faut envoyer des messages de contrôle. La dernière fonction de RTCP est optionnelle et permet de fournir des informations de session minimales comme par exemple l'identification des participants à une session. C'est particulièrement utile pour des applications ou il n'y a que très peu de contrôle des participants à une session. Page : 24 / 136

25 Les différents types de paquets RTCP sont les suivants : - SR : Sender Report indique les statistiques de réception et d'émission des participants à une session qui envoient des données. - RR: Receiver Report indique les statistiques de réception des participants à une session qui n'envoient pas des données et dont les statistiques n'excèdent pas 31 sources. - SDES : les éléments décrivant une source. - BYE : indique la fin d'une participation. - APP : fonctions spécifiques à l'application. De la même manière que pour le protocole RTP chaque paquet RTCP contient une partie fixe et une partie variable, plusieurs paquets RTCP peuvent être concaténés dans un paquet de la couche inférieure (UDP par exemple) mais le premier paquet RTCP contenu dans un paquet de la couche inférieure doit toujours contenir des informations relatives aux statistiques de transmission ou de réception (paquets SR et RR) même lorsque des données ne sont pas reçues ou transmises La vidéo numérique, les formats Les formats d images vidéo Avec l avènement de la télévision deux standards de formats d images vidéo sont apparus : le NTSC pour les Etats-Unis et une grande partie de l Asie et le PAL pour l Europe ou bien un dérivé du PAL comme le SECAM en France. Ces deux familles regroupent chacune une diversité de variantes qui ont en commun la fréquence de rafraîchissement et le nombre de lignes qui composent l image. Pour des raisons techniques il a été choisi comme base de temps la fréquence du réseau électrique du pays concerné. Ainsi aux Etats-Unis, le secteur étant en 110V à 60Hz, la télévision utilise un rafraîchissement de 60Hz. En France nous sommes en 220V à 50Hz, le SECAM utilise donc un rafraîchissement de 50Hz. Le standard NTSC propose une image de 525 lignes tandis que le standard PAL propose une image de 625 lignes. Par la suite, avec l avènement de la micro-informatique est apparu le format VGA (Video Graphics Array, tableau graphique vidéo) proposant une définition de 320x200 en 256 couleurs ou une définition de 640x400 en 16 couleurs, puis le SVGA (Super VGA, super VGA) proposant 4 définitions supplémentaires : 800x600, 1024x768, 1280x1024, 1600x1200 ainsi qu une palette de couleurs allant jusqu à 16 millions de couleurs. Enfin avec le développement des applications de visioconférence est apparu le besoin de trouver un format commun à toutes ces applications et c est l UIT-T 6 qui a défini, en 1990, deux formats couvrant les besoins exprimés dans les domaines de la visiophonie et de la 6 Union Internationale des Télécommunications Secteur de normalisation des Télécommunications Page : 25 / 136

26 visioconférence : les formats CIF (Common Intermediate Format, Format Commun Intermédiaire), QCIF (Quarter CIF, quart de CIF) et SQCIF (Sub-Quarter). Le format d image CIF est caractérisé par 352x288 points pour la luminance et par 176x144 points pour la chrominance. Le balayage est séquentiel et la fréquence d image est de 29,97 Hz. Le format d image QCIF est caractérisé par 176x144 points pour la luminance et par 88x72 points pour la chrominance, avec une fréquence d image sous-multiple de celle du format CIF, le SQCIF par 128x96 points. Par la suite le format 4CIF est apparu, il correspond au double du format CIF et il est caractérisé par une taille d image de 704x576 points pour la luminance et par 352x288 points pour la chrominance. Le format d image supérieur au 4CIF, le 16 CIF est caractérisé par 1408x1152 pour la luminance Les formats de compression de signaux vidéo Afin de rendre compte d un mouvement fluide il est nécessaire de transmettre au moins 25 images par seconde. Supposons que chaque image ait une dimension de 800x600 et que chaque pixel soit codé sur 8 bits, il faut alors un débit de : 25 x 800 x 600 x 8 = 96 Mbit/s ce qui correspond au débit de la télévision à l origine. Pour la transmission par l Internet du signal vidéo numérique il est donc nécessaire d utiliser des techniques de compression afin de réduire le débit nécessaire. Le principe utilisé est le suivant : la source procède à un encodage du signal vidéo, puis au niveau du récepteur un décodage du signal vidéo est réalisé. Différents formats de compression ont donc été normalisés, parmi lesquels le fameux MPEG (Motion Picture Experts Group, groupe d experts en images animées), néanmoins l UIT-T a aussi émis des normes de codage vidéo pour des applications de visiophonie et de visioconférence comme la norme H.261 qui s applique à des services audiovisuels utilisant des liaisons de p x 64 kbit/s (la norme H.261 est donc tout particulièrement adaptée pour des services audiovisuels utilisant des liaisons RNIS 7 ) ou la norme H.263 qui vise à transférer de la vidéo sur des liaisons bas débit. Bien que les deux normes de codage vidéo diffèrent, leur principe reste le même. Chaque image est découpée en blocs, puis on applique une transformée en cosinus discrète à chacun des blocs pris séparément. La sortie de chaque transformée est alors une matrice de coefficients transformés. Ces normes de codage permettent donc de transmettre des images animées sur des liaisons à faible débit (moins de 128 kbit/s). 7 Réseau Numérique à Intégration de Services Page : 26 / 136

27 3.3. Le multicast Généralités Une adresse multicast ne désigne pas une interface mais un ensemble d interfaces. Un couple (adresse multicast, numéro de port) désigne un groupe multicast 8. Lorsqu une application s abonne à un groupe multicast elle reçoit toutes les données émises par tous les membres du groupe et à l inverse lorsqu elle émet des données à destination de ce groupe tous les membres du groupe reçoivent ces données. Le multicast est donc une technologie tout à fait adaptée à un contexte de diffusion de groupe comme c est le cas pour la visioconférence. La source émet des paquets avec une adresse de destination qui est en fait un identifiant de groupe. Au niveau de ses routeurs IP, le réseau démultiplie les paquets de telle sorte que tous les postes récepteurs abonnés à cet instant à cette session en reçoivent chacun une copie. Prenons l'exemple suivant : une station émet de la vidéo et 3 ordinateurs veulent recevoir le flux vidéo. Sur le schéma de gauche nous avons les différents flux émis avec de l'unicast et sur celui de droite nous avons le flux émis avec le multicast. Le multicast permet de consommer moins de bande passante et diminue la charge des processeurs des stations émettrices puisque ces dernières ne doivent émettre qu'un flux de données. 8 Problème de vocabulaire : la diffusion multicast n a pas de traduction acceptable en français. Le terme employé sera donc l appellation anglophone multicast. Page : 27 / 136

28 Rappels sur les adresses IPv4 Les adresses multicast sont celles qui correspondent aux classes D sur IPv * réservé pour utilisation locale sur le LAN tous les hosts multicast du LAN routeurs multicast 239.*.*.* réservé pour l administration Identification du groupe de diffusion 28 bits Les 4 premiers bits valent 1110 indiquant une adresse multicast. Les 28 bits suivants identifient un groupe de diffusion particulier Adressage IPv6 Chaque pile IPv6 doit obligatoirement supporter le multicast (MLD 9 ). L'objectif est de ne pas devoir créer de tunnels multicast comme ça a été le cas en IPv4. Une adresse multicast a le préfixe ff00::/8 et la structure suivante: F bits F bits flags 4 bits scope 4 bits Groupe ID 112 bits flags est un champ pour indiquer certaines caractéristiques de l'adresse multicast. On peut indiquer s'il s'agit d'une adresse permanente (valeur 0) ou temporaire (valeur 1). De même, les ordinateurs qui veulent faire du PIM SSM 10 positionnent ce champ à 3. scope indique la portée de l'adresse IPv6. Cette fonctionnalité était gérée en IPv4 avec le champ time-to-live. Voici les différentes valeurs que ce champ peut prendre : 0 réservé 1 nœud 2 lien 5 site 8 organisation E global F réservé group ID est l'identifiant de groupe. Certaines adresses sont prédéfinies. Ces adresses sont listées par le RFC 2375 On apprend par exemple que le groupe de tous les routeurs sur un lien est ff02::2. 9 Le multicast est expliqué plus en détail dans le chapitre PIM SSM : protocole de routage multicast Page : 28 / 136

29 Les protocoles IPv6 Le multicast nécessite pour fonctionner des protocoles qui interviennent à différents niveaux. Au niveau lien-local, un premier protocole nommé MLD (Multicast Listener Discovery) est nécessaire pour que les applications s'abonnent à des groupes auprès du routeur d'accès. D'autres protocoles interviennent au niveau inter-lans. Ils permettent de créer des arbres de diffusion multicast en fonction des liens-local où il y a des abonnés. Ainsi, des domaines peuvent être créés entre les LANs qui souhaitent s'échanger du trafic multicast. Des protocoles interviennent au niveau inter-domaines pour qu'il soit possible d'échanger du trafic multicast entre tous ces domaines Au niveau lien-local : Le protocole MLD (Multicast Listener Discovery - RFC 2710) MLD (Multicast Listener Discovery) est le protocole de dialogue entre les stations et les routeurs pour la gestion des groupes multicast. Les applications utilisent MLD pour s'abonner ou se désabonner à un groupe multicast. Ce protocole intervient donc sur les parties terminales du réseau. Les messages MLD sont véhiculés dans des paquets ICMPv6 (protocole n 58 en décimal). Sur chaque lien-local, un seul routeur peut avoir le statut de demandeur 11 MLD. C'est-à-dire que c'est le seul qui va gérer les messages MLD sur le lien-local. S'il y a plusieurs routeurs sur le lien, c'est celui qui a la plus petite adresse IPv6 qui est demandeur, tous les autres deviennent non-demandeurs. Voici la structure d'un message MLD : Type Code 8 bits 8 bits Maximum Response Delay 16 bits Checksum 16 bits Reserved 16 bits IPv6 Multicast Address 128 bits Le champ type permet d'identifier 3 types de message MLD : Multicast Listener Report : (type = 131 en décimal) Ce message est envoyé au groupe de tous les routeurs multicast sur le lien (adresse multicast ff02 ::2). Quand une application désire s abonner à un groupe elle va émettre un message multicast listener report avec un champ «adresse multicast IPv6» contenant l addresse multicast du groupe dont elle veut faire partie. Le routeur qui reçoit ce message rajoute une entrée dans sa table MLD si elle n existait pas déjà et commence à diffuser sur le réseau local les données à destination de ce groupe. Multicast Listener Done : (type = 132 en décimal) Quand une application veut quitter un groupe multicast, elle envoit ce message au groupe des routeurs multicast (adresse ff02 ::2) en spécifiant dans le champ «adresse multicast IPv6» l adresse IPv6 du groupe qu elle veut quitter. 11 Querier en anglais Page : 29 / 136

30 Multicast Listener Query : (type = 130 en décimal) Il y a deux types de messages Multicast Listener Query qui diffèrent par le contenu de leur champ «IPv6 Multicast Address». - General Query : ce type de message est utilisé par le routeur pour connaître tous les groupes auxquels sont abonnées les applications utilisant le multicast sur le réseau local. Dans ce cas le champ «adresse multicast IPv6» possède la valeur 0. Ce message est envoyé au groupe multicast de toutes les stations sur le réseau local (ff02::1) Périodiquement, le routeur demande à toutes les stations sur le lien-local (groupe multicast ff02::1) les groupes auxquels leurs applications sont abonnées. Quand elles reçoivent ce message MLD, les stations déclenchent pour chacune des adresses multicast un compte à rebours avec une valeur initiale aléatoire (comprise entre 0 et "Maximum Response Delay" contenu dans le message MLD). Quand le compte à rebours d'une adresse est écoulé, la station envoie un message multicast listener report pour ce groupe multicast si aucun report pour ce groupe n'a été envoyé auparavant par une autre station. Ainsi, seule une réponse par groupe est donnée. Dans l'exemple ci-contre, le routeur émet une requête générale. Des applications sur les stations A et B veulent recevoir le trafic pour le groupe G1. La station A répond la première. B voit que A a déjà répondu et annule sa réponse en attente. Si le routeur ne reçoit plus de multicast listener report pour des groupes qu'il a dans sa table MLD, il supprime alors ces groupes de sa table après un délai de l'ordre de 3 minutes. - Multicast-Address-Specific Query : utilisé pour savoir s'il y a des applications abonnées à l'adresse multicast spécifique contenue dans le champ «IPv6 Multicast Address». Ce message est envoyé au groupe dont on veut savoir s'il y a des abonnés. Quand un routeur reçoit un message multicast listener done, il envoie un group-specific query afin de savoir s'il y a encore des ordinateurs sur lesquels tournent des applications abonnées à ce groupe. Si aucune machine ne répond, il efface le groupe de sa table MLD. Page : 30 / 136

31 Dans cet exemple, une application multicast sur la station A quitte le groupe G1. Le routeur envoie un Specific Query pour savoir s'il y a d'autres applications abonnées au groupe G1 sur le lien. Une application multicast lancée sur B, qui est toujours abonné au groupe G1, envoie alors un report pour le groupe G1 qui n'est donc pas effacé de la table MLD du routeur. Dans le cas où seule une application sur la station A était abonnée, le routeur n'aurait pas reçu de report et aurait effacé le groupe G1 de sa table MLD Au niveau inter-lans (Domaine PIM) Les réseau locaux qui supportent le multicast peuvent se grouper en domaines afin d échanger entre eux du trafic multicast. En pratique on constate que sur une même zone géographique des réseaux locaux sont administrés de manière cohérente au sein d un même domaine. Les protocoles de routage multicast inter-liens ont été développés pour répondre aux problèmes suivants : Comment atteindre les membres des différents groupes de diffusion répartis sur tout un domaine (arbres de diffusion)? Comment économiser de la bande passante en n acheminant les paquets multicast que là où il y a des abonnés? Comment optimiser les échanges entre routeurs? (vaut-il mieux annoncer les groupes que l on veut recevoir où les groupes que l on ne veut pas recevoir?) On peut distinguer deux familles de protocoles multicast qui résultent de deux approches différentes : - Les protocoles de routage orientés «forte densité de récepteurs» (dense mode, mode dense) comme DVMRP (Distance Vector Multicast Routing Protocol, protocole de routage multicast a vecteur de distance) qui a aujourd hui presque disparu et PIM-DM (Protocol Independant Multicast Dense Mode, multicast indépendant du protocole mode dense) qui est plus récent. Ces protocoles partent du principe qu il y a des membres de groupe multicast sur la plupart des réseaux et que l absence de membres sur un réseau constitue l exception. Dans un domaine PIM-DM, les routeurs vont inonder périodiquement tout le domaine en transmettant tous les flux multicast à leurs voisins. Les routeurs qui ne veulent pas recevoir le trafic multicast demandent à leurs voisins de cesser de leur envoyer ces flux (mécanisme de pruning ou d élagage). C est de cette manière qu est créé l arbre de diffusion. Page : 31 / 136

32 Le problème est qu un routeur qui ne désire pas recevoir de trafic multicast va passer son temps à demander qu on cesse de lui envoyer ces flux multicast, c est pourquoi cette approche a disparu au profit du mode clairsemé (sparse mode). - Les protocoles de routage orientés «faible densité de récepteurs» (sparse mode, mode clairsemé) comme PIM-SM (Protocol Independant Multicast-Sparse Mode, multicast indépendant du protocole, mode clairsemé). Ces protocoles supposent au contraire des précédents que les membres de groupes multicast sont très dispersés et peu nombreux par rapport au nombre de réseaux desservis. Un ou plusieurs points de rendez-vous sont configurés dans le domaine PIM. Ces points de rendez-vous connaissent l ensemble des sources et des récepteurs des différents groupes du domaine, ainsi ils peuvent permettre aux sources et aux abonnés de se rencontrer sans inonder le réseau. Pour des applications de visioconférence l expérience montre que les récepteurs sont peu nombreux et souvent très espacés, c est pourquoi le protocole PIM SM est le plus adapté et c est ce protocole qui est utilisé dans le M6Bone, le réseau expérimental IPv6 multicast. Dans un contexte multipoints il est nécessaire de disposer d une entité qui recense les différents participants à la session et qui centralise les informations relatives à la session. Le principe du multicast est donc de déplacer du niveau applicatif au niveau réseau l entité centralisant les informations relatives à une session. Ainsi les concepteurs d applications multipoints peuvent se concentrer sur les caractéristiques intrinsèques des logiciels sans avoir à développer à chaque fois les mêmes mécanismes de gestion de session Au niveau inter-domaines Les domaines doivent pouvoir s'échanger entre eux le trafic multicast pour qu'il soit possible de recevoir depuis n'importe quel site le trafic multicast de tout l'internet. Deux protocoles sont utilisés au niveau inter-domaine : MBGP (Multiprotocol BGP) et MSDP (Multicast Source Discovery Protocol) Cohabitation avec IPv4 Il est établi que les protocoles IPv4 et IPv6 auront à cohabiter pendant une longue période, aussi des mécanismes ont été mis en œuvre pour assurer la meilleure transition possible : des adresses compatibles IPv4 des équipements avec la double pile IPv4 / IPv6 des mécanismes pour faciliter la gestion des tunnels : 6to4 (RFC 3056), des passerelles au niveau application (ALG : Application Level Gateways) Page : 32 / 136

33 M6Bone Présentation Le M6Bone (Multicast IPv6 Backbone, épine dorsale multicast IPv6) est un réseau multicast IPv6 expérimental. Son déploiement a débuté en juin 2001 avec le concours de l association Aristote, du G6 (groupe d experts français d IPv6) et du GIP Renater. L objet de ce déploiement est d offrir aux sites intéressés une connectivité multicast IPv6 afin de tester et de développer les applications et les équipements relatifs à ce protocole. Enfin le but final de ce projet est de déployer un service avancé du protocole IPv6 afin de participer à la normalisation de ce protocole Topologie A l heure actuelle plus de 25 sites sont reliés au M6Bone, parmi lesquels des partenaires du projet ATHENA comme l ESMT Dakar, l université de Guadalajara ou bien encore le DESS Applications des Réseaux et de la Télématique à l université Paris 7. Etant donné que peu d équipements implémentent aujourd hui le multicast en IPv6, les différents sites composant le M6Bone sont reliés entre eux par des tunnels IPv6 dans IPv6 ou bien IPv6 dans IPv4, c'est-à-dire que chaque paquet multicast IPv6 est encapsulé dans un paquet IPv4 unicast ou bien dans un paquet IPv6 unicast, le choix du tunnel dépendant de la connectivité disponible. Ce mécanisme permet donc de faire transiter du trafic multicast en IPv6 par des équipements réseau qui ne supportent pas ce protocole. Le cœur du M6Bone est hébergé au GIP Renater, il s agit d une distribution FreeBSD installée sur un pentium III qui joue le rôle de RP (Rendez-vous Point, point de rendez-vous). Page : 33 / 136

34 Voici les cartes du M6Bone au niveau national, européen et mondial : Figure 2 : Carte du M6Bone à l échelle nationale. Figure 3 : Carte du M6Bone à l échelle européenne. Page : 34 / 136

35 Figure 4 : Carte du M6Bone à l échelle mondiale. Page : 35 / 136

36 3.4. Le protocole H. 323 Avec le développement du multimédia sur les réseaux, il est devenu nécessaire de créer des protocoles qui supportent ces nouvelles fonctionnalités, telles que la visioconférence : l envoi de son et de vidéo avec un soucis de données temps réel. Le protocole H.323 est l un d eux. Il permet de faire de la visioconférence sur des réseaux IP Généralités H.323 est un protocole de communication englobant un ensemble de normes utilisées pour l envoi de données audio et vidéo sur Internet. Il existe depuis 1996 et a été initié par l ITU (International Communication Union), l instance mondiale de normalisation des Télécoms téléphonie qui développe des standards de communication. Concrètement, il est utilisé dans des programmes tels que Microsoft Netmeeting, ou par des équipementiers de visioconférence (VCon, Tandberg, ). Il existe un projet OpenH.323 qui développe un client H.323 en logiciel libre afin que les utilisateurs et les petites entreprises puissent avoir accès à ce protocole. Protocole H.320 et H.323 Le protocole H.323 est utilisé pour l interactivité en temps réel, notamment la visioconférence (signalisation, enregistrement, contrôle d admission, transport et encodage). C est le leader du marché pour la téléphonie IP. Il s inspire du protocole H.320 qui proposait une solution pour la visioconférence sur un réseau numérique à intégration de service (RNIS ou ISDN en anglais), comme par exemple le service numéris proposé par France Telecom. Le protocole H.323 est une adaptation de H.320 pour les réseaux IP. A l heure actuelle, la visioconférence sur liaison RNIS est toujours la technique la plus déployée. Elle existe depuis Les réseaux utilisés sont à commutation de circuits. Ils permettent ainsi de garantir une Qualité de Service (QoS) aux utilisateurs (pas de risque de coupure du son ou de l'image). Aujourd'hui, c'est encore un avantage indiscutable. Par contre, comme pour le téléphone, la facturation est fonction du débit utilisé, du temps de communication et de la distance entre les appels. Comment ça marche? Pour pouvoir suivre une visioconférence, il faut bien entendu le matériel adéquat. Ce peut être un matériel dédié contenant tout ce qu il faut : moniteur, micro, et caméra vidéo. Ou alors, un ensemble matériel et logiciel sur un poste de travail (PC, etc.). Si la visioconférence ne compte que deux interlocuteurs, alors la liaison est en mode point à point comme illustré sur le schéma ci-dessous : Page : 36 / 136

37 Dans le cas où il y a plus de deux interlocuteurs, la visioconférence nécessite l utilisation d un pont multipoint comme illustré sur le schéma ci-dessous : Pour se connecter entre eux, les interlocuteurs sont identifiés par un numéro ou une adresse E.164. Elle est composée de numéros et est structurée comme un numéro de téléphone. En particulier, un numéro de téléphone est une adresse E.164. «E.164» est le nom de la norme qui définit ces adresses. Pour router un appel H.323 dans le réseau, il est nécessaire d avoir un «Gatekeeper» (cf. définition dans le chapitre suivant). C est un élément logiciel qui fonctionne dans un PC, ou dans un pont multipoint ou dans un routeur IP (Exemple : dans les routeurs Cisco). En fonction de l adresse destinataire contenue dans l appel H.323, les différents Gatekeepers vont établir la communication entre émetteur et destinateur et mettre en place le routage. Page : 37 / 136

38 Par ailleurs, le protocole H.323 intègre la norme T.120 qui permet le partage d applications. On peut, par exemple, afficher des documents sur les postes de travail des autres interlocuteurs. H.323 définit un ensemble de protocoles utilisés dans les transmissions multimédia : H pour l enregistrement et l initialisation des appels Q931 pour l initialisation des appels H.245 pour la négociation des canaux des médias RTP pour la transmission vidéo et audio RTCP pour le contrôle multimédia T120 pour le service de données Architecture L architecture H.323 comprend les éléments suivants : Terminaux Passerelles (Gateway) Gatekeepers MCU (Multipoint Control Unit) optionnel Les Terminaux La norme H.323 définit un certain nombre d'éléments entrant en jeu dans une communication, dont le terminal. Les terminaux peuvent être un PC, IP-Phone, etc. Figure 5 : Equipement terminal H323 Un terminal H.323 est un équipement d'extrémité permettant une communication temps réel full duplex avec un autre terminal ou une passerelle. Il doit gérer obligatoirement les flux audio et éventuellement des flux vidéo et de données. Il doit inclure un module de contrôle de Page : 38 / 136

39 l'interface utilisateur, permettant la communication avec un autre terminal. Ce module est composé d'éléments suivants : Un module pour l'établissement des appels. Ce module repose sur H qui reprend et améliore la signalisationq.931. Cette signalisation est indépendante de la signalisation H.245. Elle ne fait qu'établir une connexion entre deux terminaux. Un module de contrôle supportant la recommandation H.245. Il permet de transporter les éléments de signalisation de la communication de bout en bout. Cette signalisation permet la négociation des paramètres de communication, l'ouverture, la fermeture et gestion des circuits logiques. Un seul circuit logique H.245 est établi pour chaque communication. Il gère tous les liens logiques de cette communication. Le composant "RAS" (Registration/ Admission / Status). Ce module permet la communication avec le Portier pour la gestion des admissions et de la bande passante. Un autre module permet de maintenir le séquencement et la synchronisation des paquets et de supprimer la gigue introduite dans le réseau de transport. La couche H.225 définit le format de transmission sur les circuits logiques établis par le module de contrôle. Sur chaque circuit logique circule un type de flux (audio, vidéo, données). Un circuit logique est unidirectionnel et indépendant dans chaque sens de transmission. Un circuit logique est établi pour chaque flux. Pour communiquer, les terminaux doivent utiliser le même codec s'il n'y a pas de passerelle. La norme H.323 définit les types de codages : G.711, G.723, G.729 etc. Le codage MPEG4, développé par MPEG (Moving Picture Experts Group) est également disponible. Les passerelles Les passerelles sont des éléments optionnels capables de traiter les protocoles de type H.323 et de les convertir pour permettre l inter fonctionnement entre système (réseau IP et réseau à commutation de circuit : RTC, RNIS). Les passerelles s acquittent de plusieurs taches : la conversion de protocole de transmission et de contrôle de communication; le transcodage des flux audio et vidéo; traduction de signalisation (établissement de l appel, occupation, libération). Grâce aux capacités de traduction et de transcodage de la passerelle, un terminal H.323 pourra dialoguer avec différents terminaux. Le Gatekeeper Le Gatekeeper est un élément optionnel mais il sera obligatoire si une passerelle est installée. A l origine le Gatekeeper devait s assurer, dans le cas de communications RTC/IP, de la traduction des adresses, du contrôle d accès au réseau et de la gestion de la bande passante. Les fonctions du Gatekeeper sont : Traductions des adresses téléphoniques en adresses de transport IP reconnues par le réseau. Une table de correspondance des adresses est tenue et mise à jour par des messages. Page : 39 / 136

40 Gestion des flux. Il contrôle la bande passante allouée aux flux multimédias. L administrateur peut ainsi définir des critères d accès (fraction de la bande passante allouée aux visioconférences, le nombre maximum de conférences simultanées, et autres types de filtres). Le MCU (Unité de Contrôle Multipoint ou Pont Multipoint) C est un élément optionnel chargé du pilotage de téléconférence multipoint (la part des ressources du réseau disponible, possibilité d avoir une transmission multicast, type de codage audio ). Les éléments constitutifs du MCU sont : MC (Multipoint Controler) : Il négocie avec l ensemble des terminaux participants les fonctionnalités communes à tous, et détermine les possibilités audio vidéo et décide si l un des flux peut être transmis en mode multicast. Aucun des flux ne transite par lui. MP (Multipoint Processor) : C est le centre de traitement des flux audio, vidéo. Il les reçoit les mixe, les synchronise et les renvoie vers tous les récepteurs. Il peut assurer aussi la conversion des formats Etablissement de la communication Une communication peut être établie selon plusieurs modes : En mode direct : En l absence de Gatekeeper, chaque terminal doit posséder sa propre table de routage. Quand les adresses sont converties, il effectue un échange de message H.225 et H.224 entre les terminaux pour l établissement de la liaison RTP. Figure 6 : exemple d'un appel point à point H323 (Source : Mémoire 2004 DESS ART Auteur TRINH Van Thuong) Page : 40 / 136

41 En mode Gatekeeper, le terminal interroge le Gatekeeper pour la conversion d adresse et pour obtenir l autorisation d appeler Historique Version 1 (1996) La recommandation a été adoptée par Microsoft et Intel dans leur produit Net Meeting (dans Windows 95 et 98) et Intel Internet Phone. Cette diffusion a officialisé la norme et les principaux fournisseurs de la téléphonie ont du abandonner leurs procédés de codage propriétaire et leurs procédures d appel pour se rendre compatible avec les clients Microsoft, de plus en plus nombreux, et donc a la norme H 323. Version 2 (1998) Correction de l établissement de l appel. Un canal de contrôle H 245 devait être ouvert entre les deux terminaux, en préalable à la requête de communication fonctionnant au-dessus de TCP. La procédure pouvait prendre 8 ou 10 allées retours (RTT Round Trip Time) cela pouvait durer quelques dizaines de secondes (pas de comparaison avec RTC). Dans la version 2 le mode FastConnect (l information relative au canal de média est incluse dedans évitant d ouvrir le canal H 245). La version 2 est complètement compatible avec la version 1. Version 3 (1999) La version 3 a pour intention de traiter plus généralement la gestion d un réseau téléphonique. Fax en temps réel Méthode de transport de la signalisation d appel sur UDP Version allégée a l intention des terminaux portables Procédures de communication entre Gatekeepers Services complémentaires, mise en attente, signal d appel etc. Version 4 (2000) Les caractéristiques essentielles de cette version concernent : la convergence avec les standards IETF, la qualité de service (QoS), l intégration de la gestion avec le WEB, l intégration des services WEB et enfin toute une palette de nouveaux services ou de services existants améliorés (RAS : Registration, Admission, Status ; SIG : Signalisation ; RT(C) P : Real-time Transport (Control) Protocol ; RSVP : Ressource reservation Protocol. (Assure la qualité de service au coté de H.323)). Version 5 draft (2003) Les changements majeurs de cette version : Page : 41 / 136

42 Le canal de signalisation de l'appel H demeurera ouvert pendant l'appel. La fermeture du canal de signalisation d'appel terminera l'appel. Le procédé d'arrêt d'appel était mis à jour et il y a maintenant un deuxième procédé d'arrêt d'appel. La fonctionnalité Time to Live a été augmentée pour permettre au GK d'envoyer un temps plus long de Time to Live. Ajoute une séquence de confirmation au support d'admission Inconvénients du protocole H.323 D un point de vue technique Les réseaux IP sont à commutation de paquets, les flux de données transitent en commun sur une même liaison. La visioconférence IP mise sur une disponibilité de ces liaisons. Les débits des réseaux IP doivent donc être adaptés en fonction du trafic afin d'éviter tout risque de coupure du son et de la vidéo. Tous les sites n ont pas le même débit. Plus le débit sera élevé et plus le risque de coupure sera faible. Par ailleurs, tant que la Qualité de Service n existera pas dans les réseaux IP, la fiabilité des visioconférences sur les lignes à faible débit sera basse. Interopérabilité avec les autres normes A l heure actuelle, la compatibilité entre les différentes normes de visioconférence est assez faible. La visioconférence H.323 et H.320 sont compatibles mais elles nécessitent l emploi de passerelles H.320/H.323. En ce qui concerne les différentes normes pour la visioconférence sur IP, H.323 et IP multicast ne sont, en règle générale, pas compatibles, sauf dans le cadre de VRVS qui permet un certain degré d interopérabilité, mais ne gère pas la norme T.120. Les implémentations commerciales ont des outils pour transmettre des données mais l expérience montre que ces outils sont propriétaires et non inter opérables. Comparaison avec SIP SIP est un protocole d initiation de session pour l interactivité en temps réel. Il a été développé par l IETF et s inspire du protocole HTTP alors que H.323 s inspire de la téléphonie. SIP est plus modulaire et peut fonctionner avec d autres protocoles. Page : 42 / 136

43 3.5. Des applications pour la visioconférence Vic Le logiciel Vic est un logiciel de visioconférence permettant d émettre et de recevoir de la vidéo en unicast ou en multicast en utilisant différentes normes de codage vidéo comme les normes H261, H263 ou H263+. Ce logiciel est disponible pour Windows 98, 2000 et XP ainsi que pour les systèmes d exploitation Unix/Linux. Voici un aperçu de l interface de ce logiciel : Figure 7 : Interface du logiciel Vic. La version de VIC développée par UCL (University College Of London) est une des principales versions de ce logiciel. Ce logiciel n évolue presque plus alors même qu il reste des modifications à apporter et des bogues à corriger mais UCL reste disponible pour incorporer dans leur version des modifications issues de la communauté académique. Dans les années 90 Steve McCanne, un étudiant de UCL ayant contribué au développement de VIC, est parti préparer sa thèse à l université de Berkeley en Californie et a initié le projet OpenMash visant à développer des outils de visioconférence utilisant le multicast. Ce projet a développé sa propre version de VIC en reprenant une grande partie du code de la version initiale. Les versions de VIC de UCL et de Openmash sont compatibles entre elles, c est-à-dire qu on peut organiser une visioconférence impliquant des participants utilisant la version UCL de VIC et des participants utilisant la version OpenMash de VIC. M. Konstantin Kabassanov, un chercheur du LIP6 (Laboratoire d Informatique de l université Paris 6), a porté la version UCL de VIC pour IPv6. Cette version est disponible sur son site personnel à l adresse Le manuel d utilisation de VIC, écrit dans le cadre de ce mémoire, est présent en annexe (cf. Annexe 2. Les logiciels de visioconférence). Page : 43 / 136

44 Vic GC (Grand CIF) Avant propos Un des principaux problèmes qui s est posé lors de la retransmission de présentations ou de conférences en multicast concerne l émission des transparents puisqu il n y a que peu de solutions et qu aucune de ces solutions ne s avère être pleinement satisfaisante. La première solution consiste à brancher la sortie vidéo de l ordinateur de l orateur sur un rétroprojecteur, puis de projeter l image sur un écran et enfin de filmer cet écran à l aide d une caméra branchée sur un ordinateur afin de retransmettre l image de l écran par VIC. Cette opération permet donc de faire une conversion implicite de format depuis les transparents de l orateur qui sont en plein écran, et donc adoptent la résolution de l écran de l orateur (généralement 1024x768), jusqu à la résolution maximale imposée par Vic qui est de 352x288. Comme on peut s en douter, cette solution est fastidieuse à mettre en œuvre et très coûteuse en matériel, d autant plus que le résultat à l arrivée n est pas complètement satisfaisant puisque les transparents proposent une lisibilité très moyenne. Le principal avantage de cette solution est que les auditeurs n ont pas à se préoccuper de la synchronisation des transparents avec ceux de l orateur puisqu ils reçoivent directement sur leur écran les transparents de l orateur. Sur la capture d écran suivante on peut voir le résultat d un transparent filmé sur un écran puis retransmis ensuite au format CIF: Figure 8 : Transmission d un transparent filmé sur un écran puis transmis au format CIF. Page : 44 / 136

45 Une autre solution consiste tout simplement à déposer les transparents sur un site Internet, au format HTML ou PowerPoint, de cette manière les auditeurs disposent de transparents de très bonne qualité, mais à ce moment-là le problème est que les auditeurs doivent faire euxmêmes la synchronisation de leurs transparents avec ceux de l orateur ce qui est très inconfortable et peu pratique. Une autre solution consiste à utiliser NetMeeting, mais cette solution n est envisageable que pour des visioconférences impliquant un nombre très limité de participants (pas plus d une demi-douzaine) du fait des problèmes de stabilité de NetMeeting. Une solution simple qui permet à l auditoire de ne pas avoir à gérer la synchronisation des transparents avec ceux de l orateur, mais aussi d offrir aux auditeurs des transparents de très bonne qualité est un logiciel permettant d émettre avec une résolution 4CIF. Il suffit alors de brancher la sortie vidéo de la station de l orateur sur l entrée de la carte d acquisition d un ordinateur afin d émettre avec ce logiciel les transparents en multicast. Pour ceci on peut utiliser un boîtier permettant de convertir la sortie vidéo de l ordinateur de l orateur en PAL, ceci afin de pouvoir par la suite brancher ce signal en entrée d une carte d acquisition. Figure 9 : Transmission des transparents en multicast. De cette manière les utilisateurs peuvent recevoir les transparents de l orateur directement sur leur ordinateur en utilisant le logiciel au format 4CIF. L ordinateur distant a ainsi la possibilité de projeter les transparents sur un écran permettant à une assemblée de pouvoir suivre l événement à distance. C est un vidéo projecteur virtuel dont les caractéristiques sont : un cable en Y, branché sur la prise VGA du PC de l orateur, qui alimente le vidéo projecteur local, et le convertisseur VGA-PAL dont la sortie est envoyée sur l acquisition vidéo de la station ayant le logiciel adéquat pour émettre des transparents qui via le multicast, alimente les PCs (et vidéo projecteurs) des autres salles. Page : 45 / 136

46 La solution : VIC-GC Partant d un constat simple sur l insuffisance des formats (format 4CIF spécialement) pour retransmettre de manière lisible les transparents de l orateur via VIC notamment durant les cours DIM ou les transmissions des causeries, une recherche a été menée dans ce sens par Aurélien Amacker pour mettre au point le VIC au format 4CIF : VIC-GC. La conception du logiciel VIC a pris en compte le format 4CIF, format suffisant pour la diffusion de transparents mais ne l a pas implémenté. Lorsqu on veut émettre de la vidéo avec VIC on choisit d abord le codec 12 vidéo qu on va utiliser et le format de la vidéo. Dans la version actuelle de VIC si on a sélectionné le codec H263+ on peut opter pour le format 4CIF, cependant dans ce cas, lorsqu on clique sur le bouton «transmit» afin d émettre, VIC termine immédiatement son exécution, ce bogue étant par ailleurs bien connu des utilisateurs de VIC. Ce manque a été résorbé par l ajout de cette fonctionnalité par Aurélien Amacker au cours de l année 2003 sous Linux. Une fois l implémentation terminée Aurélien Amacker a obtenu comme résultat lors de la retransmission de transparents aux formats 4CIF : Figure 10 : émetteur sous linux des transparents lors de la Causerie Renater du 9 septembre L ambition de l association Aristote était de porter l extension de cet outil aux distributions Windows afin de toucher un plus large public. 12 CoDec : Abrév. de COdeur-DÉCodeur. Appareil transformant des données numériques en analogique et vice-versa. Page : 46 / 136

47 Rat Rat est au son ce que Vic est à la vidéo, c est à dire qu il permet d envoyer et de recevoir du son en multicast ou en unicast. Pour répondre aux contraintes temps réel Rat utilise comme Vic le protocole RTP audessus d UDP. Rat a été développé par le groupe de recherche Multimédia et Réseaux de UCL tout comme Vic, mais à la différence de Vic, UCL continue le développement et le support de ce logiciel. Rat est actuellement disponible sur le site Internet de l UCL en version 4, version qui propose un son de bonne qualité avec un échantillonnage allant jusqu à 48 KHz et une compatibilité avec IPv6. Toutes ces versions sont disponibles pour Windows et Unix/Linux. Voici un aperçu de l interface de ce logiciel : Figure 11 : Interface graphique du logiciel Rat. Rat s utilise de manière similaire à VIC (se reporter à l Annexe 2. Les logiciels de visioconférence). Page : 47 / 136

48 VideoLAN VideoLAN est un projet multi plate-forme développé initialement par des étudiants de l'ecole Centrale de Paris sous licence GNU «General Public License» permettant de lire les vidéos au format Mpeg, DVD, VCD, DivX. Ce logiciel peut s'utiliser soit comme un simple lecteur, soit, en tant que logiciel de diffusion multicast, il accepte désormais IPv6. Les informations sur ce logiciel sont disponibles sur le site officiel sur le site de RENATER ou en Annexe 2. Les logiciels de visioconférence. Transmission d un flux vidéo et audio Figure 12 : Interface du logiciel VideoLAN. L atout de VideoLAN pour la diffusion de contenu, des transparents par exemple, est indéniable comparativement à VIC-GC car il permet une retransmission avec des formats de très haute qualité à haut débit (MPEG4 avec des débits de 512 kbit/s à 2 Mbit/s). Cet avantage sera mis à profit lors des cours DIM, des séminaires Aristote de l année scolaire pour la retransmission des transparents en remplacement de VIC-GC. Le schéma est identique à celui de la Figure 9 : Transmission des transparents en multicast., les stations d émission et de réception étant équipé du logiciel VideoLAN. Ce schéma est couplé avec un système de visioconférence VIC RAT pour l interaction entre l orateur et les auditeurs des différents sites. Page : 48 / 136

49 Isabel L applicatif de visioconférence ISABEL, développé au DIT-UPM de Madrid est commercialisé par la société AGORA ( Fonctionnant sous Linux et ne nécessitant qu une Webcam, l installation en est relativement aisée car «packagée» avec une distribution Linux Suse. Ce système de visioconférence est complet, il permet une collaboration multipoint aisée car il ne nécessite pas l utilisation d un environnement multi logiciels (VIC + RAT + VideoLAN + ) basé sur TCP-UDP en mode multicast ou non, et acceptant IPv6. Différents mode d interaction sont disponibles : un mode de travail, un mode débat, un mode vidéo, un mode présentation et enfin un mode questions. Figure 13 : Exemples des modes d interactions sous Isabel. Une régie se charge de gérer la disposition des orateurs, des auditeurs, des transparents ou autres éléments affichés sur l écran de visualisation. Ce logiciel permet aux différents auditeurs d interagir. La possibilité est donnée de visualiser de manière passive sur un navigateur Web la conférence en direct, cette disposition ne nécessite pas l installation du logiciel Isabel. Page : 49 / 136

50 Passerelle IPv4 - IPv6 La passerelle IPv4 multicast IPv6 multicast s inscrit parmi les mécanismes de transition de IPv4 vers IPv6 puisqu elle permet au monde multicast IPv4 et au monde multicast IPv6 d interopérer. Son mécanisme est le suivant : on lance la passerelle avec les adresses d un groupe multicast IPv4 et d un groupe multicast IPv6. La passerelle s abonne alors au groupe multicast IPv4 et réémet toutes les données qu elle reçoit en provenance de ce groupe à destination de l adresse du groupe IPv6 multicast. Inversement, toutes les données qu elle reçoit du groupe multicast IPv6 sont réémises à destination du groupe multicast IPv4. Ceci permet donc aux membres du groupe multicast IPv4 de recevoir les données provenant du groupe multicast IPv6 et de pouvoir émettre à destination de ce groupe et donc inversement de permettre aux membres du groupe multicast IPv6 de recevoir les données provenant du groupe multicast IPv4 et de pouvoir émettre à destination de ce groupe. On pourra citer comme exemple concret les cours DIM dont les participants IPv6 (les personnes présentes à ESMT Dakar d une part) dialoguent avec les autres participants IPv4 (le DESS ART d autre part). Le résultat escompté : Notez dans l applicatif vidéo (VIC), fonctionnant ici sur un PC Windows XP en IPv4, la coexistence de communication avec le monde IPv4 et le monde IPv6 grâce à la passerelle multicast IPv4 multicast IPv6! Page : 50 / 136

51 4. Mises en œuvre 4.1. Etude et déploiement de systèmes de visioconférence Mise en œuvre d une passerelle IPv4 multicast - IPv6 multicast Etude Avant propos et état de l art Les tests de la passerelle IPv4 multicast IPv6 multicast de Konstantin Kabassanov à travers différents scénarios : 1. La bande passante en fonction des critères propre à la diffusion temps réel (gigue, ) 2. Le passerellage multiple en fonction des critères propre à la diffusion temps réel (gigue, ) Des comparaisons avec la passerelle de Luc Beurton mise en production courant de l année 2002 au sein de Renater seront également apportées, en effet on dispose actuellement d un instantanée de cette dernière qui contient plus d outils que celle de Konstantin Kabassanov (les annonces SAP, la détection de boucles). En revanche cet instantané souffre de disfonctionnement, l implémentation ne permet pas un traitement continu de l ensemble des paquets en transition. Ceci est d autant plus flagrant lors de visioconférence à haut débit (supérieur à 500 kbit/s) via le logiciel VideoLAN par exemple mais néanmoins raisonnable pour des utilisations avec les débits cumulés des logiciels VIC et RAT qui n excède pas la valeur critique. Voyons maintenant la méthodologie mise en œuvre dans les différents tests. Méthodologie des tests Pour chaque scénario décrit précédemment, les tests suivants ont été effectués : Pourcentage de paquets perdus : c est en effet un paramètre important mais une perte non significative de paquets ne signifie pas une mauvaise qualité de retransmission de la part de la passerelle. Des pertes inférieures à 0,5% ne sont pas visuellement dérangeantes avec des logiciels de visioconférence tel VIC, VidéoLAN pour la vidéo ou RAT pour l audio. On peut remarquer aussi que ce pourcentage correspond en grande partie aux paquets non traités par la passerelle mais un facteur perte de paquets réseau peut intervenir pour les tests sur les débits élevés. Pourcentage de CPU peut devenir un facteur prépondérant de la perte de paquets si le processeur n arrive plus à répondre aux besoins d un ou plusieurs passerellages. La gigue (JITTER) ou variation de bout en bout est le facteur d une bonne réception des applications temps réels, elle ne doit pas dépasser quelques dizaines de millisecondes sans quoi la retransmission n est plus en temps réel. Page : 51 / 136

52 Matériel/Logiciels Ces tests ont été effectués sur trois machines. La passerelle est un celeron 466 Mhz et 128 Mo de Ram tournant sous debian L émetteur de un ou plusieurs flux est un Pentium 4 2,8 Ghz et 512 Mo de Ram et le récepteur un Pentium Mhz et 256 Mo de Ram. Au niveau réseau, ces deux machines sont interconnectées sur un réseau Ethernet 100Mbit dédié à ces tests. Le logiciel IPerf, déjà utilisé pour une étude de la passerelle de Luc Beurton a servi d émetteur de flux multicast IPv4 et récepteur de flux multicast IPv6. C est un logiciel en ligne de commande ayant deux fonctionnalités : o Serveur : iperf -s -u -B ff01::7:9 -V -i 100 il tourne en tâche de fond et attends la réception des paquets les options u B pour le fonctionnement en mode multicast, l option -V pour désigner une adresse IPv6 et l option i 100 pour afficher le résultat au bout de 100 secondes Server listening on UDP port 5001 Binding to local address :: Receiving 1470 byte datagrams UDP buffer size: 8.00 KByte (default) [1968] local :: port 5001 connected with 2001:660:3001:4014:2c0:4fff:fe07:417d port 1035 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [1968] sec 1.39 MBytes 3.01 Mbits/sec0.682 ms 0/ 993 (0%) o Client : iperf -c u -T 1 -t 100 -i 1 -b 30m il émet le flux, ici au rythme de 30 Mbit/secondes (option -b 30m) pendant 100 secondes (option -t 100) avec un TTL de 1 et en affichant toutes les secondes le débit (-i 1) Client connecting to , UDP port 5001 Sending 1470 byte datagrams Setting multicast TTL to 1 UDP buffer size: 8.00 KByte (default) [1848] local port 1541 connected with port 5001 [ ID] Interval Transfer Bandwidth [1848] sec 363 KBytes 2.98 Mbits/sec [1848] sec 368 KBytes 3.01 Mbits/sec [1848] sec 366 KBytes 3.00 Mbits/sec [1848] sec 1.39 MBytes 3.00 Mbits/sec Les résultats suivant ne sont valables que dans le cadre de la configuration listée cidessus. Les tests ont été effectués avec des moyens suffisants pour des débits supérieurs à 45 Mbit/s ou un test de 4 passerelles simultanées avec un débit total sur ces dernières de 10 Mbit/s soit 2,5 Mbit/s chacune ce qui correspond au paroxysme de l utilisation finale de la passerelle. Page : 52 / 136

53 Résultats % Paquets perdus / Bande Passante % 0,2 0,15 0,1 0, Mbit/s % Paquets perdus Résumé : le nombre de paquets perdus augmente avec le débit tout en restant très faible 0,2% pour un débit de 45 Mbit/s! Cette perte est qualifiée de faible pour des applications temps réels (visioconférence, diffusion). % Maximum de CPU utilisé / Bande passante 80 % % Maximum de CPU utilisé Mbit/s Résumé : on constate une occupation CPU proportionnelle au débit infligé à la passerelle. 15% pour 10 Mbit/s, 30% pour 20 Mbit/s etc. soit une augmentation de 15% d occupation par palier de 10 Mbit/s supplémentaires. A 45 Mbit/s le taux d occupation de la passerelle est très important 65% mais cet ordinateur sera destiné à un usage exclusif de la passerelle et atteindra rarement les 45 Mbit/s. Cette solution reste viable, il faut tout de même constater que sur les tests de la passerelle de Luc Beurton, ce taux était beaucoup moins important. Gigue / Bande passante ms 1,2 1 0,8 0,6 0,4 0, Mbit/s Gigue Résumé : comme décrit précédemment la gigue est un facteur important pour les application temps réel, il ne faut pas dépasser un temps aller-retour de 300 ms soit 150 ms or il ici la passerelle ne rajoute quasiment aucun temps de latence. Donc cette passerelle satisfait cette condition. Page : 53 / 136

54 La première partie des tests s intéresse à l influence de la bande passante sur des paramètres faisant fluctuer une qualité de réception. Dans la partie qui suit, ce n est plus la bande passante qui nous intéresse mais le nombre de passerelle traitant en simultanée des flux différents. Le débit global sera fixe à 10 Mbit/s à partager entre les différentes passerelles (1 passerelle à 10 Mbit/s, 2 passerelles à 5Mbit/s chacune, etc.). % Paquets perdus / Nombre de passerelles % 1 0,8 0,6 0,4 0, Nombre de passerelles % Paquets perdus Résumé : peu de choses visibles sur ce graphique en effet quelque soit le nombre de passerelles pour un débit total de 10 Mbit/s on observe aucune perte de paquets. On peut en déduire que la perte est induite par le débit total que doit traiter la passerelle et que le nombre de passerelles ne s avère pas un facteur aggravant. % Maximum de CPU utisé / Nombre de passerelles % Nombre de passerelles % Maximum de CPU utilisé Résumé : le pourcentage de CPU s avère constant, encore une fois on ne trouve pas de dépendance entre le nombre de passerelles et un facteur aggravant pour la qualité de réception. Gigue / Nombre de passerelles ms 1 0,8 0,6 0,4 0, Nombre de passerelles Gigue Résumé : la gigue n a pas de variation significative en fonction du nombre de passerelles. Page : 54 / 136

55 Conclusion Qu est ce que tout cela signifie? Et bien simplement que la passerelle IPv4 multicast IPv6 multicast de Konstantin Kabassanov s avère être un outil performant pour la retransmission d une ou plusieurs visioconférences et la diffusion de contenus à hauts débits. Quand à la passerelle de Luc Beurton, elle s avère plus intéressante au niveau des options, si nous avions la possibilité d obtenir une version optimisée, elle serait plus avantageuse. Une autre passerelle dynamique pourrait servir de challenger, à voir (et à tester) Télécharger les logiciels utilisés (sources, binaires, ) La passerelle de Konstantin sur son site : Le logiciel IPerf : Réalisation En réponse à l étude théorique faite précédemment qui valide la passerelle de Konstantin Kabassanov, il a fallu mettre en production cette dernière. Passer d une passerelle de tests à une passerelle de production consiste à filtrer le nombre d applications tournant sur la machine terminale, obéir à des règles de sécurité stricte en terme d accessibilité. Et pour terminer la phase d exploitation pilote, la placer dans son environnement de production. L accès s effectue à distance via le protocole ssh en mode utilisateur ou via le port console. Page : 55 / 136

56 Développement des fonctionnalités des outils de visioconférence pour le téléenseignement interactif Fonctionnement interne de VIC Les langages de programmation Vic est un logiciel écrit en Tcl/Tk 13 pour ce qui concerne la partie interface utilisateur et en C++ pour ce qui concerne la partie traitement de l information. Pour des questions de portabilité la version de Tcl/Tk utilisée par VIC est une version fournie par UCL. Le code source Le code source du logiciel Vic se décompose en quatre répertoires : common : librairie développée par UCL et qui fournit notamment des fonctions réseau de bas niveau tcl-8.0 : il contient les sources de l interpréteur Tcl 14 fourni avec Vic tk-8.0 : il contient les sources de la librairie graphique Tk. vic : il contient les sources des fichiers Tcl et C++ qui composent le coeur du logiciel VIC. Pour apporter des modifications au logiciel VIC, il suffit la plupart du temps de modifier les fichiers sources contenus dans le répertoire vic, voici les principaux éléments de ce répertoire. o Le fichier main.cpp constitue le fichier principal du programme vic car c est celui qui contient la fonction main() qui est la première fonction appelée lors de l exécution de Vic. o Le répertoire codec/ contient les encodeurs et les décodeurs vidéo, les principaux formats de compression utilisés par Vic étant les formats h261, h263 et h263+. o Le répertoire tcl/ contient tous les scripts tcl qui sont appelés par le programme Vic. o Le répertoire net/ contient les fonctions réseaux de bas niveau permettant d envoyer et de recevoir des paquets IPv4 ou IPv6 en multicast ou en unicast. o Le répertoire rtp/ contient les fichiers source nécessaires quant à l utilisation du protocole de transport RTP, ainsi que les définitions de différentes structures de données utilisées lors de la transmission de la vidéo. o Enfin le répertoire video/ contient les définitions de structures de données permettant de réaliser les captures d images sur le périphérique vidéo. 13 Tcl est un langage de scripts tandis que Tk (Tool Kit, boite à outils) est une librairie graphique. Dans des programmes Tcl/Tk, les scripts Tcl appellent des widgets Tk (des composants graphiques) ce qui permet de créer rapidement des applications disposant d interface graphique. 14 Un interpréteur est un logiciel qui lit un script et qui exécute les instructions de ce script, ainsi tout script nécessite un interpréteur pour s exécuter. Page : 56 / 136

57 Interaction avec la norme H323+ Le schéma suivant décrit le fonctionnement de VIC pour la norme H263+. Lorsqu on veut émettre de la vidéo en utilisant Vic (en fait lorsqu on clique sur le bouton Transmit et qu un appel a la fonction transmit définie dans le fichier tcl/ui-ctrlmenu.tcl est réalisé), un objet hérité de la classe Grabber est créé (to grab = capturer en anglais) et cet objet va capturer des images avec une fréquence fonction du nombre d images par seconde que l utilisateur a indiqué dans l interface utilisateur. Ces objets héritant de la classe Grabber sont spécialisés en fonction du système d exploitation et du périphérique utilisé. Par exemple sous Windows l objet hérité de la classe Grabber sera un objet de type VfwGrabber (Vfw pour Video For Windows, l API de capture d images sous Windows) défini dans le fichier video/grabber-win32.cpp tandis que sous Linux en utilisant une carte d acquisition et une caméra on utilisera un objet grabber de type V4lGrabber (V4l pour Video4Linux, l API de capture d images sous Linux) défini dans le fichier video/grabber-video4linux.cpp. Le fichier codec/encoder-h263v2.cpp implémente l encodeur H263+. Ce fichier contient la fonction H263plusEncoder ::size(int w,inth), qui réalise un test pour déterminer le format de la vidéo à encoder. Le fichier codec/decoder-h263v2.cpp implémente le décodeur H263+. Lorsqu un paquet est reçu, la zone du paquet contenant les données propres à la partie de l image transmise est copiée à la suite des données déjà contenues dans la variable bitstream, un tableau de caractères. Quand on a reçu tous les paquets contenant chacun une partie de la même image on copie le contenu de la variable bitstream (qui contient donc à ce moment-là une image entière) dans la variable xxx_frame, puis l image nouvellement reçue est utilisée pour rafraîchir la fenêtre. Page : 57 / 136

58 VIC CG - haute résolution (4CIF) Etude Le patch pour un environnement Linux (X-windows) augmentant la capture à une largeur de 704*576 consiste à modifier le fichier vic/video/grabber-x11.cpp en deux endroits. int X11Grabber::X11Grab_TrueXBGR24() { int x, y; uint8 *yp= (uint8 *)frame_ ; uint8 *up= (uint8 *)yp + framesize_ ; uint8 *vp= up + (framesize_ >> 2) ; uint16 p0, p1 ; uint32 d ; vic/video/grabber-x11.cpp #define CDy(d) (((d<<8)&0xf800) ((d>>5)&0x7e0) ((d>>19)&0x1f)) #define XGP(px,py) XGetPixel(ximage_->image,px,py) #define XAV(m,px,py) ((((XGP(2*px,2*py)&m)+(XGP(2*px+1,2*py)&m)+(XGP(2*px,2*py+1)&m)+(XGP(2*px+1,2*py+1)&m))/4)&m) #define XMEAN(px,py) (XAV(0xff0000,px,py) XAV(0xff00,px,py) XAV(0xff,px,py)) int factor=2; for (y=0; y<height_; y++) { for (x=0; x<width_; x+=2) { p0 = CDy(XMEAN(zx,y)); *yp++ = rgb2y_[ p0 ]; p1 = CDy(XMEAN(x+1,y)); *yp++ = rgb2y_[ p1 ]; p0 = ( (p0 >> 1) & 0x7bef ) + ( (p1 >> 1) & 0x7bef ) ; *up++ = rgb2u_[ p0 ]; } y++; for (x=0; x<width_; x+=2) { p0 = CDy(XMEAN(x,y)); *yp++ = rgb2y_[ p0 ]; p1 = CDy(XMEAN(x+1,y)); *yp++ = rgb2y_[ p1 ]; } } } return 1; p0 = ( (p0 >> 1) & 0x7bef ) + ( (p1 >> 1) & 0x7bef ) ; *vp++ = rgb2v_[ p0 ]; Le patch nécessite de modifier aussi l appel à VidUtil_AllocXImage pour doubler la dimension de l image. vic/video/grabber-x11.cpp ximage_ = VidUtil_AllocXImage(dpy_, root_vis, root_depth_, w*2, h*2, False); Après avoir modifié les fichiers de capture, il faut maintenant activer le format 4CIF sur l encoder H263+. Il faut appliquer le patch suivant au fichier vic/codec/encoder-h263v2.cpp à la fonction H263plusEncoder::size pour ajouter comme nouvelle option le format 4CIF. } else if (w == 2*CIF_WIDTH && h == 2*CIF_HEIGHT) { state->pic->source_format = 4; vic/ codec/encoder-h263v2.cpp Page : 58 / 136

59 De plus, il faut augmenter la variable bitstream dans ce même fichier. h263_bitstream = (char*)malloc(65536*4); vic/ codec/encoder-h263v2.cpp Bien que suffisante pour Linux, cette solution n est pas satisfaisante dans un environnement Windows. Réalisation Pour réaliser un VIGC complet (Windows + Linux), la solution ci-dessus pour Linux doit être transposée dans les fichiers concernant l environnement Windows. Par exemple, un patch similaire à celui du fichier grabber-x11.cpp doit être appliqué au fichier grabber.cpp. La deuxième partie pour activer le format 4CIF dans l encodeur H323+ est similaire à celle pour Linux. Mais l augmentation de la variable bitstream provoque sous Windows une interruption de l application pour avoir écrit dans une zone mémoire protégée. Il s agit donc d une mauvaise gestion de la mémoire par l application VIC. Il a donc fallu modifier en conséquence le fichier de gestion des variables, celui utilisé par le tableau de caractères bitstream. Tests L émission en format 4CIF nécessite une carte d acquisition : pour la réalisation et les tests la carte Osprey 210 a été utilisée. Figure 14 : Le résultat, la transmission d un transparent au format 4CIF valide le logiciel VIC-GC La solution sous Windows a été utilisée notamment pour les environnements Aristote séminaires et conférences ainsi que pour les cours DIM durant l année Et le support technique a été assuré par mail et téléphone à toute personne l utilisant. Pour certaines applications dont la diffusion de contenu, il semble que VideoLAN soit une solution alternative intéressante. Page : 59 / 136

60 Participation de Renater au «Workshop d Isabel» du 26 mai Présentation La société AGORA organise régulièrement des «Worshop» pour promouvoir le logiciel Isabel. Elle a convié le GIP RENATER a participer à celui du 26 mai 2004, elle prête une assistance technique en anglais au personnes voulant installer ce logiciel par le biais de messageries instantanées ou par visioconférence comme ce fut le cas lors de la mise en place de la station de tests hébergée à RENATER Utilisation L installation du système «packagé» (une distribution Suse modifiée) d Isabel s est avéré ardue malgré la mise à disposition d un ordinateur puissant (dont voici les caractéristiques techniques : DELL GX270 - Pentium 4 avec une fréquence de 2,7Ghz et 256 Mo de mémoire vive), les problèmes suivants ont du être traités : Le périphérique vidéo non détecté, provenant d un conflit avec une mise à jour trop récente du BIOS, résolu par l ajout d une nouvelle carte graphique Le périphérique audio non détectée, résolu par l installation de pilotes audio ad hoc La caméra haute définition couplé à une carte d acquisition n a pas fonctionné, malgré plusieurs jours de tests avec le support technique d Isabel. Une Webcam (caractéristiques techniques : Logitech QuickCam Pro 3000) détectée par la distribution Suse, a finalement été utilisée. Ces problèmes se sont avérés être déjà un premier test avant la participation au «Workshop» puisqu il a fallu en effet utiliser le logiciel Isabel d une manière interactive : une visioconférence en Anglais pour le support technique. Jérôme Durand fut l un des participants du «Worshop» du 26 mai. Les captures suivantes ont été réalisées à partir d un poste visualisant la conférence de manière passive sur Internet sans avoir à installer le logiciel Isabel. Figure 15 : Participation au «WorkShop» d Isabel (à droite Jérôme Durand dialoguant avec l animateur) Page : 60 / 136

61 Figure 16 : Participation au «WorkShop» d Isabel (Démonstration des différents modes, explications du logiciel) Bilan Les avantages du logiciel ISABEL sont les suivant : Le fonctionnement en IPv4 et en IPv6 Le système «packagé» avec une distribution Linux Suse qui facilite l installation Le système de régie pour une mise en place plus rapide des visioconférences et la certitude que tous les auditeurs visualisent un affichage identique Le nombre d outils disponibles : les différents modes de communication, l affichage des transparents et leur modification (soulignement) d une manière identique à un tableau blanc, La qualité d affichage des vidéos et des transparents Le fonctionnement transparent d un point de vue utilisateur, une fois le système installé Les points négatifs du logiciel ISABEL découlent parfois des avantages : L installation d une Linux Suse, si certains pilotes de périphériques ne sont pas reconnus peut s avérer ardu (cf. l expérience menée au sein du GIP RENATER avec les problèmes des pilotes audio puis vidéo) De plus une distribution Linux peut s avérer un frein à la mise en place de ce système (cf. la sollicitation des usagers de VIC-GC pour une adaptation sous un environnement Windows) La formation des personnes à ISABEL même si l environnement est intuitif, et la formation et la mobilisation lors des visioconférences d une personne pour la régie ISABEL requière un poste de visioconférence dédié car il nécessite un processeur puissant ; de plus, la configuration matérielle est relativement figée Une inconnue de taille : le futur prix des licences d exploitation comparativement aux logiciels gratuits déjà utilisés (VIC, RAT, VideoLAN, ) Le test de ce logiciel s inscrit dans l évaluation des modes de visioconférence pour une vision étendue de ce type de système dans l attente d un futur déploiement ou non. Page : 61 / 136

62 4.2. La plate-forme de démonstration IPv6 du GN Elaboration du design Réseau La section qui va suivre concerne le travail fait en amont de la construction physique et logicielle de la plate-forme de démonstration IPv6. Ce travail d approche commence bien sûr par la définition du projet : la plate-forme de démonstration IPv6 du GN6 ou le «show room» IPv6 du GN Définition du projet Avant toute chose, il faut rappeler les buts de ce projet pour définir le travail à effectuer, soit le déploiement d une plate-forme de démonstration de services de visioconférence sur Internet basée sur IPv4/IPv6, H323 et SIP pouvant interconnecter différents sites dont Renater dans le but de développer les services multimédia de la nouvelle génération pour promouvoir les activités de recherche, de téléenseignements et de télétravail. De manière plus globale l obtention d une vitrine technologique IPv6. Toute technologie IPv6 doit être portable sur cette plate-forme et une documentation avec un niveau de détails importants doit être fournie (fichiers de configuration et commentaires). Dans le cadre d un possible besoin de transition du protocole IPv4 vers IPv6, il sera nécessaire d inclure deux zones de tests, une seulement IPv6 et une autre double pile IPv4 et IPv6. La contrainte sur ce projet est son temps de réalisation dont le recensement des technologies IPv6 qui font émergence et la mise à disposition de ressources. Ces dernières sont de deux ordres matériels et logiciels. Le projet n a pas de durée déterminée, il s enrichira au cours du temps. Page : 62 / 136

63 Collecte d information Cette phase consiste à collecter des informations nécessaires à une compréhension de l existant et des contraintes de l environnement. Pour se faire, il faut répondre aux questions suivantes : Quels sont les besoins du show room en termes performance et applicatifs? Les applications devront être compatibles IPv6, des applications de visioconférence et de téléphonie ont été demandées. Quelle est l infrastructure existante? L infrastructure utilisée : le réseau IPv6 multicast M6Bone déjà existant, une délégation de la part du serveur de nom du GN6 et la connexion à un routeur de Renater. Quels sont les problèmes sur le réseau actuel? Aucun, si ce n est la possibilité d obtenir rapidement des ressources pour faire des tests, ce que doit pallier la plate-forme. Quel est le niveau de compétence des personnes actuelles? Les personnes sont en formation permanente sur le sujet Quelles sont les personnes de contact? Le premier contact pour l élaboration de cette plate-forme a été Nael Hammameh qui a collaboré à la plate-forme de démonstration des Jres 2003 Quelles sont les prévisions au sein de l entreprise (nombre, lieu, sites)? Prévision à la fin de notre stage 3 sites interconnectés : GIP Renater, Artemis et enfin Inres. Quels sont les protocoles «réseau» utilisés? IPv6 multicast / IPv6 unicast Quel est le niveau de disponibilité demandé? La plate-forme sera devra (?) être disponible tout le temps. Quels sont les besoins en terme de mobilité, de sécurité et de gestion du réseau? Une sécurisation de la plate-forme sera de mise (Pare feux, Filtrage IPv6 IPv4, IPsec), l intégration d une partie Administration de la plate-forme sera une des contraintes de la mise en place d outils compatibles IPv6. Quels sont les besoins en terme d intégration voix/vidéo? Point névralgique de la deuxième étude sur la plate-forme : la visioconférence IPv6 H323, SIP ou encore le multicast. Page : 63 / 136

64 Proposition d une topologie réseau IPv Premier pas Après la collecte des informations, une analyse de celles-ci permet de mieux comprendre les besoins et contraintes de l environnement. Cette phase permet d élaborer les besoins réseaux et de développer l architecture réseau. On pourra citer comme exemple le fait que la plate-forme devra être composée de deux parties distinctes : une «seulement IPv6» et une «double pile IPv4 et IPv6» impliquant la mise en place d un routeur, jonction de ces deux parties (deux interfaces une IPv4/IPv6 et une IPv6). Pour chacune des parties du réseau : Pour la plate-forme en local (notre première étape), une mise en production d un routeur de jonction (Zebra) entre les deux parties suivantes «seulement IPv6» et «double pile IPv4 et IPv6» avec les protocoles de routage adéquats (multicast PIM6, routage statique). Mise en place d un serveur de nom maître des zones de la plateforme. Au niveau WAN (notre deuxième étape), raccordement au réseau de Renater avec la mise en place d un routeur compatible IPv6, l équipement 6wind 6100 avec les protocoles de routage adéquats (multicast avec MBGP, routage RIPng, ), raccordement au M6Bone (le 6wind assurant la fonction de tunnel et de routeur multicast). Délégation du serveur de nom avec celui de Renater. Les sites distants sont identifiés, pour commencer Renater, Artemis et enfin INRETS. La jonction s effectuera dans un premier temps par le raccordement des différentes plate-formes avec le réseau Renater. L architecture de routage est inhérente aux besoins des applications, les principaux protocoles de routage ont été cités dans les parties précédentes. Le plan d adressage IPv4 comme IPv6 sera inhérent aux besoins de la plate-forme (on parle toujours des deux zones distinctes) et surtout des contraintes extérieures sur les adresses IP (conserver une cohérence dans le préfixe réseau des adresses IPv6 avec celles de Renater par exemple). Le niveau sécurité point névralgique d un projet réseau ne sera abordé que localement (pas d accès extérieurs en mode super utilisateur aux différentes machines, des fichiers de configuration des applications adaptés BIND, Apache, ). Ce manque de politique sécuritaire devra être pallié par la poursuite et l extension de la plate-forme via les successeurs. La gestion du réseau quant à elle s effectuera par l adjonction d outils compatibles IPv6 (MRTG), elle rentrera par ce fait parmi les sections ajout de services applicatifs. Page : 64 / 136

65 Choix des distributions et activation de la pile IPv6 Etude Le choix de FreeBSD comme système d exploitation pour la station Zebra s explique, outre sa gratuité, par les fonctions de bases disponibles en IPv6 (les outils comme ping, traceroute, telnet, ssh) et des services comme serveur de nom (Bind), routeur (Zebra) et serveur de messagerie. FreeBSD est un système Unix fonctionnant sur PC compatible. Le choix pour le serveur d applications s est porté sur un système Linux répandu, gratuit intégrant IPv6 (RedHat 9.0), pour une compatibilité accrue avec les nouveaux logiciels naissants dans le domaine de la visioconférence IPv6. Pour conserver le système d exploitation d origine sur les stations mises à la disposition de la plate-forme (Windows XP), un système de démarrage double (Windows / Unix) a été installé. On dispose ainsi de systèmes Linux et Windows sur les machines de tests. Réalisation Cette partie ne traite pas de l installation proprement dite des distributions mais de l activation du protocole IPv6 en fonction des distributions. FreeBSD 5.2 Activer la pile IPv6 consiste à configurer les fichiers de démarrage de FreeBSD. Cette étape est effectuée par l intermédiaire d une ligne dans le fichier rc.conf : ipv6_enable="yes" (cf Annexe 3. Le routage). Initialisé par l installeur sysinstall ou modifié manuellement, le fichier rc.conf permet entre autre de décrire le nom de l hôte local, la configuration des interfaces potentielles et des services à lancer. RedHat 9.0 La pile IPv6 est activée sur demande à l installation de la distribution, elle peut aussi être lancée ultérieurement en tant que module indépendant par la commande : modprobe ipv6. Windows XP La pile IPv6 est livrée en standard dans Windows XP, pour l installer il convient de lancer la commande ipv6 install en tant que qu administrateur. On dispose ainsi des outils ping6 (équivalent de ping pour le protocole IPv4), tracert6 (équivalent de tracert), ipv6 if (pour afficher les informations concernant l état des interfaces, et les informations de routage),... A noter la présence d un système de désinstallation : ipv6 uninstall. Page : 65 / 136

66 Architecture L architecture qui va suivre a été approuvée. La topologie est la suivante : Cinq équipements sont actuellement disponibles sur la plate-forme : le routeur d entrée o caractéristiques techniques : 6wind OS version 6.6.1b5 o Protocoles de routage utilisés : MBGP RIPng l équipement à la fois routeur jonction des zone IPv4/IPv6 et zone IPv6 et à la fois serveur de nom o caractéristiques techniques : physique : DELL OptiPlex GX1, Pentium 3 450, 128 Mo de ram, deux cartes réseau 100 Mbit/s, disque dur 40Go système d exploitation : FreeBSD version routage (deux interfaces) : Zebra version 0.94 / PIM6sd serveur de nom : BIND version o protocoles de routage utilisés PIM6 RIPng statique Page : 66 / 136

67 le serveur applicatif o caractéristiques techniques : physique : DELL OptiPlex GX110, Pentium 3 800, 256 Mo de ram, carte réseau 100 Mbit/s, disque dur 40Go système d exploitation : RedHat 9.0 (double démarrage avec Windows XP mais aucune fonctionnalité installée sur ce système d exploitation) o applicatifs serveur Web Apache (plus site Intranet de le plate-forme) logiciels de visioconférence (multicast, H323, SIP) logiciels de gestion de réseau (MRTG, beacon) client seulement IPv6 o caractéristiques techniques : physique : DELL OptiPlex GX110, Pentium 3 800, 256 Mo de ram, carte réseau 100 Mbit/s, disque dur 40Go système d exploitation : Windows XP (double démarrage) système d exploitation : RedHat 9.0 (double démarrage) le commutateur (switch) pour connecter les périphériques à la zone IPv4/IPv6 (routeur d entrée, routeur d échange entre zone IPv4/IPv6 et zone IPv6, serveur d application), cinq ports restent disponible. o caractéristiques techniques 3com 8 ports 10/100 Mbit/s Le plan d adressage est le suivant : Page : 67 / 136

68 Routage La réalisation de l architecture décrite précédemment comporte deux étapes : 1. Paramétrage du routage interne à la plate-forme. 2. Paramétrage du routage pour acheminer vers l extérieur. Etude Configuration du routage interne avec Zebra Zebra est un logiciel gratuit qui présente l avantage d offrir une interface similaire à celle d un routeur Cisco. Zebra est téléchargeable sur et fonctionne de la manière suivante : un démon est lancé pour chaque protocole de routage. Il y a donc un démon ripng, un démon bgp, etc. et un démon zebra supervise les autres démons. Interface Adressage IPv4 Adressage IPv6 xl0 sur routegn / :660:3001:7801::53/64 xl1 sur routegn6-2001:660:3001:7802::53/64 Les fonctionnalités nécessaires sont : 1. IPv6 pour les interfaces ethernet : pour dialoguer de manière native en IPv6 2. IPv4 pour l interface ethernet de la zone IPv4 et IPv6 3. Autoconfiguration IPv6 de la zone uniquement IPv6 avec pour préfixe 2001:660:3001:7802::/64 (cf. Auto configuration des stations) 4. Routage RIPng : pour pouvoir récupérer les annonces de route IPv6 5. La mise en place d un DHCPv4 sur la zone double pile pour pouvoir simplifier la mise en place de nouvelles stations de tests Réalisation Le routeur Zebra appelé dans le cadre de la plate-forme routegn6 est la jonction entre la zone seulement IPv6 et la zone IPv4 / IPv6 (cf ). Il est ainsi en possession de deux cartes réseaux avec au moins une interface chacune : une pour l adressage IPv4 et IPv6 et une pour l adressage IPv6. Ce routeur gère uniquement l autoconfiguration des stations du côté de la zone IPv6, l autre zone étant géré par le 6wind. L installation ressort de la procédure classique (configure, make, make install) de l applicatif zebra 0.94 qui supporte IPv6. Remarque : il existe un équivalent de Zebra, nommé Quagga dont un des intérêts est qu'il reprend le flambeau alors que le développement de Zebra semble être, sinon arrêté, au moins essoufflé. La dernière version de Zebra datant de juillet 2002, celle de Quagga de août L installation de la version de Quagga sur la distribution FreeBSD 5.2 n a pas fonctionné, le choix s est donc porté sur l applicatif Zebra plus stable au moment des tests. Page : 68 / 136

69 Le fichier de configuration du DHCPv4 est présenté succinctement en annexe. Il existe deux manières pour configurer le routeur : - si le démon est déjà lancé, en accédant en local sur le port correspondant : telnet localhost 2601 (port 2601 pour zebra, 2603 pour ripng, etc.). - ou en modifiant directement les fichiers configuration zebra.conf ou ripngd.conf avec un éditeur (vi par exemple). Différentes étapes se succèdent pour faire fonctionner le routeur routegn6, les fichiers concernés et les commandes utilisées sont fournis en Annexe 3. Le routage 1. Activer IPv6 sur routegn6 (cf ). 2. Activer le routage IPv6 sur routegn6. Cette étape consiste à configurer les fichiers de démarrage de FreeBSD, il s agit d initialiser la machine comme étant un routeur IPv6. L activation s effectue par l intermédiaire du fichier rc.conf : ipv6_gateway_enable="yes". 3. Quand une machine est configurée comme routeur, elle ne fait plus l'auto configuration sur ses interfaces il est donc nécessaire de donner manuellement une adresse IPv6. Voici un extrait du résultat obtenu : /usr/local /etc/zebra.conf interface xl0 ip address /28 ipv6 address 2001:660:3001:7801::53/64 interface xl1 ipv6 address 2001:660:3001:7802::53/64 4. Si le routeur fait office de routeur unicast, envoyer des paquets "Router Advertisements" sur l'interface du site pour que les machines s'auto configurent avec le préfixe annoncé. Spécifier les interfaces sur lesquelles ont veut annoncer le préfixe. On obtient ainsi : /usr/local/etc/zebra.conf interface xl0 ipv6 nd suppress-ra! interface xl1 no ipv6 nd suppress-ra ipv6 nd prefix-advertisement 2001:660:3001:7802::/ onlink autoconfig # ripngd d # zebra -d 5. Pour terminer, lancer les démons concernés. Rappels : vous trouverez en annexe les fichiers de configuration rc.conf, ripngd.conf et zebra.conf (cf. Annexe 3. Le routage). Page : 69 / 136

70 Configuration du routeur 6wind Etude La société 6wind est une entreprise française spécialisée dans la construction de routeurs d accès IPv6. La procédure de configuration IPv6 se trouve dans les documents «CommandReference-version6.3.pdf» et «Configuration Guide 6WINDGate - version 6.6.pdf». Pour correctement configurer le routeur, il faut analyser le schéma de la topologie de la plate-forme (cf ) pour préparer la séquence de commandes. Le routeur IPv6 est la jonction entre la plateforme, plus précisément la zone IPv4/IPv6 et l extérieur. Il est ainsi en possession de deux interfaces physiques, l une câblé vers «l extérieur» et l autre vers le commutateur de la zone IPv4/IPv6. Ce routeur gère l autoconfiguration des stations sur la zone IPv4/IPv6. Interface Adressage IPv4 Adressage IPv6 eth0_0 sur 6wind / :660:3001:6321:2::2/64 eth1_1 sur 6wind / :660:3001:7801::1/64 Les fonctionnalités nécessaires sont : 1. IPv6 pour les interfaces ethernet : pour dialoguer de manière native en IPv6 2. IPv4 pour les interfaces ethernet : pour dialoguer en IPv4 3. Autoconfiguration IPv6 de la zone IPv4 et IPv6 avec pour préfixe 2001:660:3001:7801::/64 (cf. Auto configuration des stations) 4. Routage RIPng : pour pouvoir récupérer les annonces de route IPv6 5. Routage statique : pour indiquer les routes par défaut Réalisation La première étape consiste à configurer l état général du routeur (nom, nom de domaine, ) et les interfaces (eth0_0, eth1_0). Il faut ajouter l annonce des préfixes sur l interface eth1_0. La dernière étape est la configuration du routage, les routes statiques et les protocoles de routage dynamiques (RIP, RIPng). Vous trouverez en annexe le Fichier de configuration du 6wind. Page : 70 / 136

71 Procédures de tests du routage Phases de tests Les tests peuvent être décomposés en deux phases. Phase 1 : Interconnexion locale entre la zone IPv4/IPv6 et la zone seulement IPv Vérification de l exécution du service (démons : ripngd, zebra) Exécution de la commande ping (resp. ping6) sur chaque interface IPv4 (resp. IPv6) 1.3. Test du lien en traçant les annonces de routes Phase 2 : Interconnexion à l extérieur en l occurence Renater 2.1. Exécution de la commande ping6 (resp. ping) sur chaque interface IPv6 (resp. IPv4) 2.2. Test du lien en traçant les annonces de routes Exécution des tests Phase Test Description Difficultés Résultat 1 1 Vérification de l exécution du service : ps -ax aucune OK 1 2 Exécution de la commande ping en local aucune OK 1 3 Exécution de traceroute en local aucune OK 2 1 Exécution de la commande ping avec l extérieur aucune OK 2 2 Exécution de traceroute avec l extérieur aucune OK Page : 71 / 136

72 Le multicast IPv6 Pour recevoir des flux multicast sur la plate-forme du GN6, il faut que le routeur 6wind connaisse le point de rendez-vous du réseau du M6Bone pour recevoir les annonces de diffusion. Trois phases sont proposées pour réaliser la diffusion multicast : 1. Une première phase en utilisant le 6wind pour se raccorder au M6Bone 2. Une deuxième phase avec une topologie permettant l accès à l ensemble de la plateforme en configurant la station FreeBSD en routeur PIM-SM 3. Et pour terminer la validation par des entités multicast Raccordement au M6Bone avec le 6wind Etude L objectif était de raccorder au M6Bone la plate-forme. Un tunnel IPv6 dans IPv4 a été établi pour assurer la mobilité si besoin dans un environnement non IPv6. En effet la plateforme doit avoir la possibilité d être transportable physiquement comme cela a été le cas pour la présentation d une plate-forme lors des JRES 2003 (Journées Réseaux). Le protocole BGP est un protocole de routage inter-système autonome (AS). Pour qu un AS puisse échanger du trafic avec un autre AS, il est nécessaire d avoir un accord mutuel. Une fois cet accord établi, un peering est configuré entre deux routeurs des différents systèmes autonomes. Le routeur avec lequel le peering est établi est appelé neighbor BGP (voisin). Réalisation Le raccordement ne présente aucune difficulté. Il faut tout d abord ajouter dans la configuration du routeur 6wind le tunnel v6 dans v4. 6wind.conf mig # 6IN4 TUNNELS 6in :660:3007:604:2:: 2001:660:3007:604:1:: Pour recevoir les annonces de diffusion, il faut se raccorder au point de rendez-vous de RENATER. Celui-ci est 2001:660:3007:300:1::. Le raccordement consiste à ajouter dans le fichier de configuration du démon pim6sd, présent sur le routeur, le point de rendez-vous et de lancer ce dernier. pim6sd.conf static_rp ff0e::/ :660:3007:300:1:: priority 1; static_rp ff1e::/ :660:3007:300:1:: priority 1; static_rp ff3e::/ :660:3007:300:1:: priority 1; On a ainsi la liste d accès des domaines multicast disponibles (ffxe). Page : 72 / 136

73 Il faut aussi configurer le routage BGP ainsi que les neighbors BGP. # router bgp neighbor 2001:660:3007:604:1:: remote-as 1717 neighbor 2001:660:3007:604:1:: soft-reconfiguration inbound # address-family ipv6 multicast network 2001:660:3001:7800::/52 neighbor 2001:660:3007:604:1:: activate exit-address-family 6wind.conf Configuration du routeur Unix avec PIM6 Réalisation De manière identique au 6wind, il faut ajouter dans le fichier de configuration du démon pim6sd du routeur Zebra le point de rendez-vous. Les lignes sont identiques au fichier pim6sd.conf du routeur 6wind. Page : 73 / 136

74 Procédure de tests du service multicast IPv6 Phases de tests Le test consiste à vérifier dans une première phase la réception des annonces multicast du routeur et dans une deuxième phase de s abonner à une session. Les tests peuvent être décomposés en trois phases. Phase 1 : Vérification des tables de routage multicast IPv6 en local sur le routeur UNIX 1.1. Exécution des commandes permettant de visualiser les tables de routage : netstat gl ou show ipv6 route une fois connecté sur le démon zebra 1.2. Visualisation des évènements concernant le multicast : pim6stat Phase 2 : Vérification du tunnel IPv6 dans IPv4 du routeur 6wind 2.1. Vérification des tables de routage Phase 3 : Utilisation concrète du multicast par le biais de logiciels de multidiffusion 3.1. Construction et exécution d entité multicast IPv6 avec VIC et RAT 3.2. Construction et exécution d entité multicast IPv6 avec VideoLAN De plus amples informations sont disponibles en annexe (cf. Annexe 2. Les logiciels de visioconférence) pour la mise en place des entités nommées en phase 2. Exécution des tests Phase Test Description Difficultés Résultat 1 1 Vérification des tables de routage : netstat -gl aucune OK 1 2 Visualisation des évènements : pim6stat aucune OK 2 1 Vérification des tables de routage aucune OK 3 1 Exécution d une entité multicast IPv6 avec VIC et aucune OK RAT 3 2 Exécution d une entité multicast IPv6 avec VideoLAN aucune OK Page : 74 / 136

75 Ajout du service de DNS (Domain Name Server) Après le routage, le DNS est le maillon essentiel du réseau. On peut ainsi citer la dépendance de nombreux logiciels (dont les logiciels de visioconférence) à l utilisation de fonctions de type «gethostbyname» (Retourne l'adresse IP correspondant à un hôte). On peut remarquer que se choix est propre au programmeur du logiciel concerné Le service DNS avec BIND BIND (Berkeley Internet Name Domain) est l implémentation la plus courante du DNS. Installation Téléchargement sur le site suivant : ftp://ftp.isc.org/isc/bind9/9.2.3/bind tar.gz Une documentation complète est présente à la décompression de ce fichier (manuel d utilisation détaillé des nombreuses options de bind). L installation ressort de la procédure classique (configure, make, make install) de l applicatif bind qui supporte IPv6. # tar xvzf bind tar.gz #./configure prefix=/usr/local # make # make install Arborescence des fichiers etc ce répertoire contient l ensemble des fichiers de configuration named.conf named.root named.run rndc.conf forward ce répertoire contient les zones directes gn6.renater.fr localhost reverse ce répertoire contient les zones inverses ip6.arpa ip6.int in-addr.arpa localhost-rev keys ce répertoire contient les clés confv6-keys rndc-keys Page : 75 / 136

76 Log test ce répertoire contient les journaux générés par named dns-security.log dns-update.log named.log named.pid named.run named rndc ce répertoire contient des fichiers de lancement non nécessaires Paramétrage La réalisation consiste à écrire le fichier named.conf où il faut ajouter différents paramètres : - directory "/etc/dns" : emplacement de nos fichiers de configuration - listen-on-v6 { any } : écoute toutes les adresses IPv6 - include "keys/rndc-key" : utilisation d une clé de cryptage, fichier «rndc-key» - logging : permet de tracer l information - channel security_log { file "log/dns-security.log" versions 2 size 20m : enregistre toutes les requêtes et garde 2 versions de taille 20Mo - channel update_log : enregistre toute les requêtes de mise à jour - root name servers : listes des zones qui gèrent le DNS - file "etc/named.root" : liste des serveurs «.», «.fr», «.com» etc - reverse loopback zone v6 : contient les zones qui permettent d associer noms et adresses IP - dynamic zones : indique le type du serveur dans cette zone et le répertoire où se trouve son fichier de configuration. Les zones directes : - TTL : durée en secondes (ou en jours heures minutes : 3D 2H 1M) de l existence de l information émise par notre serveur dans les caches des autres serveurs. - IN : pour Internet (d autres systèmes de nommage existent CH : CHaos et HS : HeSiod) - SOA : Start Of Authority, un seul par fichier sinon seul le premier est considéré. : Si on cela signifie qu on peut le remplacer dans le fichier c'est-à-dire gn6.renater.fr - NS : pour Name Serveur, définit les serveur de noms qui ont autorités sur cette zone. - AAAA : pour une adresse de type IPv6. - A : pour une adresse de type IPv4. Les zones inverses : - résolution du nom à partir de l adresse - IPv6 : deux arborescences o ip6.int (administré par l UIT-T), caduc d après le RFC 3596 o ip6.arpa (administré par l IETF), remplaçant du ip6.int - le fonctionnement a été décrit dans la partie précédente décrivant le RFC Le DNS IPv6 et IPv4 est opérationnel en local et devra être secondaire du DNS du GN6 pour être vu d Internet. Page : 76 / 136

77 Administration Après l installation, on procède à l activation manuelle du DNS avec le fichier de configuration (cette ligne suppose la création d un utilisateur bind). /usr/local/sbin/named c named.conf -u bind $* Le fichier named.conf dont on a nommé les principales fonctionnalités, contient deux sections appelées controls et key. Ces deux directives permettent le contrôle du serveur de nom via le programme rndc. La ligne controls définit les adresses IP des machines autorisées à contrôler le serveur de nom (par exemple la machine ::1), et la ligne keys définit un couple algorithme/clef qui est en fait une sorte de mot de passe pour autoriser là aussi le contrôle à distance. Pour que la machine puisse alors s'identifier, il faut qu'elle envoie ce mot de passe. Pour cela, il faut créer un fichier rndc.conf contenant la clef (disponible en Annexe 4. Le DNS). Le programme rndc permet de stopper, démarrer, recharger la configuration du serveur BIND à distance. rndc status -> PID de named rndc reload -> recharge la base de données rndc start -> démarrage rndc stop -> arrêt On peut rappeler que l administration du serveur de nom consiste aussi à l analyse des journaux générés par ce dernier. La liste présente dans l arborescence des fichiers (vu précédemment) est non exhaustive Configuration des résolveurs Le fichier /etc/resolv.conf doit contenir l'adresse de votre serveur de noms (si vous en utilisez un) et votre domaine. L instruction search permet d identifier le domaine IPv6. Le fichier de configuration est de la forme : search nom de domaine IPv6 IPv4 Le fichier /etc/hosts permet de spécifier au système la manière de résoudre les adresses IP en fonction des noms. Les premières lignes indiquent aux librairies de commencer par rechercher les noms dans /etc/hosts, et si elles ne trouvent pas ce qu'il leur faut, de demander ensuite ces renseignements au serveur de noms (BIND). L adresse de Loopback IPv6 est ::1. Les adresses en ff0x sont destinées au multicast. Page : 77 / 136

78 Procédure de tests du service DNS Phases de tests Cette procédure consiste à vérifier la corrélation entre une adresse et un nom donné, les règles établies dans les RFCs 1886 et Cette procédure diffère suivant que le service DNS est visible ou non d Internet. Lorsque le service est visible, l utilisation d un vérificateur de zone d intégrité disponible sur Internet permet de valider le service. Dans le cas contraire il faut installer le vérificateur de zone sur le réseau local. Les tests peuvent être décomposés en trois phases. Phase 1 : Service DNS lancé et actif 1.1. Vérification de l état de l exécution du service 1.2. Lecture des journaux du système et du service Phase 2 : Test de corrélation adresse-nom et nom-adresse 2.1. Utilisation de l outil nslookup 2.2. Validation avec l outil dig Phase 3 : Test global de conformité aux RFCs 3.1. Test du DNS v6 avec l outil ZoneCheck Exécution des tests Phase Test Description Difficultés Résultat 1 1 Vérification de l état de l exécution du service : aucune OK named -g 1 2 Lecture des journaux : tail /var/log/messages + interprétation OK les fichiers présents dans le répertoire logs 2 1 Utilisation de l outil nslookup aucune OK 2 2 Validation avec l outil dig aucune OK 3 1 Tests du DNS v6 avec l outil ZoneCheck filtrage? Page : 78 / 136

79 Ajout du service de Serveur Web La mise en place d un serveur web s inscrit dans la validation d une migration IPv6 des outils traditionnels du réseau. De plus cet outil peut devenir un accès direct à une politique de communication sur la plate-forme, en effet la présence d un site Internet construit de manière à être évolutif et à décrire l ensemble des fonctionnalités d un schéma global permet une cohérence par plusieurs points de vue : l ambition de donner toutes les clés possibles aux successeurs la possibilité d une communication forte la présence d un outil de publication pour les tests présents et à venir Etude Le serveur Web s inscrit dans la mise en place d applications IPv6 sur la plate-forme. Le choix s est porté sur un serveur Apache (version supérieure à 2.0) dont la compatibilité IPv6 est avérée. Rappel : les applications sont installées sur le serveur applicatif (RedHat 9.0) compatible IPv4 et IPv6. Le serveur Web sera par ailleurs compatible avec le protocole IPv4. Une réflexion a été menée sur l utilisation de cet outil propre à la communication, la possibilité de préparer l avenir de cette plate-forme pour une utilisation plus globale dans le domaine des tests IPv6 avant mis en production a amené à installer un véritable service de publication d articles permettant l échange et la centralisation de données expérimentales. L adjonction d un système de publication a été fait par l intermédiaire du logiciel SPIP sous licence GPL 15 impliquant ainsi l installation du langage PHP, du logiciel de bases de données MySQL avec le logiciel de gestion de bases de données PHPMyAdmin Le service Web avec Apache Installation L installation ressort de la procédure classique (configure, make, make install) des applicatifs concernés Apache , SPIP 1.7.2, PHP 4.3.6, MySQL et enfin PhpMyAdmin Vous trouverez en annexe une note explicative sur les différentes installations. Paramétrage Le paramétrage d Apache «httpd.conf» consiste à réaliser les actions suivantes : Ouvrir l écoute du port 80 pour IPv6 «Listen ::80» Indiquer le nom du serveur «ServerName pc3ipv6.gn6.renater.fr» 15 General Public License, Page : 79 / 136

80 Procédure de tests du service Web Phases de tests Les tests peuvent être décomposés en trois phases. Phase 1 : Accès à ce service par l adresse IPv Ping IPv6 du serveur Web IPv Lancement d un navigateur en local avec l adresse [::1] 1.3. Lancement d un navigateur en local avec l adresse du Serveur Web IPv Lancement d un navigateur sur un client avec l adresse du Serveur Web IPv Vérification de l accès aux différentes pages et des liens vers les autres sites Phase 2 : Accès à ce service par le nom du serveur IPv Se reporter à la vérification du DNS 2.2. Lancement d un navigateur avec le nom du Serveur Web 2.3. Vérification de l accès aux différentes pages et des liens vers les autres sites Phase 3 : Accessibilité extérieure à la plate-forme 3.1. Accessibilité depuis Renater 3.2. Accessibilité depuis un poste extérieur à Renater Exécution des tests Phase Test Description Difficultés Résultat 1 1 Ping IPv6 du serveur Web IPv6 aucune OK 1 2 Lancement d un navigateur en local avec aucune OK l adresse [::1] 1 3 Lancement d un navigateur en local avec aucune OK l adresse du Serveur Web IPv6 1 4 Lancement d un navigateur sur un client avec aucune OK l adresse du Serveur Web IPv6 1 5 Vérification de l accès aux différentes pages et aucune OK des liens vers les autres sites 2 1 Se reporter à la vérification du DNS aucune OK 2 2 Lancement d un navigateur avec le nom du aucune OK Serveur Web 2 3 Vérification de l accès aux différentes pages et aucune OK des liens vers les autres sites 3 1 Accessibilité depuis Renater aucune OK 3 2 Accessibilité depuis un poste extérieur à Renater filtrage? Page : 80 / 136

81 Administration du réseau IPv Métrologie avec MRTG Etude La mise en place d un logiciel de supervision s inscrit dans la validation d une migration IPv6 des outils traditionnels du réseau. De plus cet outil peut devenir un outil d observation, permettre une meilleure compréhension et une analyse plus fine des applications utilisant le réseau. MRTG (Multi Router Traffic Grapher) permet de générer des graphes sur le trafic réseau. Il a l avantage de générer les graphes sur le web et d être gratuit. Il se base sur des requêtes SNMP collectant les informations de trafic sur l ensemble les interfaces des équipements. De plus sa configuration est simple : détection des interfaces actives sur un équipement lors de la génération de la configuration, puis interrogation par polling SNMP sur l ensemble de ces interfaces. Une version IPv6 de MRTG a été développée par l université de Rome-3. Elle permet d interroger les équipements via SNMP sur un transport IPv6. L outil est disponible sur : Réalisation Deux axes sont abordés dans l étude de l application MRTG : 1) La disponibilité de MIB collectant l information sur IPv6 2) Le support de IPv6 pour le transport SNMP Pour atteindre les objectifs de cette étude, il a donc fallu dans un premier temps sélectionner un matériel ayant des potentialités IPv6 dans ce domaine. Le choix s est porté sur le routeur 6wind 6110 de la plate-forme qui répond aux besoins des tests. L installation de l applicatif MRTG ressort de la procédure classique (configure, make, make install). Les modules Perl sont nécessaires. Pour activer IPv6 : Il est nécessaire de spécifier à l exécution de cfgmaker l option enable-ipv6 De plus il faut ajouter au fichier de configuration 6wind.cfg la ligne suivante EnableIPv6 : yes et l adresse IPv6 de l équipement à interroger pour que le transport se passe en IPv6 MRTG utilisera ainsi IPv6 pour résoudre les adresses IPv6 Le lancement de MRTG s effectue par la ligne de commande suivante : $./mrtg 6wind.cfg Page : 81 / 136

82 1) Le routeur 6wind implémente une MIB basé sur le RFC 2465 qui permet de récupérer le nombre de paquets entrant, sortant en IPv6. Dans le fichier de configuration de MRTG, ce sont ces deux OID qui sont interrogées toutes les 5 minutes. 2) Le routeur 6wind supporte le transport SNMPv6. La collecte d information peut donc se faire aussi bien en v6 qu en v4. Phases de tests Les tests peuvent être décomposés en deux phases. Phase 1 : Interrogation de MIB par des requêtes IPv4 avec le protocole SNMP 1.1. Se reporter à la vérification du serveur Web 1.2. Interrogation de MIB concernant des objets IPv Interrogation de MIB concernant des objets IPv6 Phase 2 : Interrogation de MIB par des requêtes IPv6 avec le protocole SNMP 2.1. Interrogation de MIB concernant des objets IPv Interrogation de MIB concernant des objets IPv6 Exécution des tests Phase Test Description Difficultés Résultat 1 1 Vérification du serveur Web aucune OK 1 2 Interrogation de MIB concernant des objets IPv4, aucune OK par le biais de SNMPv4 1 3 Interrogation de MIB concernant des objets IPv6, aucune OK par le biais de SNMPv4 2 1 Interrogation de MIB concernant des objets IPv4, aucune OK par le biais de SNMPv6 2 2 Interrogation de MIB concernant des objets IPv6, par le biais de SNMPv6 aucune OK Conclusion Du fait que les NOCs (Network Operations Center, les centres où sont administrés les réseaux) supervisent les réseaux en IPv4, le support IPv6 n est pas indispensable. Il est nécessaire d avoir un transport SNMP IPv6 uniquement pour les réseaux IPv6-only. Un réseau IPv6 peut-être supervisé avec un support IPv4 ou IPv6. L élément clé est la présence de MIB v6 sur l équipement interrogé. Page : 82 / 136

83 Ajout de services de visioconférence IPv6 Les logiciels traités dans cette partie sont issus du projet OpenH323. Ce projet a pour but de développer un ensemble d applications libres inter-opérables qui implémentent les recommandations de UIT-T de la norme H323. Le site officiel est le suivant Techniquement, le projet openh323 repose sur deux librairies PWLib d une part et openh323 d autre part. Les applications reposant sur ces librairies nécessitent donc une pré installation de ces dernières. Pour valider le support du protocole IPv6, il est nécessaire de vérifier sous Linux que le module a bien été compilé (pour le lancer la commande est la suivante modprobe ipv6). La présence du fichier /proc/net/if_inet6 sous linux, permet aux deux librairies de vérifier le fonctionnement d IPv6 et donc de se configurer en conséquence. La suite de l installation ressort de la procédure classique (configure, make, make install) pour PWLib et openh323 en ayant indiqué les chemins appropriés dans la variable PATH. Figure 17 : Liens entre les librairies PWLib et OpenH Configuration d un client H323 avec GnomeMeeting Etude Le logiciel GnomeMeeting est un logiciel de visioconférence, un terminal H323 sous licence GPL, c est le pendant de NetMeeting sous Windows (Microsoft) pour la visioconférence sous Linux. Ces deux logiciels sont par ailleurs compatibles. GnomeMeeting au contraire de son homologue sous Windows, est compatible IPv6 puisqu il repose sur les librairies du projet openh323, elles-mêmes compatibles IPv6. Réalisation Le logiciel GnomeMeeting très répandu dans les distributions Linux (RedHat, Mandrake) peut-être installé comme paquetage pour peu que la version soit suffisamment récente pour accepter IPv6, ce n est d ailleurs pas le cas pour la dernière distribution de RedHat 9 (version 0.98 de GnomeMeeting) avec les cdroms d installation tandis que la Mandrake 10 contient un paquetage suffisamment récent (version 1.02). Page : 83 / 136

84 L installation des sources est la suivante : $ tar xvzf gnomemeeting tar.gz $ cd gnomemeeting $./configure --prefix=/usr/local --with-ptlib-libs=/usr/local/lib --with-openh323- libs=/usr/local/lib --with-ptlib-includes=/usr/local/include/ptlib $ make $ make install Le résultat est identique à la figure ci-dessous avec une unique vidéo dans la fenêtre de réception, celle du distant Configuration d un pont MCU avec OpenMCU Etude Lors d une communication à plus de deux participants, il est nécessaire de passer par un service «applicatif» de pont multipoint (MCU : Multipoint Control Unit) qui se charge de rediffuser la vidéo et l audio à tous les participants. Le projet OpenH323 met à notre disposition un pont : OpenMCU. Ce logiciel a été testé dans plusieurs environnements Linux : distribution RedHat 9.0, distribution Mandrake 10. Réalisation L installation de différentes versions de openmcu (versions CVS, versions disponibles sur le site officiel ou sur les sites non officiels) sous la distribution RedHat s est avérée être un échec en fonctionnement IPv6. En effet le logiciel a refusé de dialoguer en v6 puisqu il n écoutait pas les requêtes v6 tandis qu il fonctionnait correctement en v4. L installation d une distribution Mandrake et des paquetages par défaut incluant openmcu se sont avérés compatibles IPv6. Les tests ont donc été réalisés sous cette distribution. Les commandes suivantes permettent de vérifier que le pont MCU écoute en IPv6 ou en IPv4. $ netstat -pl -A inet Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name tcp 0 0 *:h323hostcall *:* LISTEN 2755/openmcu $ netstat -pl -A inet6 Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name tcp 0 0 *:h323hostcall *:* LISTEN 2858/openmcu Remarque : les tests n ont pas abouti pour un pont à la fois IPv6 et IPv4, c'est-à-dire une connexion simultanée de terminaux IPv6 et IPv4 à un même pont. Page : 84 / 136

85 Le pont MCU a été testé sans l utilisation de GateKeeper, les terminaux H323 en l occurrence GnomeMeeting se sont loguer directement sur le pont MCU. Une commande suffit pour lancer le pont MCU en IPv6 : $ openmcu n v Les options possibles : -g : indique le portier (gatekeeper) de la zone H323 -n : le pont ne fait pas la découverte de portier --require-gatekeeper : découverte automatique par le pont, du portier de la zone H323. Si le pont ne trouve pas de portier dans la zone, il ne démarrera pas -v : permet de faire de la vidéo en H261 avec une qualité d image QCIF --videolarge : cette option permet de passer en CIF --videotxfps «n»: cette option permet d envoyer un certain nombre d images par secondes avec n compris entre 1 et 30 images par secondes (1<n<30), par défaut 10 images/s -i «@» permet d indiquer l interface sur laquelle il faut que le pont écoute, pour une compatibilité IPv6 il suffit d indiquer son adresse IPv6 sur laquelle les autres clients H323 vont se connecter Ci-dessous, une capture d un client H323 (GnomeMeeting) connecté à un pont MCU (openmcu) ou deux autres clients sont déjà présents : Figure 18 : Un client GnomeMeeting connecté au pont openmcu en IPv6. Page : 85 / 136

86 4.3. Transfert de connaissances La plate-forme de démonstration IPv6 du GN6 s inscrit dans la durée, par l intermédiaire de nouveaux stagiaires. Une documentation relative au fonctionnement ainsi qu aux outils disponibles sur la plate-forme a été mise à disposition sur le site de la plate-forme et par le biais des mémoires concernant ce projet. L apprenti du DESS ART qui me succède au GIP Renater, M. Benoît Le Bonhomme, doit poursuivre et étendre la plate-forme de tests et de démonstration IPv6 du GIP RENATER, dans le contexte des actions du groupe GN6, j ai donc fait en sorte de lui apprendre tout ce dont il aura besoin afin de reprendre mon travail dans de bonnes conditions. Après l avoir familiarisé avec les logiciels utilisés dans le cadre des retransmissions en multicast, en H323, je lui ai montré le fonctionnement interne de la plateforme, le routage, le DNS. Ce transfert de connaissances devrait lui permettre d aborder cette année de travail au GIP Renater avec tous les moyens nécessaires à la réussite de sa mission. Page : 86 / 136

87 5. Conclusion Le projet VIC-GC et son extension sous Windows a prouvé son utilité lors de la diffusion de transparents des séminaires Aristote et des cours DIM. L étude de nouveaux logiciels multimédia a permis d améliorer le schéma global de diffusion. En effet, le logiciel VideoLAN a été adopté pour l année scolaire La plate-forme du GN6 permet de mettre en œuvre de nouvelles méthodes de travail et de collaboration. De tester puis d exploiter les nouvelles technologies IPv6. Parmi les perspectives d avenir concernant le domaine de la visioconférence on peut citer, d une part le suivit et plus particulièrement la portabilité du système Isabel sous Windows permettant ainsi de s abroger d un schéma multi logiciels (cf. les cours DIM de l année 2003 et ceux à venir de l année 2004), d autre part l étude d une passerelle multicast IPv4 - multicast IPv6 dynamique. Par ailleurs différentes problématiques peuvent être étudiées par le biais de la plate-forme de démonstration IPv6 du GN6, par exemple l étude de la communication IPv6 entre deux serveurs de messagerie, les notions de sécurité IPv6, le DHCPv6 / DNS dynamique ou pour finir l étude d une passerelle H323/SIP. Continuer à prospecter les logiciels aux normes SIP et H323 compatible IPv6 s avérerait un enjeu intéressant, du fait de leur faible disponibilité actuelle. Cet apprentissage s est avéré très formateur d un point de vue technique et théorique. Il m a permis d adopter une démarche professionnelle en côtoyant le monde de la recherche. Page : 87 / 136

88 6. Annexes Annexe 1. Les partenaires du projet ATHENA L association Aristote et le GIP Renater : L université Paris 7 Denis Diderot : C est le DESS Applications des Réseaux et de la Télématique dépendant de l UFR d informatique de l Université Paris 7 qui participe au projet ATHENA. Ce DESS, qui utilise les services de VisioP7, le centre de visioconférence de l Université Paris 7, se situe à la pointe de la technologie concernant les expérimentations de téléenseignement utilisant les technologies de la visioconférence. Sa formation est ancrée sur la réalité du marché et la diversité des technologies, alliant Télématique, Télécommunications et Multimédia. L université d Evry : Page : 88 / 136

89 L université d Evry est représentée dans le projet ATHENA par le DESS Ingénierie Documentaire et Multimédia. Les étudiants sortant de cette formation sont des informaticiens capables de maîtriser à la fois les domaines techniques et organisationnels liés à la gestion, la création et l utilisation de l information documentaire et multimédia dans des environnements variés. L ESMT à Dakar : L Ecole Supérieure Multinationale de Télécommunications (ESMT) située à Dakar est née en 1981 de l initiative de sept pays de la sous région de l Afrique de l Ouest (Bénin, Burkina Faso, Mauritanie, Niger, Sénégal, Togo), avec le concours de la coopération internationale dans le cadre d un projet du Programme des Nations Unies pour le Développement (PNUD). L ESMT est maintenant une institution multinationale qui a pour vocation de former des ingénieurs en télécommunications spécialisés dans les domaines technique et commercial. Elle accueille en formation initiale ou en formation continue des stagiaires issus des pays membres et d autres pays utilisateurs comme le Tchad, la Guinée Conakry, le Burundi, Djibouti, Madagascar, la Côte d Ivoire, le Cameroun, le Congo L ESMT offre également des possibilités de rencontres et d échanges, en organisant des forums, des séminaires et des réunions à l échelle africaine et internationale tels que le forum sur les radiocommunications mobiles regroupant opérateurs africains et consortiums internationaux (1994 et 1997) ou le séminaires interrégional sur les techniques et usages de la télématique (1996). L'ESMT bénéficie d'aides de la part de ses partenaires internationaux sous diverses formes - renforcement des infrastructures techniques - renforcement des ressources pédagogiques - soutien d'assistance technique - soutien financier Le PNUD (Programme des Nations Unies pour le Développement) et l'uit (Union Internationale des Télécommunications) sont à l'origine de l'esmt et ont permis le développement de ses activités notamment par l envoi d experts pour la mise en place des formations (a commencer par celle des formateurs) et en permettant l'acquisition des équipements de laboratoire et des divers matériels logistiques. La coopération avec la France s'est pratiquement mise en place dès la création de l'esmt.elle s'est traduite par la mise à disposition d'experts (France Télécom, etc.), de CSN, d'aide au développement des ressources humaines de l'école et de dons en matériels. Page : 89 / 136

90 L'appui de la Suisse à l'esmt se manifeste de diverses manières : formation pédagogique de formateurs, octroi de bourses d'études à des élèves, dons de matériels didactiques, organisation en commun de séminaires. Dans le cadre de son programme d'appui institutionnel aux pays participant au projet PANAFTEL-ACDI, le Canada soutient diverses actions (installations d'énergie solaire, téléphonie rurale, transfert de compétences par des experts de CEGIBEL, etc.). Forte de tous ses partenaires, l'esmt se veut un pôle de développement des télécommunications des pays membres et utilisateurs, afin d'accroître la compétitivité des entreprises dans un environnement en profonde mutation. L Université Cheikh Anta Diop (UCAD) à Dakar : L Université de Dakar a été créée le 14 février 1957 et elle a été inaugurée en décembre Héritière de l école africaine de Médecine créée en 1915, l Université de Dakar a connu une longue évolution marquée en 1949 par la création d un enseignement préparatoire aux études médicales et par l ouverture au début des années cinquante d écoles supérieures académiquement rattachées à l Université de Bordeaux, puis érigées en 1957 en Facultés indépendantes pour former l Université de Dakar. Devenue le 30 mars 1987 l Université Cheikh Anta Diop de Dakar, l Université de Dakar est la plus ancienne et la plus importante structure d enseignement supérieur existant actuellement au Sénégal. En dehors des services administratifs centraux du rectorat elle est composée de trente établissements d enseignement supérieur et de recherche se répartissant comme suit : onze facultés, dix-neuf instituts d université ainsi que l Ecole Inter états des Sciences et Médecine Vétérinaires qui dépend scientifiquement de l Université. C est l Ecole supérieure Polytechnique rattachée à l UCAD qui participe au projet ATHENA. L Ecole Supérieure Polytechnique est répartie sur cinq départements : Génie Chimique, Génie Civil, Génie Electrique, Génie Mécanique et enfin le département Génie Informatique qui participe au projet ATHENA. Page : 90 / 136

91 Le CIRAD à Montpellier : Organisme français spécialisé en recherche agronomique appliquée aux régions chaudes, le CIRAD a pour mission de contribuer au développement rural des pays tropicaux et subtropicaux par des recherches, des réalisations expérimentales, des actions de formation, en France et à l Etranger. Ses activités recouvrent les domaines des sciences agronomiques, vétérinaires, forestières et agroalimentaires. Le Centre de Calcul El Khawarezmi (CCK) à Tunis : Le CCK, établissement sous tutelle du Ministère de L Enseignement Supérieur et dépendant de l Université El Manar de Tunis a été créé en octobre 1976 à la suite de l introduction de l Informatique en tant que discipline autonome dans les milieux universitaires. Le Centre de Calcul El Khawarezmi a été désigné au mois de juillet 1997 comme fournisseur de services Internet au profit des établissements d enseignement supérieur et de recherche. Sa mission principale est de mettre à la disposition des enseignants, des chercheurs, des doctorants et des étudiants exerçant au sein des institutions dépendant du Ministère de l Enseignement Supérieur, les moyens et les services nécessaires pour favoriser le développement de la recherche scientifique par le biais de l informatique. Dans le cadre de la réalisation du projet du Réseau National Universitaire (RNU) retenu dans le 9ème plan, le centre de calcul El Khawarizmi a été désigné, au mois de Juillet 1997 (circulaire 97/047 du 26 Juillet 1997) comme Fournisseur de Services Internet au profit des établissements de l'enseignement Supérieur. Dans le cadre du projet BIRUNI (projet d informatisation des bibliothèques universitaires tunisiennes), le CCK permet l'interconnexion des bibliothèques universitaires et assure l'hébergement du serveur central d'informations bibliographiques. Le Centre participe au projet de l'utilisation des technologies avancées comme moyen de soutien à l'enseignement et à la pédagogie, notamment pour les applications que constituent le téléenseignement ou la visioconférence. Page : 91 / 136

92 Le réseau MARWAN au Maroc : Acronyme de l expression Maroc Wide Area Network (réseau longue distance marocain), le MARWAN est un réseau informatique national à but non lucratif dédié à l éducation, à la culture et à la recherche. Sa mise en place, décidée par le Premier Ministre marocain est effectuée conjointement par le Ministère de l Enseignement Supérieur, de la Formation des Cadres et de la Recherche Scientifique ; le Ministère de l Education Nationale ; Le Ministère du Développement Social, de la Solidarité, de l Emploi et de la Formation Professionnelle et le Secrétariat d Etat auprès du Premier Ministre chargé de la Poste et des Technologies de l Information. Ce réseau correspond à un choix stratégique qui consiste à fédérer l infrastructure d information et de communication des établissements et à connecter ces derniers aux réseaux internationaux équivalents. Le MARWAN facilite les échanges d information à l échelle régionale, nationale et internationale. Il permet la diffusion du savoir et offre également aux établissements scolaires, universitaires et de formation professionnelle ainsi qu aux centres de recherche nationaux, la possibilité d utiliser les technologies de l information et de la communication. Les Nouvelles Technologies de l Information et de la Communication sont en train de provoquer une révolution, aussi importante que la révolution industrielle. Le réseau MARWAN est l outil adéquat qui va permettre au Maroc de développer ce secteur et en faire un puissant levier pour le développement et le décollage de la recherche scientifique et technique dans ce pays. Le réseau MARWAN a pour objectifs : - La généralisation de l enseignement et l amélioration de sa qualité par le développement des différents modes d enseignement et de formation à distance (téléenseignement, télé médecine ) - Le développement de la recherche scientifique et technique grâce à la multitude des formes de communications offertes par ce réseau et par la création de bases de données et de bases documentaires spécifiques Page : 92 / 136

93 - L amélioration du transfert de technologie et de la coopération internationale en connectant le réseau MARWAN aux autres réseaux internationaux similaires - La généralisation et la vulgarisation de l utilisation des technologies de l information et de communication par la couverture de l ensemble des établissements d enseignement de formation et de recherche, de l école à l université, et sur la totalité du territoire marocain - L amélioration et la rationalisation de la gestion des ressources par le partage et l échange de ces ressources, en réalisant d importantes économies par le remplacement des modes classiques de communication, de transfert et de publication de l information par les Nouvelles Technologies de l Information et de la Communication - La création d emplois par la création de nouveaux métiers et nouveaux services autour de ces Nouvelles Technologies. L université de Guadalajara au Mexique : L université de Guadalajara a été fondée en 1792 sous le nom d Université Royale de Guadalajara. C est un organisme public décentralisé du gouvernement de l état de Jalisco, qui jouit de son autonomie et d un patrimoine personnel. Ses objectifs sont d offrir des formations initiales et des formations continues à destination des techniciens, universitaires et étudiants, mais aussi plus généralement de diffuser la culture, la science et la technologie. L Institut Indien de Technologie de Kanpur en Inde (IITK) : L Institut Indien de Technologie de Kanpur est engagé dans la recherche et la mise en œuvre des nouvelles technologies. Il forme des ingénieurs motivés et compétents. L Institut célèbre la liberté de penser, cultive la vision et encourage la croissance mais inculque également des valeurs humaines et le souci de l environnement de la société. L Institut forme des bacheliers, des maîtres et des doctorants dans diverses branches technologiques et scientifiques. L IITK a mis l accent sur le recrutement d un corps enseignant compétent venant de différents points géographiques nationaux et internationaux ainsi qu une sélection très stricte des étudiants. L IITK est un établissement technologique d importance nationale pour l éducation mais aussi pour la recherche. Concernant les nouvelles technologies de l Internet, l IITK profite de subventions du gouvernement indien, de projets, de personnes compétentes, étudiants et chercheurs. Page : 93 / 136

94 Annexe 2. Les logiciels de visioconférence Manuel d utilisation de VIC VIC est un des outils du MBone du domaine de la visioconférence. L'utilisateur peut transmettre et recevoir de la vidéo avec VIC qui utilise RTP [RFC 1889]. C'est un logiciel basé sur des Codecs vidéo. De l'ordinateur dépend la performance de VIC, par exemple de nombreuses vidéos ne peuvent tourner en même temps sans surcharger le processeur. VIC est un logiciel de visioconférence permettant d'émettre et de recevoir de la vidéo en unidiffusion (unicast) ou en multidiffusion (multicast) en utilisant différentes normes de codage vidéo comme les normes H261, H263, ou H263+. Ce logiciel est disponible pour Windows 98, 2000 et XP ainsi que pour les systèmes d'exploitation Unix/Linux. Requis Il n'y a pas besoin d'équipement spécifique en dehors de la capacité de l'ordinateur d'afficher ou de recevoir de la vidéo. Pour pouvoir transmettre de la vidéo, vous devez avoir une «webcam» ou une caméra et une carte d'acquisition sur votre ordinateur. Environnements et matériels utilisés pour les Tests La version de VIC utilisée pour les tests : 2.8 ucl Plusieurs systèmes d'exploitation ont été utilisés pour ces tests : Linux Debian, Windows 2000 et Windows XP. En ce qui concerne le matériel vidéo, une caméra Sony EVI-D31 acceptant une résolution importante (704*576) ainsi qu'une carte d'acquisition Osprey 210, et une caméra Quickcam de Logitec ont été mis à disposition des tests. Installation Télécharger la version correspondant à votre système sur le site suivant : Décompresser les sources (tar -xvzf) Dans le répertoire common :./configure --enable-ipv6 && make Dans le répertoire tcl/unix :./configure && make Dans le répertoire tk/unix :./configure && make Dans le répertoire tcl/unix :./configure --enable-ipv6 && make && make install Page : 94 / 136

95 Lancement de VIC Il y a deux façons de lancer VIC, par SDR (utilitaire de session du MBone) et par ligne de commande. Le format de la ligne de commande est constitué comme suit : Prompt> vic [options] <adresse_multicast/port> L'adresse multidiffusion (multicast) doit être comprise entre et Une option très utilisée est le TTL ("Time To Live"), en effet il est initialisé par défaut à 16 ce qui est insuffisant pour la plupart des cas (63 pour couvrir l'europe et 127 pour diffuser partout). Exemple de ligne de commande ayant pour adresse de multidiffusion (multicast) et pour port 3456 avec un TTL de 63 : Prompt> vic -t /3456 Vous pouvez aussi utiliser une adresse unicast à la place de l'adresse de multidiffusion (multicast), l'émetteur et récepteur se connectent sur l'adresse du distant en conservant le même numéro de port. Les options en détail : -A nv ivs rtp -B maxbps -C conf -c ed gray od quantize [nv ivs rtp] Vic utilise la version 2 du protocole de transport RTP mais dispose de cette option permettant de le rendre compatible avec nv (logiciel vidéo de Xerox) et ivs (logiciel de visioconférence audio et vidéo de l'inria) qui sont des variantes de RTPv1. [ ] Permet de définir la valeur maximum de bit par seconde disponible lors de la transmission. Permet de définir le titre de la conférence. Si elle est omise alors le titre de la fenêtre principale de VIC sera l'adresse de destination et le port. parallax, sunvideo, rtvc, tx, videopix, vigrapix, xil, x11,still, meteor-1, xil Osprey 1k-1, vino, cosmo, galileo, indigo, j300 Non testé Testé Testé Testé (effet?) -d display? Non testé -f bvc cellb h261 jpeg nv [bvc cellb h261 jpeg nv none ] Désigne la norme utilisée lors de la transmission, ce choix peut aussi être effectué dans le panneau de contrôle. Testé -F maxfps -H -I channel -i ifaddr Donne la valeur maximum du nombre d'image par seconde qui peut être émises (à définir dans le panneau de contrôle). Valide l'option "Use-Hardware-Decode" (disponible dans le panneau de contrôle au niveau de la partie "Display"). Par défaut le décodage est effectué par logiciel. Synchronisation de VIC et RAT (cette option est lancé par le logiciel de session SDR lors de l ouverture de VIC et RAT), utilise le bus de coordination de UCL/Berkeley. Permet de lire une vidéo stockée provenant d'une émission (on utilise l'option o pour l'enregistrement). Testé Testé Testé (effet?) Ne fonctionne pas -j numlayers Non testé -K key Permet de crypter avec une clé spécifiée. Testé -L flowlabel(ip6 only) Non testé Page : 95 / 136

96 -l (creates log file) Crée un fichier de rapport d'erreur. Testé -M colormap Pour utiliser différents algorithmes de diffusion d erreur. Non testé -m mtu [ ] Permet de choisir son mtu, le maximum étant de 1024 bytes (pour le protocole de l'application). Par Testé défaut, il est de 1024 bytes. -N session [RTPname] Permet de définir le nom de la session. Testé -n atm ip ip6 rtip [atm ip ip6 rtip] Non testé -o clipfile Ne Permet de stocker la vidéo émise (on utilise l'option i fonctionne pour lire cette dernière). pas -p????????? Non testé -r????????? Non testé -S????????? Non testé -t ttl [ ] Permet pour les adresses uniquement de multidiffusion (multicast) de désigner le TTL ("Time To Live"). Par défaut, si l'on ne met pas d'indication il est Testé à 16. -U interval [ ] en ms (recommandé 200ms). Testé -u script Permet d'exécuter le script passé en argument avant le démarrage de VIC. Vous pouvez ainsi construire votre Testé interface utilisateur. -v (version) Pour connaître la version du logiciel VIC. Testé -V visual Non testé -x ifindex (ip6 only) Non testé -Xframerate=<fps> X resource=value -XtransmitOnStartup=<x> true, false Testé -X resource=value -Xbandwidth=<kbps> Vic.mtu (1024) Vic.framerate(2) Vic.defaultTTL(16) Vic.maxbw(-1) Vic.bandwidth (128) Vic.iconPrefix (vic:) Vic.priority (10) nice(3) Vic.format (none) Vic.stampInterval (1000) Vic.switchInterval (5) Vic.dither (od) Vic.tile (1) Vic.filterGain (0.25) Vic.statsFilter (0.0625) Vic.medianCutColors (150) Vic.gamma (0.7) Apport supplémenta ire de «modules» et leur valeur par défaut. Page : 96 / 136

97 Les codecs PT Nom du CoDec Audio/Vidéo Fréquence (Hz) Canal (aux ) ( A / V ) 0 PCMU A A G721 A GSM A Non assigné A DVI4 A DVI4 A LPC A PCMA A G722 A L16 A L16 A Non assigné A 13 Non assigné A 14 MPA A G728 A Non assigné A 24 Non assigné V 25 CelB V JPEG V Non assigné V 28 Nv V Non assigné V 30 Non assigné V 31 H261 V MPV V MP2T AV Non assigné? Réservé N/A N/A N/A Non assigné? Dynamique? Codage standard en Audio / Vidéo (Référence : projet général , auteurs Nguyen Khoa Zeng) Guide d utilisation Au premier lancement de VIC, une boîte de dialogue vous demande votre nom ainsi que votre courriel, ces informations seront modifiables par la suite sous Windows dans la base de registre sous linux dans le répertoire "home". Page : 97 / 136

98 La fenêtre principale La fenêtre principale est composée d'une salle d'attente virtuelle, si il n'y a aucun émetteur alors le message "Waiting for video" s'affiche. Une vidéo au format timbre poste apparaît pour chacun des émetteurs. Un click gauche de souris permet d'élargir la vidéo de la source correspondante. On peut voir à la droite de la vidéo des informations sur le participant (le nom, l'adresse IP d'émission, le protocole d'émission, le nombre d'image par seconde, la bande passante utilisée, le nombre de paquets perdus, etc.). En dessous trois boutons : mute, color et info. Cocher l'option mute permet d'ignorer (de ne pas décoder) la vidéo du participant correspondant. Vous pouvez utiliser cette fonction pour diminuer la sollicitation du processeur. C'est utile pour pouvoir augmenter la performance d'encodage de votre propre vidéo. A noter : les effets de cette option sont seulement effectifs localement. Par exemple si vous ne décodez plus votre propre retour de vidéo, cela n'empêchera les autres participants de la recevoir. Même si vous ignorez une des vidéos extérieures elle continue à être transmise à votre ordinateur. Seul le processeur est moins sollicité ce qui n'est pas le cas de la bande passante de votre réseau. L'option color contrôle la couleur de la vidéo affichée. Par défaut cette option est cochée et permet d'afficher la vidéo en couleur autrement en noir et blanc. Cette option décochée permet de gagner un peu de performance processeur. A noter : de même que pour mute, l'option color n'affecte que la vidéo affichée (incluant celle de votre vidéo locale) et non pas la vidéo transmise. L'option info consiste en un menu donnant le choix entre diverses options : Site Info, RTP Stats, Decoder Stats ou Decoder Control pour afficher les informations en temps réel sur le réseau et l'encodage de la vidéo pour la source correspondante. En bas de la fenêtre principale, il y a trois boutons : Menu, Help, Quit. Cliquer sur le bouton Menu ouvre un panneau de contrôle, sur le bouton Help pour obtenir une aide. Page : 98 / 136

99 Raccourcis / Touches claviers : En dehors du bouton Quit, vous pouvez utiliser les combinaisons de touches suivantes : "Ctrl c", "Ctrl d" pour quitter VIC. En maintenant la souris sur la vidéo et en pressant la touche "d", vous pouvez la désactiver. Si la vidéo est reconnecté vous verrez deux vidéos d un même participant, l'une est celle déconnectée et l'autre de la nouvelle connexion. Celle déconnectée disparaîtra après 2 minutes. Si vous ne pouvez attendre vous pouvez utiliser la touche "d" pour la désactiver. Utiliser les touches "1", "2", "3", "4" pour recentrer la fenêtre principale dans différentes colonnes. La fenêtre avec la vidéo élargie C'est un exemple de vidéo transmise, vous pouvez l'obtenir en cliquant sur chacune des vidéos au format timbre poste présentes dans la fenêtre principale. En dessous vous pouvez trouver un menu composé de quatre boutons : Decoder, Size, Modes et Dismiss. Le menu Decoder doit garder les paramètres par défaut. Le menu Size donne la taille de la fenêtre. Vous pouvez sélectionner différents formats : QCIF(176x144), CIF(352x288), SCIF(704x576), 1/16 NTSC(160x120), 1/4 NTSC(320x240), NTSC(640x480), 1/16 PAL(192x144), 1/4 PAL(384x288), PAL(768x576). Le menu Modes permet de changer la fenêtre de vidéo. Par défaut, ce mode est verrouillé, ce qui signifie que la fenêtre a été verouillée sur la source vidéo indiquée. Vous pouvez utiliser les touches claviers "Barre d'espace", "Entrée", ",", "<" ou ">" pour passer d'un participant à l'autre. Quand VIC tourne en tandem avec RAT (un utilitaire audio du MBone), lorsque la voix passe à un autre interlocuteur la fenêtre vidéo est permutée pour correspondre à l'orateur. Vous pouvez utiliser cette méthode avec plusieurs fenêtres vidéo simultanées. Raccourcis / Touches claviers : En dehors du bouton Dismiss, vous pouvez utiliser les combinaisons de touches suivantes : "q", "d" pour fermer cette fenêtre. Utiliser "Entrée", "Barre d'espace", ou ">" pour passer d'un participant à l'autre. Utiliser "<" ou "," pour passer d'un participant à l'autre dans le sens inverse. Page : 99 / 136

100 Le panneau de contrôle Trois parties composent se menu : Transmission, Encoder, Display, Session. La partie Transmission est composée de deux boutons et deux barres de sélection. Cocher Transmit permet de transmettre de la vidéo, pour arrêter de transmettre il faut soit décocher Transmit, soit cliquer sur le bouton Release (dans ce cas, si la carte d'acquisition requière un accès exclusif elle peut être réutilisée par une autre application). Si la périphérique ne peut pas être ouverte (par exemple, la périphérique de capture peut ne pas être présente ou elle peut être occupée par une autre application) un message d'erreur apparaît. A la droite de cette partie, affichage et paramétrage permettent d'ajuster le ratio de la vidéo et de la bande passante, respectivement en nombre d'image par seconde (de 1 à 30 images par seconde) et en nombre de bit par seconde (de 1kbps à 1024kbps). La partie Encoder permet de paramétrer le signal vidéo que vous aller transmettre. A noter, certaines options ne sont visibles que pour certains périphériques de capture. Vous pouvez choisir dans la liste déroulante du bouton Device une périphérique parmi celle qui sont disponibles (installées) sur votre ordinateur. Par exemple, sous Linux et à condition d'avoir installer le module bttv et de posséder une carte Osprey vous obtiendrez dans la sélection du bouton Device : tout d'abord "X11" qui transmet votre bureau d'ordinateur ou encore "v4l - BT878(Hauppauge (bt878))" et ce qui n'est pas le cas sous Windows un bouton Port vous permettant de choisir l'entrée physique sous laquelle vous avez branché votre caméra, un autre bouton Type qui vous permettra de sélectionner le signal désiré : auto, NTSC, PAL, SECAM. D'autres options sont disponibles dans cette partie : La possibilité d'ajuster la qualité de la vidéo Quality, de 1 à 30, 1 étant la meilleure qualité et 30 la plus mauvaise ; 5 est un bon compromis pour le choix de la qualité. Page : 100 / 136

101 Le choix du CoDec avec les normes suivantes disponibles : Par défaut, format d'encodage compatible avec le protocole de vidéo H323 de l'iut-t. Les tailles d'image disponibles sont small QCIF(176x144), normal CIF(352x288). h261 - à intervalles réguliers une image codée en JPEG - codage du mouvement et des différences - compression optimale - adapté aux débits de n x 64 Kbps H263 est une amélioration significative sur H261 qui a des options h263 additionnelles de codage et soutient un plus grand nombre de formats de vidéo. H263 la version 2, ou H263+, offres encore d'autres améliorations h263+ sur l'exécution de la compression et les options additionnelles de codage. pvh "Progressive Video with Hybrid transform" Xerox PARC Network Video. - transformation en ondelettes nv - codage des différences - codage rapide Accepte une haute résolution : 768x576 mais demande une grande nvdct bande passante (lors de mes tests 2Mb/s). Motion JPEG : JPEG animé. - gourmand en bande passante jpeg - supporté seulement par certaines périphériques qui font de la compression JPEG raw Pour le format CellB, les blocs sont codés selon la syntaxe de Sun Microsystems. CellB est un codage qui consiste à une technique de cellb tronquage des blocs qui donne un gain de compression de 16:1 avec une faible qualité d'image. La simplicité de ce codec résulte d'une implémentation rapide. bvc La partie Display est composée de boutons influençant l'affichage des vidéos : Tile est utilisé pour réarrangé les vidéos dans la fenêtre principale de windows. La partie Session fait référence aux informations que vous avez soumis au lancement de VIC c'est à dire l'adresse IP, le port UDP de la session, l'identifieur source RTP de l'instance locale et enfin le TTL ("Time To Live") ; il y a aussi la possibilité de changer l'identifiant ou encore d'entrer une note. En dessous vous trouverez deux boutons Global Stats et Members. Ce dernier vous permet de connaître l'ensemble des participants à la session que se soient ceux qui émettent ou non. L'autre affiche les statistiques de la session RTP. Le paramétrage du périphérique d'acquisition (une carte Osprey-210) sous Windows Si vous devez configurer votre périphérique vidéo, cochez dans la partie Encoder / Options... : Configure on Transmit et au moment au vous voudrez transmettre (Transmission / Transmit) vous obtiendrez une boîte de dialogue propre à votre périphérique. Les captures d'écran suivantes ont été réalisées sous Windows XP avec une carte d'acquisition Osprey-210. Page : 101 / 136

102 Pourquoi configurer votre périphérique? Car certains modèles de caméra envoie d'office une résolution différente de celle sélectionnée par VIC et entraîne une fermeture impromptue de VIC. Vous pouvez ainsi configurer une résolution adéquate : pour du CIF 352*288 lorsque vous avez choisi normal dans Encoder, du 4CIF 704*576 lorsque vous avez choisi large dans Encoder, etc. A noter, la taille 4CIF (disponible avec la norme h263+) ne fonctionne pas pour le VIC de ucl ceci a été résolu sous VIC GC. Vous avez aussi des options auxiliaires comme la luminosité, le contraste, etc. La sélection des standards vidéo NTSC, PAL, SECAM l'entrée physique Composite, SVideo qui contrairement à Linux (voir chapitre plus au haut sur l'encoder) ne sont pas intégrés directement dans les menus de VIC mais sont présents "ici". Page : 102 / 136

103 Manuel d utilisation de VIC-GC Le logiciel VIC-GC est disponible sur le site de Renater : Cette extension du logiciel VIC permet d afficher des transparents au format 4CIF (704*576 pixels). Cette fonctionnalité a été développée dans le cadre des prestations (conférences, téléenseignement, etc.) de l association Aristote par Aurélien Amacker pour les environnements Linux et Christophe Herviaux pour l environnement Windows au cours de l année L utilisation est la suivante : Dans la fenêtre principale, on accède au menu par le bouton du même nom. Dans le menu, on sélectionne la norme h263+ dans la partie Encoder, puis à la droite de cette sélection la définition large (4CIF). Pour affiner les paramètres de retransmission, Rate Control par exemple, ou pour sélectionner et paramétrer le périphérique vidéo (en 4CIF notamment) se reporter au guide d utilisation de VIC. On peut ainsi cliquer sur le bouton Transmit dans la partie Transmission pour émettre au format 4CIF. Remarque : pour pouvoir émettre au format 4CIF, il faut que le périphérique vidéo accepte une résolution minimale de 704*576 pixels. Page : 103 / 136

104 Manuel d utilisation de RAT RAT peut-être utilisé pour la vidéoconférence point à point ou en multipoint (plus de deux participants en même temps). RAT contient plusieurs fenêtre : une principale et une pour les options. Si votre carte son n'est pas supportée par la 4ème version de RAT, vous pouvez essayer la version 3. Plusieurs processus sont mis en route au lancement de RAT : rat, ratui. Requis Il n'y a pas besoin d'équipement spécifique en dehors de la capacité de l'ordinateur d'émettre ou de recevoir de l'audio. Pour pouvoir transmettre de l'audio, vous devez avoir un microphone, des haut-parleurs et une carte son. Environnements et matériels utilisés pour les Tests La version de RAT utilisée pour les tests : v Plusieurs systèmes d'exploitation ont été utilisés pour ces tests : Linux Debian, Windows 2000 et Windows XP. En ce qui concerne le matériel audio, une carte son intégrée et un microphone. Pour les ordinateurs,... Installation Télécharger la version correspondant à votre système sur le site suivant : Lancement de RAT Il y a deux façons de lancer RAT, par SDR (utilitaire de session du MBone) et par ligne de commande. Le format de la ligne de commande est constitué comme suit : Prompt> rat [options] <adresse_multicast/port> L'adresse de multidiffusion (multicast) doit être comprise entre et Une option très utilisée est le TTL ("Time To Live"), en effet il est initialisé par défaut à 16 ce qui est insuffisant pour la plupart des cas (63 pour couvrir l'europe et 127 pour diffuser partout). Exemple de ligne de commande ayant pour adresse de multidiffusion (multicast) et pour port 3456 avec un TTL de 63 : Prompt> rat -t /3456 Vous pouvez aussi utiliser une adresse d unidiffusion (unicast) à la place de l'adresse de multidiffusion (multicast), l'émetteur et récepteur se connectent sur l'adresse du distant en conservant le même numéro de port. Page : 104 / 136

105 Les options en détail : -crypt key ou -k key Permet de crypter avec une clé spécifiée (Disponible dans le menu Option>Security. Testé -f c1/c2/../cn [DVI VDVI LPC..] Permet de spécifier les Codecs utilisés lors de la transmission. Testé -allowloopback Entraîne un retour des paquets RTP pendant les sessions de multidiffusion (multicast) (utilisé pour le "debuggage"). Non testé -name name Permet de définir le nom de la fenêtre principale. Testé -p priority Permet de définir la priorité du processus sous Windows : de 1 à 3 (priorité normale à priorité critique). Aucune Non testé nécessité de changer ce paramètre. -repair method [Pattern-Match Repeat Noise None] Choix possible dans Options>Reception. Testé -t ttl [ ] Permet pour les adresses uniquement de multidiffusion (multicast) de désigner le TTL ("Time To Testé Live"). Par défaut, si l'on ne met pas d'indication il est à 15. -T Non testé -version Pour connaître la version du logiciel RAT. Testé La fenêtre principale La fenêtre principale est divisée en trois sections : Dans la section supérieure, on trouve le panneau de contrôle Listen pour recevoir de l'audio et le panneau de contrôle Talk pour envoyer de l'audio. Dans la section du milieu, on trouve la liste des participants qui reçoivent ou envoient de l'audio dans la salle virtuelle. A l'instar du logiciel vidéo du MBone VIC, on est listé comme participant dès le lancement de RAT que l'on émette de l'audio ou non. Dans VIC, avant que vous ayez commencé à transmettre, les autres participants ne save nt pas que vous êtes connecté. Dans la section inférieure, en dehors de l'information concernant la salle virtuelle (nom, adresse IP, port et TTL) on peut trouver les cinq boutons suivants : Enregistrement : ouvre une fenêtre pour enregistrer/envoyer un fichier audio. Vous pouvez envoyer un fichier avec les extensions suivantes *.wav ou *.au à tous les participants de la salle virtuelle de RATv4. Vous pouvez aussi sauvegarder le flux vidéo entrant avec les même extensions *.wav ou *.au. Aide : valider ou non l'apparition de message d'aide déclenché lors du passage de la souris. C'est utile pour le débutant pour l'apprentissage de chacune des fonctionnalités de RATv4. Options : affichage de la fenêtre de contrôle audio. About : affiche les informations a propos de RATv4. Quit : pour quitter RATv4. Page : 105 / 136

106 Les participants L'orateur est surligné. Votre nom apparaît toujours en haut de la liste. Lorsque vous parlez votre nom est surligné. Cliquer sur le nom d'un participant affiche les statistiques le concernant, incluant les informations personnelles, le décodeur et les informations réseaux. Raccourcis / Touches claviers : Un clique gauche de la souris sur un participant permet de voir les informations lui correspondant. Si vous avez une souris trois boutons, vous pouvez avec celui du milieu couper ou allumer le son sur chacun des participants. C'est possible aussi avec la combinaison : touche "Ctrl" et clique gauche de la souris. Presses "q" pour quitter RATv4 ou cliquer sur le bouton "Quit". Ecouter Pour écouter chacun des participants entrain de parler, faire attention que le volume des haut-parleurs ainsi que de la configuration de la carte son n'est pas à 0, vous pouvez dès lors cocher Listen. Décocher cette option permet de rendre muet les participants. Vous pouvez utiliser la barre de défilement pour ajuster le volume. Quand un participant parle, le volume est mesuré et le nom est surligné dans la fenêtre principale. Pour certaines cartes audio, vous pouvez choisir la sortie sur laquelle votre ordinateur peut retransmettre le son (haut-parleur, sortie "Line-out",...). Parler Pour parler à l'ensemble des personnes, vous pouvez cocher l'option Talk ou maintenir appuyé le clique droit de la souris n'importe où dans la fenêtre principale. Vous pouvez ajuster le contrôle de volume du microphone avec la barre de défilement. Quand vous parlez, de la même manière que lorsque vous écoutez les autres participants, le volume mesuré doit ne pas atteindre aire rouge sinon vous risquez de créer une distorsion du son. Pour régler correctement se problème, vous avez besoin des autres participants pour vous dire quand votre volume est correctement réglé. Pour certaines cartes audio, vous pouvez choisir la sortie sur laquelle votre ordinateur peut recevoir du son (microphone, entrée "Line-in", CD audio,...). Le microphone peut-être allumé ou éteint temporairement en maintenant le clique droit de la souris dans la fenêtre principale de RATv4 et RATv3. C'est utilisé pour répondre instantanément aux autres orateurs ou dans l'autre cas pour rendre muet son micro le Page : 106 / 136

107 temps d'attendre une réponse par exemple. Certains problèmes peuvent gêner une conversation, il se peut que une mauvaise qualité de microphone entraîne des parasites. Un autre problème peut être aussi un retour de votre propre voix, ceci peut-être régler car certaines cartes sons entraîne un retour audio local du microphone modifiable par le logiciel de configuration de cette dernière. La fenêtre des options Cliquer sur le bouton "Options" dans la fenêtre principale affiche le panneau de commande de RAT. Les options disponibles se compose en 7 catégories : préférence personnelle, transmission, réception, audio, Codecs, sécurité et interface. Les valeurs par défaut sont stockées dans la regedit de Windows ou dans les.ratdefaults sous votre répertoire local de Linux. Informations personnelles C'est ici que vous pouvez entrer les informations sur vous-même dans RATv4. Ces valeurs sont utiles pour informer les autres utilisateurs. Vous pouvez spécifier le nom qui apparaîtra dans la fenêtre principale. Les informations tapées ici seront enregistrées dans la base de registre de Windows ou dans le fichier.rtpdefaults sous votre répertoire local de Linux. Page : 107 / 136

108 Transmission Comme l indique le titre de cette partie, il s agit de définir les paramètres de transmission : format d encodage, etc. Réception Si le mode de lecture «Lecture Mode» est sélectionné, le «playout delay» du récepteur est augmenté. Ceci a pour conséquence une meilleure exécution des variables de délai du réseau, aux dépens de l'interactivité. Page : 108 / 136

109 Audio C'est ici que vous pouvez paramétrer le taux d'échantillonnage et les canaux audio qui y sont énumérés. Il est recommandé d'arrêter la suppression de silence "Silence Suppression"). Quand la suppression de silence est éteinte, vous devriez rendre muet votre microphone toutes les fois que vous ne parlez pas. Autrement vous transmettrez sans interruption le bruit de fond. Codecs Ici les Codecs audio disponibles de RATv4 sont énumérés. Par exemple, PCMU-8k-Mono peut-être utilisé pour des raisons de compatibilité avec H.323. RATv4 peut également décoder les autres formats audio entrants énumérés ici de manière transparente. Page : 109 / 136

110 Sécurité On peut définir dans cette catégorie une clé cryptée qui permettra de créer une session non visible pour les utilisateurs n'ayant pas cette clé. Interfaces Dans cette partie il y a 4 dispositifs que vous pouvez mettre à "Marche/Arrêt". En cochant "Powermeters active" vous saurez si quelqu'un parle par l'affichage de la barre de contrôle de puissance. Cela permet également de régler le volume. Ce n'est pas une bonne idée de neutraliser ce dispositif. L'aide ("Ballon Help") activée vous aide par déplacement de la souris de connaître les informations concernant une commande. La liste des participants ("Participant list") peut-être ou non affichée dans la fenêtre principale. La dernière commande ("File Control Window") est employée pour afficher la fenêtre d'enregistrement/envoie de fichiers audio. Page : 110 / 136

111 Manuel d utilisation de VideoLAN Définition La FAQ de Renater concernant videolan : VideoLAN est un projet multi plate-forme développé initialement par des étudiants de l'ecole Centrale de Paris sous licence GNU «General Public License» permettant de lire les vidéos au format Mpeg, DVD, VCD, DivX et depuis une carte satellite par le biais d'un réseau. Ce logiciel peut s'utiliser soit comme un simple lecteur à la fois léger (19 Mo sur le disque dur) et puissant (de nombreuses fonctions sont disponibles), soit, en liaison avec la partie "serveur" du logiciel, pour lire des vidéos diffusées sur un réseau local en streaming, il accepte désormais IPv6. VideoLAN comprend VLS et VLC : il y a un serveur VLS (sous Linux et Windows) qui diffuse la vidéo d'une source X (disque dur, lecteur DVD, cartes vidéos, etc.) et il y a en réception le poste client VLC (multi plate-forme dont Windows) qui lit la vidéo ainsi diffusée. Mais le client pourra tout aussi bien utiliser le lecteur pour simplement lire les propres vidéos de sa machine. VLS (VideoLAN Server), qui est capable de diffuser des fichiers MPEG-1, MPEG-2 et MPEG-4, des DVDs, des canaux satellite numériques, des chaînes de télévision numérique terrestre, et de la vidéo en temps réel sur un réseau en unidiffusion (Unicast) ou multidiffusion, VLC (à l'origine, VideoLAN Client), qui peut être utilisé en tant que serveur, pour diffuser des fichiers MPEG-1, MPEG-2 et MPEG-4, des DVDs, ou de la vidéo en temps réel sur un réseau en unidiffusion ou multidiffusion ; ou utilisé en temps que client pour recevoir, décoder et afficher des flux vidéo sous de nombreux systèmes d'exploitation. Voici le schéma global de la solution VideoLAN complète : La solution VideoLAN comp lète Page : 111 / 136

112 Les tests qui vont être effectuer concerneront VideoLAN Client (VLC), en effet le développement de VLC a permis de réunir en grande partie les caractéristiques du serveur (VLS). De plus, la configuration de VLC est plus intuitive et donne le choix entre une interface utilisateur graphique et l appel par ligne de commandes tandis que VLS utilise un script de configuration matériel et logiciel. Requis Pour émettre un flux vidéo il n'y a pas besoin d'équipement spécifique. Pour pouvoir transmettre de la vidéo, vous devez avoir une «WebCam» ou une caméra et une carte d'acquisition sur votre ordinateur. Pour pouvoir transmettre de l'audio, vous devez avoir un microphone, des haut-parleurs et une carte son. Environnements et matériels utilisés pour les Tests La version de VLC utilisée pour les tests : VideoLAN étant un produit multi plate-forme, la possibilité a été donné de le tester sous notre plate-forme de tests IPv4 et IPv6 avec les systèmes d exploitation suivant : Linux RedHat 9.0 Microsoft Windows 2000 Microsoft Windows XP En ce qui concerne le matériel vidéo, tests suivants ont été effectué avec une caméra Logitec QuickCam (remarque cette caméra a été reconnue par la distribution RedHat sur notre plateforme de test, il n y a donc pas eu à installer les drivers ad-hoc). En ce qui concerne le matériel audio, une carte son intégrée et un microphone. Les ordinateurs à notre disposition sont des Pentium 4 à 2,4Ghz (carte réseau intégrée de 1Gbit/s) sur un réseau à 10 Mbit/s. Installation Pour toute installation de VLC sur un système d exploitation particulier, vous trouverez des informations détaillées sur Installation de VLC sous Linux RedHat : Vous trouverez les paquetages nécessaires à l adresse suivante : Les deux paquetages : vlc-binary.tar.gz redhat9-updates.tar.gz Page : 112 / 136

113 Les commandes pour l installation des paquetages : tar zxf vlc-binary.tar.gz rpm U vlc/* -- force (Remarque : pour cette dernière commande il y avait un problème de dépendance entre paquetage, il a donc fallu désinstaller certains paquetages pour faire la mise à jour.) Installation de VLC sous Microsoft Windows XP : Installation des pilotes du périphérique vidéo (WebCam). Vous trouverez l exécutable nécessaire à l adresse suivante : L interface graphique Il existe deux manières de paramétrer VLC, la première étant la ligne de commande au lancement de VLC et la seconde l interface graphique. fenêtre principale VLC est à la fois un lecteur multimédia, il comprend donc les fonctions lecture, pause, piste suivante, etc. et un utilitaire de diffusion ouvrir un flux d entrée, de sortie. Remarque : un certain nombre d'options ne sont disponibles qu'en utilisant la ligne de commande. Page : 113 / 136

114 Ouverture d un flux Vous pouvez ainsi ouvrir un fichier (AVI, etc.) comme flux vidéo Ouvrir un flux > fichier Vous pouvez ainsi ouvrir un flux réseau si il y a un émetteur sur le réseau en multicast / unicast, IPv4 / IPv6 un flux vidéo ou/et audio. Ouvrir un flux > Réseau Vous pouvez ainsi ouvrir un flux provenant d une périphérique vidéo : WebCam, carte d acquisition, etc. d une périphérique audio : carte son, Ouvrir un flux > Entrée DirectSchow Page : 114 / 136

115 Envoie du flux précédent Cette étape est utile seulement pour l émission. Vous pouvez ainsi envoyer le flux précédemment ouvert vers une ou plusieurs directions : Local (visualisation) UDP (émission unicast multicast) Sous différents formats vidéo et audio : Flux de sortie Une annonce SAP peut-être mise en place lors de la diffusion de la vidéo. Pour se faire, cochez «Annonce SAP» et entrez le nom du canal sous laquelle la vidéo sera référencée. Réception du flux précédent Transmission d un flux vidéo et audio Pour pouvoir écouter l ensemble des annonces SAP émises et sélectionner une vidéo particulière, vous devez lancer VLC en ligne de commande avec l option adéquate : cd "c:\program Files\VideoLAN\VLC" VLC.exe -v --extraintf sap Dans VLC, vous pouvez ainsi afficher la liste de lecture en cliquant sur Vue puis sur liste de lecture. Page : 115 / 136

116 VideoLAN - 1 er test : diffusion d une vidéo Test IPv4 Unicast - point à point diffusion vidéo Système d exploitation de Windows XP (émetteur et récepteur local) l émetteur Windows 2000 (test de deux émetteurs) Interface utilisateur de l émetteur Par interface graphique : fichier (figure 2.) > ouvrir un fichier (avancé) (figure 3.) > sélection du fichier adéquate > cocher flux de sortie > paramètres > jouer en local (figure 6.) > Cocher UDP et indiquer l adresse unicast IPv4 du récepteur > OK > OK Système d exploitation du Windows 2000 récepteur Linux RedHat 9.0 Interface utilisateur du récepteur Par interface graphique : fichier > ouvrir un flux réseau (figure 4.) > sélectionner UDP/RTP et le port adéquat > OK CoDec d envoie vidéo MPEG4 Caractéristiques du fichier envoyé Vidéo : 609 Mo, 958 Kbps, 25.0 fps, res. 576*240 (2.21:1), XVID = XVID Mpeg-4, Supporté Audio : 81 Mo, 128 Kbps, Hz, 2 canaux, 0x55 = MPEG Layer-3, Supporté Bande passante utilisée Oscille entre 80 et 200 kb/sec [1] Qualité de l image / son Réception nette : réception identique à l émission léger décalage (moins d une seconde) Test de lancement de plusieurs Non concluante, le récepteur ne peut recevoir aucun des vidéos vers un seul client deux flux et ne réceptionne plus rien. Compatibilité Vic Rat Non : test d encodage avec H263, aucune réception (que se soit avec VIC ou VLC). Concluant? Oui : qualité de réception = qualité d émission, bande passante de moins de 200kB/s Pas de possibilité de recevoir plusieurs vidéos (exclu l utilisation pour des visioconférences). [1] Les tests de bande passante ont été effectués avec le logiciel «Du Meter». Test IPv4 Multicast - point à multipoint diffusion vidéo Interface utilisateur de l émetteur Par interface graphique : fichier > ouvrir un fichier (avancé) > sélection du fichier adéquate > cocher flux de sortie > paramètres > jouer en local > Cocher UDP et indiquer l adresse multicast IPv4 du récepteur >OK>OK Interface utilisateur du récepteur Par interface graphique : fichier > ouvrir un flux réseau > sélectionner Mutlidiff. UDP/RTP, adresse et port >OK Qualité de l image / son Réception nette : réception identique à l émission léger décalage (moins d une seconde) Test de diffusion à distance (en Nécessité de changer le TTL initialement à 1, dehors du réseau) Paramètres > Préférences > Flux de sortie > cocher Options avancées > TTL à 127 >> Fonctionne Concluant? Oui : qualité de réception = qualité d émission (réception identique à l original), bande passante de moins de 200kB/s Possibilité de plusieurs récepteurs (Tests avec 3 récepteurs dont 1 en dehors du réseau local). Page : 116 / 136

117 Les tests suivants n ont pas été effectués dans le cadre de notre plate-forme de Tests IPv6 en salle 104 mais sur un autre réseau IPv6 avec des stations et des périphériques similaires. Test IPv6 Unicast - point à point diffusion vidéo Système d exploitation de Windows XP (émetteur et récepteur local) l émetteur Interface utilisateur de l émetteur Par interface graphique : fichier > ouvrir un fichier (avancé) > sélection du fichier adéquate > cocher flux de sortie > paramètres > jouer en local > Cocher UDP et indiquer l adresse unicast IPv6 du récepteur > OK > OK Système d exploitation du Windows 2000 récepteur Linux RedHat 9.0 Interface utilisateur du récepteur Par interface graphique : Paramètres > Préférences > Entrée > cocher Forcer l utilisation d IPv6 Fichier > Ouvrir un flux réseau > sélectionner UDP/RTP et le port adéquat > OK CoDec d envoie vidéo MPEG4 Caractéristiques du fichier envoyé Vidéo : 609 Mo, 958 Kbps, 25.0 fps, res. 576*240 (2.21:1), XVID = XVID Mpeg-4, Supporté Audio : 81 Mo, 128 Kbps, Hz, 2 canaux, 0x55 = MPEG Layer-3, Supporté [2] Bande passante utilisée Oscille entre 80 et 200 kb/sec Qualité de l image / son Réception nette : réception identique à l émission léger décalage (moins d une seconde) Test à distance (en dehors du Oui (changement de TTL). [3] réseau local) Concluant? Oui : qualité de réception = qualité d émission, bande passante de moins de 200kB/s [2] Les tests ont été réalisé avec une vidéo reconnue par VLC, certains formats peuvent être mal interprétés lors du décodage de la vidéo par VLC. Test IPv6 Multicast - point à multipoint diffusion vidéo Interface utilisateur du récepteur : Par interface graphique : fichier > ouvrir un fichier (avancé) > sélection du fichier adéquate > cocher flux de sortie > paramètres > jouer en local > Cocher UDP et indiquer l adresse multicast IPv6 du récepteur >OK>OK Interface utilisateur de Par interface graphique : fichier > ouvrir un flux réseau l émetteur : > sélectionner UDP/RTP et le port adéquat > OK Qualité de l image / son : Réception nette : réception identique à l émission léger décalage (moins d une seconde) Test de diffusion à distance (en Nécessité de changer le TTL initialement à 1, dehors du réseau) : Paramètres > Préférences > Flux de sortie > cocher Options avancées > TTL à 127 Réception d un autre client en dehors du réseau local. Concluant? Oui : qualité de réception = qualité d émission, bande passante de moins de 200kB/s Page : 117 / 136

118 VideoLAN 2 ème test : diffusion d un flux en temps réel Test IPv4 Unicast ou Multicast diffusion WebCam Système d exploitation Linux RedHat 9.0 (émetteur et récepteur local) de l émetteur Interface utilisateur de Par ligne de commande (en une seule ligne) : l émetteur vlc -vvv v4l:/dev/video0 :norm=secam: frequency= :size=640x480 :channel=0 :adev=/dev/dsp :audio=0 --sout '#transcode{ vcodec=mp4v,acodec=mpga,vb=3000, ab=256,vt=800000,keyint=80,deinterlace } :std{access=udp, mux=ts,url= }' --ttl 12 Système d exploitation Windows 2000 du récepteur Interface utilisateur du récepteur CoDec d envoie vidéo Caractéristiques du flux envoyé Windows XP Par interface graphique : fichier > ouvrir un flux réseau > sélectionner UDP/RTP et le port adéquat (ou Multidiff. Avec l adresse multicast si besoin) > OK MPEG4 où : /dev/video0 est l'adresse correspondant à votre carte d'acquisition ou à votre WebCam, norm=secam est le nom du standard du signal analogique (celà peut être pal, secam ou ntsc, frequency= est la fréquence en khz de la chaîne (Attention:avec VLC < 0.6.1, la fréquence est la fréquence du canal en MHz, multipliée par 16), size=320x240 est la taille de la vidéo que vous désirez diffuser (vous pouvez également indiquer une taille standard, telle que subqcif (128x96), qsif (160x120), qcif (176x144), sif (320x240), cif (352x288) ou vga (640x480)), channel=0 est le numéro du canal (généralement, 0 pour le tuner, 1 pour le composite, et 2 pour Svidéo), adev=/dev/dsp est le périphérique audio, audio=1 est le numéro du canal audio (généralement, 0 pour mono et 1 pour stéréo), vcodec=mp4v est le format d'encodage vidéo (mp4v pour MPEG-4, mpgv pour MPEG-1, mais aussi h263, DIV1, DIV2, DIV3, I420, I422, I444, RV24, YUY2), acodec=mpga est le format audio d'encodage (mpga pour MPEG audio layer 2, a52 pour A52 / AC3), vb=3000 est le taux de compression vidéo en Kbps, ab=256 est le taux de compression audio en Kbps Page : 118 / 136

119 vt= est la tolérance sur le bitrate vidéo en bps, keyint=80 est le nombre maximal d'image entre deux images "I", deinterlace pour désentrelacer le flux à la volée, est soit : o l'adresse IP de la machine vers laquelle vous désirez diffuser en unicast ; o le nom DNS de la machine vers laquelle vous désirez envoyer en unicast ; o une adresse IP multicast. 12 est la valeur du TTL (Time To Live) de vos paquets IP (cela signifie qu'ils pourront traverser 11 routeurs). Bande passante utilisée Qualité de l image / son Concluant? Oscille entre 50 et 80 kb/sec Réception nette : fluide 25 f/s 2 secondes de décalage Qualité de réception en MPEG4 et bande passante de moins de 80kB/s mais décalage temporel. Pas de possibilité de recevoir plusieurs vidéos (exclu l utilisation pour des visioconférences). Test IPv6 Unicast ou Multicast diffusion WebCam Système d exploitation Windows XP de l émetteur Interface utilisateur de Par interface graphique : fichier > ouvrir un flux > Entrée l émetteur DirectShow > Cliquer sur le bouton Rafraîchir et choisissez le périphérique adéquat > cocher flux de sortie > paramètres > Cocher UDP et indiquer l adresse unicast ou multicast IPv6 du récepteur > OK > OK Système d exploitation Windows 2000 du récepteur Interface utilisateur du récepteur CoDec d envoie vidéo Bande passante utilisée Qualité de l image / son Concluant? Par interface graphique : fichier > ouvrir un flux réseau > sélectionner UDP/RTP et le port adéquat (ou Multidiff. Avec l adresse multicast si besoin) > OK MPEG4 Oscille entre 50 et 80 kb/sec Nette 25 f/s Qualité de réception en MPEG4 et bande passante de moins de 80kB/s mais décalage temporel. Pas de possibilité de recevoir plusieurs vidéos (exclu l utilisation pour des visioconférences). Tableau récapitulatif Vidéo format Bande passante Maxi F/S Résolution H261 (ex. VIC) kbit/s 30F/S QCIF,CIF MPEG4 (ex VideoLAN) kbit/s 30F/S QCIF,CIF Page : 119 / 136

120 Annexe 3. Le routage Fichier /etc/rc.conf Initialisé par l installeur sysinstall ou modifié manuellement, le fichier rc.conf permet entre autre de décrire le nom de l hôte local, la configuration des interfaces potentielles et les services à lancer lors du démarrage de l ordinateur. Le but de rc.conf n est pas de lancer des commandes ou d effectuer des tâches au démarrage, il est plutôt utilisé par les divers scripts de démarrage de /etc qui y trouvent les paramètres nécessaires. On obtient ainsi : /etc/rc.conf # Activation de la pile IPv6 ipv6_enable="yes" # Nom de l hôte local hostname="routegn6.renater.gn6.net" # Configuration de la machine comme routeur IPv6 ipv6_gateway_enable="yes" # Modules lancés au démarrage sshd_enable="yes" net_snmpd_enable="yes" net_snmpd_flags="yes" Named_enable="YES" moused_enable="yes" moused_port="/dev/psm0" usbd_enable="no" sendmail_enable="no" keymap="fr.iso.acc" linux_enable="yes" Fichier /usr/local/etc/zebra.conf Chaque démon a son propre fichier de configuration, zebra.conf est le nom du fichier de configuration par défaut du routeur Zebra. Il permet de définir les options de routage. /usr/local/etc/zebra.conf hostname Router password zebra enable password zebra! interface xl0 ip address /29 ipv6 address 2001:660:3001:7801::53/64 ipv6 nd suppress-ra! interface xl1 ipv6 address 2001:660:3001:7802::53/64 no ipv6 nd suppress-ra ipv6 nd prefix-advertisement 2001:660:3001:7802::/ onlink autoconfig Page : 120 / 136

121 interface plip0 ipv6 nd suppress-ra! interface lo0! interface gif0! ipv6 address 2001:660:3001:7803::1/64 no ipv6 nd suppress-ra ipv6 nd prefix-advertisement 2001:660:3001:7803::/ onlink autoconfig! ip route / ipv6 route ::/0 2001:660:3001:7801::1/48!! line vty Fichier /usr/local/etc/ripngd.conf Ce fichier permet la configuration par défaut du démon de routage RIPng. hostname ripngd password zebra router ripng network xl0 passive-interface xl1 redistribute connected log stdout /usr/local/etc/ripngd.conf Fichier /etc/dhcpd.conf Ce fichier permet la configuration par défaut du démon du DHCP en IPv4 : la liste des adresses distribuées ainsi que la passerelle et le DNS par défaut. ddns-update-style ad-hoc; default-lease-time 600; max-lease-time 7200; get-lease-hostnames true; option subnet-mask ; option domain-name-servers ; option interface-mtu 1500; /etc/dhcpd.conf subnet netmask { option routers ; range ; } Page : 121 / 136

122 Fichier de configuration du 6wind Ce fichier correspond à la configuration du routeur 6wind 6110, routage, interface, 6wind.conf gen # GEN STATEMENT hostname 6wind domainname 6wind.renater.gn6.org enable ipv4forwarding enable ipv6forwarding eth0_0 # IPV4 ADDRESS ipaddress /30 # IPV6 ADDRESS ipaddress 2001:660:3001:6321:2::2/64 eth1_0 # IPV4 ADDRESS ipaddress /28 # IPV6 ADDRESS ipaddress 2001:660:3001:7801::1/64 # IPV6 PREFIX prefix 2001:660:3001:7801::/64 rtg # IPV4 ROUTE route / # DEFAULT ROUTE ipv4_defaultroute ipv6_defaultroute 2001:660:3001:6321:1::1 # DEFAULT MULTICAST ROUTE ipv6_defaultmroute 2001:660:3001:6321:1::1 # DYNAMIC ROUTING PROTOCOLS dynamic router rip redistribute connected network eth0_0 network eth1_0 # router ripng default-information originate network 2001:660:3001:7801::/64 redistribute connected # router bgp neighbor 2001:660:3007:604:1:: remote-as 1717 neighbor 2001:660:3007:604:1:: soft-reconfiguration inbound # address-family ipv6 multicast network 2001:660:3001:7800::/52 neighbor 2001:660:3007:604:1:: activate exit-address-family # exit-dynamic mig # 6IN4 TUNNELS 6in :660:3007:604:2:: 2001:660:3007:604:1:: snmp rocommunity IPv6 default rwcommunity IPv6 default enable snmp Page : 122 / 136

123 Annexe 4. Le DNS Fichier /etc/resolv.conf Ce fichier doit contenir l'adresse de votre serveur de noms (si vous en utilisez un) et votre domaine. Si par exemple vous êtres une machine parfaitement qualifiée sur l'internet par le exemple.gn6.renater.fr, votre domaine est juste gn6.renater.fr (l instruction search permet d identifier le domaine IPv6 de gn6.renater.fr. Un exemple pratique; votre machine s'appelle exemple.gn6.renater.fr et utilise un serveur de noms qui a pour adresse ; alors votre fichier /etc/resolv.conf sera : search gn6.renater.net nameserver 2001:660:3001:7801::53 nameserver /etc/resolv.conf Fichier /etc/host Ce fichier permet de spécifier au système la manière de résoudre les adresses IP en fonction des noms. Les premières lignes indiquent aux librairies de commencer par rechercher les noms dans /etc/hosts, et si elles ne trouvent pas ce qu'il leur faut, de demander ensuite ces renseignements au serveur de noms (BIND). L adresse de Loopback IPv6 est ::1. Les adresses en FF0X sont destinées au multicast PC3-IPv6 localhost.localdomain localhost 2001:660:3001:7801:2b0:d0ff:fe9a:42a1 PC3-IPv6 localhost.localdomain localhost /etc/host ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters Page : 123 / 136

124 L arborescence des fichiers etc named.conf named.root named.run rndc.conf ce répertoire contient l ensemble des fichiers de configuration forward ce répertoire contient les zones directes gn6.renater.fr localhost reverse ce répertoire contient les zones inverses ip6.arpa ip6.int ip6.arpa ip6.int in-addr.arpa localhost-rev keys confv6-keys rndc-keys ce répertoire contient les clés Log ce répertoire contient les logs générés par named dns-security.log dns-update.log named.log named.pid named.run test named rndc ce répertoire contient des fichiers de lancement non nécessaires Fichier /etc/dns/etc/named.conf Ce fichier contient la liste des zones IPv4 et IPv6 (directes ou inverses) et le paramétrage des fichiers de traces. /etc/dns/etc/named.conf /////////////////////////////////// // Dynamic zones, [GN6] 30/06/04 // /////////////////////////////////// Options { directory "/etc/dns"; pid-file "log/named.pid"; listen-on-v6 { any; }; listen-on { Page : 124 / 136

125 }; ; ; }; allow-transfer { ::1; secondaries; }; include "keys/rndc-key"; controls { inet ::1 port 953 allow { ::1; } keys { "rndc-key"; }; }; acl "secondaries"{ ; 2001:660:3001:4001::53; 2001:660:3001:4002::60; }; logging { category dnssec { security_log; }; category security { security_log; }; category update { update_log; }; channel security_log { file "log/dns-security.log" versions 2 size 20m; print-time yes; print-category yes; print-severity yes; severity info; }; channel update_log { file "log/dns-update.log" versions 2 size 20m; print-time yes; print-category yes; print-severity yes; severity info; }; category default { default_syslog;default_log; }; category config { default_debug; }; category unmatched { default_debug; }; category queries { default_debug; }; category client { default_debug; }; category xfer-in { default_log; }; category xfer-out { default_log; }; category notify { default_log; }; channel default_log { file "log/named.log" versions 2 size 20m; print-time yes; print-category yes; print-severity yes; severity info; }; channel default_debug { Page : 125 / 136

126 }; file "log/named.run" versions 2 size 20m; severity dynamic; }; channel default_syslog { syslog daemon; severity info; }; /////////////////////// // root name servers // /////////////////////// zone "." { type hint; file "etc/named.root"; }; ////////////////////// // localhost forward// ////////////////////// zone "localhost" { type master; file "forward/localhost"; }; //////////////////////////////////// // reverse loopback zone (v4 & v6)// //////////////////////////////////// //localhost reverse IPv6 zone " ip6.int" { type master; file "reverse/localhost-rev"; }; //localhost reverse IPv4 zone " in-addr.arpa" { type master; file "reverse/localhost-rev"; }; /////////////////////////// // Dynamic zones FORWARD // /////////////////////////// // forward IPv4 & IPv6 zone "gn6.renater.fr" { type master; file "forward/gn6.renater.fr"; }; /////////////////////////// // Dynamic zones REVERSE // /////////////////////////// Include "keys/confv6-keys"; Page : 126 / 136

127 // reverse IPv4 zone zone " in-addr.arpa." { type master; file "reverse/ in-addr.arpa."; }; // reverse IPv6 Zone 2001:660:3001:7801 zone " ip6.int."{ type master; file "reverse/ ip6.int."; }; zone " ip6.arpa."{ type master; file "reverse/ ip6.arpa."; }; // reverse IPv6 Zone 2001:660:3001:7802 zone " ip6.int."{ type master; file "reverse/ ip6.int."; }; zone " ip6.arpa."{ type master; file "reverse/ ip6.arpa."; }; // secondaire de sem.renater.fr zone "renater.fr" { type slave; file "forward/renater.fr."; masters { 2001:660:3001:4002::60; }; }; // secondaire sem2.renater.fr reverse IPv6 Zone 2001:660:3001:780 zone " ip6.int."{ type slave; file "reverse/ ip6.int."; masters { 2001:660:3001:4001::53; }; }; zone " ip6.arpa."{ type slave; file "reverse/ ip6.arpa."; masters { 2001:660:3001:4001::53; }; }; // secondaire reverse IPv4 zone zone " in-addr.arpa.» { type slave; file "reverse/ in-addr.arpa."; masters { ; }; }; Page : 127 / 136

128 Fichier /etc/dns/forward/localhost Ce fichier contient les informations du localhost en IPv4 et IPv6 pour la zone directe. $TTL 1D IN SOA routegn6.gn6.renater.fr. prevost.renater.fr. ( ; 3600 ; refresh (1 heure) 900 ; retry (15 minutes) ; expire (1w) 1080 ; minimum (18 minutes) ) IN NS localhost. localhost. IN A localhost. IN A localhost. IN AAAA 2001:660:3001:7801::53 localhost. IN AAAA 2001:660:3001:7802::53 localhost. IN AAAA ::1 Fichier /etc/dns/forward/gn6.renater.fr Ce fichier décrit la zone directe IPv4 et IPv6 de routegn6 : gn6.renater.fr. $TTL 1D IN SOA routegn6.gn6.renater.fr prevost.renater.fr. ( ; serial 1800 ; refresh (30 minutes) 900 ; retry (15 minutes) ; expire (19 hours 12 minutes) 1080 ; minimum (18 minutes) ) IN NS sem.renater.fr. IN NS routegn6.gn6.renater.fr. routegn6 IN A AAAA 2001:660:3001:7801::53 pc3ipv6 IN A AAAA 2001:660:3001:7801:2b0:d0ff:fe9a:42a1 pc2ipv6 IN AAAA 2001:660:3001:7802:2b0:d0ff:fe9a:4359 www6 IN A www6 IN AAAA 2001:660:3001:7801:2b0:d0ff:fe9a:42a1 localhost IN A localhost IN AAAA ::1 loopback IN CNAME localhost Page : 128 / 136

129 Fichier /etc/dns/reverse/localhost-rev Ce fichier contient les informations du localhost en IPv4 et IPv6 pour la zone inverse. $TTL 1D IN SOA routegn6.gn6.renater.fr prevost.renater.fr. ( ; serial 1800 ; refresh (30 minutes) 900 ; retry (15 minutes) ; expire (19 hours 12 minutes) 1080 ; minimum (18 minutes) ) IN NS localhost. 1 IN PTR localhost. Fichier /etc/dns/reverse/localhost-rev Ce fichier décrit la zone inverse IPv6 de routegn6 : gn6.renater.fr. Il comprend l ensemble des machines du sous réseau 2001:660:3001:7801::. De la même manière il existe des fichiers int et arpa pour chacun des sous-réseaux. $TTL 1D /etc/dns/reverse/ IN SOA routegn6.gn6.renater.fr. prevost.renater.fr. ( ; serial 1800 ; refresh (30 minutes) 900 ; retry (15 minutes) ; expire (19 hours 12 minutes) 1080 ; minimum (18 minutes) ) IN NS routegn6.gn6.renater.fr. $ORIGIN ip6.int IN PTR routegn6.gn6.renater.fr. 1.a.2.4.a.9.e.f.f.f.0.d.0.b.2.0 IN PTR pc3ipv6.gn6.renater.fr. Fichier /etc/dns/etc/rndc.conf Ce fichier contient la clé de configuration pour l administration à distance du serveur de nom par le programme rndc. /etc/dns/etc/rndc.conf key "rndc-key" { algorithm hmac-md5; secret "c3ryb25nigvub3vnacbmb3igysbtyw4gynv0ig1hzgugzm9yigegd29tyw4k" }; options { default-key "rndc-key"; default-server ::1; default-port 953; }; Page : 129 / 136

130 Annexe 5. Le serveur Web Rappel, les sources des logiciels téléchargés sur le Serveur Applicatifs sont disponibles à partir de l arborescence suivante : /usr/local/src Installation de MySQL On télécharge MySQL à l adresse suivante (le Tarball en fin de page, mysql tar.gz) : Tous les packages MySQL existant sur la machine doivent être désinstallés, la commande suivante permet de voir dans la liste des packages installés sur le système, ceux qui ont dans leur nom la chaîne mysql (sans respecter la casse). rpm -qa grep -i mysql On les supprime avec la commande rpm -e. Dans le répertoire de travail, on décompresse l'archive. tar xvfz mysql tar.gz Cela crée le répertoire mysql , dans ce répertoire on tape alors :./configure make On tape maintenant en temps que root : make install A la première installation de MySQL vous devez taper la commande suivante :./mysql /scripts/mysql_install_db Il faut créer le groupe mysql, puis l'utilisateur mysql du groupe mysql. groupadd mysql useradd -g mysql mysql MySQL et le groupe doit être propriétaire des bases. chown -R mysql /usr/local/var chgrp -R mysql /usr/local/var Lancement du daemon MySQL : scripts/mysqld_safe & Dans le fichier mysql.server.sh au lieu on écrit hostname, on modifie également la variable basedir (au lieu d'avoir basedir= on écrit basedir=/usr/local) et pour finir la variable datadir (au lieu de datadir=@localstatedir@ on écrit datadir=/usr/local/var). Lancement automatique. cp./mysql /support-files/mysql.server.sh /etc/rc.d/init.d/mysql chmod 755 /etc/rc.d/init.d/mysql chkconfig --level 345 mysql on Page : 130 / 136

131 A présent MySQL est installé, il reste la configuration des utilisateurs. La première chose à faire est de mettre un mot de passe pour root pour l'accès à l'administration des bases de données. La commande à taper est : mysqladmin -u root password 'mot-de-passe' Maintenant on va créer un compte utilisateur (test par exemple), pour cela on doit se connecter en tant qu'administrateur de la base à la base de donnée MySQL contenant les infos sur les utilisateurs et leurs droits. mysql -u root -p mysql A présent on va entrer l'utilisateur test qui sera un super utilisateur avec les mêmes droits que root. mysql> INSERT INTO user -> VALUES('localhost','test',PASSWORD('mot-de-passe'), -> 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y',' ',' ',' ',' ','0','0','0'); Pour voir si la saisie s'est bien passée. mysql> SELECT * FROM user; Un utilisateur root sans mot de passe est présent par défaut, on va le supprimer. mysql>delete FROM user WHERE Host="lefautif"; Maintenant pour prendre tout ça en compte. mysql> FLUSH PRIVILEGES; Pour quitter. mysql>quit Installation de Apache Apache est disponible à l adresse suivante : On désarchive en tapant : tar xvfz apache_ tar.gz De la même manière que MySQL, on supprime les anciennes versions avec : rpm -qa grep -i php rpm -qa grep -i apache rpm -e nom-du-package Dans le répertoire ou l archive a été décompressée, on tape alors :./configure --prefix=/usr/local/apache2 --enable-module=most --enable-shared=max make Page : 131 / 136

132 Maintenant en tant que root : make install Modifications du fichier httpd.conf se trouvant sous /usr/local/apache2/conf : ServerName nom_de_la_machine Port 80 Lancement du daemon Apache. /usr/local/apache/bin/apachectl start Installation de PHP4 PHP4 est disponible à l adresse suivante : Pour PHP4, on tapera d'abord tar xvfz php tar.gz A présent dans le répertoire de php../configure --with-apxs2=/usr/local/apache2/bin/apxs --with-config-filepath=/usr/local/apache2/conf --enable-versioning --with-mysql --with-ftp --enablebcmath=yes --enable-debug=no --enable-memory-limit=yes --enable-tracks-vars make Puis en tant que root. make install Modifications du fichier httpd.conf se trouvant sous /usr/local/apache2/conf : LoadModule php4_module libexec/libphp4.so AddModule mod_php4.c AddType application/x-tar.tgz AddType application/x-httpd-php.php.php3.php4.phtml AddType application/x-httpd-php-source.phps DirectoryIndex index.html index.htm index.php3 index.php index.php4 Puis dans le répertoire de l archive décompressée. cp./php-4.3.6/php.ini-recommended /usr/local/apache/conf/php.ini On relance Apache /usr/local/apache/bin/apachectl restart Page : 132 / 136

133 Installation de SPIP La distribution de SPIP est disponible à l adresse suivante. On désarchive dans le répertoire accessible depuis un navigateur /usr/local/apache2/htdocs. unzip SPIP-v1-7-2.zip La configuration de SPIP s effectue par un accès au répertoire nouvellement crée via un navigateur Web : La démarche est simple et toutes les étapes sont explicites, ainsi on crée une nouvelle base de donnée correspondant au site Internet. Il existe deux interfaces pour SPIP, l une pour la publication des articles ( l autre pour consulter les pages soit le site lui-même ( Remarque, la deuxième interface, concernant la lecture des articles est un module (squelette) dont la charte graphique peut être modifiée. Installation de PHPMyAdmin La distribution de PHPMyAdmin est disponible à l adresse suivante. On désarchive dans le répertoire accessible depuis un navigateur /usr/local/apache2/htdocs. tar xvzf phpmyadmin pl1.zip On peut ainsi gérer les bases de données (dont celles de SPIP) par un accès au répertoire nouvellement crée via un navigateur Web ( pl1). Détection de l utilisation du protocole IPv6 par un navigateur Web Certaines applications de sites Web utilisent l'adresse IP que ce soit pour effectuer des statistiques, reconnaître les utilisateurs... L implémentation PHP suivante permet de faire la différence entre un utilisateur IPv6 et IPv4. Dans le cas du site Web de la plate-forme de démonstration IPv6 du GN6, il s agira d afficher une image différente en fonction du protocole utilisé. Une manière ludique de montrer à un utilisateur lambda que la couche protocolaire IPv6 reste transparente pour n importe quel type d applications. Page : 133 / 136

134 Cette fonction doit être insérée dans une page HTML. <? class ipv6 { /* * Détermine si une adresse IP est de norme IPv6 */ function is_ipv6($ip = "") { if ($ip == "") { $ip = ipv6::get_ip(); } if (substr_count($ip,":") > 0 && substr_count($ip,".") == 0){ return true; } else { return false; } } /* * Détermine si une adresse IP est de norme IPv4 */ function is_ipv4($ip = "") { return!ipv6::is_ipv6($ip); } /* * Retourne l'adresse IP du visiteur */ function get_ip() { return getenv ("REMOTE_ADDR"); } } /* * Tester IPv6 */ echo "Votre IP est ".ipv6::get_ip()." et vous utilisez la norme : "; echo (ipv6::is_ipv6())? "IPv6":"IPv4"; echo (ipv6::is_ipv6())? "<img src=\"image1.gif\">":"<img src=\"image2.gif\">";?> Page : 134 / 136

135 Interface graphique du site Web Quelques captures du site Page : 135 / 136

136 Annexe 6. Bibliographie Références sur Internet : le site de l association Aristote : le site du GIP Renater : le site du projet Grille de Conférences : le site du laboratoire Multimédia et Réseau de UCL : le site personnel de Konstantin Kabassanov sur lequel on peut trouver des versions de Vic pour Windows compatibles avec IPv6 : le site du M6Bone Livres IPv6, Théorie et Pratique Gizelle Cizeault (Ouvrage du G6), O'Reilly Page : 136 / 136