DE D ES S S S
Ap A p pl p li ic ca at ti io on n s s d de es s R Ré és se ea a u u x x e et t d de e l la a Té T él l ém é m at a ti iq q u u e e
Ch C h ri r i st s t op o ph he e H H e e r r vi v i au a u x x
M M ul u lt ti id di if f fu f us s io i on n
e e t t s s er e r vi v ic c es e s a av va an nc cé és s e e n n IP I P v6 v 6
Mémoire soutenu en septembre 2004
Directeur des études : Gilbert Sol
Directeur du mémoire : Yves Legrandgérard Tuteur en entreprise : Jacques Prévost
Deux exemplaires de ce mémoire sont déposés et librement consultables au secrétariat du DESS « Applications des Réseaux et de la Télématique »
Toute reproduc tion en est interdite sans accord écrit de l’auteur et du directeur des études
Université Paris 7 Denis Diderot
UFR d’INFORMATIQUE
Remerciements
Je tiens tout d’abord à remercier M. Jacques Prévost qui a su me conseiller, me guider et m’apporter les réponses nécessaires au bon déroulement de mon stage et pour m’avoir accepté en tant que stagiaire Aristote.
Je remercie pour leur formation et leurs conseils, Yves Legrandgérard, mon directeur de mémoire, Gilbert Sol, mon directeur d’étude au DESS Applications des Réseaux et de la Télématique ainsi que Bernard Tuy, responsable de IPv6 au GIP RENATER.
Je remercie les personnes du GIP RENATER : Jérôme Durand, Simon Muyal, Kostya Kortchinsky, Siby Harouna pour leur aide technique très précieuse.
Je tiens à remercier également le directeur du GIP RENATER, M. Dany Vandromme, d’avoir donné son autorisation à ma venue.
Je remercie l’ensemble de l’équipe du GIP Renater, le SSO et le secteur administratif pour leur bonne humeur et cette ambiance agréable de travail.
Sommaire
1. Introduction...3
2. Contexte de travail...3
2.1. L’association Aristote... 3
2.2. Le réseau Renater et le GIP Renater... 3
2.2.1. Le Réseau National des Télécommunications pour la Technologie, l’Enseignement et la recherche ...3
2.2.2. Le GIP Renater...3
2.3. Le GN6... 3
2.4. Des actions de téléenseignement... 3
2.4.1. Le projet ATHENA...3
2.4.2. Les cours DIM...3
2.4.3. Les séminaires Aristote ...3
2.4.4. Les Causeries de Renater...3
2.4.5. La grille de Conférences...3
2.5. Cadre et objectifs ... 3
3. Les technologies employées...3
3.1. IPv6... 3
3.1.1. Un plus grand nombre d’adresses IP...3
3.1.2. Une hiérarchisation des adresses...3
3.1.3. Auto configuration des stations ...3
3.1.4. Le routage ...3
3.1.5. Le serveur de nom ...3
3.1.6. La sécurité...3
3.1.7. La métrologie ...3
3.2. La visioconférence... 3
3.2.1. RTP (Real-Time Transport Protocol), RTCP (Real-Time Transport Control Protocol) : les protocoles de transport de trafic temps réel...3
3.2.2. La vidéo numérique, les formats ...3
3.3. Le multicast... 3
3.3.1. Généralités ...3
3.3.2. Rappels sur les adresses IPv4...3
3.3.3. Adressage IPv6...3
3.3.4. Les protocoles IPv6...3
3.3.5. Cohabitation avec IPv4 ...3
3.3.6. M6Bone ...3
3.4. Le protocole H. 323 ... 3
3.4.1. Généralités ...3
3.4.2. Architecture...3
3.4.3. Etablissement de la communication...3
3.4.4. Historique ...3
3.4.5. Inconvénients du protocole H.323 ...3
3.5. Des applications pour la visioconférence ... 3
3.5.1. Vic...3
3.5.2. Vic GC (Grand CIF)...3
3.5.3. Rat...3
3.5.4. VideoLAN ...3
3.5.5. Isabel...3
3.5.6. Passerelle IPv4 - IPv6 ...3
4. Mises en œuvre...3
4.1. Etude et déploiement de systèmes de visioconférence ... 3
4.1.1. Mise en œuvre d’une passerelle IPv4 multicast - IPv6 multicast...3
4.1.1.1. Etude... 3
4.1.1.2. Réalisation... 3
4.1.2. Développement des fonctionnalités des outils de visioconférence pour le téléenseignement interactif ...3
4.1.2.1. Fonctionnement interne de VIC ... 3
4.1.2.2. VIC CG - haute résolution (4CIF)... 3
4.1.3. Participation de Renater au « Workshop d’Isabel » du 26 mai 2004...3
4.1.3.1. Présentation... 3
4.1.3.2. Utilisation... 3
4.1.3.3. Bilan... 3
4.2. La plate-forme de démonstration IPv6 du GN6... 3
4.2.1. Elaboration du design Réseau...3
4.2.1.1. Définition du projet ... 3
4.2.1.2. Collecte d’information ... 3
4.2.2. Proposition d’une topologie réseau IPv6...3
4.2.2.1. Premier pas ... 3
4.2.2.2. Choix des distributions et activation de la pile IPv6 ... 3
4.2.2.3. Architecture ... 3
4.2.3. Routage...3
4.2.3.1. Configuration du routage interne avec Zebra... 3
4.2.3.2. Configuration du routeur 6wind ... 3
4.2.3.3. Procédures de tests du routage ... 3
4.2.4. Le multicast IPv6...3
4.2.4.1. Raccordement au M6Bone avec le 6wind ... 3
4.2.4.2. Configuration du routeur Unix avec PIM6 ... 3
4.2.4.3. Procédure de tests du service multicast IPv6 ... 3
4.2.5. Ajout du service de DNS (Domain Name Server)...3
4.2.5.1. Le service DNS avec BIND ... 3
4.2.5.2. Procédure de tests du service DNS ... 3
4.2.6. Ajout du service de Serveur Web...3
4.2.6.1. Etude... 3
4.2.6.2. Le service Web avec Apache ... 3
4.2.6.3. Procédure de tests du service Web ... 3
4.2.7. Administration du réseau IPv6...3
4.2.7.1. Métrologie avec MRTG ... 3
4.2.8. Ajout de services de visioconférence IPv6...3
4.2.8.1. Configuration d’un client H323 avec GnomeMeeting... 3
4.2.8.2. Configuration d’un pont MCU avec OpenMCU... 3
4.3. Transfert de connaissances ... 3
5. Conclusion ...3
6. Annexes...3
Annexe 1. – Les partenaires du projet ATHENA ... 3
Annexe 2. – Les logiciels de visioconférence ... 3
Manuel d’utilisation de VIC ...3
Manuel d’utilisation de VIC-GC ...3
Manuel d’utilisation de RAT ...3
Manuel d’utilisation de VideoLAN ...3
Annexe 3. – Le routage... 3
Fichier /etc/rc.conf ...3
Fichier /usr/local/etc/zebra.conf ...3
Fichier /usr/local/etc/ripngd.conf ...3
Fichier /etc/dhcpd.conf ...3
Fichier de configuration du 6wind ...3
Annexe 4. – Le DNS... 3
Fichier /etc/resolv.conf ...3
Fichier /etc/host ...3
L’arborescence des fichiers...3
Fichier /etc/DNS/etc/named.conf ...3
Fichier /etc/DNS/forward/localhost ...3
Fichier /etc/DNS/forward/gn6.renater.fr ...3
Fichier /etc/DNS/reverse/localhost-rev...3
Fichier /etc/DNS/reverse/localhost-rev...3
Fichier /etc/DNS/etc/rndc.conf...3
Annexe 5. – Le serveur Web... 3
Installation de MySQL ...3
Installation de Apache...3
Installation de PHP4...3
Installation de SPIP...3
Installation de PHPMyAdmin ...3
Détection de l’utilisation du protocole IPv6 par un navigateur Web...3
Interface graphique du site Web...3
Annexe 6. – Bibliographie ... 3
1. Introduction
L’association Aristote est impliquée dans la mise en œuvre et la retransmission en multicast d’évènements à caractère pédagogique tels que les cours DIM, les Causeries de Renater et les séminaires Aristote.
L’emploi des logiciels de visioconférence en multicast dans le cadre de ces retransmissions a permis de révéler des besoins quant aux fonctionnalités offertes par ces outils.
C’est dans cette optique que le projet VIC-GC a vu le jour courant de l’année 2003. VIC- GC est un projet portant sur les modifications du logiciel utilisé pour émettre et recevoir de la vidéo en multicast afin de lui permettre de transmettre les transparents de l’orateur lors d’un cours ou d’une présentation.
Après une première phase de recherche et de création de ce projet dans l’environnement Unix conduite par Aurélien Amacker, alors stagiaire du DESS ART durant l’année scolaire 2002/2003, ma mission a été de porté ce logiciel à l’environnement Windows. Cette phase de développement du projet intégrait la pérennisation des techniques déjà utilisées.
D’autre part, le GIP Renater, partenaire de l’association Aristote, participe au processus de transition du protocole IPv4 vers IPv6 en proposant à la communauté académique un service de passerelle IPv4 – IPv6 multicast et c’est dans ce contexte que j’ai été chargé du passage de l’exploitation pilote à la mise en production.
En effet l’association Aristote est concernée par le développement du protocole IPv6 qui, outre les nombreuses fonctionnalités innovantes qu’il apporte, permettra à de nombreux pays oubliés par les nouvelles technologies de l‘Information et de la Communication de bénéficier d’un nombre d’adresses IP nécessaire au déploiement de leurs réseaux et ainsi d’accéder aux ressources pédagogiques contenues sur le réseau Internet, c’est pourquoi l’association Aristote encourage ses partenaires du projet ATHENA à mettre en œuvre des réseaux IPv6 et IPv6 multicast.
Pour aider de nombreux organismes et les accompagner tout au long de la démarche de transition IPv4 vers IPv6, le GIP RENATER a mis en place avec eux le Groupe des Néophytes IPv6 : le GN6.
C’est dans ce cadre que le projet de création d’une plate- forme IPv6 a été initié. Différents partenaires dont l’association Aristote ont mis à disposition les ressources nécessaires pour promouvoir les activités de recherche, de téléenseignements et de télétravail. J’ai été chargé de mettre en place cette vitrine technologique IPv6.
2. Contexte de travail
2.1. L’association Aristote
Créée de manière informelle en 1984 par l'INRIA, le CEA, EDF et le CNES, formalisée en 1988, l'Association Aristote regroupe de grands organismes ou entreprises français intéressés comme acteurs ou comme utilisateurs à l'évolution des télécommunications de transmissions de données.
L'objectif d'Aristote se situe dans le domaine des techniques, moyens, outils et services de communication informatique, notamment :
Ø mettre en commun des efforts de prospective, d'étude et d'information faits par ses membres.
Ø promouvoir l'élaboration et la mise en service de nouveaux produits, systèmes et services d'intérêt général au bénéfice de ses partenaires. Cette activité se déroule dans le cadre des groupes de travail techniques d'Aristote.
Ø organiser ou encourager des actions avancées d'information ou de formation : séminaires d'intérêt général, séminaires de formation technique, journées d'étude thématiques.
L’association Aristote est un acteur important dans le développement et dans la diffusion de connaissances concernant les nouvelles technologies de l’information et de la communication.
Pour en savoir plus : http://www.aristote.asso.fr
2.2. Le réseau Renater et le GIP Renater
2.2.1. Le Réseau National des Télécommunications pour la Technologie, l’Enseignement et la recherche
RENATER (Réseau National de Télécommunications pour la Technologie, l’Enseignement et la Recherche) a été créé dans les années 1990 dans le but de fédérer et d’organiser les infrastructures de télécommunications pour l’Education, la Recherche et l’Enseignement.
Aujourd’hui, plus de 600 sites sont raccordés au réseau RENATER. Ceci leur permet de communiquer entre eux, d’accéder aux centres de recherche publique et privés, aux établissements d’enseignement du monde entier via l’Internet.
Le réseau RENATER est composé d’une infrastructure métropolitaine et de liaisons internationales à haut débit. Des points de présence de RENATER sont également implantés dans les départements d’Outre Mer. RENATER est basé sur une architecture distribuée : il comprend une épine dorsale nationale à haut débit multi-Gbit/s - RENATER 3 - qui fédère des réseaux de collecte régionaux développés avec le soutien des collectivités territoria les dans le cadre de l’aménagement du territoire.
La liaison entre le réseau RENATER et le réseau GEANT est à 10Gbit/s. Grâce à cette liaison le réseau RENATER est relié aux réseaux de la Recherche européens et nord- américains.
La communication avec l’Internet, en France, est réalisée par le SFINX, un point d’échange entre les opérateurs, auquel RENATER est relié à 1 Gbit/s. La communication avec l’Internet dans le reste du monde est assurée par le raccordement de RENATER à 2.5 Gbit/s à l’épine dorsale Internet mondiale OpenTransit de France Télécom.
Avec la version 3 de RENATER, les débits des liaisons de l’épine dorsale sont presque partout de 2,5 Gbit/s. Ces liaisons sont – presque partout – organisées en boucle : ceci augmente la disponibilité en cas d’incident – il y a toujours un chemin de secours disponible – et facilite la mise en place de liaisons de voisinage entre régions. Le réseau Ile de France est un réseau maillé avec des liens pouvant atteindre 2,5Gbit/s.
Voici la carte de RENATER 3 :
Au niveau des points d'accès régionaux de son épine dorsale, RENATER 3 propose de nombreux services :
Ø un service IPv4 permettant d’accéder aux communautés de la recherche et de l’enseignement, nationales et internationales ainsi qu’à l’Internet
Ø un service de diffusion IPv4 (IP multicast), utilisée pour la visioconférence et le téléenseignement interactif
Ø un service IPv6, utilisé par les universités pour préparer la migration de IPv4 vers IPv6, ainsi que par de nombreux projets de recherche et développement.
IPv6 est la nouvelle version du protocole IP de l’Internet. En Europe, les réseaux de la recherche sont très actifs pour préparer et commencer cette migration, et proposer un service IPv6 pour les expérimentations des premiers utilisateurs. RENATER est au premier plan de cette évolution : dans RENATER 3, il y a un service IPv6 natif, c’est à dire placé sur le même plan que le service IPv4.
IPv6 est conçu pour s’affranchir des limitations d’IPv4 (pénurie d’adresse IPv4, explosion des tables de routage…), mais aussi pour prendre en compte les avancées issues des recherches sur les réseaux, comme l’auto configuration, la mobilité, le multicast ou encore la sécurité.
Pour en savoir plus : http://www.renater.fr
2.2.2. Le GIP Renater
Le GIP1 RENATER réunit de grands organismes de recherche et d'enseignement, ainsi que le ministère en charge de l'Education Nationale, de la recherche et de la technologie, pour développer et faire fonctionner le réseau RENATER.
Un GIP (groupement d'Intérêt public) est un organisme à but non lucratif, réunissant des administrations de l'Etat et des organismes publics pour une activité définie : dans le cas du GIP RENATER il s'agit du réseau RENATER.
Le GIP RENATER est le maître d'ouvrage de la partie commune de RENATER, constituée de son épine dorsale RENATER 3, des liaisons internationales, de ses actions pilotes, et du service SFINX, qui est un GIX (Global Internet eXchange), point d'échange de trafic Internet entre prestataires de services Internet, ou opérateurs de télécommunications qui veulent échanger du trafic, sans transit et sans passer par des infrastructures internationales
Le GIP RENATER est également le coordinateur technique et opérationnel global de l'ensemble du réseau RENATER y compris ses éléments régionaux. Il représente le réseau RENATER auprès des institutions françaises et étrangères, et notamment auprès des autres réseaux de la Recherche.
Le directeur du GIP RENATER est M. Dany Vandromme, professeur des universités ; L'équipe du GIP RENATER comprend aujourd'hui un peu moins de 30 personnes : ingénieurs, techniciens et personnel administratif répartis entre Paris et Montpellier.
1 GIP : Groupement d’Intérêt Public.
2.3. Le GN6
De nombreux organismes de la communauté des utilisateurs de RENATER désirent actuellement démarrer de petits réseaux IPv6 dans leurs organismes : cela leur permettra d’acquérir l’expertise nécessaire, et d’étudier concrètement divers aspects techniques et opérationnels de l’introduction de IPv6. Ainsi, ils pourront ensuite planifier dans de bonnes conditions le passage de IPv4 vers IPv6.
Pour les aider et les accompagner tout au long de cette démarche, le GIP RENATER a mis en place avec eux le Groupe des Néophytes IPv6 : le GN6.
Le GN6 est un groupe de travail qui met ensemble des acteurs « réseau » des organismes de la communauté RENATER : organismes utilisateurs de RENATER, réseaux de collecte de RENATER, réseaux ou organismes étrangers qui ont une convention de coopération avec le GIP RENATER.
Ses objectifs sont notamment :
Ø permettre de s’initier à la mise en œuvre de IPv6 et de ses applications de base,
Ø faciliter, par des échanges d’information et des retours d’expérience systématiques, le démarrage de réseaux pilotes IPv6 – qui pourront être connectés au service IPv6 de RENATER - dans les organismes,
Ø faciliter, dans les mêmes conditions, la participation aux actions pilotes menées par le GIP RENATER et/ou le G6, par exemple IPv6 multicast ou DNSsec.
Ø faciliter l’accès aux connaissances des experts, notamment ceux du GIP RENATER et de l’Association G6.
Démarré mi-2002, le GN6 comporte déjà une vingtaine de personnes, et se réunit tous les deux mois. Certains de ses membres, éloignés de quelques milliers de kilomètres, participent régulièrement aux réunions en visioconférence sur IPv6.
Pour en savoir plus : http://www.RENATER.fr/Evenements/200210GN6/index.htm
2.4. Des actions de téléenseignement
2.4.1. Le projet ATHENA
Actions pour des Transmissions Harmonieuses et des Echanges de Natures Académiques
ATHENA est un projet mis en œuvre par l’association Aristote en association avec différents partenaires pour l’étude et la validation de processus d’échanges académiques via des transmissions réseau de contenus scientifiques entre sites académiques francophones.
ATHENA a pour objectif de contribuer au développement d’échanges académiques à travers les NTIC (Nouvelles Technologies de l’Information et de la Communication) entre le réseau Renater et les milieux universitaires de ces pays.
A la différence d’autres expériences il ne s’agit pas de mettre à la disposition des partenaires des supports multimédia (cédéroms ou vidéocassettes par exemple), l’intérêt est de mettre en place un dispositif d’échanges en temps réel (interactif) à travers les outils modernes de communications et en particulier à l’aide de la visioconférence. D’où le besoin d’une analyse de la faisabilité technique avec l’étude des moyens de communications dont disposent les futurs partenaires : ordinateurs, équipements de visioconférence, connectivité Internet, réseaux analogiques, numériques, hertziens…
Les premiers tests sont validés par :
Ø des essais de visioconférence en point à point avec les partenaires,
Ø la diffusion en direct d’évènements, l’ambition étant de faire du temps réel,
Ø l’accent mis sur l’interactivité ne supposant pas l’ignorance d’autres dispositions notamment la mise, par chaque partenaire, à la disposition de l’ensemble du réseau constitué, des documents scientifiques à contenus consultables via Internet.
Ces échanges de contenu à caractères scientifiques avec les pays de l’Afrique francophone contribuent à une homogénéisation des connaissances dans les secteurs des télécommunications, réseaux…
Cette mise en partage des connaissances à pour objectif de donner aux étudiants africains le même savoir que celui dispensé aux étudiants européens.
La carence de personnel et de salles de cours dans beaucoup de pays africains pourrait être compensée par cet enseignement à distance.
Le projet ATHENA a été initié par l’apprenti du DESS ART au GIP Renater de la promotion 2000/2001, M. Harouna Siby, qui a prospecté et trouvé des contacts en Afrique et plus précisément au Sénégal, puis ce projet a vu arriver de nouveaux partenaires en Inde, en Tunisie et au Maroc avec le travail de M. Lionel David, apprenti du DESS ART au GIP Renater lors de l’année scolaire 2001/2002.
Les nombreux partenaires du projet ATHENA sont listés en annexe (cf. Annexe 1. – Les partenaires du projet ATHENA.).
Le projet ATHENA constitue pour l’association Aristote un moyen de nouer des partenariats et de partager des connaissances et des savoir-faire avec des partenaires académiques du monde entier.
2.4.2. Les cours DIM
DIM (Diplômes d'Ingénierie Multimédia): c'est le nom d'un projet commun à plusieurs DESS – ou enseignements équivalents – de technologies d'informatique et de réseau.
DIM leur permet d'organiser régulièrement des cours communs, partagés en interactif grâce à la visioconférence et à des outils de travail coopératif sur Renater.
Ces enseignements sont dispensés à :
Ø L’Université d'Evry Val d'Essonne (UEVE)
Ø L’Institut National des télécommunications à Evry (INT) Ø L’Université Paris VII sur le campus de Jussieu
Ø L’Université de Valenciennes et du Hainaut-Cambrésis (UVHC)
Ø L’Ecole Supérieure Multinationale de Télécommunications de Dakar (ESMT) Ø La Faculté Polytechnique de Mons
Le GIP Renater apporte sa contribution au support technique de DIM : réseau et service IP multicast, technologies de vidéo numérique sur IP.
DIM a démarré en Octobre 2001. Voici une vue de la salle du DESS ART à Paris VII, lors de la réception du premier cours DIM émis par le DESS IDM à Evry :
Figure 1 : à gauche se trouvent les transparents de l’orateur, à droite l’image de l’orateur. Les élèves peuvent poser des questions grâce aux micros qui se trouvent sur les tables.
Les cours sont dispensés à tour de rôle par un enseignant de chacune des cinq formations concernées.
Les cours DIM constituent une expérience grandeur nature de l’usage de la visioconférence dans le cadre du téléenseignement interactif, en effet en plus de voir et d’entendre l’orateur les étudiants peuvent poser des questions pendant le cours.
2.4.3. Les séminaires Aristote
Dans le cadre de ses activités de diffusion de la connaissance auprès de ses membres, l'Association Aristote organise régulièrement des séminaires de haut niveau : les séminaires Aristote. Ils sont groupés en cycles de 6 séminaires d'une journée chacun par année scolaire.
Ces séminaires se déroulent le plus souvent dans un amphithéâtre de l'Ecole Polytechnique.
Ils sont principalement destinés aux utilisateurs évolués, aux administrateurs de réseaux et d'ordinateurs, et aux responsables et décideurs.
Chaque séminaire est consacré à un thème précis, choisi dans le domaine des technologies des réseaux et de leurs applications de base. Il en aborde divers aspects: principes et état de l'art, produits et réalisations industrielles et/ou opérationnelles; compte rendus d'expériences ou de stratégies d'utilisateurs. Il fait intervenir des orateurs de haut niveau : experts internationaux, spécialistes des organismes d'Aristote, représentants des industriels et des fournisseurs de produits.
2.4.4. Les Causeries de Renater
Les Causeries de Renater sont des conférences virtuelles d’une demi-journée à une journée disponibles sur Renater.
Elles se déroulent entièrement en télé présence, grâce aux possibilités de visioconférence permises par les performances de Renater.
Les orateurs et les auditeurs sont dans des salles de réunion équipées pour le multimédia, ou parfois simplement dans leurs bureaux : ces lieux sont réunis en une vaste salle de conférence virtuelle par le réseau RENATER et les autres réseaux de la recherche : certains sont en effet à l’étranger. Tous les participants peuvent voir et entendre l’orateur, interagir et poser des questions, puis participer au débat.
Au total, et suivant le sujet de la Causerie, il y a de 10 à 50 points d’écoute, pouvant représenter plus d’une centaine de personnes.
Chaque Causerie est dédiée à un thème précis. Il est traité par un ou plusieurs orateurs de haut niveau : membres de l’équipe du GIP Renater, responsables réseaux des Centres de Ressources Informatiques des universités, professeurs de DESS d’informatique, experts reconnus, utilisateurs compétents etc.
Certains des thèmes retenus jusqu’ici concernent le réseau Renater: déploiement, opération, technologies. D'autres abordent des applications avancées ou innovantes rendues possibles par Renater.
Les Causeries sont ouvertes à toute la communauté des utilisateurs de Renater.
Les organisateurs des Causeries sont actuellement : Guy Bisiaux (Université de Valenciennes) et Jacques Prévost (GIP Renater).
2.4.5. La grille de Conférences
La Grille de Conférences est le plus récent des projets dans lequel est impliquée l’association Aristote, il s’agit de proposer une normalisation du mode opératoire des techniques utilisées pour la visioconférence et la retransmission en multicast d’évènements à caractère pédagogique.
La Grille de Conférences réunit sur Renater (et ailleurs) un ensemble de noeuds (points d'écoute et de participation) de visioconférence, équipés et opérés de manière cohérente et coordonnée.
La Grille permet de réaliser aisément des conférences virtuelles, avec des groupes d'auditeurs situés à chaque noeud.
La Grille sépare totalement l'organisation de la virtualité, qui est du domaine des animateurs des noeuds, et l'organisation du contenu, qui est du domaine de l'animateur de chaque conférence : celui- ci peut préparer sa conférence ou son séminaire pratiquement sans avoir à se soucier de la virtualisation – et en bénéficiant d'auditeurs à distance, capables de poser des questions et de participer aux débats, et aussi en programmant, s'il le désire, des intervenants à distance : il suffit qu'ils se rendent au noeud de la Grille le plus proche.
La Grille de Conférences, c'est :
Ø Une technologie de pointe pour la visioconférence dans chaque noeud Ø Un mode opératoire commun bien défini
Ø Des interconnexions réseau de qualité entre les noeuds Ø Un accueil et une mise en oeuvre dans chaque noeud
Actuellement on trouve des nœuds de la grille de conférence à Caen, Dakar, Paris, Montpellier et Toulouse.
La Grille s'efforce d'intégrer les technologies validées par les utilisations à grande échelle de ces derniers temps, notamment DIM, Causeries de Renater et séminaires Aristote, ainsi que les conclusions des retours d'expérience de ces utilisations pilotes et notamment leurs suggestions d'améliorations.
2.5. Cadre et objectifs
Ma formation au sein du DESS Applications des Réseaux et de la Télématique à l’université de Paris VII effectuée en alternance, s’est déroulée dans le cadre d’un partenariat entre l’association Aristote et le GIP Renater. Le stage a été effectué dans les locaux du GIP Renater. Mes tuteurs durant ce stage étaient : Jacques Prévost (Association Aristote) chargé des applications avancées (visioconférences…) et Bernard Tuy, responsable des technologies IPv6 et IP multicast au sein du GIP Renater.
Le sujet du stage comportait deux axes principaux :
Ø La mise en place et le développement de nouvelles fonctionnalités dans le domaine de la visioconférence orientée téléenseignement (transmission de séminaires et de conférences), notamment en IPv6,
Ø L’étude et le déploiement d’autres modes de visioconférences dans le cadre d’une plate- forme de démonstration IPv6.
La première partie sur le multicast IPv6 s’inscrit dans la continuité de ce qui a été fait par mon prédécesseur du DESS ART, Aurélien Amacker. Le but était de contribuer au développement de fonctionnalités demandées par l’utilisateur et de l’interactivité des actions de téléenseignement mises en œuvre par l’association Aristote et de nombreux autres utilisateurs.
La mise en place d’une plate- forme de démonstration IPv6 s’inscrit dans le cadre de prestation de services et de communication qui permet de promouvoir le protocole IPv6 tout en montrant des plateformes de production mettant en œuvre des services associés à ce nouveau protocole.
3. Les technologies employées
3.1. IPv6
IPv4 a été initialement conçu pour un réseau comprenant une centaine d'ordinateurs. Avec le web, Internet a vu son utilisation augmenter de manière exponentielle si bien que la saturation du réseau a été initialement prévue pour 1994. Des solutions comme le NAT (translation d'adresses) et le CIDR (Classless InterDomain Routing - RFC2 1519) ont permis de ralentir considérablement l'explosion du réseau et ont permis de mettre au point un nouveau protocole Internet appelé IPv6.
IPv6 est conçu pour remédier aux limitations de IPv4 et en même temps répondre à de nouvelles exigences techniques apparues au niveau des réseaux ou des applications. La normalisation du protocole arrive aujourd'hui en bout de cycle. Voici une exp lication synthétique des fonctionnalités principales du protocole IPv6 :
3.1.1. Un plus grand nombre d’adresses IP
Les adresses IPv4 ont presque toutes été allouées et IPv6 a pour première mission d'apporter un plus grand nombre d'adresses. Une adresse IPv6 est composée de 128 bits contre 32 bits pour IPv4. Le nombre d'adresses IPv6 disponibles a été estimé entre 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 (la casse des symboles n'a pas d'importance). Par exemple :
fedc:0000:0000:0000:0400:a987:6543:210f
Dans un champ, il n'est pas nécessaire d'écrire les 0 placés en tête et plusieurs champs nuls consécutifs peuvent être abrégés par "::". Ce symbole ne peut apparaître qu'une seule fois dans une adresse. L'adresse précédente s'écrit donc en fait :
fedc::400:a987:6543:210f 3.1.2. Une hiérarchisation des adresses
L'objectif principal d'IPv6 a été de hiérarchiser les adresses pour permettre de plus grands agrégats et une réduction de la taille des tables de routage des routeurs de backbone (épine dorsale).
Voici le schéma d'une adresse IPv6 :
001 3 bits
TLA 13 bits
sTLA 13 bits
Res 6 bits
NLA 13 bits
SLA 16 bits
Interface ID 64 bits
2 RFC : Request For Comment
Topologie publique Topologie privée
Chaque partie est réservée à un usage précis. Il est à noter que la partie publique de l'adresse peut être encore amenée à certaines modifications. La partie privée quant à elle gardera définitivement cette structure.
- Les 3 premiers bits 001 sont utilisés pour identifier le format d'adresse IPv6 agrégé (aggregatable global unicast addresses).
- Le TLA (Top Level Aggregator) est réservé pour numéroter des opérateurs de transit.
Il n'existe pas aujourd'hui d'opérateur de transit IPv6 et cette partie n'est utilisée que pour différencier certains types spécifiques d'adresses (adresses de test, adresses officielles, 6to4...)
- Le sTLA (sub TLA) permet de numéroter les différents fournisseurs d'accès IPv6.
Chaque Internet Registry3 possède une partie du subTLA pour numéroter les providers de sa zone géographique. Quand l'espace d'adressage assigné est épuisé, l'Internet Registry se voit confier un nouvel espace par l'IANA.
- Les 6 bits suivants sont réservés pour pouvoir étendre la partie sTLA ou NLA en fonction des évolutions futures.
- Le NLA (Network Level Aggregator) est la partie réservée aux providers pour numéroter leurs différents clients et gérer la hierarchie au sein de leur réseau.
- Le SLA (Site Level Aggregator) est la partie réservée aux sites pour permettre de hiérarchiser le réseau en créant d'éventuels sous-réseaux. Les 16 bits du SLA permettent un découpage du site en 65 536 sous-réseaux ce qui permet de n'allouer, même à des sites de très grande taille qu'un seul NLA-ID (identifiant de NLA)
Cette structure hiérarchique permet de pallier un des problèmes majeurs du protocole IPv4 à savoir l'explosion de la taille des tables de routage des routeurs de backbone. Par exemple, Renater compte aujourd'hui environ 4000 routes qui sont agrégées en un peu plus de 140 agrégats IPv4 et il ne suffit que de 2 préfixes IPv6 pour annoncer l'ensemble du pilote IPv6 (le préfixe de production et le préfixe de test) sur le réseau Internet IPv6.
3.1.3. Auto configuration des stations
Un autre objectif a été de supprimer les commandes manuelles à fournir en IPv4 (adresse IP, passerelle par défaut) pour que la connexion au réseau devienne "plug-and-play" sans avoir à configurer de serveurs supplémentaires comme les serveurs DHCP.
Les 64 bits de poids fort de l'adresse IPv6 correspondent à un identifiant de réseau et les 64 bits restants sont l'identifiant d'interface qui peut être déterminé automatiquement en fonction de l'adresse physique de la machine.
L’autoconfiguration est réalisée par une politique de découverte des voisins (« neighbor discovery » RFC 2461) : une station qui démarre va émettre un paquet "router sollicitation"
pour faire savoir au routeur du LAN qu'elle a besoin du préfixe du LAN pour calculer son adresse IPv6. Ce dernier répondra par un paquet "router advertisement" contenant le préfixe du LAN ainsi que d'autres informations comme la passerelle par défaut. Une station configurera son adresse IPv6 en concaténant le préfixe reçu et son identifiant d'interface qu'elle a calculé à partir de son adresse physique.
3 Un Internet Registry a la mission d'allouer des blocs d'adresses IP et des préfixes IPv6 dans sa zone géographique. Les Internet Registries aujourd'hui sont l'ARIN pour l'Amérique du Nord (www.arin.net), l'ATNIC pour l'Amérque du Sud (www.atnic.net), RIPE-NCC pour l'Europe, l'Afrique du Nord et le centre de l'Asie (www.ripe.net), l'APNIC pour l'Asie Pacifique (www.apnic.net). L'ICANN assure la coordination des Internet Registries (www.iana.net).
Les différentes étapes de l’algorithme « neighbor discovry » (RFC 2461) : Ø La toute première étape consiste à créer l’adresse lien local.
L’adresse de lien local est valide uniquement sur un même espace de lien sans routeur intermédiaire. Un routeur ne route pas ce type d’adresse.
L’interconnexion par un commutateur de niveau MAC représente cet espace lien.
Voici le schéma d'une adresse de lien local IPv6 de préfixe fe80::/10 :
F E 8
1111 1111 10 0 ID Interface
10 bits 54 bits 64 bits
Une fois l’unicité de cette adresse vérifiée grâce à l’algorithme DAD (détection d’adresses dupliquées), la machine est en mesure de communiquer avec les autres machines du lien.
Ø A la fin de cette étape la station va émettre un paquet « routeur sollicitation » pour faire savoir au routeur du LAN qu'elle a besoin du préfixe du LAN pour calculer son adresse IPv6
Ø Ce dernier répondra par un paquet « router advertisement » contenant le préfixe du LAN ainsi que d'autres informations comme la passerelle par défaut.
Ø La machine doit chercher à acquérir un message d’annonce du routeur pour déterminer la méthode d’obtention de l’adresse Unicast globale et de connaître la route par défaut (dans le cas d’une autoconfiguration sans état). Cette étape permet à la machine de connaître le ou les préfixes du réseau qui sont annoncés par les routeurs. Ce préfixe a une longueur de 64 bits. La machine ajoute son identifiant d’interface (déduit à partir de son adresse IEEE 802.3) pour construire son adresse IPv6.
Ø S’il y a un routeur sur le lien local, la machine doit appliquer la méthode indiquée par le message d’annonce du routeur, à savoir : l’autoconfiguration sans état ou l’autoconfiguration avec état.
Ø En l’absence de routeur sur le lien local, la machine doit essayer d’acquérir l’adresse Unicast globale par la méthode d’autoconfiguration avec état. Si la tentative échoue, c’est terminé. Les communications de feront uniquement au niveau du lien local.
Ø Une station configurera son adresse IPv6 en concaténant le préfixe reçu et son identifiant d'interface qu'elle a calculé à partir de son adresse physique.
3.1.4. Le routage
Le routage IPv6 offre très peu de différences avec IPv4. Les protocoles de routage IPv6 les plus connus sont RIPng adaptation de RIPv2, OSPFv3, ISIS pour IPv6 et BGP4+.
3.1.5. Le serveur de nom Comment fonctionne le DNS ?
Le service de résolution de noms (RFC 1034) permet la correspondance d’une adresse IP à un nom et inversement.
Ø Ce service est une base de donnée répartie, ceci permet un contrôle local de segments de la base de données globale.
Ø La structure de la base de données du DNS est décrite comme un arbre inversé avec le nœud racine au dessus (étiquette nulle). Chaque nœud dans l’arbre a une étiquette, qui identifie de manière unique le nœud relativement à son parent. On garantit ainsi l’unicité d’un nom dans une structure arborescente.
L’exemple suivant illustre les deux points précédents :
Le RFC 1886 décrit les extensions apportées à ce service pour prendre en compte le protocole IPv6.
Le choix du nom de domaine de la plate-forme
Pour une dénomination claire de toutes les machines participant à la plate- forme de démonstration IPv6 du GN6, le choix du nom de domaine a été gn6.renater.fr. Ainsi toutes machines ayant pour serveur de noms celui de la plate- forme aura comme nom exemple.gn6.renater.fr, exemple fera partie de la plate-forme du GN6 hébergée par Renater.
Ce choix n’est donc pas anodin de plus il faut vérifier son unicité auprès du serveur de noms primaire.
""
fr
renater
gn6
pc3ipv6
Le domaine de la plate- forme est une simple sous division de renater.fr, on parle ainsi de délégation du serveur de noms gérant la zone renater.fr au serveur de noms secondaire gérant la zone gn6.
Ainsi le serveur de noms routegn6 gère sa propre zone gn6.renater.fr.
Les fichiers de Zone
La correspondance adresse IP et nom s’effectue à l’aide d’enregistrements (RR,
« Ressource Record ») au niveau du fichier (RFC 1912) gn6.renater.fr de notre serveur de noms.
Il existe différents type d’enregistrement RR dont celui de type SOA (Start Of Authority), c’est l’enregistrement qui indique la zone dans laquelle le DNS se trouve : gn6.renater.fr.
D’autres types de RR peuvent définir (listes non exhaustives cf. manuel d’utilisation de bind généré à l’installation de ce serveur de nom) :
- les adresses IPv4 du domaine : c’est le type A.
- les adresses IPv6 domaine : c’est le type AAAA (ou A6 obsolète).
- le nom du serveur de noms d’une zone : c’est le type NS.
- le courriel : c’est le type MX - les alias : c’est le type CNAME.
- l’adresse IP inverse : c’est le type PTR.
Les « résolveurs »
Les « résolveurs » (RFC 1034) sont des programmes qui interfacent les applications utilisateur aux serveurs de noms de domaines. Dans le cas le plus simple, un résolveur reçoit une requête provenant d'une application (ex., certaines applications de visioconférences). Le résolveur est situé sur la même machine que l'application recourant à ses services, mais devra par contre consulter des serveurs de noms de domaines sur d'autres hôtes. Les résolveurs sont souvent de simples routines qui créent des requêtes et des envois à travers un réseau au serveur de noms.
Le DNS et IPv6
Le RFC 3596 décrit les modifications à apporter au niveau des DNS pour qu'ils puissent supporter les adresses IPv6.
La résolution nom adresse est décrite au travers d'un enregistrement AAAA. La machine exemple.gn6.renater.fr sera enregistrée sur le DNS du domaine gn6.renater.fr comme il suit :
exemple IN AAAA 2001:770:4001:5024:200:39ff:fe4e:a9f6
La correspondance adresse nom est faite par un enregistrement de classe IN et de type PTR dans un domaine de nom spécial ip6.arpa. La notation de l'adresse est de type nibble : on renverse tous les symboles de l'adresse en hexadécimal par demi-octet, séparés par des points.
La correspondance adresse nom de l'exemple précédent est écrite comme il suit dans le DNS : 6.f.9.a.e.4.e.f.f.f.9.3.0.0.2.4.2.0.5.1.0.0.4.0.7.7.0.1.0.0.2.ip6.arpa IN PTR exemple.gn6.renater.fr
3.1.6. La sécurité
La sécurité est assurée par deux mécanismes : IPsec qui permet la confidentialité des échanges de données entre les usagers et les access-lists qui permettent de protéger les réseaux contre les intrusions.
- Le protocole IPv6 permet l'authentification et le chiffrement des données (AH et ESP pour IPsec). La sécurité doit être obligatoirement gérée sur toutes les piles IPv6 afin de pouvoir échanger entre tous les nœuds des informations confidentielles.
- La sécurité est aussi gérée en filtrant certains protocoles qui peuvent être utilisés pour attaquer le réseau. Le problème est que l'implémentation des access-lists sur les routeurs n'est pas toujours réalisée.
3.1.7. La métrologie
La métrologie est aujourd'hui utilisée dans la plupart des réseaux, qu'ils soient locaux, métropolitains, nationaux ou internationaux. Elle permet de superviser le réseau, d'analyser les flux (afin d'obtenir une aide au diagnostic) et de vérifier le bon dimensionnement de l'architecture. C'est également un outil pour la sécurité puisqu'elle permet la détection des incidents et de certaines attaques.
Les entités de gestion émettent des requêtes vers les nœuds supervisés pour vérifier les valeurs de certaines variables. Les agents sont des modules logiciel qui compilent d'abord des informations sur les dispositifs hôtes contrôlés, puis stockent ces informations dans une base de données de gestion, et la fournissent finalement (proactivement ou réactivement) aux entités de gestion par l'intermédiaire d'un protocole de gestion de réseau.
La structure de l’information de gestion définie par l’ISO est basée sur la collecte d’objets. Ces objets sont stockés dans des bases de données de gestion appelée MIB (Management Information Base). Ces objets vont alors permettre de décrire le comportement et offrir des points de contrôles des systèmes managés et optionnellement des actions que le manageur peut alors solliciter. Pour ce faire chaque objet offre un ensemble d’attributs, de comportements et d’actions et doivent pouvoir être créés et effacés.
Les variables que l’on cherche à gérer à distance doivent être identifiées de façon unique.
Des règles normalisées ont été proposées pour autoriser l’utilisation de ces numéros d’identificateur. L’ISO a décidé de se baser sur les identificateurs d’objets (OID) qui reposent sur un arbre d’enregistrement unique.
Un protocole simple de gestion de réseaux, SNMP (Simple Network Management Protocol) a été développé par l’IETF dans le cadre de la définition d’un système de gestion pour les réseaux utilisant les protocoles TCP/IP. De fait, SNMP est très répandu aussi bien dans le domaine des réseaux locaux, que celui des réseaux métropolitains ou des réseaux WAN4.
4 Les réseaux WAN (Wide Area Network), couvrent les communications mondiales.
3.2. La visioconférence
3.2.1. RTP (Real-Time Transport Protocol), RTCP (Real-Time Transport Control Protocol) : les protocoles de transport de trafic temps réel
Les applications en temps réel n'ont pas les mêmes besoins que les applications de transfert de données. En effet, lors de la diffusion d'une vidéo sur IP, si certains paquets se perdent il est inutile de les émettre à nouveau et la caractéristique "temps réel" de ce type d'application est due au fait qu'il est ici plus important de recevoir les données au bon moment que de recevoir toutes les données.
Un protocole de transport a donc été défini pour cette tâche : RTP (Real Time Transport Protocol, protocole temps réel). Celui-ci fait partie des protocoles qu'on appelle de "nouvelle génération" car adapté tout spécialement à un type d'application : la diffusion d'informations multimédia interactives sur l'Internet.
Ainsi RTP propose des services particuliers comme le transport d'information compressée sous différents formats, le numérotage d'une séquence de paquets, l'estampillage et une surveillance de bonne réception de données multimédia.
Quant à RTCP, il s’agit d’un protocole destiné à assurer le contrôle du trafic. Il permet à l’émetteur de récolter des informations au sujet de la qualité de la transmission.
Chacun de ces deux protocole s utilise un port séparé d'une paire de ports. RTP utilise le port pair et RTCP le port impair immédiatement supérieur.
3.2.1.1. RTP
RTP (RFC 3550) est un protocole de transport de données multimédia ou temps réel. Il ne fournit aucune garantie de qualité de service et se place généralement au dessus d'UDP5 pour fonctionner.
Ainsi RTP ne garantie pas une diffusion ordonnée des données mais aide l'application à reconstruire une séquence de données multimédia grâce à ses fonctions de numérotage et d'estampillage.
Il est important de savoir que RTP est destiné à transporter un seul type d'information à la fois, par exemple lors de la diffusion d'une vidéo, la vidéo et le son utiliseront deux flux de données RTP différents et le multiplexage d'informations diverses devra plutôt être assuré par un protocole sous-jacent (le port destination dans UDP par exemple).Voici quelques définitions qui permettront de mieux comprendre ce protocole.
- Données RTP : Il s'agit des informations transportées par le protocole, par exemp le du son ou de la vidéo encodée de différentes manières.
- Paquet RTP : Un paquet RTP contient une entête fixe RTP, une liste pouvant être vide des sources participant au paquet et les données RTP. Typiquement un paquet du protocole sous-jacent (UDP) contie nt un seul paquet RTP.
5 User Datagram Protocol, protocole de datagrammes en mode utilisateur.
- Port : L'abstraction permettant à un protocole de transport de différencier des destinations multiples au sein d'un même ordinateur.
- SSRC : "Synchronization source", il s'agit de l'identifiant unique d'un flux de données RTP afin d'être indépendant de l'adresse réseau du protocole sous-jacent.
- CSRC : "Contributing source", certaines applications qui sont appellées des mixers combinents plusieurs flux de données RTP en un seul, pour savoir d'ou proviennent les différents flux, une liste de sources ayant contribué au flux est insérée dans l'en-tête du paquet RTP.
Le format d'un paquet RTP est le suivant :
V=2 2 bits
P 1 bit
X 1 bit
CC 4 bits
M 1 bit
PT 7 bits
Numéro de séquence 16 bits Horodate
32 bits Identificateur SSRC
32 bits Identificateurs CSRC
32 * (0-15) bits
… Données
…
Chaque ligne fait 32 bits, les 12 premiers octets sont toujours présents dans un paquet RTP alors que la liste des CSRC est seulement présente si elle a été insérée par un mélangeur.
La signification des différents champs est la suivante :
- Version (V) : identifie la version de RTP, la dernière étant la numéro 2. L'utilitaire vat (ancêtre de Vic) utilisait la version 0 de RTP et le premier draft (brouillon) sur RTP définissait la version 1 de RTP.
- padding (P) : si ce bit est posé alors le paquet RTP contient un ou plusieurs octets de remplissage à la fin du paquet qui ne font pas partie des données, le dernier octet du padding (bourrage) indique la taille de celui-ci.
- extension (X) : si ce bit est posé alors l'entête fixe RTP est suivie d'une entête d'extension qui peut être définie par l'utilisateur.
- CSRC Count (CC) : indique le nombre d'identifiants CSRC qui suivent l'entête fixe RTP.
- marker (M) : l’interprétation de ce bit est laissé à l'application, par exemple elle peut servir à définir le moment ou l'on change d'image lors de la diffusion d'une vidéo - payload type (PT) : indique le format des données RTP et donc leur interprétation par
l'application.
- Numéro de séquence : ce numéro est incrémenté de un à chaque paquets de données RTP envoyé, il peut être utilisé pour détecter des pertes ou reconstruire une séquence de paquets.
- Horodate : l'estampille contenue dans le paquet RTP indique l'instant auquel le premier octet de données à été encapsulé dans le paquet RTP. Elle doit être dérivée d'une horloge et doit augmenter de façon monotone et linéaire pour permettre une synchronisation.
- SSRC : identifie de façon unique la source sur laquelle il faut se synchroniser.
- liste de CSRC : le nombre de CSRC est donné par le champs CC. les CSRC sont insérés par les mixers.
Le format des paquets RTP doit rester simple et il est déconseillé d'essayer de faire du multiplexage sur les différents formats de données pour les raisons suivantes :
Ø Si deux flux de données partagent le même paquet RTP et donc le même identificateur SSRC et qu'il faille changer le type d'encodage de l'un des flux de données il ne sera pas possible d'identifier quel flux de données a changé son encodage
Ø Par définition un identificateur SSRC est relatif à un seul espace-temps et une seule numérotation des paquets. Si on multiplexe plusieurs types de données il faudrait disposer de plusieurs temporisations et plusieurs numérotations pour pouvoir identifier le flux de données ayant subit des pertes.
Ø Comme on va le voir plus loin, les rapports de réception RTCP sont relatif qu'à un seul timing et une seule numérotation par SSRC et ne précisent par le type de flux de données.
Ø Un mixer ne sait mixer qu'un seul type de données.
Ø Un paquet RTP contenant plusieurs types de données rendrait difficile : l'utilisation possible de différentes ressources réseau en envoyant par exemple les paquets contenant de la vidéo sur un lien différent de ceux contenant du son, le choix de la réception d'un sous ensemble des données multimédia (seulement le son par exemple) Ainsi l'utilisation d'une SSRC unique par média permet de remédier aux trois premiers points. On voit que la partie qui transporte les données du protocole RTP est assez simple, en effet toute sa complexité se situe dans le contrôle "temps réel" de ses données.
3.2.1.2. RTCP
RTCP (RFC 3550) est un protocole qui permet d'obtenir des informations diverses sur une session RTP en cours : nombre de participants, qualité de réception, départ ou arrivée d'un nouveau participant. C'est donc un protocole de Feedback qui se doit d'être extensible par rapport au nombre participants à une session, qu'ils soient dix ou quelques millions.
Ainsi RTCP transmet périodiquement des paquets de contrôle à tous les partic ipants d'une session.
RTCP a quatre rôles :
Ø La fonction première de RTCP est de fournir un retour sur la qualité de la distribution des données. Ce retour peut être utile pour l'adaptation dynamique de l'encodage lors d'une transmission et permet par exemple de déterminer si une mauvaise réception est globale ou locale à une session.
Ø Le protocole RTCP permet de transporter un identificateur qu'on nomme CNAME pour "canonical name". En effet SSRC peut changer lors d'une session par exemple si l'on se rend compte d'une collision de SSRC alors que CNAME ne change pas.
Ø Les deux premières fonctions nécessitent que tous les participants à une session RTP doivent envoyer des paquets RTCP ainsi la bande passante utilisée par les messages RTCP doit être extensible avec le nombre de participants à une session. Si chaque participant a une session envoie des paquets RTCP aux autres, il est possible de connaître le nombre de participants et ensuite de calculer le débit auquel il faut envoyer des messages de contrôle.
Ø La dernière fonction de RTCP est optionnelle et permet de fournir des informations de session minimales comme par exemple l'identification des participants à une session.
C'est particulièrement utile pour des applications ou il n'y a que très peu de contrôle des participants à une session.
Les différents types de paquets RTCP sont les suivants :
- SR : Sender Report indique les statistiques de réception et d'émission des participants à une session qui envoient des données.
- RR: Receiver Report indique les statistiques de réception des participants à une session qui n'envoient pas des données et dont les statistiques n'excèdent pas 31 sources.
- SDES : les éléments décrivant une source.
- BYE : indique la fin d'une participation.
- APP : fonctions spécifiques à l'application.
De la même manière que pour le protocole RTP chaque paquet RTCP contient une partie fixe et une partie variable, plusieurs paquets RTCP peuvent être concaténés dans un paquet de la couche inférieure (UDP par exemple) mais le premier paquet RTCP contenu dans un paquet de la couche inférieure doit toujours contenir des informations relatives aux statistiques de transmission ou de réception (paquets SR et RR) même lorsque des données ne sont pas reçues ou transmises.
3.2.2. La vidéo numérique, les formats
3.2.2.1. Les formats d’images vidéo
Avec l’avènement de la télévision deux standards de formats d’images vidéo sont apparus : le NTSC pour les Etats-Unis et une grande partie de l’Asie et le PAL pour l’Europe ou bien un dérivé du PAL comme le SECAM en France.
Ces deux familles regroupent chacune une diversité de variantes qui ont en commun la fréquence de rafraîchissement et le nombre de lignes qui composent l’image.
Pour des raisons techniques il a été choisi comme base de temps la fréquence du réseau électrique du pays concerné. Ainsi aux Etats-Unis, le secteur étant en 110V à 60Hz, la télévision utilise un rafraîchissement de 60Hz. En France nous sommes en 220V à 50Hz, le SECAM utilise donc un rafraîchissement de 50Hz.
Le standard NTSC propose une image de 525 lignes tandis que le standard PAL propose une image de 625 lignes.
Par la suite, avec l’avènement de la micro- informatique est apparu le format VGA (Video Graphics Array, tableau graphique vidéo) proposant une définition de 320x200 en 256 couleurs ou une définition de 640x400 en 16 couleurs, puis le SVGA (Super VGA, super VGA) proposant 4 définitions supplémentaires : 800x600, 1024x768, 1280x1024, 1600x1200 ainsi qu’une palette de couleurs allant jusqu’à 16 millions de couleurs.
Enfin avec le développement des applications de visioconférence est apparu le besoin de trouver un format commun à toutes ces applications et c’est l’UIT-T6 qui a défini, en 1990, deux formats couvrant les besoins exprimés dans les domaines de la visiophonie et de la
6 Union Internationale des Télécommunications – Secteur de normalisation des Télécommunications
visioconférence : les formats CIF (Common Intermediate Format, Format Commun Intermédiaire), QCIF (Quarter CIF, quart de CIF) et SQCIF (Sub-Quarter).
Le format d’image CIF est caractérisé par 352x288 points pour la luminance et par 176x144 points pour la chrominance. Le balayage est séquentiel et la fréquence d’image est de 29,97 Hz.
Le format d’image QCIF est caractérisé par 176x144 points pour la luminance et par 88x72 points pour la chrominance, avec une fréquence d’image sous-multiple de celle du format CIF, le SQCIF par 128x96 points.
Par la suite le format 4CIF est apparu, il correspond au double du format CIF et il est caractérisé par une taille d’image de 704x576 points pour la luminance et par 352x288 points pour la chrominance.
Le format d’image supérieur au 4CIF, le 16 CIF est caractérisé par 1408x1152 pour la luminance.
3.2.2.2. Les formats de compression de signaux vidéo
Afin de rendre compte d’un mouvement fluide il est nécessaire de transmettre au moins 25 images par seconde. Supposons que chaque image ait une dimension de 800x600 et que chaque pixel soit codé sur 8 bits, il faut alors un débit de :
25 x 800 x 600 x 8 = 96 Mbit/s
ce qui correspond au débit de la télévision à l’origine.
Pour la transmission par l’Internet du signal vidéo numérique il est donc nécessaire d’utiliser des techniques de compression afin de réduire le débit nécessaire.
Le principe utilisé est le suivant : la source procède à un encodage du signal vidéo, puis au niveau du récepteur un décodage du signal vidéo est réalisé.
Différents formats de compression ont donc été normalisés, parmi lesquels le fameux MPEG (Motion Picture Experts Group, groupe d’experts en images animées), néanmoins l’UIT- T a aussi émis des normes de codage vidéo pour des applications de visiophonie et de visioconférence comme la norme H.261 qui s’applique à des services audiovisuels utilisant des liaisons de p x 64 kbit/s (la norme H.261 est donc tout particulièrement adaptée pour des services audiovisuels utilisant des liaisons RNIS7) ou la norme H.263 qui vise à transférer de la vidéo sur des liaisons bas débit.
Bien que les deux normes de codage vidéo diffèrent, leur principe reste le même. Chaque image est découpée en blocs, puis on applique une transformée en cosinus discrète à chacun des blocs pris séparément. La sortie de chaque transformée est alors une matrice de coefficients transformés.
Ces normes de codage permettent donc de transmettre des images animées sur des liaisons à faible débit (moins de 128 kbit/s).
7 Réseau Numérique à Intégration de Services
3.3. Le multicast
3.3.1. Généralités
Une adresse multicast ne désigne pas une interface mais un ensemble d’interfaces. Un couple (adresse multicast, numéro de port) désigne un groupe multicast8.
Lorsqu’une application s’abonne à un groupe multicast elle reçoit toutes les données émises par tous les membres du groupe et à l’inverse lorsqu’elle émet des données à destination de ce groupe tous les membres du groupe reçoivent ces données.
Le multicast est donc une technologie tout à fait adaptée à un contexte de diffusion de groupe comme c’est le cas pour la visioconférence.
La source émet des paquets avec une adresse de destination qui est en fait un identifiant de groupe. Au niveau de ses routeurs IP, le réseau démultiplie les paquets de telle sorte que tous les postes récepteurs abonnés à cet instant à cette session en reçoivent chacun une copie.
Prenons l'exemple suivant : une station émet de la vidéo et 3 ordinateurs veulent recevoir le flux vidéo. Sur le schéma de gauche nous avons les différents flux émis avec de l'unicast et sur celui de droite nous avons le flux émis avec le multicast.
Le multicast permet de consommer moins de bande passante et diminue la charge des processeurs des stations émettrices puisque ces dernières ne doivent émettre qu'un flux de données.
8 Problème de vocabulaire : la diffusion multicast n’a pas de traduction acceptable en français. Le terme employé sera donc l’appellation anglophone multicast.
3.3.2. Rappels sur les adresses IPv4
Les adresses multicast sont celles qui correspondent aux classes D sur IPv4 224.0.0.0 - 239.255.255.255
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
1 1 1 0 Identification du groupe de diffusion
28 bits
Les 4 premiers bits valent 1110 indiquant une adresse multicast. Les 28 bits suivants identifient un groupe de diffusion particulier.
3.3.3. Adressage IPv6
Chaque pile IPv6 doit obligatoirement supporter le multicast (MLD9). L'objectif est de ne pas devoir créer de tunnels multicast comme ça a été le cas en IPv4.
Une adresse multicast a le préfixe ff00::/8 et la structure suivante:
F 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 SSM10positionnent ce champ à 3.
scope indique la portée de l'adresse IPv6. Cette fonctionnalité était gérée en IPv4 avec le champ time-to-live. Voici les différentes valeurs que ce champ peut prendre :
0 réservé 1 nœud 2 lien 5 site
8 organisation E global F réservé
group ID est l'identifiant de groupe. Certaines adresses sont prédéfinies. Ces adresses sont listées par le RFC 2375 On apprend par exemple que le groupe de tous les routeurs sur un lien est ff02::2.
9 Le multicast est expliqué plus en détail dans le chapitre 3.3.3
10 PIM SSM : protocole de routage multicast
3.3.4. Les protocoles IPv6
Le multicast nécessite pour fonctionner des protocoles qui interviennent à différents niveaux. Au niveau lien-local, un premier protocole nommé MLD (Multicast Listener Discovery) est nécessaire pour que les applications s'abonnent à des groupes auprès du routeur d'accès. D'autres protocoles interviennent au niveau inter-LANs. Ils permettent de créer des arbres de diffusion multicast en fonction des liens- local où il y a des abonnés. Ainsi, des domaines peuvent être créés entre les LANs qui souhaitent s'échanger du trafic multicast.
Des protocoles interviennent au niveau inter-domaines pour qu'il soit possible d'échanger du trafic multicast entre tous ces domaines.
3.3.4.1. Au niveau lien-local : Le protocole MLD (Multicast Listener Discovery - RFC 2710)
MLD (Multicast Listener Discovery) est le protocole de dialogue entre les stations et les routeurs pour la gestion des groupes multicast. Les applications utilisent MLD pour s'abonner ou se désabonner à un groupe multicast. Ce protocole intervient donc sur les parties terminales du réseau. Les messages MLD sont véhiculés dans des paquets ICMPv6 (protocole n°58 en décimal). Sur chaque lien- local, un seul routeur peut avoir le statut de demandeur11 MLD. C'est-à-dire que c'est le seul qui va gérer les messages MLD sur le lien- local. S'il y a plusieurs routeurs sur le lien, c'est celui qui a la plus petite adresse IPv6 qui est demandeur, tous les autres deviennent non-demandeurs.
Voici la structure d'un message MLD :
Type 8 bits
Code 8 bits
Checksum 16 bits Maximum Response Delay
16 bits
Reserved 16 bits
IPv6 Multicast Address 128 bits
Le champ type permet d'identifier 3 types de message MLD :
Multicast Listener Report : (type = 131 en décimal) Ce message est envoyé au groupe de tous les routeurs multicast sur le lien (adresse multicast ff02 ::2). Quand une application désire s’abonner à un groupe elle va émettre un message multicast listener report avec un champ « adresse multicast IPv6 » contenant l’addresse multicast du groupe dont elle veut faire partie.
Le routeur qui reçoit ce message rajoute une entrée dans sa table MLD si elle n’existait pas déjà et commence à diffuser sur le réseau local les données à destination de ce groupe.
Multicast Listener Done : (type = 132 en décimal) Quand une application veut quitter un groupe multicast, elle envoit ce message au groupe des routeurs multicast (adresse ff02 ::2) en spécifiant dans le champ « adresse multicast IPv6 » l’adresse IPv6 du groupe qu’elle veut quitter.
11 Querier en anglais
