services avancés ipv4 et ipv6 pour la communication audiovisuelle

Université Paris 7 Denis Diderot UFR d’INFORMATIQUE

DESS Applications des Réseaux et de la

Télématique

Benoît LE BONHOMME

Services avancés IPv4 et IPv6 pour la

communication audiovisuelle

Soutenu en septembre 2005 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

LE BONHOMME Benoît DESS Applications des Réseaux et de la Télématiques 2004-2005

- 2 -

TU1. INTRODUCTION ............................................................................................................................ 5

U2.U UENVIRONNEMENT DE TRAVAILU.................................................................................................. 6 U2.1.U UL’ASSOCIATION ARISTOTEU.................................................................................................................... 6 U2.2.U ULE RESEAU RENATER-4U ..................................................................................................................... 7 U2.3.U ULE GIP RENATERU............................................................................................................................... 9 U2.4.U USIPA SERVICES IP AVANCES ET PROSPECTIVE U ..................................................................................... 9 U2.5.U ULE GN6U .............................................................................................................................................. 10

U3.U UOBJECTIFS DU STAGEU .............................................................................................................. 11 U4.U UCONTEXTE DE TRAVAILU............................................................................................................ 12

U4.1.U UIPV6U.................................................................................................................................................... 12 U4.1.1.U UUn plus grand nombre d’adresses IPU............................................................................................ 12 U4.1.2.U UArchitectures des adresses IPv6(RFC 3513)U................................................................................. 13 U4.1.3.U UFormat d’un datagramme IPv6 (RFC 2460)U ................................................................................. 14 U4.1.4.U ULes différents types d’adresses IPv6 U ............................................................................................. 15 U4.1.5.U UAuto configuration des stations (RFC 2461)U................................................................................. 15 U4.1.6.U ULe routageU ..................................................................................................................................... 17

U4.2.U ULE SERVICE DE NOMS U .......................................................................................................................... 17 U4.3.U UETAT DE LA PLATE-FORME IPV6 EN SEPTEMBRE 2004U ........................................................................ 19 U4.4.U UEVOLUTION DE LA PLATE-FORMEU........................................................................................................ 22

U4.4.1.U UPourquoi le changement d’architecture ?U ..................................................................................... 22 U4.4.2.U UDéfinitions de la norme IEEE 802.1qU ........................................................................................... 22 U4.4.3.U UStructure de la plate-formeU ........................................................................................................... 24

U4.4.3.1. Mise en place des VLANs....................................................................................... 24 U4.4.3.2. Mise en place d’un pare feu.................................................................................... 34 U4.4.3.3. Mise en service des domaines renater.gn6.net et renater.gn6.org ........................ 38 U4.4.3.4. Mise en place d’un outil de supervision : Nagios.................................................... 39U U4.4.3.5. Mise en place d’un serveur SMTP (Postfix)............................................................ 42

U5.U ULES PROTOCOLES DE COMMUNICATION AUDIOVISUELLEU................................................ 44 U5.1.U ULE MULTICASTU .................................................................................................................................... 44

U5.1.1.U UGénéralitésU .................................................................................................................................... 44 U5.1.2.U UAdressage Multicast IPv4 U.............................................................................................................. 45 U5.1.3.U UAdressage IPv6U.............................................................................................................................. 45 U5.1.4.U UGestion des groupes multicastU....................................................................................................... 46

U5.1.4.1.U UMLD version 1 (RFC 2710)U ..................................................................................... 46 U5.1.4.2.U UMLD version 2 (RFC 3810)U ..................................................................................... 48 U5.1.4.3.U UAu niveau inter-LANs (Domaine PIM) U..................................................................... 48 U5.1.4.4.U UAu niveau inter-domaines U ....................................................................................... 50

U5.1.5.U UM6BoneU ......................................................................................................................................... 51 U5.1.5.1. Présentation............................................................................................................ 51 U5.1.5.2. Topologie ................................................................................................................ 51

U5.2.U URTP ET RTCP (RFC 3550 ANCIENNEMENT 1889)U .............................................................................. 54 U5.2.1.U UIntroductionU................................................................................................................................... 54 U5.2.2.U UEn-tête d’un paquet RTPU ............................................................................................................... 55 U5.2.3.U URTCPU ............................................................................................................................................. 55

U5.2.3.1. Les paquets RTCP de type « Sender Report » et « Receiver Report » ................. 56 U5.2.3.2. Différences entre la RFC 1889 et 3550 .................................................................. 58

U5.2.4.U UProfil RTP Audio et Vidéo (RFC 3551 anciennement 1890)U......................................................... 58 U5.2.4.1. Différences entre la RFC 1890 et 3551 .................................................................. 59

U5.3.U UH323U................................................................................................................................................... 60 U5.3.1.U UVisioconférence H.323U .................................................................................................................. 60 U5.3.2.U UNormes H.323U ............................................................................................................................... 61 U5.3.3.U UPortier H.323 (Gatekeeper)U .......................................................................................................... 63 U5.3.4.U ULe plan de numérotation E.164U ..................................................................................................... 66 U5.3.5.U URéseaux de portier H.323U.............................................................................................................. 66


- 3 -

U5.3.6.U USécurité d’un réseau H.323U ........................................................................................................... 70 U5.3.7.U UPont multipoint (MCU)U ................................................................................................................. 71

U5.4.U UPROTOCOLE SIP (RFC 3261)U .............................................................................................................. 72 U5.4.1.U UArchitecture protocolaire SIPU ....................................................................................................... 72 U5.4.2.U UOuverture d’une session U................................................................................................................ 74 U5.4.3.U UAppel SIP entre deux utilisateursU .................................................................................................. 74 U5.4.4.U UDescription des méthodes de requêtes U .......................................................................................... 76 U5.4.5.U UEtablissement d’une communication en mode client serveurU........................................................ 77 U5.4.6.U UFormat des messages SIPU.............................................................................................................. 78 U5.4.7.U UComparaison SIP et H323U............................................................................................................. 79

U6.U ULES APPLICATIONS DE COMMUNICATIONS AUDIOVISUELLES U ......................................... 81 U6.1.U ULES SEMINAIRES ARISTOTEU................................................................................................................. 81 U6.2.U ULE PROJET DIMU .................................................................................................................................. 84 U6.3.U UISABELU ............................................................................................................................................. 85 U6.4.U ULES LOGICIELS LIBRES UTILISANT LE PROTOCOLE SIPU ........................................................................ 86

U6.4.1.U ULes clients SIP dit U.A.C.(User Agent Client)U............................................................................... 86 U6.4.2.U ULes serveurs mandatairesU.............................................................................................................. 87 U6.4.3.U ULes serveurs SIP d’enregistrement « PBX »U.................................................................................. 88

U7.U UMISE EN ŒUVRE U......................................................................................................................... 89 U7.1.U ULES OUTILS H323U ............................................................................................................................... 89

U7.1.1.U UOpenH323U ..................................................................................................................................... 89 U7.1.2.U UInstallation des librairies H323 sous Linux Debian sargeU ............................................................ 90 U7.1.3.U UTest du fonctionnement des librairies H323 avec les protocoles IPv4 et IPv6U ............................. 91 U7.1.4.U UTest entre deux clients H323U ......................................................................................................... 95 U7.1.5.U UTest du logiciel openMCUU............................................................................................................. 97 U7.1.6.U UTest du portier H323 GNUgkU ...................................................................................................... 101 U7.1.7.U UConfiguration des clients H323 avec un portier H323U................................................................ 103

U7.2.U ULES OUTILS SIP U................................................................................................................................. 108 U7.2.1.U UAppel SIP avec l’outil kphoneU ..................................................................................................... 108

U8.U UAPPLICATION DE GESTION D’UNE VISIOCONFERENCE A L’AIDE DU LOGICIEL VIDEOLANU .......................................................................................................................................... 110

U8.1.U UVIDEOLAN U ........................................................................................................................................ 110 U8.1.1.U ULire un flux du réseauU.................................................................................................................. 110 U8.1.2.U ULecture à partir d'une entrée vidéoU ............................................................................................. 112 U8.1.3.U UDiffuser une vidéo en multicastU ................................................................................................... 113 U8.1.4.U UVLMU............................................................................................................................................. 115

U8.2.U UAPPLICATION DE GESTION DE VISIOCONFERENCE U ............................................................................. 116 U8.2.1.U UTest du bon fonctionnement du service multicast du siteU ............................................................ 116 U8.2.2.U UDémarrage de l’application U ........................................................................................................ 118 U8.2.3.U ULa causette multicastU ................................................................................................................... 120 U8.2.4.U ULa gestion d’une visioconférenceU ................................................................................................ 121

U8.3.U UCARACTERISTIQUES TECHNIQUES DE L’APPLICATION DE VISIOCONFERENCE U .................................... 127 U8.3.1.U ULa communicationU ....................................................................................................................... 127 U8.3.2.U ULa causette multicast « Aristo-MultiChat »U................................................................................. 134 U8.3.3.U ULa gestion d’une visioconférenceU ................................................................................................ 135

U8.4.U UEXEMPLE DE CONFERENCEU................................................................................................................ 140 U8.5.U UEVOLUTIONS ET AMELIORATIONS U ..................................................................................................... 142

U9.U UCONCLUSIONU............................................................................................................................ 143 U10.U UANNEXESU................................................................................................................................... 144

U10.1.U UANNEXE 1 - CONFIGURATION DU ROUTEUR 6WINDU .......................................................................... 144 U10.2.U UANNEXE 2 - CONFIGURATION DU COMMUTATEUR CISCO 2950U......................................................... 150 U10.3.U UANNEXE 3 - CONFIGURATION DU SERVEUR DE NOM « BIND 9 »U ...................................................... 154 U10.4.U UANNEXE 4 - BIBLIOGRAPHIEU ............................................................................................................. 162


- 4 -

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 accordé sa confiance en tant que stagiaire Aristote.

Je tiens aussi à remercier M. Bernard Tuy pour ses précieux conseils ainsi que tout le personnel du GIP RENATER avec en particulier les personnes suivantes pour leurs conseils et leur accueil: Marcolino Pires, Jérôme Durand, Simon Muyal, Thierry Bono, Cécile Marlet, Laurence Freyt-Caffin et Sandra Cabaret.

Je tiens à remercier également le directeur du GIP RENATER, M. Dany Vandromme, d’avoir donné son autorisation à ma venue.

Je remercie pour leurs formations, leurs conseils mais aussi pour la disponibilité dont ils ont fait preuve tout au long de l’année pour répondre à nos questions, Yves Legrandgérard, mon directeur de mémoire et Gilbert Sol, mon directeur d’étude au DESS Applications des Réseaux et de la Télématique.


- 5 -

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 OTESA a vu le jour courant l’année 2004. OTESA est un ensemble d'outils choisis et intégrés par Aristote ou bien développés spécifiquement, pour transmettre sur RENATER, en haute qualité, des cours, conférences et séminaires (vidéo et transparents), ainsi que pour les enregistrer et traiter ces enregistrements pour pouvoir les rejoués par la suite.

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.

La mise en place de cette plate-forme a été amorcée par les stagiaires d’Aristote les années précédentes notamment Christophe Herviaux mon prédécesseur au GIP RENATER, étudiant du DESS ART.


- 6 -

2. Environnement 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çaises intéressées 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 Hgroupes de travail techniquesH 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.

Aristote effectue ses actions grâce aux moyens suivants :

des contributions en nature des organismes membres : participation de leurs experts

aux groupes de travail, hébergements gracieux de services (serveur Web: hébergé par le CEA; secrétariat : hébergé par l'Ecole Polytechnique).

des ressources financières : cotisations des organismes membres, revenus issus de

certaines activités payantes telles que séminaires et conférences, sponsorisations éventuelles. Etant un organisme à but non lucratif, Aristote ne fait pas de bénéfice global : tout excédent financier, lorsqu'il y en a, est réinvesti dans de nouvelles activités.

Pour en savoir plus : HUhttp://www.aristote.asso.frUH


- 7 -

2.2. Le réseau RENATER-4 « 4P

èmeP génération du Réseau National de télécommunications pour

la Technologie, l’Enseignement et la Recherche »

Depuis plus de 10 ans, le Groupement d'Intérêt Public RENATER, maître d’ouvrage du Réseau National de Télécommunications pour la Technologie, l'Enseignement et la Recherche, s’emploie à faire évoluer le réseau RENATER pour répondre aux besoins de connectivité de plus en plus important de ses communautés. A l'issue d’un appel d’offres publié en mai 2004 pour l’évolution du réseau, le nouveau RENATER-4 sera déployé d’ici la fin de l’année avec les spécificités suivantes :

Une nouvelle architecture améliorée avec un maillage complet sur l’ensemble des points de présence du réseau

Une meilleure utilisation du réseau par l’introduction des techniques les plus avancées

de routage pour une distribution équilibrée de la charge sur l'ensemble du réseau

Une disponibilité renforcée et sécurisation par boucles homogènes

Une possibilité de répondre aux besoins de très hauts débits des grands projets de recherche en établissant des chemins optiques de bout en bout entre les points de présence

Les entreprises qui contribuent à l’évolution du réseau sont Telecom Développement pour la fourniture de l'ensemble des liaisons (à l'exception de l'Ile de France et de la Corse), France Telecom pour la liaison avec la Corse, CISCO pour les équipements de routage et de commutation, Telecom Développement, Level3 et Neuf Telecom pour le réseau optique dédié aux grands projets de recherche et ALCATEL pour les équipements optiques. C’est Communication & Systèmes qui assurera le déploiement, la gestion et l'administration de la totalité du nouveau réseau RENATER-4 sous contrôle du GIP RENATER.


- 8 -

Figure 1 : RENATER-4

RENATER, Réseau National de télécommunications pour la Technologie l’Enseignement et la Recherche, a été déployé au début des années 90 pour fédérer les infrastructures de télécommunication pour la recherche et l’éducation. Afin de mener à bien cette action, le Groupement d’Intérêt Public RENATER a été constitué en janvier 1993. Les membres du GIP RENATER sont le Ministère de l’Éducation Nationale de l’enseignement supérieur et de la Recherche et des grands organismes de recherche, le CEA, le CIRAD, le CNES, le CNRS, l’INRA, l’INRIA, l’INSERM, le BRGM, le CEMAGREF et l’IRD.

Aujourd’hui, RENATER fournit à ses ayants droit une connectivité nationale et internationale à très haut débit, l’accès à des contenus et à des services leur permettant de travailler avec leurs homologues du monde entier. Plus de 600 sites sont « raccordés » à RENATER le plus souvent via des réseaux de collecte (réseaux régionaux ou métropolitains), mis en place à l’initiative des collectivités territoriales.

Le réseau RENATER est constitué d’une infrastructure nationale reliant des points de présence en région et dans les DOM-TOM ainsi que des liaisons internationales, et un nœud d’échange entre prestataires de service Internet appelé SFINX (Service for French INternet eXchange).

Le réseau RENATER est interconnecté au réseau Pan-Européen enseignement et recherche nommé GÉANT qui relie plus de 3500 établissements et fournit également une connectivité mondiale grâce à l’EDA (European Distributed Access), un système d’interconnexion distribuée avec des réseaux similaires dans d’autres régions du monde, notamment l’Amérique et l’Asie.


- 9 -

2.3. Le GIP RENATER

Le GIPTP

1PT 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 4, 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.

2.4. SIPA Services IP Avancés et prospective

Le groupe SIPA est un service du GIP RENATER dont j’ai fais partie pendant l’année de mon stage.

S’appuyant sur des travaux expérimentaux, le premier rôle de l’équipe est de déterminer

les nouveaux usages et services qui vont pouvoir être mis en exploitation au profit de la communauté académique, usager naturel de RENATER. La mise en exploitation peut nécessiter une étape pilote, qui associe des usagers sélectionnés aux équipes de Renater et à son centre de supervision (CS).

En amont, des travaux de recherche appliquée et des expérimentations sont nécessaires.

De ce point de vue, la participation aux projets de recherche tant nationaux qu’internationaux est indispensable.

La transmission des connaissances et des compétences acquises par des actions de

formation tant internes qu’externes est le moyen de mettre en place les relais opérationnels pour que les bénéficiaires puissent s’approprier ces nouveaux usages mis à leur disposition. TP

1PT GIP : Groupement d’Intérêt Public.


- 10 -

2.5. 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 la cohabitation IPv4 et 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, 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 : HUhttp://www.gn6.orgUH


- 11 -

3. Objectifs du stage

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. Pendant la durée de mon stage, j’ai été intégré dans l’équipe SIPA(Services IP Avancés et prospective) du GIP RENATER. Le rôle de l’équipe SIPA est de déterminer les nouveaux usages et services qui vont pouvoir être mis en exploitation au profit de la communauté académique, usager naturel de RENATER. La mise en exploitation peut nécessiter une étape pilote, qui associe des usagers sélectionnés aux équipes de Renater et à son centre de supervision (CS). En amont, des travaux de recherche appliquée et des expérimentations sont nécessaires. De ce point de vue, la participation aux projets de recherche tant nationaux qu’internationaux est indispensable. La transmission des connaissances et des compétences acquises par des actions de formation tant internes qu’externes est le moyen de mettre en place les relais opérationnels pour que les bénéficiaires puissent s’approprier ces nouveaux usages mis à leur disposition. Au cours de l’année d’apprentissage, deux domaines de travail ont été abordés.

La visioconférence pour la poursuite de la validation du support avancé pour les utilisateurs, des relations avec les développeurs, pour les outils utilisés ou susceptibles d’être utilisés dans les séminaires Aristote, les Causeries de RENATER, les cours de DESS DIM, au-dessus des services réseau multicast IPv4 et IPv6 et mise en œuvre d’outils pour la retransmission de conférence.

La Plate-forme de démonstration IPv6 pour la poursuite et extension de la

plate-forme de tests et de démonstration IPv6 du GIP RENATER, dans le contexte des actions du groupe GN6 qui regroupe divers utilisateurs avancés de IPv6 et de ses applications. En liaison – par l’intermédiaire des ingénieurs du GIP RENATER – avec de grands industriels (CISCO, 6Wind, Microsoft) pour les équipements et les principales applications. La deuxième partie sur le multicast IPv6 s’inscrit dans la continuité de ce qui a été fait par mon prédécesseur du DESS ART, Christophe Herviaux.


- 12 -

4. Contexte de travail

Pendant la durée de mon stage, il m’a fallu reprendre la plate-forme de démonstration IPv6 du GN6, l’objectif est de déployer une plate-forme de démonstration des services de visioconférence sur Internet basée sur IPv4/IPv6, H323 et SIP pouvant interconnecter différents sites dont le GIP 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éenseignement et de télétravail.

Cette plate-forme a aussi pour intérêt de montrer la possibilité de coexistence des environnements IPv4 et IPv6 ou encore de se passer de l’environnement IPv4 tout en assurant des services identiques (serveur de nom, serveur web,...).

4.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 1994. Des solutions comme le NAT (translation d'adresses) et CIDR (Classless InterDomain Routing - RFCTP

2PT 1519) ont permis de

ralentir considérablement l'explosion de la taille des tables de routages d’Internet 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. Les travaux principaux concernant IPv6 sont maintenant terminés. Voici une explication synthétique des fonctionnalités principales du protocole IPv6 :

4.1.1.Un plus grand nombre d’adresses IP

Les adresses IPv6 ont 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 1 564 et 3 911 873 538 269 506 102 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. 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 TP

2PT RFC : Request For Comment


- 13 -

4.1.2.Architectures des adresses IPv6(RFC 3513)

Le grand nombre d’adresse IPv6 a permis 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 (cœurs de réseau).

Voici le schéma d'une adresse IPv6 unicast global:

| n bits | m bits | 64 bits | +---------------------------+----------------+-----------------------+ | préfixe globale de routage| ID sous-réseau | interface ID | +---------------------------+----------------+-----------------------+ 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.

- Le préfixe global de routage est le préfixe réseau assigné à un site. - L’ID Site est la partie réservée aux sites pour permettre de hiérarchiser le réseau en

créant d'éventuels sous-réseaux. - Interface ID est la partie permettant d’identifier une interface sur un lien.

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 réseau IPv6 (le préfixe de production et le préfixe de test) sur le réseau Internet IPv6.

Topologie publique Topologie de site Topologie privée


- 14 -

4.1.3.Format d’un datagramme IPv6 (RFC 2460)

Figure 2: format d’un datagramme IPv6

Signification des différents champs :

TVersion (4 bits) :T il s’agit de la version du protocole IP que l’on utilise (ici la valeur de version est 6) afin de vérifier la validité du datagramme.

TClasse du Trafic, en anglais Traffic Class (8 bits) :T champ relatif à la classe de trafic au sens DiffServ (Mécanisme qui permet de garantir la qualité de service).

TLabel du Flux , en anglais Flow Label (20 bits) :T champ relatif au flux d’information. Ce champ contient un numéro unique choisi par la source, qui a pour but de faciliter le travail des routeurs et la mise en oeuvre des fonctions de qualité de service.

TLongueur de la "Charge Utile», en anglais Payload Length (entier non-signé sur 16 bits) : T Longueur en octets de la charge utile, c’est-à-dire le reste du paquet qui suit cet en-tête IPv6. (Il faut noter que tous les en-têtes d’extension présents sont considérés comme faisant partie de la charge utile, c’est-à-dire inclus dans le décompte de la longueur).

TEn-tête suivant, en anglais Next Header (8 bits) :T Identifie le type de l’en-tête suivant immédiatement l’en-tête IPv6. Utilise les mêmes valeurs que le champ " protocole " d’IPv4.

TNombre de Sauts Maximum, en anglais Hop Limit (entier non-signé sur 8 bits) :T décrémenté de 1 pour chaque nœud que le paquet traverse. Le paquet est éliminé si le Nombre de Sauts Maximum arrive à zéro.

TAdresse Source, en anglais Source Address (128 bits) :T adresse de l’expéditeur initial du paquet.


- 15 -

TAdresse Destination, en anglais Destination Address (128 bits) :T adresse du destinataire projeté du paquet (qui peut ne pas être le destinataire ultime, si un en-tête de routage est présent).

4.1.4.Les différents types d’adresses IPv6 IPv6 reconnaît trois types d’adresses : unicast, multicast et anycast. Le premier de ces types, le type unicast, est le plus simple. Une adresse de ce type désigne une interface unique. Un paquet envoyé à une telle adresse, sera donc remis à l’interface ainsi identifiée. Une adresse de type multicast désigne un groupe d’interfaces qui en général appartiennent à des nœuds différents pouvant être situés n’importe où dans l’Internet. Le mécanisme permettant la transmission des paquets vers plusieurs interfaces sera expliqué par la suite. Le dernier type, anycast, provient d’une proposition faite pour IPv4 [RFC 1546]. Comme dans le cas du multicast, une adresse de type anycast désigne un groupe d’interfaces, la différence étant que lorsqu’un paquet a pour destination une telle adresse, il est acheminé à un des éléments du groupe et non pas à tous.

4.1.5.Auto configuration des stations (RFC 2461)

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 peuvent être calculés en fonction de l'adresse physique de l'interface.

L’autoconfiguration est réalisée par la découverte des voisins (« neighbor discovery » RFC 2461)

Les différentes étapes de l’algorithme « neighbor discovery » (RFC 2461) :

La toute première étape consiste à construire l’adresse lien local.

• L’adresse de lien local est valide uniquement sur un même lien sans routeur intermédiaire.

• Un routeur ne route pas ce type d’adresse. • L’interconnexion par un commutateur représente cet espace lien.

Voici le schéma d'une adresse de lien local IPv6 de préfixe fe80::/10 :

F E 8 EUI-64

1111 1110 10 0 ID Interface 10 bits 54 bits 64 bits


- 16 -

En éthernet l’identifiant EUI-64 est obtenu à partir de l’adresse MAC de l’interface. L’adresse Mac est modifiée comme suit pour obtenir l’identifiant EUI-64 :

MAC: aa:bb:cc:dd:ee:ff EUI-64: 02bb:ccff:fedd:eeff

Ainsi, toute interface de MAC aa:bb:cc:dd:ee:ff aura pour adresse IPv6 lien local: fe80::02bb:ccff:fedd:eeff

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 globale.

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 reçoit le message d’annonce du routeur et détermine la méthode d’obtention de l’adresse Unicast globale et connaît 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 à une longueur de 64 bits. La machine ajoute son identifiant d’interface (déduit à partir de son adresse MAC) 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.

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, la machine ne pourra pas construire son adresse IPv6 globale et communiquée avec l’extérieur de son réseau. Les communications se feront uniquement au niveau du lien local.


- 17 -

4.1.6.Le routage

Le routage IPv6 offre très peu de différences avec IPv4. Les protocoles de routage IPv6 les plus connus sont RIPng [RFC2080] adaptation de RIPv2 [RFC1723], OSPFv3 [RFC2740], ISIS pour IPv6 (Draft IETF) et BGP4+ [RFC2858].

4.2. Le service de noms

Comment fonctionne le DNS ?

Le service de résolution de noms (RFC 1034) effectue 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 :

Figure 3 : Serveurs de noms pour les domaines renater.gn6.net et renater.gn6.org


- 18 -

Le domaine de la plate-forme est une simple sous division de gn6.net et gn6.org, on parle ainsi de délégation du serveur de noms gérant la zone gn6.net et gn6.org au serveur de noms gérant la zone renater.

Ainsi le serveur de noms se trouvant sur la machine routegn6 gère ses propres zones renater.gn6.net et renater.gn6.org.

Le RFC 1886 décrit les extensions apportées à ce service pour prendre en compte le protocole IPv6. Deux extensions principales ont été définies pour le schéma d’adressage IPv6 :

L’enregistrement AAAA. Les nouveaux domaines ip6.int et ip6.arpa.

Le DNS est un système de bases de données réparties qui permet d’associer des

informations typées à des noms. Ainsi la correspondance du nom vers l’adresse en IPv4 est réalisée en associant au nom de la machine à un ou plusieurs enregistrement de classe IN et de type A. Chaque enregistrement contient une valeur qui est une adresse IPv4.

Pour IPv6 un mécanisme analogue est conservé. Un nouveau type d’enregistrement est défini, de classe IN et de type AAAA. Similairement à l’enregistrement qui est établit la correspondance entre le nom d’une interface et son adresse IPv4, l’enregistrement AAAA établit la correspondance entre le nom de l’interface et son adresse IPv6.

La correspondance de l’adresse IPv6 vers le serveur de nom est traitée par le DNS en IPv4 grâce à des enregistrements de classe IN et de type PTR dans un domaine particulier in-addr.arpa. De façon analogue, la correspondance entre une adresse IPv6 et le nom de l’interface associée est faite par un enregistrement de classe IN et de type PTR dans un domaine de nom spécial, ip6.int.

Il a été décidé par l’IABTP

3PT de remplacer à terme ip6.int, domaine dans lequel les adresses

IPv6 inverses sont actuellement enregistrées, par le domaine ip6.arpa [RFC 3152].

TP

3PT IAB : Internet Architecture Board comité appartenant à l’IETF.


- 19 -

4.3. Etat de la plate-forme IPv6 en septembre 2004

La plate-forme est composée de deux parties distinctes : une partie « seulement IPv6 » et une partie « double pile IPv4 et IPv6 » la jonction de ces deux parties (deux interfaces une IPv4/IPv6 et une IPv6) s’effectue à l’aide d’un routeur de jonction (zebra).

Un serveur de nom primaire des zones permet de référencer les machines de la plate-

forme.

Figure 4 : architecture de la plate-forme en septembre 2005

Cinq équipements sont disponibles sur la plate-forme :

le routeur d’entrée

o caractéristiques techniques : • 6wind 6110

6OS version 6.6.1b5 o Protocoles de routage utilisés :


- 20 -

MBGP RIPng

l’équipement à la fois routeur jonction des zones 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 5.2.1 routage (deux interfaces) : Zebra version 0.94 / PIM6sd serveur de nom : BIND version 9.2.3

o protocoles de routage utilisés PIM6 (Multicast) RIPng (Unicast) Statique (Unicast)

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 2.0.49 (plus site Intranet de le plate-forme) logiciels de visioconférence (multicast (Vidéolan), H323 (Netmeeting,

gnomemeeting)) 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


- 21 -

Figure 5 : plan d’adressage de la plate forme IPv6 Plan d’adressage : Pour cette plate forme IPv6, nous avons deux préfixes réseaux, un IPv4 et un IPv6. Pour l’adresse de réseau IPv4, nous avons l’adresse 195.89.126.24 avec le masque 255.255.255.240. En IPv6 l’adresse de réseau est 2001:660:2002:4200::/63, cela nous permet de pouvoir faire 16 sous réseaux avec un masque /64.


- 22 -

4.4. Evolution de la plate-forme

4.4.1. Pourquoi le changement d’architecture ?

Un problème de sécurité se pose si l’on veut pouvoir mettre en place des services accessibles depuis l’extérieur de la plate forme. Une politique de sécurisation doit être appliquée, la solution retenue est la création de différents VLANs permettant d’appliquer un filtrage spécifique entre les différents VLANs.

4.4.2. Définitions de la norme IEEE4 802.1q La norme IEEE 802.1q est le standard pour décrire les VLANs. Le standard VLAN est

décrit pour des LAN commutés. Ce standard est construit sur la base des standards IEEE 802.1d et IEEE 802.1p.

Un VLAN (Réseau Local Virtuel) est un réseau local regroupant un ensemble de machines de façon logique et non physique.

Ces machines sont regroupées selon différents critères :

• Un VLAN de niveau 1 du modèle OSI (aussi appelés VLAN par port) définit un réseau virtuel en fonction des ports de raccordement sur le commutateur ;

• Un VLAN de niveau 2 du modèle OSI (également appelé VLAN MAC) consiste à définir un réseau virtuel en fonction des adresses MAC des stations. Ce type de VLAN est beaucoup plus souple que le VLAN par port car le réseau est indépendant de la localisation de la station ;

• Un VLAN de niveau 3 du modèle OSI : on distingue plusieurs types de VLAN de niveau 3 :

o Le VLAN par sous-réseau associe des sous-réseaux selon l'adresse IP source des datagrammes. Ce type de solution apporte une grande souplesse dans la mesure où la configuration des commutateurs se modifie automatiquement en cas de déplacement d'une station. En contrepartie une légère dégradation de performance peut se faire sentir dans la mesure où les informations contenues dans les paquets doivent être analysées plus finement.

o Le VLAN par protocole permet de créer un réseau virtuel par type de protocole (par exemple TCP/IP, IPX, AppleTalk, etc.), regroupant ainsi toutes les machines utilisant le même protocole au sein d'un même réseau.

Le marquage permet de reconnaître les trames. L'appartenance à tel ou tel VLAN peut être déduite des informations contenues dans la trame éthernet (adresse IEEE, protocole...) ou insérée dans cette trame.

TP

4PTIEEE : Institute of Electrical and Electronics Engineers


- 23 -

Les informations fournies dans une trame Ethernet sont définies par la norme IEEE 803.1q, le format de la trame Ethernet est modifiée pour pouvoir contenir les deux octets de la balise VLAN.

Figure 6 : trame Ethernet avec la balise VLAN Priorité : Ce champ de 3 bits fait référence au standard IEEE 802.1P. Sur 3 bits on peut coder 8 niveaux de priorités de 0 à 7. La notion de priorité dans les TVLANs T est sans rapport avec les mécanismes de priorité TIPT. Ces 8 niveaux sont utilisés pour fixer une priorité aux trames d'un TVLANT relativement aux autres TVLANs T. CFI (« TCanonical Format Identifier » Format canonique de l’identificateurT) : Ce champ codé sur 1 bit assure la compatibilité entre les adresses MAC Ethernet et Token Ring. Un commutateur Ethernet fixera toujours cette valeur à 0. Si un port Ethernet reçoit une valeur 1 pour ce champ, alors la trame ne sera pas propagée puisqu'elle est destinée à un port «sans balise» (untagged port).


- 24 -

VID (VLAN identificateur) : Ce champ de 12 bits sert à identifier le réseau local virtuel auquel appartient la trame. Il est possible de coder 4094 (2^12-2) VLANs avec ce champ.

4.4.3. Structure de la plate-forme

4.4.3.1.Mise en place des VLANs

Pour mettre en place cette architecture, j’ai mis en place un commutateur (switch) administrable TP

5PTpermettant de créer plusieurs VLANs.

Un commutateur Cisco 2950 (avec la version 12.0(5.3)WC(1) de l’IOS et 12 ports

éthernet) a donc été mis en place pour remplacer le communicateur 3com. Au niveau connexion entre le réseau RENATER et la plate-forme, le routeur 6wind 6110

compatible IPv6 est installé avec les protocoles adéquats (multicast MBGP, routage RIPng). Ce routeur est connecté à un switch permettant la création de plusieurs VLANs par port en IPv4 et IPv6.

Au niveau du routeur 6Wind, plusieurs sous-interfaces sont configurées intégrant la norme 802.1q pour la création des VLANs, le routeur 6wind pouvant ainsi faire du filtrage de paquet IPv4 et IPv6 pour chacun des sous-réseaux.

Sur le commutateur se trouve deux VLANs avec des adresses IPv4 et IPv6, un VLAN pour les services accessibles depuis l’extérieur et un VLAN pour le réseau local. Un routeur de jonction (zebra) situé dans le réseau local fait le lien entre les deux parties suivantes « seulement IPv6 » et « double pile IPv4 et IPv6 » avec les protocoles de routage adéquats (multicast , routage statique).

Configuration du routeur 6Wind

Le routeur 6Wind permet de créer plusieurs sous-interfaces sur un même port physique, j’ai donc associé trois sous-interfaces avec trois adresses de réseaux différents et trois valeurs de VLANs différentes.

La première sous interface est le réseau d’interconnexion entre le routeur et le switch Cisco, l’adresse de ce réseau est 192.168.0.0/24. Cette adresse de réseau permet de faire un réseau non visible de l’extérieur du routeur donc une meilleure sécurité pour l’interface d’administration du commutateur.

L’adresse 192.168.0.1 est assignée pour la sous interface du routeur 6Wind et l’adresse 192.168.0.2 pour l’interface du commutateur cisco.

L’interface d’administration du commutateur s’effectuant avec le protocole telnet, il faut effectuer cette connexion sur une des machines de la plate-forme.

Je n’ai pas assigné à cette sous interface une adresse IPv6 car le commutateur Cisco peut être administré seulement avec une adresse IPv4.

TP

5PT Un commutateur administrable est administrable avec une adresse IP et implémente le protocole SNMP


- 25 -

La plate-forme ayant une adresse de réseau IPv4 avec un masque de réseau en 255.255.255.240, j’ai divisé cette adresse en deux pour avoir deux réseaux avec un masque en 255.255.255.248.

Deux adresses de réseaux ont été affectées à deux sous interfaces du routeur 6Wind. Le routeur a donc pour connaissance deux réseaux IPv4 ayant un masque en

255.255.255.248. J’ai aussi effectué la configuration de ces deux sous interfaces pour le protocole IPv6,

pour cela il faut rentrer pour chaque sous interface, une adresse IPv6 et un préfixe IPv6. Le préfixe IPv6 permet l’auto configuration IPv6 des machines du réseau.

J’ai donc assigné le préfixe 2001:660:2002:4201::/64 a une interface et 2001:660:2002:4203::/64 à la seconde permettant d’avoir deux réseaux IPv6 distincts.

Configuration du commutateur Cisco 2950

La configuration des VLANs sur un switch pouvant se faire soit par port, soit par adresse MAC ou soit par adresse IP, j’ai choisi de faire des VLANs par port ce qui est approprié pour cette plate-forme.

Chaque sous-interfaces ayant une valeur de VLAN différente, le commutateur peut ensuite savoir en fonction de cette valeur vers quel port rediriger la trame éthernet.

Un port est configuré pour l’interconnexion entre le routeur et le commutateur avec la technique d’agrégation de liens que l’on appellera par la suite trunking permettant à ce port de recevoir des trames ayant une valeur de VLAN différentes.

Les autres ports sont configurés par la suite pour ne gérer que les trames ayant une certaine valeur de VLAN.


- 26 -

Figure 7 : VLANs entre le routeur 6Wind 6110 et le commutateur Cisco 2950

Equipements de la plate-forme :

le routeur d’entrée

o caractéristiques techniques : • 6wind 6110

6OS version 6.7.0b9 Protocoles de routage utilisés : MBGP RIPng

le commutateur

o caractéristiques techniques commutateur Cisco 2950 IOS version 12.0(5.3)WC(1)


- 27 -

l’équipement à la fois routeur jonction des zones IPv4/IPv6 et zone IPv6 sur le VLAN attribué au réseau local

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 5.2.1 routage (deux interfaces) : Zebra version 0.94 / PIM6sd

o protocoles de routage utilisés PIM6 RIPng Statique

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 : Débian Sarge

o applicatifs serveur Web Apache 2.0.49 (plus site Internet de le plate-forme) logiciels de visioconférence (multicast, H323, SIP) logiciels de gestion de réseau (NAGIOS) serveur de nom : BIND version 9.2.3

client réseau local

o caractéristiques techniques : physique : portable DELL Latitude, Pentium 3 750, 128 Mo de ram,

carte réseau 100 Mbit/s, disque dur 10Go système d’exploitation : Debian Sarge

o applicatifs client IPv4 et IPv6 sur le réseau local

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 : Mandrake 10.0


- 28 -

Figure 8 : plan d’adressage de la plate-forme après la mise en place de VLANs pour une zone DMZTP

6PT

Avantages de cette structure :

L’avantage de cette architecture est la sécurisation de la plate-forme avec les différents

VLANs, la gestion centralisée du réseau et la possibilité d’intégrer de nouveau VLAN comme par exemple un VLAN invité.

Le routeur 6wind permet un filtrage des paquets IPv4 et IPv6 pour chacun des VLANs. Les deux zones de test, une seulement IPv6 et une autre double pile IPv4 et IPv6

permettant de tester les technologies IPv6.

Configuration du commutateur Cisco 2950 Voici la partie configuration pour les VLANs :

Switch#show vlan

TP

6PT DMZ : zone démilitarisée étant un sous-réseau isolé par un pare-feu.


- 29 -

VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active Fa0/9, Fa0/10, Fa0/11, Fa0/12 2 reseau_local active Fa0/2, Fa0/3, Fa0/4, Fa0/5 3 DMZ active Fa0/6, Fa0/7, Fa0/8 4 prive active 17 VLAN0017 active 1002 fddi-default active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active #show conf interface FastEthernet0/1 duplex full speed 100 switchport mode trunk ! interface FastEthernet0/2 description partie RL_1 switchport access vlan 2 ! interface FastEthernet0/3 description partie RL_2 switchport access vlan 2 ! interface FastEthernet0/4 description partie RL_3 switchport access vlan 2 ! interface FastEthernet0/5 description partie RL_4 switchport access vlan 2 ! interface FastEthernet0/6 description partie DMZ_1 switchport access vlan 3 ! interface FastEthernet0/7 description partie DMZ_2 switchport access vlan 3


- 30 -

! interface FastEthernet0/8 description partie DMZ_3 switchport access vlan 3 ! interface FastEthernet0/9 ! interface FastEthernet0/10 ! interface FastEthernet0/11 ! interface FastEthernet0/12 ! interface VLAN1 no ip address no ip directed-broadcast ip nat outside shutdown ! interface VLAN4 ip address 192.168.0.2 255.255.255.0 no ip directed-broadcast ip nat outside !

Configuration du routeur 6Wind 6110 Voici la configuration de l’interface d’entrée du réseau de la plate-forme eth1_0 :

kriska{}display conf running eth1_0 # IPV4 ADDRESS # IPV6 ADDRESS # IPV6 PREFIX # INTERFACE STATEMENT intf up disable autoconfv6 mtu default tcp4mss disable tcp6mss disable


- 31 -

disable ipsec disable qos in disable qos out enable arp enable ndp router_advert smart 30000 1800 none 0 yes physical media auto bnet1 # BIND bind eth1_0 vlan 4 "prive" # IPV4 ADDRESS ipaddress 192.168.0.1/24 # IPV6 ADDRESS # IPV6 PREFIX # INTERFACE STATEMENT intf up disable autoconfv6 mtu default tcp4mss disable tcp6mss disable disable ipsec disable qos in disable qos out enable arp enable ndp router_advert smart 30000 1800 none 0 yes bnet2 # BIND bind eth1_0 vlan 2 "RL" # IPV4 ADDRESS ipaddress 195.89.126.225/29 # IPV6 ADDRESS ipaddress 2001:660:2002:4201::1/64 # IPV6 PREFIX prefix 2001:660:2002:4201::/64 # INTERFACE STATEMENT intf up disable autoconfv6 mtu default tcp4mss disable


- 32 -

tcp6mss disable disable ipsec disable qos in disable qos out enable arp enable ndp router_advert smart 30000 1800 none 0 yes bnet3 # BIND bind eth1_0 vlan 3 "DMZ" # IPV4 ADDRESS ipaddress 195.89.126.233/29 # IPV6 ADDRESS ipaddress 2001:660:2002:4203::1/64 # IPV6 PREFIX prefix 2001:660:2002:4203::/64 # INTERFACE STATEMENT intf up disable autoconfv6 mtu default tcp4mss disable tcp6mss disable disable ipsec disable qos in disable qos out enable arp enable ndp router_advert smart 30000 1800 none 0 yes

Test du bon fonctionnement des VLANs :

Définition du test : Une machine A envoie un ping vers une machine B. Sur chaque machine, le logiciel de capture de trame éthernet «Ethereal » est lancé. La vérification se fait en vérifiant que les machines de deux VLANs différents ne communiquent pas entre elles. Configuration : Machine A (VLAN 1) – IPv4 : 195.89.126.234/29


- 33 -

Machine B (VLAN 2) – IPv4 : 195.89.126.228/29 Passerelle pour le VLAN 1 – IPv4 : 195.89.126.233/29 Passerelle pour le VLAN 2 – IPv4 : 195.89.126.225/29 Résultat : Envoie de la commande : ping 195.89.126.228 Affichage des trames émises et reçues. «Le numéro devant la trame indique l’ordre des trames »

machine A (Ethéreal) machine B (Ethéreal)

1 : 195.89.126.234 195.89.126.233 demande ARP TP

7PT« qui est

195.89.126.228 »

2 : 195.89.126.225 195.89.126.228 demande ARP « qui est 195.89.126.228 »

4 : 195.89.126.233 195.89.126.234 réponse ARP

3 : 195.89.126.228 195.89.126.225 réponse ARP

5 : 195.89.126.234 195.89.126.228 Envoie message ICMPTP

8PT

6 : 195.89.126.228 195.89.126.234 Réponse message ICMP

Conclusion du test : Avec cette manipulation, on voit que la machine communique avec le routeur pour joindre

une machine d’un autre VLAN. La norme 802.1q étant un protocole de niveau deux de la couche OSI, ce test est valable

pour le protocole IPv4 et IPv6. Cela confirme le bon fonctionnement des VLANs sur la plate-forme.

TP

7PT ARP : Protocole de résolution d'adresse (Address Resolution Protocol)

TP

8PT ICMP : Internet de Contrôle de Message (Internet Control Message Protocole)


- 34 -

4.4.3.2. Mise en place d’un pare feu

La mise en place d’un pare feu permet de sécuriser la plate-forme. Ce pare feu a été configuré au niveau du routeur 6Wind qui est le routeur d’entrée de la plate-forme.

Le routeur 6Wind permet de filtrer tous les paquets IPv4 et IPv6 provenant de l’intérieur et de l’extérieur du réseau. J’ai choisi la politique d’interdire tous les paquets rentrant vers le réseau de la plate-forme et d’autoriser l’accès au serveur web et le serveur de nom.

Nous pouvons aussi créer des règles différentes entre le protocole IPv4 et IPv6, pour la

plate-forme, je reproduis les mêmes règles pour les deux protocoles.

Lors de la création des règles, il faut garder à l'esprit que les règles sont lues dans l'ordre croissant des numéros, dés qu'un paquet correspond à une règle le pare feu arrête de lire les règles. Ceci implique que si on crée deux règles, disons numéro 1400 et 1800, qui peuvent s'appliquer à une adresse IP spécifique, la règle 1400 sera toujours utilisée et la règle 1800 jamais.

Au niveau du routeur 6Wind 6110, les règles peuvent être comprises entre 999 et 2000 ou

entre 10000 et 60000. Lors de l’activation du pare feu, le routeur génère plusieurs règles automatiques.

# FILTER AUTOMATIC RULES rule6 190 allow ipv6-icmp from any to any icmp6type 133 rule6 191 allow ipv6-icmp from any to any icmp6type 134 rule6 192 allow ipv6-icmp from any to any icmp6type 135 rule6 193 allow ipv6-icmp from any to any icmp6type 136 rule 120 allow udp from any 500 to any 500 rule6 120 allow udp from any 500 to any 500 rule 125 allow tcp from any 22 to any rule 126 allow tcp from any to any 22 rule6 125 allow tcp from any 22 to any rule6 126 allow tcp from any to any 22 rule6 200 allow ipv6-icmp from any to FF02::1 icmp6type 130 rule6 201 allow ipv6-icmp from any to FF02::2 icmp6type 132

rule : règle pour le protocole IPv4 rule6 : règle pour le protocole IPv6 Comme le précise la RFC 1918, j’arrête les paquets sur les adresses de type privé. Cette RFC décrit l'allocation d'adresses pour des réseaux privés.


- 35 -

Voici les filtres installés : rule 01500 deny all from 192.168.0.0/16 to any via eth0_0 rule 01501 deny all from any to 192.168.0.0/16 via eth0_0 rule 01506 deny all from 172.16.0.0:255.240.0.0 to any via eth0_0 rule 01507 deny all from any to 172.16.0.0:255.240.0.0 via eth0_0 rule 01508 deny all from 10.0.0.0:255.0.0.0 to any via eth0_0 rule 01509 deny all from any to 10.0.0.0:255.0.0.0 via eth0_0

Pour pouvoir communiquer avec l’Internet, il faut faire des règles « dynamiques ». Si on utilise les règles « dynamiques », quand on envoie un paquet vers Internet, le pare feu va ajouter une entrée a sa table d'états. Cette entrée comprendra l'adresse IP de l'ordinateur à qui j'ai envoyé le paquet, et sur quel numéro de port j'ai effectué une connexion sur cet ordinateur. Quand des paquets reviendront de l'Internet, ils seront refusés s'ils ne proviennent pas de cette adresse IP et du numéro de port. Bien sur, les règles "dynamiques" ne fonctionnent qu'avec TCP puisque UDP ne supporte pas la création de connexions virtuelles, il est appelé "state-less" protocole et il ne peut pas utiliser la table d'état. Voici les lignes de configuration pour utilisées des règles « dynamiques » entre mon réseau et l’extérieur :

######################### # règle pour IPv4 # ######################### # indique de regarder dans les règles crées dynamiquement rule 01010 check-state # refuse les règles dynamiques avec l’option established rule 01020 deny tcp from any to any in established # indique de laisser passer les paquets tcp de “set up” de mon réseau vers

l’extérieur # et de créer une règle dynamique rule 01021 allow tcp from 195.89.126.224/28 to any setup keep-state ######################### # règle pour IPv6 # ######################### # identique au protocole Ipv4 rule6 01010 check-state rule6 01020 deny tcp from any to any in established rule6 01021 allow tcp from 2001:660:2002:4200::1/60 to any setup keep-state


- 36 -

Les serveurs devant être accessibles depuis l’extérieur, je laisse passer les paquets à destination de l’adresse du service et son numéro de port. Voici les règles pour les serveurs web et dns :

rule 01050 allow tcp from any to 195.89.126.234 80 rule 01051 allow udp from any to 195.89.126.234 80 rule 01060 allow udp from any to 195.89.126.234 53 rule 01061 allow tcp from any to 195.89.126.234 53 rule6 01040 allow tcp from any to 2001:660:2002:4203:2b0:d0ff:fe9a:42a1 53 rule6 01041 allow udp from any to 2001:660:2002:4203:2b0:d0ff:fe9a:42a1 53 rule6 01050 allow tcp from any to 2001:660:2002:4203:2b0:d0ff:fe9a:42a1 80 rule6 01051 allow udp from any to 2001:660:2002:4203:2b0:d0ff:fe9a:42a1 80

Voici la configuration complète du pare feu :

# FILTER AUTOMATIC RULES rule6 190 allow ipv6-icmp from any to any icmp6type 133 rule6 191 allow ipv6-icmp from any to any icmp6type 134 rule6 192 allow ipv6-icmp from any to any icmp6type 135 rule6 193 allow ipv6-icmp from any to any icmp6type 136 rule 120 allow udp from any 500 to any 500 rule6 120 allow udp from any 500 to any 500 rule 125 allow tcp from any 22 to any rule 126 allow tcp from any to any 22 rule6 125 allow tcp from any 22 to any rule6 126 allow tcp from any to any 22 rule6 200 allow ipv6-icmp from any to FF02::1 icmp6type 130 rule6 201 allow ipv6-icmp from any to FF02::2 icmp6type 132 # FILTER AUTOMATIC RULES # FILTER RULES IPv4 rule 01000 allow icmp from any to any rule 01010 check-state rule 01020 deny tcp from any to any in established rule 01021 allow tcp from 195.89.126.224/28 to any setup keep-state rule 01030 allow udp from 195.89.126.224/28 to any rule 01040 allow udp from any 53 to 195.89.126.227 rule 01041 allow udp from 195.89.126.227 to any 53 rule 01050 allow tcp from any to 195.89.126.234 80


- 37 -

rule 01051 allow udp from any to 195.89.126.234 80 rule 01060 allow udp from any to 195.89.126.227 53 rule 01061 allow tcp from any to 195.89.126.227 53 rule 01500 deny all from 192.168.0.0/16 to any via eth0_0 rule 01501 deny all from any to 192.168.0.0/16 via eth0_0 rule 01506 deny all from 172.16.0.0:255.240.0.0 to any via eth0_0 rule 01507 deny all from any to 172.16.0.0:255.240.0.0 via eth0_0 rule 01508 deny all from 10.0.0.0:255.0.0.0 to any via eth0_0 rule 01509 deny all from any to 10.0.0.0:255.0.0.0 via eth0_0 # FILTER RULES IPv6 rule6 01000 allow ipv6-icmp from any to any rule6 01010 check-state rule6 01020 deny tcp from any to any in established rule6 01021 allow tcp from 2001:660:2002:4200::1/60 to any setup keep-state rule6 01023 allow udp from 2001:660:2002:4201::1/64 to any rule6 01024 allow udp from 2001:660:2002:4202::1/64 to any rule6 01025 allow udp from 2001:660:2002:4203::1/64 to any rule6 01040 allow tcp from any to 2001:660:2002:4203:2b0:d0ff:fe9a:42a1 53 rule6 01041 allow udp from any to 2001:660:2002:4203:2b0:d0ff:fe9a:42a1 53 rule6 01050 allow tcp from any to 2001:660:2002:4203:2b0:d0ff:fe9a:42a1 80 rule6 01051 allow udp from any to 2001:660:2002:4203:2b0:d0ff:fe9a:42a1 80 # FILTER STATEMENT enable filter # IPv4 RPF CHECK # IPv6 RPF CHECK # LOG

Ce type de configuration de pare feu permet d’interdire toute intrusion dans le réseau

et de permettre l’accès qu’aux services qui doivent être vus par l’extérieur. Les règles « dynamiques » permettent aussi aux hôtes du réseau de communiquer avec

l’extérieur, ces règles « dynamiques » ont une durée de vie réduite, d’où une meilleure sécurité.


- 38 -

4.4.3.3. Mise en service des domaines renater.gn6.net et renater.gn6.org

Un serveur de nom était configuré sur la plate-forme IPv6 en septembre 2004, le domaine était gn6.renater.fr. Les noms de domaine gn6.net et gn6.org ayant été créés, il a fallu mettre en place deux noms de domaine pour la plate-forme IPv6 du gn6, renater.gn6.net et renater.gn6.org. Le serveur de nom gérant les noms de domaines gn6.net et gn6.org est situé à l’INRETSTP

9PT et

géré par Elba Burity. Le serveur de noms est l’application BIND 9.2.3(Berkeley Internet Name Domain) de l’université de Berkeley a donc été reconfiguré avec ces deux noms de domaine. Les personnes de l’extérieur peuvent donc accéder aux serveurs de la plate-forme avec le nom de domaine renater.gn6.net et renater.gn6.org. L’adresse du site web de la plate-forme IPv6 est donc HUwww.renater.gn6.netUH et HUwww.renater.gn6.orgUH.

TP

9PT INRETS : HTUInstitut National de Recherche sur les Transports et leur Sécurité UTH


- 39 -

4.4.3.4. Mise en place d’un outil de supervision : Nagios

La supervision du réseau n’étant pas assurée, j’ai mis en place un outil de supervision de la plate-forme, fonctionnant en IPv4 et en IPv6.

L’outil qui a été choisi est Nagios version 2.0 (http://www.nagios.org). Pour que cet outil puisse effectuer de la supervision, j’ai installé les plugins version 1.4 pour Nagios(http://sourceforge.net/projects/nagiosplug).

Nagios est une application servant à la surveillance des services et systèmes et du réseau.

Elle surveille les hôtes et services que vous spécifiez et alerte quand il se produit un problème et quand ça redevient normal.

Cet outil informe les utilisateurs par envoi de courriel, pour cela un serveur SMTP « Postfix » a été mis en place.

Pour faire fonctionner Nagios, il faut avoir une machine fonctionnant sous Unix avec un

compilateur C et la pile TCP/IP en IPv4 et IPv6 configuré. Nagios offre la possibilité d’administrer le réseau à partir de scripts CGI, il faut donc avoir

un serveur web. L’outil de supervision a donc été installé sur le serveur applicatif. Tous les plugins (pour la version 1.4) ne fonctionnent pas avec le protocole IPv6, voici la

liste des plugins fonctionnant en IPv6 :

• check_ping: envoie d’un message ICMP • check_by_ssh: teste le service ssh d’une machine • check_http: teste un serveur web • check_ldap: protocole d’annuaire • 4check_smtp: teste un serveur smtp • check_tcp: teste une connexion tcp

Après configuration, Nagios surveille plusieurs équipements de la plate-forme et m’informe s’il y a un problème sur un service.

Liste des équipements configurés avec les services surveillés :

• routeGN6.renater.gn6.net : routeur de jonction entre la partie IPv4/IPv6

et IPv6 o Services :

« alive » : teste si la machine répond au ping IPv6 « ping4routeGN6 » : teste si la machine répond au ping

IPv4 « ssh » : teste le service ssh


- 40 -

• pc3-ipv6.renater.gn6.net : serveur applicatif o Services :

« alive » : teste si la machine répond au ping IPv6 « ping4 pc3-ipv6 » : teste si la machine répond au ping

IPv4 « http » : teste le service http du site web « ssh » : teste le service ssh « smtp » : teste le serveur smtp « dns » : teste le serveur de nom en IPv4

• pc2-ipv6.renater.gn6.net : machine communiquant seulement en IPv6

o Services : « alive » : teste si la machine répond au ping IPv6 « ssh » : teste le service ssh

• 6wind.renater.gn6.net : routeur d’entrée de la plate-forme

o Services : « alive » : teste si la machine répond au ping IPv6 « ping46wind » : teste si la machine répond au ping IPv4 « ssh » : teste le service ssh

• lienGIP : Interconnexion entre la plate-forme IPv6 et le GIP RENATER

o Services : « alive » : teste si la machine répond au ping IPv6 « ping4lienGIP » : teste si la machine répond au ping

IPv4

Aucun service n’a été configuré pour tester la machine pc4-ipv6 étant sur le VLAN réseau local puisque cette machine correspond à une machine utilisateur et ne fonctionne pas en permanence.

L’inconvénient de cette architecture de supervision vient du fait que si un équipement

tombe en panne, tel que le 6Wind, le lien avec le GIP RENATER, le service DNS ou bien encore le serveur smtp, Nagios va voir qu’il y a un problème mais ne pourra pas envoyer de message d’erreur car le serveur smtp ne pourra pas envoyer de message.

Pour une meilleure supervision et une meilleure information, il faudrait installer Nagios à l’extérieur de la plate-forme.

Ensuite les hôtes et leurs services peuvent être visualisé et administré à partir du serveur

web.


- 41 -

Figure 9 : interface web indiquant l’état des hôtes

Figure 10 : interface web indiquant l’état des services


- 42 -

4.4.3.5.Mise en place d’un serveur SMTP (Postfix)

Pour que l’outil de supervision puisse communiquer l’état des services et des hôtes, nagios doit envoyer des courriels aux personnes concernées.

Il a donc fallu mettre en place un serveur SMTP permettant l’envoi de courriels. J’ai choisi d’installer l’application Postfix dû à sa simplicité d’installation, de configuration et c’est une application fiable.

Ce serveur SMTP étant accessible seulement par l’application nagios, je n’ouvre pas son

port de communication 25 au niveau du pare feu du routeur. Après la configuration de l’application Postfix, il faut indiquer dans le fichier « main.cf »

les adresses qui peuvent se connecter à ce serveur pour envoyer des courriels. Voici la ligne indiquant les plages d’adresses :

mynetworks = 127.0.0.0/8, 195.89.126.224/28, [2001:660:2002:4200::]/60

On remarquera la syntaxe avec des crochets pour indiquer une plage d’adresse IPv6. Dans le serveur de noms, je rajoute une ligne dans le fichier gérant le domaine

renater.gn6.net et une ligne dans le fichier de renater.gn6.org, cela indique le serveur smtp. Voici la ligne pour le domaine renater.gn6.net :

@ IN MX 10 pc3-ipv6.renater.gn6.net. ; création d’un alias pour le nom du serveur smtp.RENATER.gn6.net. IN CNAME pc3-ipv6.renater.gn6.net.

Test du fonctionnement du serveur SMTP : Ce test a été effectué avec la machine pc2-ipv6 qui contient seulement une interface IPv6. Le serveur SMTP écoute sur une adresse IPv4 et une adresse IPv6. Pour effectué ce test, je configure un client de messagerie (Mozilla) sur la machine pc2-

ipv6 (cette machine est connectée au réseau IPv6 seulement, elle ne peut pas avoir de communication IPv4) en indiquant l’adresse du serveur SMTP pour l’envoi des courriels.


- 43 -

Ensuite, j’envoie un courriel vers une adresse et je regarde si le message est bien arrivé au niveau d’une boite de messagerie fonctionnant en IPv4.

Ayant reçu le courriel envoyé depuis cette machine, cela indique que l’application Postfix envoie bien les courriels en IPv6 et en IPv4.


- 44 -

5. Les protocoles de communication audiovisuelle

5.1. Le multicast

5.1.1.Généralités

Une adresse multicast ne désigne pas une interface mais un ensemble d’interfaces. Une adresse multicast désigne un groupe multicastTP

10PT.

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 ses 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 réplique 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.

TP

10PT 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.


- 45 -

5.1.2.Adressage Multicast IPv4

Les adresses multicast sont celles qui correspondent en IPv4 aux adresses entre 224.0.0.0 et 239.255.255.255.

Voici quelques adresses réservées : 224.0.0.* réservé pour utilisation locale sur le LAN 224.0.0.1 tous les hosts multicast du LAN 224.0.0.2 routeurs multicast 239.*.*.* réservé pour l’administration

Toutes les adresses réservées sont référencées par l’IANA TP

11PTet sont disponibles à l’adresse :

HUhttp://www.iana.org/assignments/multicast-addressesUH. Voici le format d’une adresse multicast IPv4 :

1 1 1 0 Identification du groupe de diffusion 28 bits

Les 4 premiers bits valent 1110 indiquant une adresse multicast (224). Les 28 bits suivants identifient un groupe de diffusion particulier.

5.1.3.Adressage IPv6

Chaque pile IPv6 doit obligatoirement supporter le multicast (MLD). Une adresse multicast a le préfixe ff00::/8 et la structure suivante:

F F

1111 4 bits

1111 4 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 SSMTP

12PT positionnent ce champ à 3.

scope indique la portée de l'adresse IPv6. Cette fonctionnalité était partiellement 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é

TP

11PT IANA : Internet Assigned Numbers Authority www.iana.org

TP

12PT PIM SSM : protocole de routage multicast


- 46 -

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 (la valeur 0 indique que cette adresse est permanente, la valeur 2 indique que la portée est le lien local et le dernier 2 désigne les routeurs).

5.1.4.Gestion des groupes multicast

5.1.4.1. MLD version 1 (RFC 2710)

Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de routage multicast et un protocole de gestion de groupe multicast. Ce dernier réalise la signalisation entre l’hôte et son routeur d’accès à l’Internet. En IPv6, le protocole utilisé pour la gestion de groupe s’appelle MLD (Multicast Listener Discovery).

Le protocole MLD est utilisé par un routeur IPv6 pour découvrir la présence de récepteurs multicast, ainsi que les adresses multicast concernées. MLD est un protocole asymétrique qui spécifie un comportement différent pour les hôtes et les routeurs multicast. Toutefois, pour les adresses multicast qu’un routeur lui-même écoute, il doit exécuter les deux parties du protocole et répondre à ses propres messages. MLD est un sous-protocole d’ICMPv6, les messages MLD étant des messages ICMPv6 particuliers.

Les messages MLD sont envoyés avec une adresse source IPv6 lien-local, le champ « nombre de sauts » fixé à 1 et l’option « IPv6 Router Alert » activée. Cette option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles ils ne sont pas intéressés.

Voici le format d’un datagramme :

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Response Delay | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Multicast Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : Types de messages

• Recensement des récepteurs multicast (130)


- 47 -

• Rapport d’abonnement multicast (131) • Résiliation d’abonnement multicast (132)

Code : initialisé à 0 par l’émetteur et ignoré par la suite. Checksum : porte sur l’ensemble du message MLD et de l’en-tête IPv6 Délai Maximum de réponse : permet de définir un temps maximum de réponse pour les messages de type query Adresse multicast : adresse IPv6 multicast ou initialisé à 0 suivant le type de messages.

Le routeur envoie régulièrement des messages d’abonnement général à l’adresse de diffusion générale sur le lien (FF02 ::1). Les hôtes déclenchent des temporisateurs pour chaque adresse multicast qu’ils écoutent. Si un temporisateur expire sans que l’hôte ait entendu une réponse d’un de ses voisins concernant la même adresse, il va envoyer un rapport d’abonnement à l’adresse multicast du groupe. Ce système de temporisateurs permet aux hôtes de surveiller les rapports des autres hôtes sur le lien et d’annuler leurs propres rapports concernant les mêmes groupes. Ainsi la quantité du trafic peut être contrôlée.

Pour souscrire à une adresse multicast spécifique, un hôte envoie un rapport d’abonnement non-sollicité. Pour cesser d’écouter une adresse multicast, l’hôte peut simplement ne plus répondre aux messages de rapport du routeur. S’il était le seul récepteur de ce groupe sur ce lien, après un certain temps l’état du routeur concernant ce groupe va expirer. Le routeur va ainsi arrêter de faire suivre les paquets multicast envoyés au groupe en question.

MLD version 1 permet toutefois la possibilité d’une résiliation rapide. Dans ce cas,

l’hôte envoie un message de résiliation d’abonnement à l’adresse multicast de « tous les routeurs du lien local » (FF02::2). Le routeur répond avec un message de rapport spécifique à l’adresse en question. S’il n’y a plus de récepteur pour répondre à ce rapport, le routeur effacera l’adresse de sa table de routage.

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.


- 48 -

- 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.

5.1.4.2. MLD version 2 (RFC 3810)

Cette version du protocole implémente pour IPv6 les fonctionnalités du protocole IGMPv3 défini pour IPv4, la plus importante étant l’introduction du filtrage des sources. Un hôte peut désormais spécifier les sources qu’il veut ou qu’il ne veut pas écouter pour un groupe multicast donnée. Cette information peut être utilisée par les protocoles de routage multicast afin d’éviter l’acheminement des paquets multicast provenant de certaines sources vers des liens où il n’y a pas de récepteur intéressé.

5.1.4.3. Au niveau inter-LANs (Domaine PIM)

Les réseaux 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 :

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ée au groupe G1, envoie alors un rapport 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.


- 49 -

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 RFC1075) qui a aujourd’hui presque disparu et PIM-DM (Protocol Independant Multicast – Dense Mode, multicast indépendant du protocole – mode dense RFC3973) qui est plus récent, mais en voie de disparition aussi.

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.

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é RFC2362).

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.


- 50 -

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.

5.1.4.4. 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 RFC2858) et MSDP (Multicast Source Discovery Protocol RFC3618).


- 51 -

5.1.5. M6Bone

5.1.5.1. 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 dans RENATER afin de participer à la normalisation de ce protocole.

5.1.5.2. Topologie

A l’heure actuelle plus de 80 sites sont reliés au M6Bone, parmi lesquels des partenaires du projet ATHENA comme l’ESMT Dakar, l’université de Guadalajara au Mexique 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 de l’encapsulation 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.


- 52 -

Voici les cartes du M6Bone au niveau national, européen et mondial :

Figure 11 : Carte du M6Bone à l’échelle nationale.

Figure 12 : Carte du M6Bone à l’échelle européenne.


- 53 -

Figure 13 : Carte du M6Bone à l’échelle mondiale.

Figure 14 : JRES 2003 Bernard TUY-Jerome DURAND


- 54 -

5.2. RTP et RTCP (RFC 3550 anciennement 1889)

5.2.1.Introduction

Le protocole RTP (Realtime Transport Protocol) a été créé pour permettre le séquencement des paquets, l’horodatage des paquets, l’identification des paquets ainsi que la surveillance de l’état des connexions.

RTP est au-dessus du protocole UDP car le protocole TCP est inadapté au transport de paquet en temps réel. TCP exige une fiabilité de 100%, favorise la fiabilité au dépends du délai et TCP existe seulement en version unicast.

Le problème du protocole UDP est la non fiabilité du service de transport, on ne connaît pas le taux de pertes de paquet et il est impossible de reconstituer le flux et de synchroniser les médias.

RTP et son compagnon RTCP (Realtime Transport Control Protocol) permettent respectivement de transporter et de contrôler des flots de données qui ont des propriétés temps-réel.

RTP et RTCP sont des protocoles qui se situent au niveau de l'application et utilisent les

protocoles sous-jacents de transport TCP ou UDP. Mais l'utilisation de RTP/RTCP se fait généralement au-dessus de UDP.

RTP et RTCP peuvent utiliser aussi bien le mode Unicast (point à point) que le mode

Multicast (multipoint).

Ces deux protocoles ont les champs nécessaires pour reconstituer le flux, identifier le type d’information transportée et de contrôler l’arrivée des paquets à destination.

Le protocole RTP fournit les outils nécessaires aux applications pour le séquencement et l’horodatage des paquets UDP ce qui permet de reconstituer l’ordre des paquets, synchroniser les médias et détecter la perte de paquets.

Figure 15 : Schéma de la recomposition des paquets


- 55 -

5.2.2.En-tête d’un paquet RTP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V : version = 2 P : padding indiquant s’il y a des octets de remplissage X : extension de l’en-tête CC : nombre de source d’écoute M : marqueur PT : type des données Sequence number : numéro de séquence Timestamp (Horodate) : moment où le premier octet a été échantillonné SSRC : identifie de manière unique la source CSRC : identifie les sources contribuant

5.2.3.RTCP

Le protocole RTCP est le protocole de contrôle qui accompagne RTP pour mesurer les performances.

Il fournit des informations sur la qualité de la session, l’information en retour pour une source, permet à une source de changer de politique et met en évidence des défauts de distribution individuelle et collective.

Il permet aussi de contrôler le débit auquel les participants à une session RTP transmettent leurs paquets RTCP, plus il y a de participants, moins la fréquence d’envoie de paquets RTCP par un participant est grande et il faut toujours garder le trafic RTCP en dessous de 5% du trafic de la session. Il existe 5 types de paquets RTCP pour transporter des informations de contrôle : • SR : Sender Report, transmission de statistiques des participants actifs en émission


- 56 -

• RR : Receiver Report, transmission de statistiques des participants passifs • SDES : Source Description items (CNAME, NAME, EMAIL, PHONE,...) • BYE : Fin de participation • APP : fonctions spécifiques à l'application

5.2.3.1. Les paquets RTCP de type « Sender Report » et « Receiver Report »

Chaque participant d’une session RTP envoie soit des paquets de type « Sender Report »,

soit du type « Receiver Report ». La différence entre ces deux types de paquets est que le type « Sender Report » provient d’une source de paquets RTP et contient des statistiques de transmission et réception par les participants qui sont des expéditeurs actifs.

Les paquets de type « Receiver Report » proviennent des participants qui reçoivent des paquets RTP et ils envoient des statistiques de réception. Voici l’en-tête d’un paquet RTCP « Sender Report »: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| RC | PT=SR=200 | length | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word | sender +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | fraction lost | cumulative number of packets lost | 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


- 57 -

V : version = 2 P : padding indiquant s’il y a des octets de remplissage RC : nombre de blocs d’information PT : type du paquet RTCP ici PT=SR=200 Length : longueur totale SSRC of sender : identifie de manière unique la source NTP timestamp : moment où le rapport a débuté RTP timestamp : horodate conforme à l’unité des paquets RTP SSRC_1 : SSRC de la première source fraction lost : nombre de paquet perdus / nombre de paquets prévus depuis l’expédition du dernier rapport cumulative number of packets lost : nombre de paquets perdus extended highest sequence number received : numéro de séquence étendu du dernier paquet RTP reçu. interarrival jitter : gigue interarrivée, écart moyen de la différence de deux paquets au niveau du récepteur par rapport à l’émetteur last SR (LSR) : horodate du dernier SR delay since last SR (DLSR) : délai depuis le dernier SR Le paquet RR (Receiver Report) est identique au paquet SR (Sender Report) à la différence qu’il ne contient pas les informations de l’émetteur (SSRC of sender, NTP timestamp, RTP timestamp, sender's packet count, sender's octet count).

Les paquets de type SDES (Source description RTCP packet) permettent de garder une trace de tous les participants d’une session.

Voici les différentes informations pouvant être contenues dans un paquet SDES :

• CNAME: identifie la source de façon unique en général par un nom et une adresse de domaine

• NAME: nom du participant • EMAIL: mél du participant • PHONE: numéro de téléphone du participant • LOC: emplacement géographique • TOOL: application du participant • NOTE: permet d’indiquer l’état du participant • PRIV: extension privée

SDES: Description du paquet RTCP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| SC | PT=SDES=202 | length | header +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC/CSRC_1 | chunk +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


- 58 -

| SSRC/CSRC_2 | chunk +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ SDES items : les différentes informations pouvant être contenues.

Ce protocole fait une transmission périodique de paquets de contrôle (rapports) à tous les participants d’une session RTP.

Les paquets de type BYE indiquent la fin d’une session RTP à tous les participants. Les paquets de type APP permettent l’expérimentation de nouvelle application. Il existe des contraintes sur les paquets composés, les paquets de type SR et RR doivent

être envoyés aussi fréquemment que les contraintes sur la bande passante le permettent afin de maximiser les informations statistiques, chaque paquet RTCP doit contenir un paquet SR ou RR. Les nouveaux participants à une session doivent recevoir le plus rapidement possible le CNAME pour une source et chaque paquet RTCP doit contenir un paquet SDES.

5.2.3.2. Différences entre la RFC 1889 et 3550 La majeure partie de la RFC 3550 est identique à la RFC 1889. Il n'y a aucun changement

dans le format des paquets RTP et RTCP, seulement des changements de règles et d’algorithmes pour ces protocoles. Le plus grand changement est un perfectionnement de l'algorithme pour calculer quand envoyer les paquets RTCP.

Les différences entre ces deux RFC permettent de gérer plusieurs milliers de sessions aux conférences multi-participants.

5.2.4.Profil RTP Audio et Vidéo (RFC 3551 anciennement 1890)

Le profil RTP décrit un profil pour l’utilisation de RTP et RTCP pour une conférence

multi-participants audio et vidéo avec un minimum de contrôle. On y retrouve le conseil pour l’encodage de l’audio et de la vidéo, le document décrit

également le son et l’image devant être transportés par RTP ainsi que les ports assignés.

Recommandation Audio :

• Une application qui n’envoie pas de paquets pendant les silences positionne le bit M (Maker bit) a 1 dans l’en-tête RTP.

• Une application qui envoie des paquets pendant les silences positionne le bit M a 0. • L’horloge RTP est indépendante du nombre de canaux utilisés et de l’encodage.


- 59 -

• Les fréquences d’échantillonnage utilisable (Hz) : o 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000.

• Pour les sessions multi-canaux, les échantillons d’un même instant doivent être dans le même paquet RTP.

• L’encodage audio numérique est basé sur l’échantillonnage. o Tous les échantillons sont représentés par un nombre constant de bits. o Un paquet RTP peut contenir un nombre quelconque d’échantillons. o La durée d’un paquet audio est déterminée par le nombre d’échantillons. o Voici les différents types d’encodages recommandés :

DVI4, G722, G723, G726-40, G726-32, G726-24, G726-16, G728, G729, G729D, G729E, GSM, GSM-EFR, L8, L16, LPC, MPA, PCMA, PCMU, QCELP, VDVI.

Recommandation Vidéo :

• Voici les différents types d’encodages vidéo recommandés :

CelB JPEG H261 H263 H263-1998 MPV MP2T nv

Assignation de port :

Le protocole RTP doit fonctionner avec un port UDP ainsi que le protocole RTCP, il est préconisé de choisir un port aléatoirement pour RTP et pour RTCP, on choisit le port immédiatement supérieur. Exemple, si on a choisi le port 5004 pour RTP alors on choisit le port 5005 pour le protocole RTCP.

5.2.4.1. Différences entre la RFC 1890 et 3551 La RFC 3551 actualise principalement les types d’encodages audio et vidéo.

RTCP est un protocole de contrôle associé à RTP, il mesure les performances, par contre il n'offre pas de garantie. Pour cela il faut, employer un protocole de réservation du type RSVP (Resource ReSerVation Protocol RFC 2205) ou bien s'assurer que les liens de communications utilisés sont correctement dimensionnés par rapport à l'utilisation qui en est faite.


- 60 -

5.3. H323

5.3.1.Visioconférence H.323 La visioconférence H.323 permet d’effectuer une communication interactive combinant de multiples média tel que l’audio, la vidéo et les données. Cela permet des réunions à distance ainsi que le télé-enseignement etc. La norme H.323 est un protocole d’échange audio, de vidéo, de données, de contrôle et de signalisation. Un service multipoint de visioconférence H323, c’est :

• des terminaux, pour entrer en conférence • des ponts, pour la connexion des terminaux en multipoints • éventuellement des passerelles, pour accueillir des terminaux RNIS (Réseau

Numérique à Intégration de Service) • un réseau de portiers, pour intégrer un autre service dans le réseau • des pare-feu intégrant H.323, pour sécuriser le réseau • des applications, pour accéder aux services


- 61 -

5.3.2.Normes H.323 La norme H.323 est tirée de la norme H.320 (RNIS), elle définit comment des

systèmes audio et vidéo peuvent communiquer sur des réseaux de paquets fonctionnant en mode sans connexion et sans garantie de qualité de service.

Cette norme a été publiée par l’ITU-TTP

13PT, la première version de H.323 a été publiée en

1996 et la version 3 en 1999. Elle fournit un protocole permettant à tous les outils de fonctionner ensemble et traite plusieurs informations tel que le contrôle, la signalisation, l’audio, la vidéo et les données.

Figure 16 : Schéma représentant les normes que gère le protocole H.323

Voici les étapes d’un appel H.323 avec les ports utilisés :

• H.225-RAS (port UDP 1719) : ouverture d’un canal RAS (Registration, Admission, Status)

o enregistrement des terminaux auprès du portier (optionnel) • H.225-SIG (port TCP 1720) : ouverture du canal de signalisation

o initialisation des appels • H.245 (port TCP > 1024) : ouverture du canal de contrôle

o négociations des médias échangés entre terminaux • RTP/RTCP (ports UDP > 1024) : ouverture des canaux logiques pour les données

o Transport et contrôle de l’audio et de la vidéo

TP

13PT ITU-T : International Telecommunications Union - Telecommunication sector, organisation représentant les

opérateurs de télécommunications du monde entier.


- 62 -

• T.120 (port TCP 1503) : ouverture d’un canal pour le partage d’applications L’inconvénient des appels sans portier est que l’utilisateur doit utilisé uniquement

l’adresse IP, que les terminaux doivent être en adressage public et l’on doit ouvrir les ports TCP et UDP au-dessus de 1024.

Figure 17 : Schémas d’un appel H.323 sans portier H.323

H.225 (SIG) : Signalisation d’appel, mise en paquets et synchronisation pour système en mode paquet (basé sur Q.931). H.245 : Contrôle du signal: capacité d’échange, initialisation de l’échange, ouverture/fermeture des canaux. RTP/RTCP : Protocole de transport temps réel.


- 63 -

5.3.3.Portier H.323 (Gatekeeper) Un portier est utilisé dans une communication H.323 pour permettre d'établir une

communication entre deux « clients » de visioconférence. Ce portier peut être soit un logiciel, soit un matériel intégré dans un routeur ou un pont. La norme oblige un portier à effectuer plusieurs tâches, la traduction des adresses IP et E164, le contrôle d’admission, le contrôle de la bande passante et la gestion de la zone H.323. Optionnellement, il peut contrôler le signal d’appel, l’autorisation d’appel, la gestion de la bande passante, la gestion des appels et le routage des appels.

• Appel avec un portier :

Tout d’abord, les terminaux s’enregistrent auprès d’un portier H.323 avec un numéro E.164 ou un nom d’alias H.323, le portier peut alors faire la conversion entre l’adresse IP de la machine et le numéro E.164. Le portier connaît ensuite l’état de connexion des terminaux et les appels entre terminaux se font avec le numéro E.164 ou le nom d’alias H.323.


- 64 -

Figure 18 : Enregistrement à un portier H323

Il existe trois modes de fonctionnement d’un portier, l’appel direct où le portier ne fait que mettre en communications les terminaux, le portier gère et route les paquets H.225 et H.245 entre les terminaux et le dernier mode est le routage complet, appelé mode serveur mandataire (Proxy), cela permet de n’avoir aucune connexion directe entre les terminaux, tous les paquets H.323 sont envoyés au serveur mandataire qui route ensuite ces paquets. L’avantage est qu’un terminal avec une adresse privée peut être appelé ou appeler et cela diminue le nombre de port à ouvrir sur un pare feu. Mais tous les portiers n’intègrent pas la fonction de serveur mandataire.


- 65 -

Figure 19 : Trois modes de connexions en utilisant un portier H.323


- 66 -

5.3.4. Le plan de numérotation E.164

Le service d’appels H.323 est organisé autour du numéro E.164 des postes ou terminaux.

Chaque poste H.323 est identifié par un numéro de type E.164. Ce numéro s’intègre

dans le plan de numérotation national RENATER, lui-même intégré dans un plan international commun à divers réseaux de la recherche.

Le plan de numérotation national est le suivant :

0pppp nnnn Où :

0pppp : est un préfixe national (attribué par Renater) qui identifie le site dans lequel se trouve le poste H.323 (ou le pont multipoint),

nnnn : est le numéro interne au site de ce poste ou bien d’une conférence

fonctionnant sur un pont multipoint interne au site. Il est attribué par le responsable technique du site. Le nombre de chiffres (nnnn) peut varier, en fonction des impératifs techniques de chaque site.

Par la suite, un préfixe international pourra se rajouter en tête de ce numéro national. Il

permettra à des postes situés dans d’autres pays d’appeler des postes situés sur Renater et ses organismes utilisateurs. Inversement, il sera possible aux postes situés sur Renater et ses organismes utilisateurs d’appeler, par leur numéro H.323 sous sa forme internationale, des postes ou des conférences accessibles via les réseaux de la recherche d’autres pays participant à ce système d’appels H.323.

L’infrastructure de réseau mondial GDS (Global Dialling Scheme) basée sur des "gatekeepers" permet de faire le lien entre les différents pays avec les préfixes E.164.

Exemple de numéro national en France : 01 5394 8097 Où 015394 est le préfixe national, 8097 désigne le poste H.323.

5.3.5.Réseaux de portier H.323

Un portier H.323 gère une zone H.323 unique, il lui est attribué un préfixe X puis les terminaux s’enregistrent auprès du portier avec un numéro E.164 unique avec le préfixe X et ensuite les appels se font à l’aide des numéros E.164.

Les portiers sont interconnectés entre eux ce qui permet en fonction du numéro E.164 de router l’appel. Les portiers permettent aussi de s’affranchir du préfixe pour les appels à l’intérieur de la même zone.


- 67 -

Schéma des réseaux de portier H.323 :

Figure 20 : Appel vers n° E.164


- 68 -

Figure 21 : Réécriture de n° E.164


- 69 -

Figure 22 : Appel vers numéro E.164 interne


- 70 -

Figure 23 Schéma international des portiers H.323

5.3.6.Sécurité d’un réseau H.323

La sécurisation d’un réseau H.323 peut se faire de trois manières, par filtrage réseau avec des listes d’accès, un serveur mandataire derrière un pare feu ou un pare feu intégrant H.323. Pour un pare feu, il faut ouvrir les ports pour les équipements concernés, ce n’est pas une solution correcte puisqu’il faut ouvrir tous les ports au-dessus de 1024. Avec un serveur mandataire, on ouvre les ports vers le serveur mandataire ce qui permet de faire passer tout le trafic H.323 par le serveur mandataire. Des pare feu tel que Netscreem, Check Point ou Cisco PIX permettent de détecter dés la signalisation d’appel les ports UDP et TCP négociés et il ouvre dynamiquement les ports concernés pendant la durée de la connexion.


- 71 -

5.3.7. Pont multipoint (MCU) Un pont multipoint est indispensable si on veut effectuer une visioconférence de plus

de trois participants. C’est l’élément central d’une visioconférence H.323, il reçoit les flux audio et vidéo (et autres parfois) de chacun des participants, et les répercute vers les autres. Ce sont des équipements coûteux et souvent matériels, des constructeurs comme Tandberg, Polycom et Radvision construisent ce type de matériel.

Pour l’enregistrement d’un pont multipoint auprès d’un portier, le pont enregistre ses conférences sur le portier comme un terminal H.323, l’adresse IP du pont ainsi qu’un numéro E.164 unique pour chaque conférence, si le pont n’enregistre pas ses conférences auprès du portier, les conférences ne seront pas accessibles par les terminaux, mais le pont pourra appeler les terminaux par leur adresse IP. Si un terminal ne s’enregistre pas auprès du portier, il ne pourra pas appeler une conférence se déroulant sur un pont multipoint.

Le pont multipoint doit pouvoir être intéropérable avec les terminaux H.323, il doit supporter toutes les normes H.323, pour l’audio les normes G711, G722, G723, G728, G729 et MPEG4, pour la vidéo les normes H.216, H.263, H.264 en mode QCIF, CIF, 4CIF, la norme T.120 pour le partage d’application. Pour intégrer un pont dans un réseau de portiers, soit le pont intègre une fonction de un portier et il communique avec d’autres portiers, soit-il n’intègre pas de portier et il doit pouvoir s’interfacer à n’importe quel portier.


- 72 -

5.4. Protocole SIP (RFC 3261)

Le protocole SIP (Session Initiation Protocol) est un protocole de signalisation appartenant à la couche application du modèle OSI. Son rôle est d’ouvrir, modifier et libérer les sessions.

Le protocole SIP a été développé au sein du groupe de travail MMUSIC (Multiparty Multimedia Session Control) de l’IETF (Internet Engineering Task Force).

L’idée de départ de SIP était de développer un protocole englobant toutes les fonctions de traitement des appels actuellement offertes par le réseau téléphonique public commuté. Ainsi, SIP gère les fonctions standard de signalisation téléphonique telles que la composition du numéro, la sonnerie, le signal d’appel et la tonalité qui indique lorsque la ligne est occupée.

Ce protocole a par ailleurs été conçu pour fournir de nombreuses fonctionnalités SS7 (Signalling System 7) de gestion des appels incluant les services de traduction de numéros, mais aussi des options beaucoup plus complexes telles que l’identification de l’appelant. De plus, puisque SIP fonctionne avec un grand nombre de protocoles de transmission multimédia, il permet d’initier, de gérer et de terminer un large éventail de services multimédia.

5.4.1.Architecture protocolaire SIP

Le protocole SAP (Session Announcement Protocol RFC 2974) informe de l’ouverture d’une session en mode multicast ou non et le protocole SDP (Session Description Protocol RFC 3266) fournit la description des sessions multimédias.

Pour établir et terminer des communications multimédia, SIP utilise les 5 fonctions suivantes :

• Location utilisateur : permet de localiser le poste terminal utilisé pour communiquer

• Capacités utilisateurs : détermine quels médias vont être échangés (voix, vidéo, données…) ainsi que les paramètres associés.

• Disponibilité utilisateur: détermine si le poste appelé souhaite communiquer et autorise l’appelant à la contacter.

• Initialisation d’appel avertit les parties appelant et appelé de la demande d’ouverture de session (sonnerie ou message de réception d’appel) et mise en place des paramètres d’appel.

• Gestion d’appel : gère le transfert et la fermeture des appels.

SIP permet l’ouverture de sessions entre :


- 73 -

2 utilisateurs unicast : communication entre 2 stations. plusieurs utilisateurs en multicast : via une unité de contrôle MCU(Multipoint

Control Unit) . plusieurs utilisateurs pleinement interconnectés en multicast via un réseau à

maillage complet de connexions.

L’architecture en couches de SIP, telle que la présente le modèle OSI, fait apparaître une palette de nombreux protocoles :

SIP peut être également utilisé sur ATM(AAL5), X25 et frame relay.

Tous les éléments SIP doivent être implémentés avec le protocole TCP et UDP.

A chacune des couches de l’architecture SIP sont associés des protocoles tels que :

RSVP est un protocole utilisé pour les ressources réseaux sur IP avec une excellente qualité de service (QoS).

RTP.(Real-time Transport Protocol) pour transporter des informations en temps réel avec une excellente qualité de services.

RTCP.(Real-Time streaming Control Protocol) pour assurer le contrôle de flux des données multimédia.

SAP(Session Announcement Protocol) pour préciser si les sessions multimédia ouvertes le sont en multicast.

SDP(Session Description Protocol) est un protocole de description des sessions multimédia.


- 74 -

5.4.2.Ouverture d’une session Les différents éléments intervenant dans l’ouverture d’une session sont:

• La nature des échanges, le choix des protocoles les mieux adaptés (RSVP, RTP, RTCP, SAP, SDP).

• La détermination du nombre de sessions : par exemple, pour véhiculer de la vidéo, 2 sessions doivent être ouvertes (l’une pour l’image et l’autre pour la vidéo).

• L’identifiant de chaque utilisateur et sa machine décrit par une adresse que l’on nomme URL SIP et qui se présente comme une URL Mailto :

Informations_utilisateur@domaine [paramètres] [en-têtes]

Informations_utilisateur : nom d’utilisateur ou numéro de téléphone

Domaine : nom de domaine ou adresse IP et port

Paramètres : transport = udp ou tcp / user = phone ou IP / method = INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER / ttl = 0 à 255 / maddr = adresse IP multicast…

En-têtes : hname = hvalue & hname = hvalue…

• La requête URI : permet de localiser le proxy server auquel est rattaché la machine de l’appelé

• La requête SIP : une fois le client (machine appelante) connecté à un serveur SIP

distant, il peut lui adresser une ou plusieurs requêtes SIP et recevoir une ou plusieurs réponses de ce serveur. Les réponses contiennent certains champs identiques à ceux des requêtes, tels que : Call-ID, Cseq, To et From.

5.4.3. Appel SIP entre deux utilisateurs Lorsqu'un téléphone SIP se connecte au réseau IP, il signale sa présence à un serveur

mandataire SIP. Le serveur mandataire SIP met à jour l'annuaire LDAP qui indique l'adresse IP du téléphone et les opérations autorisées. Ce serveur mandataire dialogue avec un serveur de noms pour assurer la correspondance entre le nom de domaine de l'équipement et une adresse IP. Le téléphone appelant interroge son serveur mandataire pour localiser le téléphone destinataire (son adresse IP) et, s'il est disponible, engage le dialogue.


- 75 -

Figure 24 : Architecture SIP entre deux utilisateurs

1. L’application téléphonique SIP A s'inscrit dans le serveur mandataire SIP qui

effectue une demande d'appel auprès du serveur mandataire SIP B. Il analyse le nom de domaine de B à l'aide du serveur de noms. Le serveur mandataire SIP B transfère la demande au téléphone IP B.

2. Le téléphone B sonne et demande à l'utilisateur s'il souhaite répondre. La

réponse positive (200 OK) part alors vers le serveur mandataire B, passe par le serveur mandataire A et arrive sur l’application téléphonique A pour lui indiquer que l'appel est accepté.

3. L’application téléphonique A renvoie directement au téléphone B un accusé de

réception (ACK), et la communication est engagée.


- 76 -

5.4.4.Description des méthodes de requêtes

Les échanges entre un terminal appelant et un terminal appelé se font par l’intermédiaire de requêtes :

• INVITE : cette requête indique que l’application (ou utilisateur) correspondante à l’URL SIP spécifiée est invitée à participer à une session. Le corps du message décrit cette session (par ex : médias supportés par l’appelant). En cas de réponse favorable, l’invité doit spécifier les médias qu’il supporte.

• ACK : permet de confirmer que le terminal appelant a bien reçu une réponse

définitive à une requête INVITE.

• OPTIONS : un proxy server en mesure de contacter un terminal appelé, doit répondre à une requête OPTIONS en précisant ses capacités à contacter le même terminal.

• BYE : cette requête est utilisée par le terminal de l’appelé à fin de signaler qu’il

souhaite mettre un terme à la session.

• CANCEL : cette requête est envoyée par un terminal ou un proxy server à fin d’annuler une requête non validée par une réponse finale :

Si une machine ayant été invitée à participer à une session, et ayant accepté l’invitation ne reçoit pas de requête ACK, alors elle émet une requête CANCEL.

• REGISTER : cette méthode est utilisée par un client pour enregistrer son adresse

auprès du serveur auquel il est relié.

ULes réponses :U

Chaque réponse aux requêtes reçues est caractérisée par ce qu’on appelle un code et un motif, appelés respectivement Code d’état et Reason Phrase. Le motif étant la définition en clair du code d’état. Il existe 6 classes de réponses.

− 1xx = Information : la requête a été reçue et continue à être traitée ;

− 2xx = Succès : l’action a été reçue avec succès, comprise et acceptée ;

− 3xx = Redirection : une autre action doit être menée afin de valider la requête ;

− 4xx = Erreur du client : la requête contient une syntaxe erronée ou ne peut pas être traitée par ce serveur ;

− 5xx = Erreur du serveur : le serveur n’a pas réussi à traiter une requête apparemment correcte ;

− 6xx = Echec général : la requête ne peut être traitée par aucun serveur.


- 77 -

5.4.5.Etablissement d’une communication en mode client serveur

Pour établir une communication, l’appelant, que l’on désignera par client, adressera sa requête à un serveur SIP, qui lui donnera les moyens de communiquer. Seulement il existe 5 types de serveurs :

l’U.A.S.(User Agent Server) : c'est l'application du terminal d'abonné qui reçoit les requêtes et l'U.A.C.(User Agent Client) est l'application de ce même terminal qui émet les requêtes.

le serveur mandataire ou P.S. (Proxy Server) : auquel est relié un terminal fixe ou

mobile (lors de son déplacement, le terminal est relié au PS le plus proche et change constamment de PS) agit à la fois comme client et serveur. Un tel serveur peut interpréter et modifier les messages qu’il reçoit avant de les retransmettre.

le R.S.(Redirect Server) : réalise simplement une association (mapping) d’adresses

vers une ou plusieurs nouvelles adresses ( lorsqu’un client appelle un terminal mobile - redirection vers le PS le plus proche - ou en mode multicast - le message émis est redirigé vers toutes les sorties auxquelles sont reliés les destinataires - ). Notons qu’un Redirect Server est consulté par l'UAC comme un simple serveur et ne peut émettre de requêtes contrairement au PS.

le L.S.(Location Server) fournit la position courante des utilisateurs dont la

communication traverse les RS et PS auxquels il est rattaché : cette fonction est assurée par le service de localisation.

le RG(Registrar) est un serveur qui accepte les requêtes REGISTER et offre

également un service de localisation comme le LS. Chaque PS ou RS sont généralement reliés à un Registrar.

L’ouverture d’une session à l’aide du protocole SIP peut s’effectuer de façon directe

entre deux User Agents jouant le rôle du client et du serveur ou de façon indirecte au travers d’un serveur proxy.


- 78 -

5.4.6.Format des messages SIP

Un message SIP peut être à la fois une requête d’un client (terminal appelant) vers un serveur (terminal appelé), ou une réponse d’un serveur vers un client :

Ligne de requête (Méthode, Requête URI, version SIP) En tête général, ou de requête, ou d’entité CRLF (permet de spécifier la fin du champ d’en-têtes, et le début du corps du message) Corps du message

Figure 25 : Requête d’un client vers un serveur

Ligne d’état (version SIP, code d’état, Reason Phrases) En tête général, ou de réponse, ou d’entité CRLF (permet de spécifier la fin du champ d’en-têtes, et le début du corps du message) Corps du message

Figure 26 : Requête d’un serveur vers un client

Les différents champs d'en-tête qu'utilise SIP ne nécessitent pas d'ordre particulier sauf dans le cas de l'en-tête général où l'ordre des champs d'en-tête importe. En particulier, l'on distingue les champs d'en-têtes des messages transmis saut par saut (c'est-à-dire qui sont interprétés et peuvent être modifiés ou ajoutés par tous les serveurs qu'ils traversent) des en-têtes des messages transmis de bout en bout (interprétés par les émetteurs et destinataires uniquement et non modifiables par les serveurs traversés). Les champs d'en-tête saut par saut doivent apparaître avant les champs d'en-tête de bout en bout. Les serveurs mandataires ne doivent pas réordonner les champs d'en-tête mais peuvent ajouter éventuellement des champs.

Chaque méthode (ACK, BYE, CANCEL, INVITE, OPTIONS, REGISTER) requière, ne supporte pas ou supporte de façon optionnelle certains champs d'en-tête. Par exemple, les champs d'en-tête CALL-ID, Cseq, FROM et TO sont requis par toutes les méthodes (dans le cas de la méthode OPTIONS, il faut ajouter en plus le champ d'en-tête Allow ). Ces champs d'en-tête sont de type "de bout en bout".

Il existe 4 types de champs d'en-tête:

En-tête général s’applique à la fois aux messages de requête et de réponse : Accept, Accept-Encoding, Accept-Language, CALL-ID, Contact, Cseq, Date, Encryption, Expires, From, Record-Route, Timestamp.


- 79 -

En-tête d’entité définit le type d'informations contenues dans le Corps du message ou la ressource identifiée par la requête en l'absence du Corps du message : Content-Encoding, Content-Lenght, Content-Type.

En-tête de requête Le champ d'en-tête de requête autorise le client à ajouter des informations concernant sa requête et lui-même à destination du serveur : Authorization, Contact, Hide, Max-Forwards, Organization, Priority, Proxy-Authorization, Proxy-Require, Route, Require, Response-Key, Subject ou User-Agent.

En-tête de réponse Le champ d'en-tête de réponse autorise le serveur à ajouter des informations concernant sa réponse, qui ne peuvent pas être placées dans la ligne d'état, sur lui-même et sur l'accès à la ressource identifiée par la requête URI : Allow, Proxy-Authorization, Retry-After, Server, Unsupported, Warning ou WWW-Authenticate.

Contrairement aux protocoles standards tels que IP ou TCP, où le format des paquets ou segments est bien déterminé, le format des messages SIP n’est pas standard. Les champs d’en-tête sont choisis " à la carte " selon un panelle de champs. Lorsque les messages SIP sont transportés par UDP, avec authentification et une description de session complexe, il arrive que la taille du message SIP de requête ou réponse dépasse la MTU.

Pour résoudre ce problème, un format compact a été défini utilisant des abréviations pour certains champs.

Dans le cas des requêtes, un corps du message est ajouté ou non selon la méthode utilisée (par exemple : le corps du message d’une requête INVITE contient des informations indiquant la progression de la requête). Dans le cas des réponses, le corps du message est obligatoire (par exemple : la réponse à une requête INVITE contient dans le corps du message, une description de la session).

5.4.7.Comparaison SIP et H323 • Avantages du protocole H.323 :

Il existe de nombreux produits (plus de 30) utilisant ce standard adopté par de

grandes entreprises telles Cisco, IBM, Intel, Microsoft, Netscape, etc.

Les cinq principaux logiciels de visioconférence (Picturel 550, Proshare 500, Trinicon 500, Smartstation, Cruiser 150, utilisent sur IP la norme H.323.

Un niveau d’interopérabilité très élevé, ce qui permet à plusieurs utilisateurs d'échanger des données audio et vidéo sans faire attention aux types de média qu'ils utilisent.

• Avantages du protocole SIP :


- 80 -

SIP est un protocole plus rapide : la séparation entre ses champs d’en-tête et son corps du message facilite le traitement des messages et diminue leur temps de transition dans le réseau.

Nombre des en-têtes est limité (36 au maximum et en pratique, moins d'une dizaine d'en-têtes sont utilisés simultanément), ce qui allège l'écriture et la lecture des requêtes et réponses.

SIP est un protocole indépendant de la couche transport : il peut aussi bien s’utiliser avec TCP que UDP.

De plus, il sépare les flux de données de ceux la signalisation : ce qui rend plus souple l'évolution "en direct" d'une communication (arrivée d'un nouveau participant, changement de paramètres…).


- 81 -

6. Les applications de communications audiovisuelles

6.1. Les séminaires Aristote

Les séminaires d'Aristote sont transmis en direct (vidéo, voix, transparents) sur RENATER. Plusieurs dizaines d'auditeurs distants bénéficient de cette "téléparticipation".

La transmission en direct sur l’Internet peut être reçue sur un micro-ordinateur (PC Windows XP par exemple) ou une station de travail (Unix, Linux…).

Il y a deux méthodes, le choix entre les deux dépendant essentiellement de votre connectivité à l’Internet :

• Pour un site connecté à un réseau de la recherche (en France : RENATER), la réception audio et vidéo s’effectue en multicast à l’aide du service IP multicast.

• Si le site n’est pas connecté à un réseau de la recherche, la réception audio et vidéo s’effectue en streaming REAL.

Pour permettre la diffusion en haute qualité à travers le réseau RENATER, les séminaires sont retransmis à l’aide des outils OTESA.

OTESATP

14PT est un ensemble d'outils choisis et intégrés par Aristote, ou bien développés

spécifiquement, pour transmettre sur RENATER, en haute qualité, des cours, conférences et séminaires (vidéo et transparents), ainsi que pour les enregistrer et traiter ces enregistrements pour pouvoir les rejouer par la suite.

OTESA repose, pour l'essentiel, sur des logiciels libres ou gratuits, multi-plateformes, et sur des formats de données (audio, vidéo, transparents) standards.

OTESA est structuré en outils indépendants : ce sont des briques de base, que, pour chaque utilisation, l'on assemble comme on le désire. Ces outils sont interopérants grâce à un format d'échange de données commun de OTESA, que tous peuvent écrire ou lire. Ce format d'échange commun constitue le coeur d'OTESA. Grâce à cette structure modulaire, OTESA est très souple et évolutif, et pourra s'enrichir considérablement à l'avenir : nouveaux outils, nouvelles fonctionnalités.

OTESA est constitué de :

• VideoLAN pour la transmission et l'enregistrement de la vidéo (ou de l'audio).

TP

14PT OTESA : Outils de Transmission et d'Enregistrement de Séminaires Aristote

HTUhttp://www.aristote.asso.fr/OTESA/UTH


- 82 -

• ARTS pour la transmission et l'enregistrement des transparents en temps réel, ARTS est un producteur d'enregistrement conforme au format commun.

• ASSS est un interpréteur du format commun pour le post-traitement en vue de pouvoir rejouer à partir d'un CD ou d'un serveur. ASSS est aussi très pratique pour faire des diaporamas à partir de bien d'autres données que celles que ARTS fabrique, ASSS est un interpréteur qui produit des scripts SMIL.

• PPTtoOTESA pour faire le post-traitement avec ASSS (ou tout autre interpréteur ou éditeur de OTESA) d'une présentation Microsoft Powerpoint dans laquelle les flux audio de chaque diapo sont enregistrés (ce que l'on obtient dans le menu Diaporama / Enregistrer la présentation dans Powerpoint). PPTtoOTESA est un producteur d'enregistrement conforme au format commun

• OEaE est un éditeur du format d'échange commun de OTESA.

VideoLAN : la diffusion en direct et l'enregistrement de la vidéo

Développé par des étudiants de l'Ecole Centrale de Paris, VideoLAN est un outil de diffusion et de réception de vidéo en haute qualité. C'est un logiciel libre multiplateformes, qui utilise le multicast IP (ainsi que l'unicast), aussi bien en IPv6 qu'en IPv4. VideoLAN est retenu par OTESA à cause de la qualité et de la performance qu'il offre : typiquement, qualité TV (encodage Mpeg4 à 1 Mbit/s).

Pour plus d'information, voir HUwww.VideoLAN.org UH .

ARTS : la diffusion en direct et l'enregistrement des diapos

ARTS est destiné à l'enregistrement et à la transmission en temps réel des transparents d'un cours, d'un séminaire, d'une conférence.

Contrairement à la plupart des autres outils, ARTS n'apporte aucune contrainte sur l'outil utilisé par l'orateur.

ARTS est capable de transmettre l'image des transparents, en temps réel, par le Web, en excellente qualité (qualité informatique) : il doit être alors associé à un serveur Web tel qu'Apache.

ARTS est également capable d'enregistrer ces images, ainsi que les données annexes correspondantes, au format d'échange commun des outils OTESA, qui permet ensuite à ASSS


- 83 -

(Aristote Smil Slide Show) de générer automatiquement le script SMIL qui permet de rejouer le séminaire.

ASSS : la fabrication automatique des scripts SMIL

ASSS (AristoteSmilSlideShow) : un outil qui sert à SMILiser automatiquement un cours ou une conférence enregistrés avec un autre outil de OTESA : ASSS traite un format de description des données (audio, vidéo, transparents, timings...) d'une présentation. Ce format est un format d'échange commun à tous les outils d'OTESA.

Associé à ARTS, ASSS permet de fabriquer le script SMIL d'une présentation quel que soit le support de présentation informatique des transparents de ce cours.

Associé à PPTtoOTESA, ASSS vous permet de SMILiser votre présentation Powerpoint

Associé à un éditeur de textes, ASSS vous permet de réaliser très simplement un diaporama avec des fichiers images, et d'associer à chaque image un commentaire audio et une légende textuelle. Vous pouvez même intercaler des séquences vidéo entre les images !

ASSS est particulièrement intéressant pour des applications de cours à distance.

PPTtoOTESA : pour SMILiser automatiquement une présentation PowerPoint

PPTtoOTESA (Powerpoint To OTESA) : un outil qui, à partir d'une présentation Powerpoint contenant des enregistrements audio associés à chaque diapo, produit les données destinées à ASSS, conformément au format d'échange commun de OTESA.

OEaE : pour modifier ou extraire des données du format d'échange commun de OTESA

OEaE (OTESA Edit and Extract) est un éditeur du format commun de OTESA. En fonction des commandes qu'il trouve dans son fichier d'initialisation, il lit le fichier de description XML de la structure d'origine, modifie et/ou extrait les données, et écrit le résultat dans un nouveau fichier XML, dans le répertoire de destination. Il y recopie également (dans des sous répertoires qu'il crée) les fichiers multimédias associés (images, son, vidéo).


- 84 -

6.2. Le projet 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 situés dans : 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 (DESS ART), 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.

Les outils de visioconférence et leur mise en oeuvre :

La visioconférence nécessaire pour DIM comporte deux composants majeurs : l'audio et la vidéo, d'une part, l'affichage à distance en temps réel (et en bonne qualité) des transparents, d'autre part.

Une chaîne de transmission est affectée à l'audio et la vidéo. Dans une salle DIM, elle nécessite un PC multimédia (avec microphones, enceintes, ou raccordement à la régie audio s'il y en a une) et une bonne caméra, ainsi qu'un vidéoprojecteur et un écran.

Une autre chaîne de transmission est affectée aux transparents. Dans une salle DIM, elle nécessite un PC et un vidéoprojecteur.

L'audio et la vidéo :

La technique visioconférence repose sur le service IPv4 et IPv6 multicast de RENATER.

L’outil VideoLAN (haute qualité) permet la transmission de l'enseignant, en mode diffusion de son site vers tous les autres, c'est le « canal orateur » et pour l'interaction globale inter-sites les « outils MBone », on utilise VIC pour la vidéo et RAT pour l'audio. C'est le canal « interaction globale ».

Les transparents :

Technique : partage d'applications en H.323 / T.120 avec Netmeeting.

Les PC des sites DIM récepteurs démarrent Netmeeting et le connectent au Netmeeting du PC de l'orateur distant. Les adresses IP correspondantes, non publiques, sont connues des organisateurs.


- 85 -

6.3. ISABEL

L’applicatif de visioconférence ISABEL, développé au DIT-UPM de Madrid est commercialisé par la société AGORA (HUhttp://isabel.dit.upm.esUH). 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 27 : 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.


- 86 -

6.4. Les logiciels libres utilisant le protocole SIP

Plusieurs applications ont été développées pour la communication avec le protocole SIP, la suite indiquent les différents logiciels libres permettant d’installer clients, serveurs mandataires (proxy) et serveurs SIP d’enregistrement (PBX).

6.4.1. Les clients SIP dit U.A.C.(User Agent Client)

C'est l'application du terminal d'abonné qui émet les requêtes et l'U.A.S.(User Agent Serveur) est l'application qui recoit les requêtes. Clients Linux :

• Kphone o Site du projet kphone:

HUhttp://www.wirlab.net/kphone/index.html UH o Kphone fonctionnant avec le protocole IPv6

HUhttp://www.iptel.org/products/kphone/UH • Linphone

HUhttp://www.linphone.org/ UH • miniSIP

HUhttp://www.miniSIP.org/ UH • SFLphone

HUhttp://www.sflphone.org/ UH • SIPXphone

HUhttp://www.SIPfoundry.org/SIPXphone/UH • SIPXezPhone

HUhttp://www.SIPfoundry.org/SIPXezPhone/ UH

Clients windows:

• AdoreInfotech Softphone HUhttp://www.adoreinfotech.com/UH

• Shtoom HUhttp://www.divmod.org/projects/shtoomUH

• SIP COMMUNICATOR HUhttps://SIP-communicator.dev.java.net/UH

• SIPXphone HUhttp://www.SIPfoundry.org/SIPXphone/UH

• SIPXezPhone HUhttp://www.SIPfoundry.org/SIPXezPhone/ UH


- 87 -

6.4.2.Les serveurs mandataires Le serveur mandataire ou P.S. (Proxy Server) : auquel est relié un terminal fixe ou

mobile (lors de son déplacement, le terminal est relié au PS le plus proche et change constamment de PS) agit à la fois comme client et serveur. Un tel serveur peut interpréter et modifier les messages qu’il reçoit avant de les retransmettre.

• SIPd : serveur mandataire SIP et serveur de location HUhttp://www.sxdesign.com/ UH

• SIP Express Router : serveur mandataire et routeur SIP HUhttp://developer.berlios.de/projects/ser/UH

• PartySIP HUhttp://www.nongnu.org/partySIP/partySIP.html UH

• Sarp : serveur mandataire SIP et RTP HUhttp://sarp.sourceforge.net/UH

• SIProxd : serveur mandataire SIP et RTP HUhttp://SIProxd.sourceforge.net/UH

• SIPX : serveur mandataire et SIP PBX HUhttp://www.SIPfoundry.org UH

• vocal HUhttp://www.vovida.org/ UH

• Yxa HUhttp://www.stacken.kth.se/projekt/yxa/UH

• NIST SIP HUhttp://snad.ncsl.nist.gov/proj/iptel/UH

• Mini SIP Proxy HUhttp://www.tosti.com/files/perl-SIP-minipbx-0.1.tar.gzUH

• OpenSER HUhttp://openser.org/UH


- 88 -

6.4.3.Les serveurs SIP d’enregistrement « PBX » Le serveur SIP d’enregistrement assure la commutation des appels et leurs autorisations, il peut servir aussi de routeur ou de switch dans certains modèles, ainsi que de serveur DHCP. Il peut posséder des interfaces de type analogiques (fax), numériques (postes), numériques (RNIS,QSIG) ou opérateurs (RTC-PSTN ou EURO-RNIS).

• Asterisk : SIP PBX supportant les protocoles SIP et H323 HUhttp://www.asterisk.org/ UH

• OpenPBX HUhttp://www.voicetronix.com.au/open-source.htm#openpbxUH

• PBX4Linux : PBX RNIX HUhttp://isdn.jolly.de/UH

• SIPX HUhttp://www.SIPfoundry.org/SIPX/downloads.html UH

• YATE HUhttp://yate.null.ro/UH


- 89 -

7. Mise en œuvre

7.1. Les outils H323

7.1.1.OpenH323 La solution applicative gratuite est développée par le projet openH323 ayant 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 HUwww.openH323.org UH.

Pour les tests du protocole H323 avec le protocole IPv6, un ordinateur a été rajouté sur la plate forme IPv6 avec comme système d’exploitation une débian sarge. Cela permet de mettre en place les librairies H323 sur une machine avec les applications que l’on veut tester. Cet ordinateur a ensuite été installé dans le VLAN DMZ avec une adresse IPv4 et IPv6.

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.


- 90 -

7.1.2.Installation des librairies H323 sous Linux Debian sarge

Les dernières versions du projet openH323 se trouvent sur le site Internet

HUhttp://sourceforge.net/projects/openH323UH . Pour configurer une machine avec les librairies H323, il faut installé deux librairies, PWLIB et openH323.

La version installée de PWLIB est la 1.9.0 et pour openH323 la version 1.17.1, dans la documentation fournit avec ces deux librairies, il est précisé que le protocole IPv6 est intégré à ces deux librairies depuis l’année 2002 à titre expérimental.

L’installation de la librairie s’effectue en téléchargent le fichier PWLIB -v1_9_0-src-tar.gz, après l’extraction de l'archive avec la commande tar –zxf PWLIB -v1_9_0-src-tar.gz un dossier « PWLIB » est créé avec les codes sources de cette librairie.

Il faut ensuite exécuter les deux commandes configure et make pour installer cette librairie.

La librairie openH323 s’installe aussi de la même manière avec le fichier openH323-v1_17_1-src-tar.gz.

Pour que ces librairies puissent être utilisées par des applications h323, il faut mettre les chemins vers ces deux librairies dans deux variables globales. Les lignes de code ci-dessous ont été écrites dans le fichier « /etc/profile » :

PWLIB DIR="/home/lebonhomme/PWLIB " export PWLIB DIR OPENH323DIR="/home/lebonhomme/openH323" export OPENH323DIR LD_LIBRARY_PATH="$PWLIB DIR/lib:$OPENH323DIR/lib" export LD_LIBRARY_PATH


- 91 -

7.1.3.Test du fonctionnement des librairies H323 avec les protocoles IPv4 et IPv6

Après avoir installé les librairies PWLIB et openH323, nous devons pour tester le

protocole H323, installé une application permettant de faire des tests H323. Ce programme ce trouve dans le répertoire openH323/samples/simple. L’application

s’appelle simph323 sous linux et simple.exe sous windows. Pour installer cette application il faut taper la commande make dans ce répertoire.

Cela créer ensuite un répertoire obj_linux_x86_r où se trouve l’application.

Pour ce test, il faut avoir installé les librairies sur deux ordinateurs. Ces deux ordinateurs doivent aussi fonctionner avec IPv4 et IPv6.

UConfiguration des ordinateurs : PC1 : Adresse IPv4 : 195.89.126.235 Adresse IPv6 : 2001:660:2002:4203:2c0:4fff:fea9:22c4 PC2 : Adresse IPv4 : 195.89.126.226 Adresse IPv6 : 2001:660:2002:4201:201:3ff:fe83:7d09

UTest appel IPv4 vers IPv4 en local :

• Dans un premier shell on lance la commande permettant d’écouter avec l’adresse 127.0.0.1 et d’attendre un appel :

./simph323 -tttt -n -i 127.0.0.1 -l –a

• Dans un deuxième shell on écoute sur l’adresse 195.89.126.235 et on appel l’adresse

127.0.0.1 :

./simph323 -tttt -n -i 195.89.126.235 -n 127.0.0.1 Sur le premier shell, l’application attend une connexion d’où le message :

0:00.221 H323 Listener:8060490 H323 Awaiting TCP connections on port 1720 0:00.242 H323 Listener:8060490 TCP Waiting on socket accept on

ip$127.0.0.1:1720

Lorsqu’on tape la deuxième commande dans le second shell, on s’aperçoit qu’une connexion est établit entre les deux applications.


- 92 -

En réponse, les deux shell indique que la connexion est effectuée :

0:08.552 H225 Answer:8060fa8 H323 InternalEstablishedConnectionCheck:

connectionState=EstablishedConnection fastStartState=FastStartDisabled


• Dans un premier shell on lance la commande permettant d’écouter avec l’adresse ::1 et

d’attendre un appel :

./simph323 -tttt -n -i [::1] -l –a

• Dans un second shell, on écoute en IPv6 et on appelle l’adresse ::1 :

./simph323 -tttt -n -i [2001:660:2002:4203:2c0:4fff:fea9:22c4] -n [::1] Message du premier shell indiquant que l’application écoute en IPv6 :

0:00.233 H323 Listener:8060470 H323 Awaiting TCP connections on port 1720 0:00.246 H323 Listener:8060470 TCP Waiting on socket accept on ip$[::1]:1720

En réponse les deux shells indiquent que la connexion est effectuée :

0:08.552 H225 Answer:8060fa8 H323 InternalEstablishedConnectionCheck:



• Dans le premier shell, on écoute sur l’adresse 127.0.0.1 et on attend un appel :

./simph323 -tttt -n -i 127.0.0.1 -l –a

• Dans le deuxième shell, on écoute avec l’adresse IPv6 et on appel l’adresse 127.0.0.1

./simph323 -tttt -n -i [2001:660:2002:4203:2c0:4fff:fea9:22c4] -n 127.0.0.1

Les deux shell indique les mêmes résultats que précédemment ce qui indique que la connexion s’effectue correctement entre l’appel avec une adresse IPv4 et une adresse IPv6.


- 93 -

UTest appel IPv4 vers IPv4 entre deux ordinateurs :

• Avec le premier hôte, on attend un appel avec l’adresse 195.89.126.235 :

./simph323 -tttt -n -i 195.89.126.235 -l –a

• Avec le deuxième hôte, on appel l’adresse 195.89.126.235 avec l’adresse 195.89.126.26 :

./simph323 -tttt -n -i 195.89.126.226 -n 195.89.126.235

L’appel se déroule correctement puisqu’on a le message indiquant que la connexion est établit entre les deux hôtes.

1:24.406 H225 Answer:8060a48 H323 InternalEstablishedConnectionCheck:



• Le premier hôte écoute sur l’adresse IPv6 2001:660:2002:4203:2c0:4fff:fea9:22c4 :

./simph323 -tttt -n -i [2001:660:2002:4203:2c0:4fff:fea9:22c4] -l -a Le deuxième hôte appel l’adresse IPv6 2001:660:2002:4203:2c0:4fff:fea9:22c4 avec son adresse IPv6 2001:660:2002:4201:201:3ff:fe83:7d09 :

./simph323 -tttt -n -i [2001:660:2002:4201:201:3ff:fe83:7d09] -n [2001:660:2002:4203:2c0:4fff:fea9:22c4]

Le premier hôte indique avec un message qu’il écoute avec l’adresse IPv6 :

0:00.208 SimpleH323 H323 Started listener

Listener[ip$[2001:660:2002:4203:2c0:4fff:fea9:22c4]:1720] 0:00.212 H323 Cleaner H323 Started cleaner thread Waiting for incoming calls for "root" 0:00.216 H323 Listener:80602a0 H323 Awaiting TCP connections on port 1720 0:00.235 H323 Listener:80602a0 TCP Waiting on socket accept on

ip$[2001:660:2002:4203:2c0:4fff:fea9:22c4]:1720


- 94 -

Lorsque l’appel est effectué les deux hôtes indiquent que la connexion c’est effectué correctement :

1:03.854 H225 Caller:8061198 H323 InternalEstablishedConnectionCheck:



• Le premier hôte écoute sur son adresse IPv4 195.89.126.226: ./simph323 -tttt -n -i 195.89.126.226 -l –a

• Le deuxième hôte appel l’adresse IPv4 195.89.126.226 avec son adresse IPv6

2001:660:2002:4203:2c0:4fff:fea9:22c4

./simph323 -tttt -n -i [2001:660:2002:4203:2c0:4fff:fea9:22c4] -n 195.89.126.226

Le message indiquant que la connexion a été établit s’affiche sur l’écran des deux hôtes :

0:02.631 H225 Caller:8062dc8 H323 InternalEstablishedConnectionCheck:

connectionState= EstablishedConnection fastStartState=FastStartDisabled

Cette série de tests permet de valider les librairies PWLIB et openH323 avec le protocole IPv4 et IPv6.


- 95 -

7.1.4.Test entre deux clients H323

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.

Le logiciel est installé dans la version de base du système d’exploitation debian sarge, les tests ont été effectués avec la version 1.2.1 de GnomeMeeting.

Le premier test est une connexion entre deux clients GnomeMeeting. Un client étant dans le VLAN seulement IPv6 de la plate forme IPv6 et le deuxième étant dans le VLAN réseau local ayant une adresse IPv4 et IPv6.

Figure 28 : Schéma du test entre les deux clients H323

Il existe deux manières de se connecter aux clients : En tapant l’adresse IPv4 ou IPv6 de l’hôte ou bien en tapant son nom inscrit dans le DNS. Pour appeler un hôte avec une adresse IPv6, il faut inscrire l’adresse IPv6 entre crochet : Exemple : h323 :[2001:660:2002:4202:2b0:d0ff:fe9a:4359]


- 96 -

Voici les écrans des deux tests effectués avec GnomeMeeting :

Figure 29 : Appel du client se trouvant dans le VLAN IPv6 seulement en utilisant l’adresse IPv6

Figure 30 : Appel du client se trouvant dans le VLAN IPv6 seulement en utilisant le nom de l'hôte

Ce test nous permet de confirmer que le logiciel GnomeMeeting fonctionne avec le protocole IPv6 ainsi que la résolution de nom en IPv6 avec le serveur DNS.


- 97 -

7.1.5.Test du logiciel openMCU

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, sur la plate forme IPv6 ce logiciel est installé sur la machine h323 (OS : debian sarge) dans la zone DMZ. Nous utiliserons la version 1.1.9 du logiciel openMCU téléchargeable sur le site HUhttp://sourceforge.net/projects/openH323UH.

U Installation et configuration du logiciel openMCU :

Pour installer le logiciel openMCU, il faut téléchargé le fichier openMCU-v1_1_9-src-tar.gz et décompresser ce fichier. Un répertoire openMCU_v1_1_9 est ensuite créé. Ensuite on tape la commande make pour installer ce logiciel. Cette installation produit un fichier exécutable openMCU permettant de lancer le pont multipoint. Le lancement de openMCU ce fait de deux manières, soit en tapant sur la ligne de commande les options, soit en éditant un fichier openMCU.ini dans le répertoire ~/.PWLIB _config/. Voici le fichier de configuration utilisé pour les tests :

[Options] #indique qu’on n’utilise pas de portier H323 no-gatekeeper=True trace=True #indique le fichier de log output=/home/lebonhomme/openMCULog/openMCU.log #indique le nom des sessions crées defaultroom=gn6 #indique l’utilisation de la vidéo video=True audio-loopback=* #indique l’adresse IPv4 ou IPv6 que l’on utilise, ici on indique l’adresse IPv6 interface=2001:660:2002:4203:2c0:4fff:fea9:22c4

Si nous n’indiquons pas l’adresse de l’interface, par défaut le logiciel prend l’interface

IPv4 de l’hôte.


- 98 -

Si on indique une adresse IPv4 et IPv6 (exemple : interface=195.89.126.235, 2001:660:2002:4203:2c0:4fff:fea9:22c4) dans ce cas le logiciel n’interprète pas la ligne et écoute avec l’adresse IPv4.

Plusieurs configurations d’interface ont été testées pour faire écouter le logiciel en IPv4 et IPv6. Voici les configurations testées et non interpréter par le logiciel openMCU :

interface=195.89.126.235,2001:660:2002:4203:2c0:4fff:fea9:22c4

interface=195.89.126.235,[2001:660:2002:4203:2c0:4fff:fea9:22c4]

interface=2001:660:2002:4203:2c0:4fff:fea9:22c4 interface=195.89.126.235

UTest du logiciel openMCU en IPv6 :

Le test effectué s’effectue avec trois machines. La machine H323 où le logiciel openMCU est installé. Sur ce pont multipoint, se connectent en IPv6 deux clients avec le logiciel GnomeMeeting. Un client dans le VLAN seulement IPv6 et un client dans le VLAN réseau local.


- 99 -

Figure 31 : Schéma de l'appel d'un openMCU en IPv6

Sur les clients H323 GnomeMeeting, nous tapons l’adresse IPv6 de l’openMCU et nous visualisons ensuite les hôtes de la visioconférence.


- 100 -

Figure 32 : Un client GnomeMeeting connecté au pont openMCU en IPv6

Ce même test a été effectué avec la version 1.1.7 du logiciel openMCU disponible sur

le site www.openH323.org avec un système d’exploitation windows XP. Avec cette version du logiciel, le pont multipoint a fonctionné avec une adresse IPv4

mais pas une adresse IPv6. Avec tous les formats de configuration de l’interface, le logiciel openMCU écoute sur

l’adresse IPv4 de la machine.

Ce test permet de valider le fonctionnement du logiciel openMCU version 1.1.9 avec le protocole IPv6. L’inconvénient de cette version vient du fait que le pont multipoint H323 écoute sur l’interface IPv4 ou IPv6 mais pas les deux en même temps.


- 101 -

7.1.6.Test du portier H323 GNUgk

OpenH323 Gatekeeper - The GNU Gatekeeper est un projet « open-source » qui implémente un gatekeeper H.323. Un gatekeeper fournit des services de contrôle d'appel pour les terminaux H.323. Il s'agit une partie essentielle de la plupart des installations de téléphonie sur Internet qui sont basées sur la norme H.323.

Selon la recommandation H.323, un gatekeeper doit fournir les services suivants:

• Traduction d'Adresse • Contrôle d'Admissions • Contrôle de Bande Passante • Gestion de Zone • Signalisation d’appel • Autorisation d'Appel • Gestion de Bande Passante • Gestion des Appels

Le GNU Gatekeeper implémente la plupart des fonctions basées sur la pile du protocole OpenH323.

UCompilation du portier H323 « Gatekeeper »

Pour installer le gatekeeper vous avez besoin d'au moins PWLIB 1.5.0 et OpenH323 1.12.0 ou ultérieur. La version de développement du gatekeeper a généralement besoin de la version de OpenH323 la plus récente disponible. Ces librairies sont disponibles sur la page de téléchargement de OpenH323. Nous avons testé la version 2.2.2 du portier H323 GNUgk.

Avant de compiler le gatekeeper, il faut avoir installer les librairies PWLIB et OpenH323.

Sous Unix faire TconfigureT et Tmake optT dans le répertoire du gatekeeper pour construire la version release du gatekeeper.

UConfiguration du gatekeeper

Le fichier de configuration est un fichier texte normal. Soit-on l’indique au lancement du gatekeeper en tapant par exemple /usr/sbin/gnugk -c /etc/gnugk.ini avec gnugk.ini le fichier de configuration. La deuxième possibilité est d’utiliser un fichier de configuration gatekeeper.ini situé dans le répertoire ou se trouve l’exécutable du gatekeeper.


- 102 -

Un préfixe E164 a été alloué par le GIP RENATER qui est le 5399. Cela indique qu’un utilisateur numérotera le numéro 015399 puis le numéro de poste H323 de l’utilisateur sur la plate forme pour pouvoir contacter un correspondant en H323.

Exemple : Hôte 1 a le numéro 0001, alors un correspondant distant numérotera le numéro 0153990001 pour le joindre.

Voici le fichier de configuration utiliser par le gatekeeper de la plate forme IPv6.

[Gatekeeper::Main] Fourtytwo=42 Name=GK_GN6 TimeToLive=300 ;Interface d’écoute du portier H323 Home=195.89.126.235 [RasSrv::RewriteE164] ;Réécriture pour pourvoir router, vers les GK de sites, les appels venant ;de l'international ;Exemple : un appel venant de l’étranger vars la plate forme avec le code ;francais 0033, il tape 0033153990001 seras réécrit en 0153990001 0033=0 [LogFile] Rotate=Daily RotateTime=00:00 [RoutedMode] ;on route les paquets GKRouted=1 H245Routed=1 CallSignalHandlerNumber=1 RemoveH245AddressOnTunneling=1 AcceptNeighborsCalls=1 AcceptUnregisteredCalls=1 DropCallsByReleaseComplete=1 SendReleaseCompleteOnDRQ=1 Q931PortRange=20000-20999 H245PortRange=30000-30999 [Proxy] ;mettre 1 si on veut qu'il fasse proxy ;ici test sans la fonstion de proxy Enable=0 T120PortRange=40000-40999 RTPPortRange=50000-59999 [RasSrv::Neighbors] ;les addresses des gatekeepers francais de RENATER GIPRENATER1=195.89.126.13;0 GIPRENATER2=195.89.126.14;0


- 103 -

7.1.7.Configuration des clients H323 avec un portier H323 Microsoft NetMeeting :

L’application Microsoft NetMeeting permet l’enregistrement de son numéro E164 sur un portier H323.

Deux paramètres sont obligatoires pour pouvoir effectuer des appels à l’aide du portier

H323 en utilisant un numéro E164 : • L’adresse IP du portier H323 • Le numéro E164 que l’on utilise

Figure 33 : Fenêtre de configuration de NetMeeting du compte benoît avec le numéro E164 0153990001


- 104 -

GnomeMeeting :

Le client gnomemeeting permet également de s’enregistrer auprès d’un portier H323, pour ceci il faut indiquer dans la configuration les mêmes paramètres que pour NetMeeting.

Figure 34 : Fenêtre de configuration pour le numéro E164 0153990002


- 105 -

UAppel d’un client H323 avec un numéro E164 :

Pour appeler un correspondant avec son numéro E164, il suffit de numéroter son numéro comme un numéro téléphonique.

Figure 35 : Appel vers le numéro 0153990001 à partir du client H323 GnomeMeeting

UTest du portier H323 GNUgk en IPv6 :

Dans le fichier de configuration du gatekeeper, nous avons indiqué l’adresse IPv6 de l’interface d’écoute du gatekeeper :

Home= 2001:660:2002:4203:2c0:4fff:fea9:22c4

Après plusieurs changements de syntaxe pour l’adresse IPv6, à chaque lancement du

gatekeeper, la ligne était ignorée et l’interface par défaut était prise pour l’écoute du gatekeeper.


- 106 -

Voici le message au lancement du gatekeeper :

OpenH323 Gatekeeper - The GNU Gatekeeper with ID 'GK_GN6' started Gatekeeper(GNU) Version(2.2.2) Ext(pthreads=1,radius=1,mysql=0,pgsql=0,large_fdset=0)

Build(Jul 8 2005, 19:12:28) Sys(Linux i686 2.4.27-2-386) Listen on 195.89.126.235,127.0.0.1

La commande netstat -pl -A inet a confirmé que le gatekeeper n’écoutais pas avec l’adresse IPv6.

Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name tcp 0 0 localho:afs3-fileserver *:* LISTEN 9930/gnugk tcp 0 0 h323.re:afs3-fileserver *:* LISTEN 9930/gnugk tcp 0 0 localhost.localdom:1721 *:* LISTEN 9930/gnugk tcp 0 0 h323.RENATER.gn6.n:1721 *:* LISTEN 9930/gnugk

Et la commande netstat -pl -A inet6 nous indique que le gatekeeper n’écoute pas sur

l’adresse IPv6.

UTest de l’application GnomeMeeting avec enregistrement sur le gatekeeper en IPv6 :

Le deuxième test est de savoir si le logiciel GnomeMeeting fonctionnant en IPv6 peut

s’enregistrer vers un portier H323 en IPv6. Vu que le portier H323 GNUgk n’écoute pas en IPv6, nous avons testé si

GnomeMeeting envoyait correctement des paquets IPv6 vers l’adresse du gatekeeper que nous lui avons indiqué. Nous avons utilisé pour cela le logiciel Ethereal permettant de capturer les trames IPv4 et IPv6 d’une machine.

En IPv4, deux paquets sont envoyés vers le gatekeeper, deux paquets avec le protocole H225 un « gatekeepeerRequest » et un « gatekeeperConfirm » tous deux recevant une réponse du gatekeeper.


- 107 -

Pour ce test nous avons rentré l’adresse IPv6 dans le champ hôte gatekeeper sous deux formes, avec des crochets et sans crochets.

2001:660:2002:4003:2c0:4fff:fea9:22c4 ou [2001:660:2002:4003:2c0:4fff:fea9:22c4]

Dans le cas sans crochet, GnomeMeeting tente de faire une résolution de nom DNS avec l’adresse IPv6 n’à aucune réponse du serveur DNS. Dans le cas de l’adresse entre crochet, il n’interprète pas cette ligne et n’envoie pas de paquet H225 vers l’adresse IPv6.

Dans ces deux cas, le logiciel répond par une erreur d’enregistrement auprès du gatekeeper.

En conclusion, nous avons vu à la suite de ces tests que ni le logiciel GNUgk ni le logiciel GnomeMeeting ne fonctionnent avec le protocole IPv6 pour l’enregistrement auprès d’un portier H323.


- 108 -

7.2. Les outils SIP

7.2.1.Appel SIP avec l’outil kphone

KPhone est un logiciel libre publié sous licence GPL de téléphonie sur IP, client du protocole SIP.

Le téléchargement de ce logiciel s’effectue sur le site HUhttp://www.wirlab.net/kphone/ UH.

Sous linux debian, un paquetage est disponible, l’installation s’effectue en tapant la ligne de commande apt-get install kphone.

Appel entre deux logiciels kphone : Ce test permet une communication SIP entre deux utilisateurs disposant du logiciel kphone. Pour cela nous avons installé le logiciel kphone sur deux ordinateurs équipés du système d’exploitation debian Sarge.

Figure 36 : Appel SIP entre deux utilisateurs

Pour cela, nous configurons chaque logiciel kphone en indiquant le nom de l’utilisateur, sa partie utilisateur de l’URL SIP ainsi que la partie hôte de l’URL SIP. Ensuite, nous pouvons appeler un autre utilisateur en tapant dans la partie « Nouvel appel » : SIP:NOM@ADRESSE.


- 109 -

Figure 37 : Interface de kphone

Figure 38 : Communication SIP avec un autre utilisateur


- 110 -

8. Application de gestion d’une visioconférence à l’aide du logiciel VidéoLan

8.1. VideolanP

15P

VideoLAN est une solution complète pour la lecture et la diffusion de vidéo par réseau,

développée par des étudiants de l'Ecole Centrale Paris et des développeurs du monde entier, sous licence GNU General Public License (GPL). VideoLAN est conçu pour diffuser des vidéos MPEG sur des réseaux hauts débits.

VideoLAN a été historiquement conçu pour la diffusion sur réseau, mais le principal

logiciel du projet, VLC media player, est devenu un lecteur multimédia tout en un multi-plateformes.

Historiquement appelé VideoLAN Client, VLC media player est le principal logiciel de la solution VideoLAN.

VLC fonctionne sur de nombreux systèmes d'exploitation : Linux, Windows, Mac OS X, BeOS, BSD, Solaris, Familiar Linux, Yopy/Linupy et QNX. Il peut lire :

• Des fichiers MPEG-1, MPEG-2 et MPEG-4 / DivX depuis un disque dur, un lecteur de CD-ROM.

• Des DVDs, VCDs, et des CDs audio. • Depuis des cartes d'acquisition satellite (DVB-S). • De nombreux types de flux réseau: UDP Unicast, UDP Multicast (MPEG-TS), HTTP,

RTP/RSTP, MMS. • depuis des cartes d'acquisition ou d'encodage (sur GNU/Linux ou Windows

seulement)

VLC peut également être utilisé comme serveur de diffusion de flux.

8.1.1. Lire un flux du réseau

Pour lire un flux réseau, ouvrez le menu “Fichier” et sélectionnez l'élément “Ouvrir un flux réseau”.

• Pour ouvrir un flux UDP unicast, sélectionnez TUDP/RTPT, et indiquez le port UDP approprié dans la zone de saisie (il s'agit du port 1234 pour des flux envoyés par un serveur VLC ou VLS).

• Pour ouvrir un flux UDP multicast, sélectionnez TUDP/RTP multidiffT. Indiquez l'adresse du groupe multicast dans la zone de texte “Address”, et spécifiez le port UDP adéquat.

TP

15PT Pour plus d’informations au sujet de videolan : HTUwww.videolan.orgUTH


- 111 -

• Pour ouvrir un flux envoyé sur HTTP (Webradios, WebTVs, Shoutcast, Icecast...), FTP, ou MMS (serveur de médias de Microsoft), choisissez "HTTP/FTP/MMS" et indiquez l'URL correspondante dans la zone de saisie correspondante, (par exemple http://live.stream.org:8080/live ou mms://live.ms.stream.net:8080/live.asf). Ceci est également la méthode pour ouvrir un flux RTSP avec l'interface de MacOS X.

• Pour ouvrir un flux RTSP (envoyé par un seveur de flux Darwin, VLC, etc) avec l'interface wxWindows, choisissez "RTSP" et indiquez l'URL dans la zone de texte.

Vous pouvez commencer la lecture en choisissant le bouton TOk T

Figure 39 : Lecture d'un flux multicast IPv4


- 112 -

8.1.2. Lecture à partir d'une entrée vidéo Ouvrez le menu « Fichier » et choisissez « Ouvrir un périphérique de capture... » Sous Windows, les « Webcams », les cartes de télévision, les cartes d'acquisition sont

supportées, pourvu qu'elles soient fournies avec des pilotes compatibles DirectShow. Vous pouvez choisir le périphérique à utiliser pour l'acquisition vidéo et audio via les

listes déroulantes "Nom du périphérique vidéo" et "Nom du périphérique audio". Si le périphérique n'apparaît pas dans la liste, essayez en cliquant sur le bouton "Rafraîchir la liste". Vous pouvez accéder aux réglages de votre périphérique d'acquisition cliquant sur le bouton configure. Ces options dépendent du pilote du périphérique.

Vous pouvez utiliser la boîte "Propriétés du périphérique" si vous voulez accéder à la boîte de dialogue de configuration de chaque périphérique. Utilisez la boîte Propriétés du Tuner pour les réglages du tuner (norme PAL/NTSC, fréquence ...) pour les cartes TV. Le bouton Options avancées... permet de choisir d'autres réglages utiles dans quelques cas rares, tels que le "chroma" de l'entrée (la façon dont les couleurs sont codées) et de la taille de la mémoire tampon d'entrée.

Figure 40 : Lecture des périphériques vidéo et audio sous Windows.


- 113 -

Sous Linux, les périphériques comme les « Webcams », les cartes de télévision, les cartes d'acquisition fournies, sont compatibles si elles sont supportées par l'architecture Video4Linux.

Pour les outils Video4Linux, vous pouvez mettre le nom du périphérique vidéo ou audio

en utilisant les boites de saisie "Nom du périphérique vidéo" et "Nom du périphérique audio". Le bouton "Options avancées..." permet de choisir quelques réglages utiles dans quelques cas rares, comme l'entrée du "chroma"(la manière dont sont codées les couleurs) et la taille du buffer d'entrée.

8.1.3. Diffuser une vidéo en multicast

Après avoir configuré l’entrée que vous voulez lire avec videolan, vous pouvez choisir son mode de diffusion.

Un des modes de diffusion est l’envoie de la vidéo et du son vers une adresse multicast. Dans la fenêtre "Ouvrir…", cliquez sur "Flux de sortie" puis sur "Paramètres". Vous pouvez ensuite configurer le mode de diffusion. Pour la diffusion en multicast entrez

l’adresse IPv4 ou IPv6 dans la zone "UDP" avec le numéro de port ensuite pour visualiser la vidéo et le son, cliquez sur "Jouer en local".

Optionnellement, indiquez les options de transcodage ainsi que le nom de la session SAP.

Nous reviendrons par la suite pour les différentes options de transcodage de la vidéo et

du son.


- 114 -

Figure 41 : Fenêtre de configuration du flux de sortie


- 115 -

8.1.4. VLM

VideoLAN Manager est un petit outil de gestion de médias conçu pour contrôler plusieurs flux avec une seule instance de VLC. Cela permet de la diffusion multiple et la vidéo à la demande (VoD). Cet outil ayant été récemment ajouté, il n'est possible de le contrôler que par les interfaces Telnet et HTTP.

Interface Telnet

Vous pouvez démarrer l'interface Telnet comme toute autre interface en utilisant la ligne de commande :

T% vlc --intf telnet T

T% vlc --extraintf telnet T

L'interface Telnet peut aussi être démarrée depuis l'interface wxWindows:

Figure 42 : Démarrage de l'interface telnet.

Nous expliquerons par la suite comment avec l’application de gestion de visioconférence

nous contrôlons la réception et la diffusion de flux vidéo et audio en multicast.


- 116 -

8.2. Application de gestion de visioconférence

L’objectif de l’application de gestion de visioconférence est de simuler une conférence se déroulant avec différents orateurs.

Videolan permettant de transmettre et de recevoir la vidéo et le son en haute qualité avec le service multicast, l’application contrôle Videolan en lui indiquant ce qu’il doit émettre ou recevoir.

L’application relie tous les utilisateurs de cette application en utilisant une adresse multicast IPv4 ou IPv6 connue de tous les participants.

Chaque participant à une visioconférence doit avoir lancé l’application qui envoie par la suite des informations vers l’adresse multicast et écoute les messages arrivant de cette adresse.

L’utilisation du multicast à l’avantage d’envoyer un seul paquet UDP vers toutes les autres applications écoutant sur l’adresse multicast.

L’application comporte à ce jour deux fonctionnalités, une causette multicast et le contrôle du logiciel videolan. Ces fonctionnalités étant implémentées en greffons, il est simple d’ajouter d’autres fonctionnalités.

Pour chaque session, deux types de participants existent :

• Le président de séance qui est le seul à pouvoir donner ou non la parole à un participant.

• Les auditeurs et orateurs pouvant demander la parole et attendant que le président de séance leur délivre.

8.2.1. Test du bon fonctionnement du service multicast du site

Avant d’utiliser l’application de gestion de visioconférence, il est recommandé de vérifier

le bon fonctionnement du service multicast en IPv4 ou en IPv6. Des outils sont disponibles tel que l’application beaconP

16P permettant à l’aide d’un serveur

et de clients de tester le service multicast IPv4. Avec le protocole IPv6, l’application client dbeaconP

17 Pest disponible et elle se connecte à

un serveur où vous pouvez visualiser si votre service multicast IPv6 fonctionne correctement. Après avoir testé le service multicast, il faut effectuer un test de réception et de diffusion

entre videolan pouvant être perturbé par des pares feux réseaux ou systèmes. Pour cela il faut installer deux logiciels videolan sur deux ordinateurs connectés à deux

réseaux différents. TP

16PT Plus d’information sur le projet beacon : http://dast.nlanr.net/projects/Beacon/

TP

17PT Plus d’information sur le projet dbeacon : http://artemis.av.it.pt/~hsantos/dbeacon/


- 117 -

Un videolan récupère le flux d’un périphérique vidéo (exemple : une Webcam) et diffuse ce flux vers une adresse multicast.

Le deuxième ordinateur lit ensuite le flux multicast à l’aide du logiciel videolan. Si le deuxième ordinateur lit correctement le flux vidéo et audio, il faut effectuer le test

inverse. L’ordinateur envoyant le flux vidéo et audio devient l’ordinateur lisant le flux venant de l’adresse multicast et le deuxième ordinateur envoie le flux vidéo et audio.

Figure 43 : configuration de l'envoie d'un flux vers l'adresse multicast IPv6 ff0e::4444


- 118 -

Figure 44 : configuration de la lecture d'un flux venant de l'adresse multicast IPv6 ff0e::4444

8.2.2. Démarrage de l’application

Au préalable, l’application étant écrite avec le langage de programmation java, l’utilisateur doit avoir installé la machine virtuelle java disponible sur le site Hwww.java.sun.comH.

Nous conseillons d’installer la version 5.0 de la machine virtuelle java. Pour démarrer l’application, l’utilisateur doit exécuter le fichier pilotage.jar. Ce fichier est

un exécutable java, sous windows il suffit de double-cliquer sur ce fichier pour l’exécuter, sous Unix il faut taper la commande java –jar pilotage.jar.

Une fenêtre de renseignement s’ouvre ensuite, voici les différentes informations qu’il faut

renseigner :

• Le nom du site participant à la visioconférence. • L’adresse et le numéro de port multicast permettant aux applications de communiquer

entre elles. • Le TTL, durée de vie du paquet permettant de restreindre ou non la visioconférence.


- 119 -

• Si le mot de passe est inscrit, alors cet utilisateur sera le président de la visioconférence. Le président devant être unique, si un participant est déjà le président alors un message indiquera qu’il est participant à cette session. Le mot de passe est Aristote, ce renseignement permet seulement que tous les participants ne demandent pas d’être président de séance.

• La sélection du « chat » permet d’activer la causette multicast • La sélection du « pilotage » permet d’activer le contrôle de videolan

Figure 45 : Fenêtre de renseignement pour l'application de gestion de visioconférence


- 120 -

8.2.3. La causette multicast

En validant la fonctionnalité « chat », le participant va recevoir tous les commentaires qu’écrivent les autres participants.

Quand on écrit un message dans cette causette, tous les autres participants visualisent ce qui vient d’être écrit.

Ci dessous nous visualisons une discussion entre trois personnes, la fenêtre principale

permet de visualiser les messages écrits et la barre de texte en dessous permet d’écrire un message.

Figure 46 : Interface graphique de la causette multicast

Cette causette permet d’envoyer des informations à tous les participants comme l’adresse de diffusion de videolan ou bien des erreurs techniques etc.

Cette fonctionnalité est très utile car cela permet de pouvoir communiquer avec les autres participants sans passer par les moyens habituels qui sont les mails, le téléphone etc.


- 121 -

8.2.4. La gestion d’une visioconférence

Configuration de videolan Videolan a besoin d‘être configuré avant la première utilisation de l’application de

gestion. L’application envoie des commandes au logiciel videolan pour envoyer un flux vidéo et

audio, l’application ne connaissant les caractéristiques de la carte d’acquisition ou de la camera, l’application doit alors envoyer des commandes génériques à videolan.

Pour cela il faut configurer dans le logiciel videolan la source vidéo et audio par défaut qu’il faut récupérer.

Pour cela il faut ouvrir la fenêtre de configuration de videolan dans « Paramètres » puis « Préférences ».

La source vidéo et audio à sélectionner se trouve dans « Input / Codecs — Access modules — DirectShow ».

Si dans la liste déroulant vous ne trouvez pas votre matériel, cliquez sur le bouton « Refresh list».

Cette action a besoin d’être effectuée qu’une seule fois avant la première utilisation de l’application de gestion de visioconférence.

Figure 47 : Configuration des périphériques vidéo et audio


- 122 -

Configuration de la connexion telnet :

L’application de gestion de visioconférence envoie des commandes au logiciel videolan à l’aide de l’interface telnet que nous avons expliqué précédemment.

Cette interface écoute sur l’adresse locale et sur un port pouvant être configuré, par défaut ce port est le numéro 4212.

Par la suite cette interface demande un mot de passe pour la connexion, par défaut ce mot de passe est admin.

Le port telnet et le mot de passe doivent être indiqué dans la configuration de l’application que nous expliquerons par la suite.

Pour pouvoir modifier le numéro de port et le mot de passe, il faut modifier la configuration de videolan.

Ouvrir la fenêtre de configuration de videolan dans « Paramètres » puis « Préférences ». Les modifications se font dans la partie « Interface — General — Telnet »

Figure 48 : Configuration de la connexion telnet

Fonctionnalité de contrôle du logiciel videolan

En activant la fonctionnalité « pilotage » de la première fenêtre de renseignement, le participant demande à l’application de contrôler videolan pour la visioconférence.


- 123 -

Pour cela le participant doit avoir lancé le logiciel videolan avec l’interface telnet activer comme nous l’avons écrit précédemment.

Cette interface doit être activé pour permettre à l’application de gestion d’envoyer des commandes au logiciel videolan.

Pour débuter une visioconférence, il faut d’abord renseigner l’application sur les

différentes options de la visioconférence. Voici les différents renseignements devant être indiqué pour la gestion de la

visioconférence :

• Le port telnet de videolan ainsi que son mot de passe. • L’adresse multicast (IPv4 ou IPv6) et numéro de port de la diffusion de la vidéo et du

son • Le codec vidéo, le débit (de 16 kbit/s à 3072 kbit/s) et l’échelle (de 0,25 à 2) • Le codec audio, le débit (de 16 kbit/s à 512 kbit/s) et le nombre de canaux (de 1 à 6)

Liste des codecs vidéo disponibles pour la diffusion :

• mp1v : MPEG-1 • mp2v : MPEG-2 • mp4v : MPEG-4 • div1 : DivX 1 • div2 : DivX 2 • div3 : DivX 3 • h263 • h264 • WMV1 : Windows Media Video 1 • WMV2 : Windows Media Video 2 • Theo : Theora

Liste des codecs audio disponibles pour la diffusion :

• mpga2 : MPEG audio Layer 2 • mp2a : x-MPEG2 • mp3 : MPEG Audio Layer-3 • mp4a : MPEG 4 audio (RFC 3016) • a52 : audio streams source plug-in • vorb : Vorbis • flc : FLAC Free Lossless Audio Codec • spxs : SPEEX Après avoir cliqué sur le bouton “OK”, l’application envoie vers l’adresse multicast de

l’application les renseignements utilisateurs. Elle réceptionne en même temps les informations transmises par les autres participants. La liste des utilisateurs est continuellement actualisée en fonction des données reçues.


- 124 -

Au niveau de videolan, l’application se connecte à la connexion telnet et configure l’envoie et la réception des données multimédia. Une fenêtre s’ouvre ensuite où l’on distingue tous les participants. Les utilisateurs peuvent avoir trois états :

• Ecoute de l’auditeur : Etat 0 couleur turquoise • Demande de parole : Etat 1 couleur rouge • Orateur : Etat 2 couleur bleu

Avec cette interface, on retrouve un bouton en dessous les participants permettant de

demander la parole. Pour chaque participant on a un bouton « info » permettant de visualiser différentes

informations :

• Le nom. • L’adresse IPv4 ou IPv6 utilisée. • Si la causette est activée ou non. • Si ce participant est le président de session.

Figure 49 : Informations a sujet du participant benoit.

A côté de chaque participant se trouvent deux boutons « OK » et « NO », ces deux

boutons servent au président de séance pour donner ou non la parole à un participant qui a préalablement demander la parole.

Pour un autre participant, s’il appuie sur un de ces boutons, un message lui indiquant qu’il n’est pas président s’affiche.

Avec ces fonctionnalités, un participant à une session peut demander la parole, voir les

participants à la session, écouter un orateur et aussi devenir orateur.

Voici quelques exemples d’écran pour la gestion des participants : Trois participants à la visioconférence : « ben », « ben2 » et « ben3 »


- 125 -

Figure 50 : ben2 est orateur

Figure 51 : L’utilisateur « ben » demande la parole


- 126 -

Figure 52 : Message transmit sur l’écran du président lorsqu’il donne la parole à l’utilisateur « ben »

Figure 53 : Deux participants sont à l’écoute et le participant « ben » est orateur


- 127 -

8.3. Caractéristiques techniques de l’application de visioconférence

8.3.1. La communication

L’architecture de l’application de gestion de visioconférence a été étudiée avant l’implémentation pour être une application évolutive.

Une architecture a été trouvée permettant à l’application de communiquer avec les autres applications connectées à un même groupe multicast et retransmettre les messages reçus aux greffons de l’application.

Cette application étant implémentée avec le langage de programmation java, cela nous

permet d’utiliser des processus légers ce qui implique une charge plus faible pour l’ordinateur.

Cette application à un processus principal que l’on appelle « bus de communication », ce

bus écoute sur l’adresse de groupe multicast IPv4 ou IPv6 que l’utilisateur lui a indiqué pendant la configuration, ce bus analyse ensuite les messages et les envoies vers le greffon concerné. Nous expliquerons par la suite le format des messages.

Pour envoyer un message, un greffon n’envoie pas directement le message vers le groupe multicast, il envoie tous d’abord ce message vers le bus de communication qui ajoute des informations au message avant de l’envoyer vers le réseau.

Ceci permet d’avoir une architecture où le bus de communication est le seul processus à écouter et transmettre des informations vers le réseau, ce bus dirige aussi les messages vers les greffons.


- 128 -

Figure 54 : Schéma de l'architecture de l'application de gestion de visioconférence

Un greffon communique avec le bus à l'aide d'un système de « pile », chaque greffon à un processus léger écoutant les messages contenus dans une pile. Quand un message est mis dans cette pile par le bus, le processus se réveille et traite ce message en fonction de l’information qu’il contient.


- 129 -

Figure 55 : Schéma d'envoie des messages par le bus

Pour qu’un greffon envoie des informations, il doit tout d’abord envoyer le message au

bus de communication. Ceci s’effectue de la même manière que pour la réception avec une pile d’envoie de

message. Le bus de communication attend qu’il y ait un message dans cette pile puis ajoute des

informations à ce message pour l’envoyer vers le réseau. La différence qu’il y a avec les piles de réception des greffons vient du fait qu’il n’y a

qu’une seule pile d’envoie pour tous les greffons. Le bus ajoute pour tous les greffons les mêmes informations, il n’est donc pas nécessaire

d’avoir une pile d’envoie par greffon.


- 130 -

Figure 56 : Schéma de l'envoie des messages par les greffons

Ajout d’un greffon

L’ajout d’un greffon est rendu simple par cette architecture puisque le bus de communication n’analyse pas les messages, il s’occupe seulement de les transmettes au bon greffon.

La liste des greffons étant contenue dans une liste, au niveau de la programmation, il faut ajouter seulement quelques lignes.

Pour le greffon de la causette, nous ajoutons les lignes dans la classe « FenetreRenseignement.java » ce qui ajoute dans la liste des greffons le « Chat » :

if (chat == true) { nbPlugs++; //courrante est un objet regroupant toutes les informations concernant la session courrante.addPlug("Chat");


- 131 -

}

Ensuite avec le lancement du bus de communication, on parcourt la liste des greffons et en comparant le nom des greffons avec ceux implémentés, on lance la classe concernée.

Voici le code qui permet de lancer les greffons de la causette et du contrôle de videolan dans la classe « Bus.java » :

// boucle parcourant la liste des plugins for (int i = 0; i < plugins.length; i++) { // création du nombre de pile permettant la communication entre le // bus et les plugins messageForPlugs[i] = new MessageList(); // on compare le nom du plugin et on construit l’objet du plugin // lancement de la gestion des utilisateurs et du contrôle de vlc if (plugins[i].compareTo("Pilotage") == 0) { IGInfoVLC igVLC = new IGInfoVLC(messageForBus, messageForPlugs[i], this.courante); // lancement du processus legers pour le contrôle de vlc igVLC.start(); } // lancement du chat de communication if (plugins[i].compareTo("Chat") == 0) { GestionChat chat = new GestionChat(messageForBus, messageForPlugs[i], nomUser); // lancement du processus legers pour le chat chat.start(); } }


- 132 -

Nous avons vu à l’aide de cet exemple qu’il est simple d’ajouter un greffon à l’application.

Le format des messages

Pour pouvoir communiquer entre les applications et entre les greffons et le bus de communication, il a été mis en place un format de message.

Ce format est inspiré du format XML permettant d’avoir des messages structurés. Le format des messages entre les applications contient quatre informations insérées à

l’intérieur des balises :

• Le nom du participant envoyant le message, balise <nomSrc> • Le nom du participant qui doit recevoir le message (Pour tous les participants, on met

le nom « all »), balise <nomDest> • Le greffon de destination du message, balise <PluginDest> • Le greffon de la source du message, balise <PluginSrc>

Ensuite vient le message envoyé par le greffon indiqué par la balise <Plugin>. Voici le type d’un message (Ce message indique des informations sur le participant

« toto » pour le greffon qui contrôle videolan) :

<Pilotage> <nomSrc>toto</nomSrc> <PluginDest>Pilotage</PluginDest> <PluginSrc>Pilotage</PluginSrc> <nomDest>all</nomDest> <Plugin> <alive></alive> <name>toto</name> <chatOn>on</chatOn> <President>on</President> <etat>2</etat> </Plugin> </Pilotage>

Tous les greffons envoient leurs messages vers le bus de communication puis le bus

rajoute les informations concernant l’application. Dans l’exemple précédant voici le message envoyé par le greffon et reçu par le bus :


- 133 -

<alive></alive> <name>toto</name> <chatOn>on</chatOn> <President>on</President> <etat>2</etat>

Le bus rajoute ensuite toutes les autres informations et indique le message vers le greffon destination par la balise <Plugin>.

L’application recevant ce message regarde les différents éléments et en fonction du nom de destination et du greffon de destination, envoie le message vers le bon greffon.

Ce système d’ajout d’information par le bus de communication permet que les greffons

n’aient aucune contrainte pour former les messages. Chaque message envoyé par le bus est envoyé deux fois vers le réseau, ce système a été

mis en place pour avoir une fiabilité dans l’envoie des messages car l’application ne demande pas d’accusé de réception des messages et le multicast fonctionne avec le protocole UDP.

En envoyant deux fois le message vers le réseau, il y a une forte probabilité pour que les applications distantes reçoivent le message.

Pour que les applications ne traitent pas deux fois le même message, l’application envoyant le message insère au début du message le numéro du message envoyé. L’application recevant le message regarde le numéro et l’adresse IP du participant qui a envoyé le message, il compare dans une table d’association le numéro du message et l’adresse IP, si ce numéro avec cette adresse IP a déjà été reçu alors il ne traite pas ce message et s’il n’a pas été reçu, il ajoute l’association numéro du message et adresse IP dans sa table. Cette association empêche qu’une application traite deux fois un message.

Initialisation du participant sur le réseau.

A l’initialisation de l’application, un message est envoyé à destination des autres participants.

Ce message contient le nom du participant et s’il est président ou non. Pour que les autres applications ne confondent pas ce message avec un message à destination d’un greffon, le numéro de ce message est –1. Lorsqu’une application reçoit ce message, il regarde le nom du participant et s’il a le même nom, alors il envoie un message indiquant que ce nom est déjà pris pour la session, le participant doit alors inscrire un autre nom.

Le message contient également l’information s’il est le président. Cette information permet de ne pas avoir deux « présidents » d’où si le participant « président » voit qu’il y a un autre « président » alors il lui envoie un message d’erreur.

Voici le type de message envoyé par un nouveau participant :

-1 <AreYou>toto</AreYou> <President>on</President>


- 134 -

Voici le message envoyé si le nom est déjà pris :

-1 <IAM>toto</IAM>

Si la présidence est déjà prise:

-1 <President>toto</President>

8.3.2. La causette multicast « Aristo-MultiChat »

La causette multicast est un greffon de l’application. Ce greffon permet d’envoyer et de recevoir du groupe multicast des messages textes.

Cela permet aux participants ayant validé cette option de communiquer entre eux. Le greffon est composé d’une interface graphique où l’on peut lire les messages reçus

ainsi qu’écrire des messages textes.

Comme nous l’avons expliqué précédemment, le greffon ne reçoit et n’envoie pas directement des messages du groupe multicast, pour la communication, il utilise les piles entre le greffon et le bus de communication de l’application.

Dés qu’un message reçu par le bus est pour le greffon chat, le greffon chat l’analyse puis inscrit sur l’interface graphique le nom du participant ayant envoyé le message ainsi que son message.

Pour envoyer un message, l’application récupère le texte de l’interface graphique puis après avoir mis le texte entre des balises XML ainsi que le nom du participant envoyant le message, il met ce message dans la pile d’envoie du bus de communication.

Le greffon envoie un objet « MessPlugs » au bus de communication contenant toutes les informations dont à besoin le bus de communication.

Cet objet « MessPlugs » contient le nom du greffon source, le nom du greffon destination, le nom du destinataire du message ainsi que les données du message.

Voici un exemple de message envoyé au bus de communication par le greffon « chat » où on retrouve le nom du participant envoyant le message (toto) ainsi que sont textes (bonjour):

<NomSrc>toto</NomSrc> <Texte>bonjour</Texte>


- 135 -

Lorsque le greffon reçoit un message du bus de communication, il récupère du message le

nom du participant qui a envoyé le message ainsi que le texte. Ces deux informations sont ensuite inscrites sur l’interface graphique de chaque participant.

Figure 57 : Interface graphique de la causette multicast

8.3.3. La gestion d’une visioconférence

La gestion d’une visioconférence s’effectue à l’aide du greffon pilotage, qui comme les autres greffons communique avec le bus de communication.

Au démarrage de ce greffon, le participant doit avoir au préalable ouvert le logiciel videolan avec l’interface telnet.

Ensuite le greffon pilotage ouvre une fenêtre où le participant indique les paramètres de la visioconférence ainsi que le port telnet et le mot de passe pour l’interface telnet du logiciel videolan.

Voici les listes des renseignements que le participant doit inscrire :

• Le port telnet de videolan. • Le mot de passe de la connexion telnet à videolan. • L’adresse du groupe multicast (IPv4 ou IPv6) pour la réception et la diffusion de la

vidéo et du son à l’aide de videolan.


- 136 -

• Le port du groupe multicast pour la réception et la diffusion de la vidéo et du son à l’aide de videolan.

• Les paramètres de la retransmission vidéo (liste des paramètres vue précédemment).

• Les paramètres de la retransmission audio (liste des paramètres vue précédemment).

Figure 58 : Fenêtre de configuration de videolan

Le greffon pilotage ouvre ensuite une connexion telnet avec le logiciel videolan et envoie les commandes pour la configuration.

Les commandes envoyées et reçues par ce greffon sont indiquées par des balises XML. Toutes les trois secondes un message est envoyé vers les autres applications indiquant que

l’utilisateur est toujours participant à la session, il y est aussi indiqué son nom, s’il a le greffon chat activé, s’il est le président de la session et son état. Voici un type de message envoyé :

<alive></alive> <name>toto</name> <chatOn>on</chatOn> <President>on</President> <etat>2</etat>


- 137 -

Si au bout de dix secondes, l’application n’a pas reçu ce type de message d’un participant alors il considère que le participant est parti de la session de visioconférence.

Sinon trois autres types de messages sont envoyés par le greffon pilotage, un pour

demander la parole, un pour donner la parole à un participant et un pour lui refuser la parole. Voici les types de messages qu’envoie le greffon pilotage pour la gestion de la parole :

# envoie d’une demande de parole d’un participant <info>demandeParole</info> <nom>toto</nom> #refus de la parole pour le participant toto (envoyé par le président) <info>refusParole</info> <nom>toto</nom> #donne la parole pour le participant toto (envoyé par le président) <info>donneParole</info> <nom>toto</nom>

Ces différents types de messages permettent d’effectuer la gestion des participants à une

visioconférence. Pour le contrôle de videolan, l’application configure deux conteneurs, un conteneur pour

la réception vidéo et audio et un conteneur pour la diffusion vidéo et audio. Le conteneur pour la réception vidéo et audio a besoin de connaître l’adresse du groupe

multicast et le port. Voici les commandes envoyées au logiciel videolan par la connexion telnet pour la réception:

#création d’un nouveau conteneur de nom recv avec le multicast activé new recv broadcast enabled # pour lire le flux de l’adresse 224.8.5.88 et du port 5634 setup recv input udp://@224.8.5.88:5634 # ou si l’adresse est en IPv6 setup recv input udp://@[ffe1::4444]:5634 #indique de diffuser le flux en local setup recv output #duplicate{dst=display}


- 138 -

Le conteneur permettant de diffuser le flux doit avoir toutes les informations pour la diffusion, voici les commandes envoyées au logiciel videolan avec l’interface telnet :

#création d’un nouveau conteneur de nom send avec le multicast activé new send broadcast enabled #lecture du flux venant du périphérique d’entrée vidéo et audio pour windows setup send input dshow:// #lecture du flux venant du périphérique d’entrée vidéo et audio pour unix setup send input v4l:// #envoie du flux vers le groupe multicast 224.8.5.88 et le port 5634 #et envoie en local # les paramètres de diffusion sont dans le paramètres transcode setup send output #transcode{vcodec=mp4v,vb=1024,scale=1,acodec=mpga,ab=192,channels=2}: duplicate{dst=display,dst=std{access=udp,mux=ts,url=224.8.5.88:5634}} #envoie du flux vers un groupe multicast en IPv6 setup send output #transcode{vcodec=mp4v,vb=1024,scale=1,acodec=mpga,ab=192,channels=2}: duplicate{dst=display,dst=std{access=udp,mux=ts,url=[ffe1::4444]:5634}}

Avec ces deux conteneurs, le greffon peut ensuite actionner l’un ou l’autre. Voici la commande pour actionner un conteneur :

#on active le conteneur recv control recv play

Voici la commande pour stopper un conteneur :

#on stoppe le conteneur recv control recv stop

Le greffon pilotage envoie et reçoit des commandes et lorsqu’une commande lui indique qu’elle doit émettre alors l’application envoie à videolan une commande d’arrêt pour la réception et une commande d’envoie pour l’émission du flux vidéo et audio.


- 139 -

Voici les deux commandes envoyées:

control recv stop control send play

Quand l’application reçoit la commande indiquant qu’une autre personne doit émettre alors elle arrête l’émission et démarre la réception, voici les commandes :

control send stop control recv play


- 140 -

8.4. Exemple de conférence

Le schéma ci-dessous permet d’avoir une visualisation de l’utilisation de l’application de gestion de visioconférence pour gérer les participants avec videolan pour transmettre et recevoir la vidéo et le son, on peut accompagner cette configuration de l’application « ARTS » permettant la retransmission en temps réel des transparents de l’orateur.

Dans ce schéma nous avons trois salles :

• La salle président où l’orateur principal se trouve. En rentrant le mot de passe dans l’application, il est le seul à pouvoir donner la parole à un participant. Il accompagne son exposé de l’application « ARTS » pour retransmettre sa présentation.

• Les salles 1 et 2 regroupent différents participants (exemple : des étudiants suivant un cours), à l’aide de l’application ils peuvent suivre l’exposé de l’orateur puis ensuite poser des questions en appuyant sur le bouton « Demande Parole » permettant de faire savoir à l’orateur qu’il souhaite être orateur. Dans cette configuration, il est envisageable que d’autres orateurs se trouvent dans une des salles et ils peuvent aussi effectuer des exposés.


- 141 -

Figure 59 : Schéma d'une utilisation de l'application de gestion de visioconférence


- 142 -

8.5. Evolutions et améliorations Plusieurs évolutions et améliorations peuvent être apportées à l’application :

• Garder en dans un fichier certains renseignements d’une visioconférence. • Un bouton pour retirer la demande de parole. • Un fichier d’initialisation. • Ajout de greffon pour d’autres fonctionnalités. • Mise en place de certaines fonctionnalités de RTCP, SAP et SDP. • Intégrer cette gestion de visioconférence dans le code source de videolan.

L’application de gestion de videolan est un logiciel nouveau et pas finalisé, il reste à

apporter des améliorations, prendre en compte les remarques des utilisateurs etc. C’est une application pouvant très facilement évoluer puisque l’implémentation

s ‘effectue avec des greffons.


- 143 -

9. Conclusion Le travail effectué cette année a permis au groupe de travail GN6 d’avoir une plate-forme

de démonstration IPv6 fiable au niveau réseau permettant d’effectuer des tests aux niveaux applicatifs à l’intérieur de la plate forme mais aussi avec d’autres plates-formes tel que la plate-forme IPv6 de la société SFR.

Parmi les prospectives d’avenir de la plate-forme IPv6, il faut continuer à prospecter les logiciels aux normes SIP et H323 compatible IPv6 ce qui s’avère un enjeu intéressant, du fait de leur faible disponibilité actuelle.

L’expérience a démontré que le développement de l’utilisation des nouvelles technologies

de l’information et de la communication dans le cadre du téléenseignement nécessite non seulement des avancées techniques dans le domaine des applications et des réseaux.

Parmi les perspectives d’avenir concernant le domaine de la visioconférence, il faut continuer à développer l’application de gestion de visioconférence. Cette application est la première à proposer une solution de visioconférence de haute qualité puisque les logiciels existants tel que vic et rat n’offrent pas la possibilité d’avoir une bonne qualité vidéo et audio.

L’inconvénient de cette solution vient du fait qu’elle s’appuie sur le service de multicast donc réservé aux utilisateurs du réseau de la recherche.

Cet apprentissage s’est avéré très formateur d’un point de vue technique et théorique. Il

m’a permis de travailler sur les nouvelles technologies avec le protocole IPv6 et les nouvelles solutions multimédias.


- 144 -

10. Annexes

10.1. Annexe 1 - Configuration du routeur 6Wind Ce fichier correspond à la configuration du routeur 6wind 6110, routage, interface, …

gen # GEN STATEMENT hostname kriska domainname renater.gn6.net enable ipv4forwarding enable ipv6forwarding disable telnet enable ssh disable http_config disable decapsulation # ARP TABLE # NDP TABLE # HOST # NAMESERVER # LOG eth0_0 # IPV4 ADDRESS ipaddress 193.49.159.242/30 # IPV6 ADDRESS ipaddress 2001:660:3001:4021:2::2/64 # IPV6 PREFIX # INTERFACE STATEMENT intf up disable autoconfv6 mtu default tcp4mss disable tcp6mss disable disable ipsec disable qos in disable qos out enable arp enable ndp router_advert smart 30000 1800 none 0 yes


- 145 -

physical media auto eth1_0 # IPV4 ADDRESS # IPV6 ADDRESS # IPV6 PREFIX # INTERFACE STATEMENT intf up disable autoconfv6 mtu default tcp4mss disable tcp6mss disable disable ipsec disable qos in disable qos out enable arp enable ndp router_advert smart 30000 1800 none 0 yes physical media auto baudrate 2048 bnet2 # BIND bind eth1_0 vlan 2 "RL" # IPV4 ADDRESS ipaddress 195.89.126.225/29 # IPV6 ADDRESS ipaddress 2001:660:2002:4201::1/64 # IPV6 PREFIX prefix 2001:660:2002:4201::/64 # INTERFACE STATEMENT intf up disable autoconfv6 mtu default tcp4mss disable tcp6mss disable disable ipsec disable qos in disable qos out enable arp


- 146 -

enable ndp router_advert smart 30000 1800 none 0 yes bnet1 # BIND bind eth1_0 vlan 4 "prive" # IPV4 ADDRESS ipaddress 192.168.0.1/24 # IPV6 ADDRESS # IPV6 PREFIX # INTERFACE STATEMENT intf up disable autoconfv6 mtu default tcp4mss disable tcp6mss disable disable ipsec disable qos in disable qos out enable arp enable ndp router_advert smart 30000 1800 none 0 yes bnet3 # BIND bind eth1_0 vlan 3 "DMZ" # IPV4 ADDRESS ipaddress 195.89.126.233/29 # IPV6 ADDRESS ipaddress 2001:660:2002:4203::1/64 # IPV6 PREFIX prefix 2001:660:2002:4203::/64 # INTERFACE STATEMENT intf up disable autoconfv6 mtu default tcp4mss disable tcp6mss disable disable ipsec disable qos in disable qos out enable arp


- 147 -

enable ndp router_advert smart 30000 1800 none 0 yes bnet4 # BIND bind eth1_0 vlan 5 "IPv6_only" # IPV4 ADDRESS # IPV6 ADDRESS ipaddress 2001:660:2002:4202::1/64 # IPV6 PREFIX prefix 2001:660:2002:4202::/64 # INTERFACE STATEMENT intf up disable autoconfv6 mtu default tcp4mss disable tcp6mss disable disable ipsec disable qos in disable qos out enable arp enable ndp router_advert smart 30000 1800 none 0 yes loopback # LOOPBACK INTERFACES rtg # IPV4 ROUTE # IPV6 ROUTE route 2001:660:2002:4204::/64 2001:660:2002:4204::2 route 2001:4c18:0:f20::/64 2001:660:2002:4204::2 route 2001:4c18:0:f10::/64 2001:660:2002:4204::2 route 2001:4c18:0:a20::/64 2001:660:2002:4204::2 route 2001:4c18:0:a21::/64 2001:660:2002:4204::2 # DEFAULT ROUTE ipv4_defaultroute 193.49.159.241 ipv6_defaultroute 2001:660:3001:4021:1::1 # IPV6 MULTICAST ROUTE # DEFAULT MULTICAST ROUTE ipv6_defaultmroute none # DYNAMIC ROUTING PROTOCOLS dynamic


- 148 -

# interface eth0_0 ipv6 ospf6 passive # router rip redistribute connected network eth0_0 network eth1_0 # router ripng default-information originate network 2001:660:2002:4201::/64 network 2001:660:2002:4202::/64 network 2001:660:2002:4203::/64 redistribute connected # router ospf6 ospf6 router-id 0.0.0.1 redistribute connected interface eth1_0 area 0.0.0.0 # exit-dynamic # LOG pim6sm # INTERFACES network bnet3 any network bnet2 any network bnet4 any # PIM RPF rpf use-fib # BSR/RP ELECTION bsr-candidate disable rp-candidate disable # STATIC RP mig # 6IN4 TUNNELS 6in4 1 193.49.159.242 213.223.38.177 2001:660:2002:4204::1

2001:660:2002:4204::2 # 4IN6-6IN6 TUNNELS # 6TO4 TUNNELS


- 149 -

# AUTOMATIC TUNNELS # ISATAP_ROUTER # ISATAP_PREFIX # DSTM fil # FILTER RULES IPv4 rule 01000 allow icmp from any to any rule 01010 check-state rule 01021 allow tcp from 195.89.126.224/28 to any setup keep-state rule 01030 allow udp from 195.89.126.224/28 to any rule 01040 allow udp from any 53 to 195.89.126.227 rule 01041 allow udp from 195.89.126.227 to any 53 rule 01050 allow tcp from any to 195.89.126.234 80 rule 01051 allow udp from any to 195.89.126.234 80 rule 01060 allow udp from any to 195.89.126.227 53 rule 01061 allow tcp from any to 195.89.126.227 53 rule 01500 deny all from 192.168.0.0/16 to any via eth0_0 rule 01501 deny all from any to 192.168.0.0/16 via eth0_0 rule 01506 deny all from 172.16.0.0:255.240.0.0 to any via eth0_0 rule 01507 deny all from any to 172.16.0.0:255.240.0.0 via eth0_0 rule 01508 deny all from 10.0.0.0:255.0.0.0 to any via eth0_0 rule 01509 deny all from any to 10.0.0.0:255.0.0.0 via eth0_0 # FILTER RULES IPv6 rule6 01000 allow ipv6-icmp from any to any rule6 01010 check-state rule6 01020 deny tcp from any to any in established rule6 01021 allow tcp from any to any setup keep-state rule6 01023 allow udp from 2001:660:2002:4201::1/64 to any rule6 01024 allow udp from 2001:660:2002:4202::1/64 to any rule6 01025 allow udp from 2001:660:2002:4203::1/64 to any rule6 01040 allow udp from any 53 to 2001:660:2002:4201::53 rule6 01041 allow udp from 2001:660:2002:4201::53 to any 53 # FILTER STATEMENT disable filter # IPv4 RPF CHECK # IPv6 RPF CHECK # LOG exit


- 150 -

10.2. Annexe 2 - Configuration du commutateur Cisco 2950 Voici la configuration du switch 2950 :

Switch#show running-config Current configuration: ! version 12.0 no service pad service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Switch ! enable secret 5 $1$Nwyd$LfZAEjFB6tFkO793qfSRf1 ! ! ! ! ! ! no spanning-tree vlan 1 ip subnet-zero ip igmp snooping vlan 2 mrouter interface Fa0/1 ip igmp snooping vlan 3 mrouter interface Fa0/1 no ip igmp snooping cluster enable management 0 ! ! ! interface FastEthernet0/1 duplex full speed 100 switchport mode trunk ! interface FastEthernet0/2 description partie RL_1


- 151 -

switchport access vlan 2 ! interface FastEthernet0/3 description partie RL_2 switchport access vlan 2 ! interface FastEthernet0/4 description partie RL_3 switchport access vlan 2 ! interface FastEthernet0/5 description partie RL_4 switchport access vlan 2 ! interface FastEthernet0/6 description partie DMZ_1 switchport access vlan 3 ! interface FastEthernet0/7 description partie DMZ_2 switchport access vlan 3 ! interface FastEthernet0/8 description partie DMZ_3 switchport access vlan 3 ! interface FastEthernet0/9 ! interface FastEthernet0/10 ! interface FastEthernet0/11 description partie IPv6_only switchport access vlan 5 ! interface FastEthernet0/12 description partie IPv6_only switchport access vlan 5 ! interface VLAN1 no ip address


- 152 -

no ip directed-broadcast ip nat outside shutdown ! interface VLAN4 ip address 192.168.0.2 255.255.255.0 no ip directed-broadcast ip nat outside ! ip default-gateway 192.168.0.1 ip nat inside source list 199 interface VLAN4 overload access-list 199 dynamic Cluster-NAT permit ip any any snmp-server engineID local 0000000902000005DCD1BC00 snmp-server community private RW snmp-server community public RO snmp-server community private@es0 RW snmp-server community public@es0 RO ! line con 0 exec-timeout 0 0 transport input none stopbits 1 line vty 0 4 password ******** login line vty 5 15 password ******** login ! end

Voici la configuration des vlans sur le switch 2950 :

Switch#show vlan VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active Fa0/9, Fa0/10 2 reseau_local active Fa0/2, Fa0/3, Fa0/4, Fa0/5


- 153 -

3 DMZ active Fa0/6, Fa0/7, Fa0/8 4 prive active 5 IPv6_only active Fa0/11, Fa0/12 17 VLAN0017 active 1002 fddi-default active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active


- 154 -

10.3. Annexe 3 - Configuration du serveur de nom « BIND 9 »

L’arborescence des fichiers etc/bind/ ––––––––– ce répertoire contient l’ensemble des fichiers de configuration | named.conf | named.root | named.run | rndc.conf etc/bind/forward ––––– ce répertoire contient les zones directes

| db.renater.gn6.net | db.renater.gn6.org | localhost

etc/bind/reverse –––––– ce répertoire contient les zones inverses | 1.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. | 1.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.int. | 2.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. | 2.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.int. | 3.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. | 3.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.int. | 238.98.195.in-addr.arpa. | localhost-rev etc/bind/keys–––––––– ce répertoire contient les clés | rndc-keys etc/bind/log–––––––– ce répertoire contient les logs générés par named | dns-security.log | dns-update.log | named.log | named.run

Fichier /etc/bind/named.conf Ce fichier contient la liste des zones IPv4 et IPv6 (directes ou inverses) et le paramétrage des fichiers de traces.

include "/etc/bind/named.conf.options"; // prime the server with knowledge of the root servers zone "." {


- 155 -

type hint; file "/etc/bind/db.root"; }; // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; //////////////////////////////////// // reverse loopback zone (v4 & v6)// //////////////////////////////////// //localhost reverse IPv6 zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { type master; file "reverse/localhost-rev"; }; //localhost reverse IPv4 zone "0.0.127.in-addr.arpa" { type master;


- 156 -

file "reverse/localhost-rev"; }; /////////////////////////// // Dynamic zones FORWARD // /////////////////////////// // forward IPv4 & IPv6 zone "renater.gn6.net" { type master; file "forward/db.renater.gn6.net"; }; zone "renater.gn6.org" { type master; file "forward/db.renater.gn6.org"; }; /////////////////////////// // Dynamic zones REVERSE // /////////////////////////// Include "confv6-keys"; // reverse IPv4 zone 195.89.126 zone "238.98.195.in-addr.arpa." { type master; file "reverse/238.98.195.in-addr.arpa."; }; // reverse IPv6 Zone 2001:660:2002:4201 zone "1.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.int."{ type master; file "reverse/1.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.int."; }; zone "1.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa."{ type master; file "reverse/1.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.";


- 157 -

}; // reverse IPv6 Zone 2001:660:2002:4202 zone "2.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.int."{ type master; file "reverse/2.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.int."; }; zone "2.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa."{ type master; file "reverse/2.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa."; }; 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; };


- 158 -

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 { file "log/named.run" versions 2 size 20m; severity dynamic; channel default_syslog { syslog daemon; severity info; }; };

Fichier /etc/bind/forward/localhost Ce fichier contient les informations du localhost en IPv4 et IPv6 pour la zone directe.

$TTL 1D @ IN SOA routeGN6.gn6.renater.net. prevost.renater.fr. ( 2005012701 ; 3600 ; refresh (1 heure) 900 ; retry (15 minutes) 604800 ; expire (1w) 1080 ; minimum (18 minutes) ) IN NS localhost.


- 159 -

localhost. IN A 127.0.0.1 localhost. IN A 195.89.126.227 localhost. IN AAAA 2001:660:2002:4201::53 localhost. IN AAAA 2001:660:2002:4202::53 localhost. IN AAAA ::1

Fichier /etc/bind/forward/db.renater.gn6.net Ce fichier décrit la zone directe IPv4 et IPv6 de routeGN6 : renater.gn6.net. Le fichier décrivant la zone renater.gn6.org est identique en remplaçant le .net par .org.

$TTL 1D @ IN SOA pc3-ipv6.renater.gn6.net. prevost.renater.fr.

(2005062201 1080 900 69120 1080 ) ; 2005062201 ; serial ; 1800 ; refresh (30 minutes) ; 900 ; retry (15 minutes) ; 69120 ; expire (19 hours 12 minutes) ; 1080 ; minimum (18 minutes) ; ) renater.gn6.net. IN NS pc3-ipv6.renater.gn6.net. ;machines & routeurs localhost IN A 127.0.0.1 routeGN6.renater.gn6.net. IN A 195.89.126.227 IN AAAA 2001:660:2002:4201::53 pc3-ipv6.renater.gn6.net. IN A 195.89.126.234 IN AAAA 2001:660:2002:4203:2b0:d0ff:fe9a:42a1 pc2-ipv6.renater.gn6.net. IN AAAA

2001:660:2002:4202:2b0:d0ff:fe9a:4359 h323.renater.gn6.net. IN A 195.89.126.235 h323.renater.gn6.net. IN AAAA

2001:660:2002:4203:2c0:4fff:fea9:22c4


- 160 -

6wind.renater.gn6.net. IN A 195.89.126.225 IN AAAA 2001:660:2002:4201::1 ;hotes virtuels www.renater.gn6.net. IN CNAME pc3-ipv6.renater.gn6.net. www.gn6.net. IN CNAME pc3-ipv6.renater.gn6.net. @ IN MX 10 pc3-ipv6.renater.gn6.net. smtp.renater.gn6.net. IN CNAME pc3-ipv6.renater.gn6.net.

Fichier /etc/bind/reverse/localhost-rev Ce fichier contient les informations du localhost en IPv4 et IPv6 pour la zone inverse.

$TTL 1D @ IN SOA pc3-ipv6.renater.gn6.net prevost.renater.fr. ( 2005060901 ; serial 1800 ; refresh (30 minutes) 900 ; retry (15 minutes) 69120 ; expire (19 hours 12 minutes) 1080 ; minimum (18 minutes) ) IN NS localhost. 1 IN PTR localhost.

Fichier /etc/bind/reverse/3.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. Ce fichier décrit la zone inverse IPv6 de pc3-ipv6 et h323. Il comprend l’ensemble des machines du sous réseau 2001:660:2002:4203::. De la même manière il existe des fichiers int et arpa pour chacun des sous-réseaux.

$TTL 1D


- 161 -

@ IN SOA pc3-ipv6.renater.gn6.net. prevost.renater.fr. ( 2005062201 ; serial 1800 ; refresh (30 minutes) 900 ; retry (15 minutes) 69120 ; expire (19 hours 12 minutes) 1080 ; minimum (18 minutes) ) IN NS pc3-ipv6.renater.gn6.net. $ORIGIN 3.0.0.8.1.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. 1.a.2.4.a.9.e.f.f.f.0.d.0.b.2.0 IN PTR pc3-ipv6.renater.gn6.net. 4.c.2.2.9.a.e.f.f.f.f.4.0.c.2 IN PTR h323.renater.gn6.net.


- 162 -

10.4. Annexe 4 - Bibliographie

Livres et cours :

• IPv6 Théorie et pratique, Gizelle Cizeault (Ouvrage du G6), O'Reilly • JAVA et Internet, G. Roussel, Vuibert • Cours de Nicolas Menecer DESS ART

• Cours de Gilbert Sol DESS ART

Références Internet :

• HUhttp://aristote.asso.frUH : le site de l’association Aristote

• HUhttp://www.renater.frUH : le site du GIP RENATER

• HUwww.renater.fr/Video/IPv6/Multicast-Oct2003/P/UH : Bernard Tuy, Causerie de RENATER 10/2003

• HUhttp://www.urec.cnrs.fr UH : cours de l’UREC • HUwww.ietf.org UH : IETF • HUwww.voip-info.org UH : site dédié à la voix sur IP

services avancés ipv4 et ipv6 pour la communication audiovisuelle

Documents