Page de garde

Remerciements

Je tiens tout d’abord à remercier mon maître de stage, Jacques Prévost (GIP Renater et
trésorier de l’association Aristote), qui a su me conseiller, me guider et m’apporter les
réponses nécessaires au bon déroulement de mon stage. Dany Vandromme (Directeur du GIP
Renater) pour son accueil au GIP Renater ainsi que Didier Courtaud (Directeur de
l’association Aristote) 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 ainsi que Gilbert Sol, mon directeur d’étude au DESS Applications des Réseaux et
de la Télématique, et enfin Harouna Siby, ancien stagiaire Athena et étudiant au DESS ART.

Je remercie Kostya Kortchinsky, Philippe Bourcier et Bernard Tuy, pour leur aide technique
très précieuse.

Je remercie mes deux camarades stagiaires, aujourd’hui ingénieurs chez Renater, Jérôme
Durand et Pierre-Emmanuel Goiffon, ainsi que le petit dernier des stagiaires INSA de Lyon
IPv6, Ahmed Sahnoun, pour leur amitié et les bons moments passés en collaborant sur
différents projets.

Je remercie Sonia Zghal Kallel (Ingénieur au CCK Tunisie), Y.N Singh (Ingénieur,
enseignant à l’IITK en Inde), Bruno Roger et Oumar Samba Ba (Ingénieurs et enseignants à
l’ESMT de Dakar) pour leur collaboration dans le cadre du projet Athena.

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.

2
Sommaire

Introduction _______________________________________________________________ 5
Résumé ___________________________________________________________________ 6
I. Contexte ______________________________________________________________ 8
1. ARISTOTE __________________________________________________________ 8
2. RENATER___________________________________________________________ 9
a) Le Réseau National de Télécommunications pour la Technologie, l'Enseignement et
la Recherche _________________________________________________________ 9
b) Le GIP Renater ____________________________________________________ 13
3. Le projet ATHENA ___________________________________________________ 14
a) Description _______________________________________________________ 14
b) Partenaires________________________________________________________ 14
4. Objectif du stage _____________________________________________________ 19
II. Les technologies employées _____________________________________________ 20
1. IP multicast _________________________________________________________ 20
a) Généralités________________________________________________________ 20
b) Adressage ________________________________________________________ 21
c) Les protocoles _____________________________________________________ 22
2. Le protocole IPv6 ____________________________________________________ 25
a) Introduction _______________________________________________________ 25
b) Caractéristiques d’IPv6 ______________________________________________ 25
c) Nouvelles fonctionnalités du protocole IPv6 _____________________________ 26
d) Transition IPv4 - IPv6_______________________________________________ 27
e) Format de l’en-tête du datagramme IPv6 ________________________________ 28
f) En-têtes d’extensions ________________________________________________ 29
g) Adressage IPv6 et hiérarchisation des adresses ___________________________ 30
h) Généralités sur le routage : protocoles RIP, BGP, OSPF en IPv6 _____________ 31
i) Le serveur de nom __________________________________________________ 34
j) Nouveaux protocoles liés à IPv6 _______________________________________ 35
3. Visioconférence IP multicast____________________________________________ 35
a) Le temps réel ______________________________________________________ 35
b) Les outils du Mbone ________________________________________________ 37
III. Point d’avancement sur ATHENA ______________________________________ 39
1. Partenaires actuels ____________________________________________________ 39
a) Conventions de partenariats __________________________________________ 39
b) Validation du multicast ______________________________________________ 40
c) Evaluation du protocole IPv6 _________________________________________ 42
d) Accessibilité au multicast pour les partenaires, mise en place de passerelles ____ 42
2. Extension d’ATHENA, nouveaux contacts, actions menées ___________________ 44
a) Un point sur le projet EUMEDISCONNECT _____________________________ 44
b) CCK Tunisie ______________________________________________________ 44
c) MARWAN Maroc__________________________________________________ 51
3. Autres contacts ______________________________________________________ 51

3
 a) IITK INDE _______________________________________________________ 51
b) UDG Mexique _____________________________________________________ 53
IV. Mise en place d’une solution de visioconférence IPv6 multicast ______________ 55
1. Objectif ____________________________________________________________ 55
2. Contexte____________________________________________________________ 55
a) Le projet DIM _____________________________________________________ 55
b) Les Causeries du FMbone ____________________________________________ 55
c) IPv6 à l’ESMT ____________________________________________________ 56
d) Le GN6 __________________________________________________________ 57
e) Les réseaux de la recherche en Afrique__________________________________ 57
f) Le réseau IPv6 multicast, architecture des sites ___________________________ 58
3. Réalisation technique _________________________________________________ 62
a) Le routeur IPv6 multicast, configuration et fonctionnalités __________________ 62
b) Station en IPv6 multicast ____________________________________________ 73
c) Le serveur DNS ____________________________________________________ 77
V. Mise en place d’une passerelle de transcodage multicast - unicast pour la
visioconférence IP multicast : UTG _________________________________________ 83
1. Objectif ____________________________________________________________ 83
2. Contexte____________________________________________________________ 83
a) Nouveaux partenaires _______________________________________________ 83
b) Projet DIM _______________________________________________________ 83
3. Réalisation technique _________________________________________________ 83
a) Serveur UTG ______________________________________________________ 83
b) Station UTG ______________________________________________________ 92
c) Tests effectués _____________________________________________________ 98
Conclusion ______________________________________________________________ 100
Bibliographie ____________________________________________________________ 101

4
Introduction

L’expansion d’Internet dans les pays en voie de développement offre aujourd’hui un accès
beaucoup plus aisé à de grandes quantités de données et d’informations déjà disponibles dans
les pays industrialisés. De nos jours, un trop grand écart existe entre les systèmes d’éducation
des pays du « Nord » et ceux du « Sud ». Afin d’homogénéiser au mieux le partage du savoir,
le secteur de l’éducation peut maintenant compter sur les nouvelles technologies de l’Internet.
Ainsi, de nouveaux concepts apparaissent (universités virtuelles, campus électroniques,
téléenseignement, etc.) donnant la possibilité d’acquérir les mêmes connaissances que celles
transmises dans les pays industrialisés. Mais l’utilisation des télécommunications dans le
secteur de l’enseignement est surtout une solution au problème du manque de personnel
enseignant.

C’est dans ce cadre que le projet Athena a vu le jour au début de l’année 2001. Athena est un
projet promouvant des échanges interactifs dans le cadre du téléenseignement entre des sites
académiques français et d’Afrique francophone. Il s’agit donc d’une collaboration autour des
nouvelles technologies de l’Internet et en particulier la visioconférence. Le projet Athena est à
l’heure actuelle en pleine expansion (Sénégal, Tunisie, Maroc) et commence même à
s’étendre vers l’Inde, le Mexique et la Chine.

Le projet français Athena est basé sur le volontariat, la mise en place de collaborations
humaines et d’échanges interactifs, la volonté d’un partage culturel. L’expérience montre que
l’aspect d’échange et de volontariat privilégiant le contact humain est plus prometteur dans le
cadre d’une collaboration qu’un projet de simple mise en place de complexe de télé-
enseignement.

C’est donc après une première phase de recherche de partenariats conduite par Mr Harouna
Siby, alors stagiaire du DESS ART durant l’année scolaire 2000/2001, que j’ai intégré le
projet Athena pour rentrer dans une phase de développement intégrant la pérennisation des
techniques déjà utilisées, l’ouverture vers de nouvelles technologies et l’extension vers de
nouveaux contacts.

Mon travail s’est réparti sur deux axes, l’un concernant l’évolution des partenariats et donc un
aspect relationnel, l’autre concernant les techniques employées, leur utilisation et leur
développement dans la cadre des collaborations correspondant à un aspect technique du stage.
Nous verrons donc dans un premier temps les techniques employées dans le cadre d’Athena,
puis un point d’avancement dans un contexte relationnel du projet, et enfin les deux
principales parties techniques du stage, la mise en place d’une plate forme de visioconférence
en IPv6 multicast et la mise en place d’une passerelle de transcodage unicast – multicast.

5
Résumé

De part sa nature privilégiant le contact humain pour le partage des connaissances, basé sur le
volontariat et les nouvelles technologies de l’Internet, le projet Athena présente deux aspects
que sont le relationnel et la technique.

J’ai donc dans un premier temps eu à étudier les technologies qui allaient me servir tout au
long des échanges avec nos partenaires, les protocoles IP multicast (le Mbone) et IPv6, le
temps réel et la visioconférence en IP. Ceci m’a servi pour l’évaluation des solutions dont
disposent les différents partenaires dans le cadre de futures collaborations.

Etant arrivé dans une phase de développement et de recherche de partenariats, j’ai d’abord
pris contact avec les partenaires africains déjà présent dans le projet, l’ESMT 1 et l’UCAD2 à
Dakar au Sénégal. Nous avons ensemble validé les transmissions en visioconférence
multicast, par l’intermédiaire des cours DIM3, des séminaires X-Aristote 4, de la conférence
ATHENS5. Il s’agissait ici de s’assurer d’une bonne interactivité qui a notamment été
démontrée par les cours DIM, pour lesquels l’ESMT a donné un cours par visioconférence sur
la voix sur IP, et par la conférence ATHENS pour laquelle des spécialistes sénégalais de
l’UCAD ont fait une présentation par visioconférence de l’état actuel de l’Internet en Afrique.

Pour les nouveaux contacts que nous avons établi au courant de cette année, le point
intéressant a été d’évaluer les solutions qui se présentaient à eux. Le CCK6 en Tunisie, par
exemple, n’étant ni équipé du multicast ni du protocole IPv6, il a fallu évoluer dans un
schéma bien précis. Tout d’abord, pourquoi ne pas lui donner accès au multicast sans qu’il ait
pour autant à effectuer des manipulations de son côté, c’est là qu’une passerelle unicast -
multicast rentre en jeux puisqu’elle permet l’accès au multicast via un réseau unicast. Il faut
évaluer dans un premier temps les possibilités d’interactions en attendant de mettre en place le
multicast. En effet, avant une éventuelle connexion au multicast, il faut s’assurer que la
qualité de la liaison entre les deux entités soit assez bonne. J’ai donc eu à fournir des conseils,
des aides et effectuer des expérimentations pour valider les possibilités de partenariats.
L’ensemble des nouveaux contacts, motivés et volontaires ont montré leur détermination à
cette collaboration dans le cadre d’Athena. J’ai donc travaillé en collaboration avec le CCK en
Tunisie, Le MARWAN7 au Maroc, L’IITK8 en Inde, le pôle IPv6 de l’UDG9 au Mexique. Un
futur contact en Chine se développera durant l’année scolaire 2002/2003 et un séjour au GIP
Renater est organisé pour un ingénieur du CCK afin qu’il acquiert les connaissances
nécessaires à la mise en place et la supervision du multicast sur son réseau.

1
ESMT : Ecole Supérieure Multinationale de Télécommunications à Dakar
2
UCAD : Université Cheick Anta Diop à Dakar
3
DIM : Diplôme Informatique et Multimédia (cours en visioconférence entre divers formations universitaires)
4
Séminaires X-Aristote : Séminaires organisés par l’association Aristote sur les nouvelles technologies
5
ATHENS : Conférence en partenariat avec de grandes écoles européennes sur l’évolution des technologies de
l’Internet
6
CCK : Centre de Calcul El Khawarizmi de Tunisie (réseau pour l’enseignement et la recherche)
7
MARWAN : MARoc Wide Area Network, réseau pour l’enseignement et la recherche au Maroc
8
IITK : Indian Institute of Technology Kanpur
9
UDG : Université de Guadalajara au Mexique

6
Techniquement mon stage s’est réparti en deux parties, la première était la mise en place
d’une plate-forme IPv6 au sein du DESS ART de Jussieu, ceci dans le but de transmettre les
cours DIM en IPv6 multicast. La seconde était d’installer et d’expérimenter un service de
transcodage multicast – unicast grâce à une passerelle UTG. La plupart des nouveaux
partenaires n’ayant pas accès au multicast, il paraît important d’offrir ce service. Pour
effectuer des tests d’interactivité, le passage par UTG sans avoir à installer le multicast sur
son réseau (ce qui n’est pas négligeable en temps) est très intéressant. Offrir des services aux
nouveaux partenaires est une priorité, et c’est dans ce but que j’ai mis en place la passerelle et
qu’une passerelle de transition IPv4/IPv6 est en cours de mise en place.

Il se dégage maintenant plusieurs actions à mener en priorité pour la suite du projet. Tout
d’abord, des problèmes rencontrés avec UTG doivent être résolus afin d’offrir un service
stable. De plus la migration de la passerelle UTG vers IPv6 et sur plate-forme Intel est à
prévoir. Le manque de connectivité vers l’Internet pour les futurs contacts met en jeux la mise
en place d’un autre service de changement de débit. Une passerelle haut-débit / bas-débit
permettrait ainsi de diffuser de la vidéo à 2 Mbit/s sans pour autant pénaliser les partenaires
n’ayant que peu de bande passante (comme pour le MARWAN avec 64 Kbit/s). Ce dernier
projet provient de la volonté d’utiliser les outils du Mbone à haut-débit.

La poursuite et l’extension des contacts est bien sûr une des priorités du projet Athena,
d’ailleurs l’année scolaire 2002/2003 devrait voir se développer un partenariat avec la Chine.

7
I. Contexte

1. ARISTOTE

Aristote est une association régie par la loi 1901. Elle a été créée en 1984 par l'INRIA, le
CEA, EDF et le CNES puis 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 que - font ses
partenaires, et s’il y a lieu - 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.

Les membres sont soit des entités de recherche ou d'enseignement publiques ou privées, soit
des entités industrielles ou commerciales.
Ils sont répartis en trois catégories : titulaires, associés, correspondants. Ces trois catégories
bénéficient des mêmes possibilités de travail dans les groupes techniques et des mêmes tarifs
dans les séminaires et formations.

Voici les différents groupes de travail que présente Aristote : ATHENA, Calcul Scientifique
Distribué, C-SMIL (le club SMIL10 d’Aristote), C-UIML (le club UIML11 d’Aristote),
GIHM12, Multimédia, PIN13, Wapiti 14 .

10 SMIL : Synchronised Multimedia Integration Language

11 UIML : User Interface Markup Language
12 GIHM : Graphiques et Interface Homme Machine
13 PIN : Pérennisation des Informations Numériques
14 WAPITI : le WEB, ses Applications Professionnelles en Intranet et les Technologies de l’Information

8
 2. RENATER

a) Le Réseau National de Télécommunications pour la Technologie,

l'Enseignement et la Recherche

(1) Le réseau Renater et sa communauté d’utilisateurs

- Les utilisateurs :

Aujourd’hui plus de 600 sites ayant une activité dans les domaines de la Recherche, la
Technologie, l’Enseignement et la Culture sont raccordés au réseau Renater. Ce réseau leur
permet de communiquer entre eux, d’accéder aux centres de recherche publics et privés, aux
établissements d'enseignement du monde entier et à l’Internet.

- Le réseau Renater :

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.

- La partie métropolitaine du réseau :

Renater est basé sur une architecture distribuée : il comprend une épine dorsale nationale à
haut débit multi-Gbit/s - Renater 3 - qui fédère des réseaux de collecte régionaux développés
avec le soutien des collectivités territoriales dans le cadre de l’aménagement du territoire.

- Les points de présence outre-mer :

Renater dispose également de points de présence dans les domaines et territoires d’outre-mer.

- Les liaisons vers les autres pays et vers l’Internet :

Renater est interconnecté à 2.5 Gbit/s aux autres réseaux de recherche européens et
américains via le réseau pan-européen GEANT.

Une liaison directe de 155 Mbit/s avec les Etats-Unis est exclusivement dédiée à certains
projets de recherche prioritaires qui peuvent ainsi communiquer efficacement avec leurs
partenaires nord-américains via les réseaux des grands organismes scientifiques des Etats
Unis (vBNS, ESNET) à travers le nœud de communication scientifique STAR TAP à
Washington.

9
Une liaison de 20 Mbit/s aboutissant en Corée assure la communication avec les réseaux de la
recherche de la zone Asie-Pacifique, notamment celui du Japon.

La communication avec l’Internet, en France, est réalisée par le nœud d’échange SFINX,
auquel Renater est relié à 500 Mbit/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.

(2) Renater 3, épine dorsale de Renater

Avec Renater 3, les débits des liaisons de l’épine dorsale sont presque partout de 2,5 Gbit/s ou
davantage. 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.

Ces débits atteignent même 80 Gbit/s en Ile de France.

10
11
 (3) Les services proposés par Renater

Au niveau des points d'accès régionaux à son épine dorsale, Renater propose de nombreux
services :

- Des services de réseau IP performants :

Un service de bout en bout avec qualité garantie et un guichet unique pour l’ensemble du
territoire national, un service IPv4 conventionnel permettant d’accéder aux communautés de la
recherche et de l’enseignement, nationales et internationales ainsi qu’à l’Internet, un service
de réseaux privés virtuels permanents (VPN) ou à la demande (VP) entre sites, avec une
qualité de service garantie de bout en bout.

- Des services de réseau avancés :

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 : RNRT, RNTL, 6e Programme Cadre…un service de diffusion IPv6
(multicast), également utilisé pour la visioconférence et le téléenseignement,

Un accès à des contenus pédagogiques et culturels via une boucle à 2,5 Gbit/s reliant des sites
à fort contenus culturels. Ces services peuvent être utilisés par tous les organismes et sites de
la communauté Renater si ceux-ci sont reliés aux points de présence, par des réseaux de
collecte régionaux qui les relaient.

La sécurité est également un thème fort de Renater : engagements et chartes de déontologies

signés par les organismes utilisateurs, mesures techniques spécifiques dans le réseau, CERT-
Renater y contribuent.

(4) Renater 3, une technologie de pointe :

- L’infrastructure : la fibre optique à des dizaines de Gbit/s :

Les technologies optiques, telles que le multiplexage de longueurs d'onde (DWDM),

permettent d'utiliser la fibre optique à très haut débit : dans une même fibre, ce multiplexage
permet de transporter plusieurs fois 2.5 Gbit/s, bientôt plusieurs fois 10 ou 40 Gbit/s. Ceci est
utilisé en particulier sur l’épine dorsale nationale de Renater 3 et dans la boucle optique qui
constitue la partie francilienne à 80 Gbit/s de Renater.

- IPv6 : la nouvelle génération de l’Internet :

IPv6 est la nouvelle version du protocole IP de l’Internet. Elle va prendre la relève de la

version 4, IPv4, au cours des prochaines années – et elle le fait déjà au Japon et en Asie-
Pacifique.
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.

12
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 et tout aussi performant.
Renater est même l’un des premiers au monde à proposer un service de diffusion (multicast)
sur IPv6, clé du développement de la visioconférence et du téléenseignement sur cette
nouvelle version de IP !

- Former et accompagner les utilisateurs pour qu’ils maîtrisent ces

technologies de pointe :

Les technologies des réseaux et de leurs utilisations avancées évoluent vite. En garder la
maîtrise n’est pas chose simple, même avec la compétence que l’on trouve dans la
communauté des utilisateurs de Renater. Pour les aider, Renater organise des actions de
formation ou d’accompagnement, et participe à d’autres actions animées par des experts de
cette communauté : présentations techniques en vidéo : Renater en vidéo, ainsi que des
séminaires virtuels : les Causeries du FMbone, et aussi des cours en partenariat avec le CINES à
Montpellier, et des conférences spécifiques : IPv6 en Octobre 2002 en partenariat avec Aristote et
partcicipation à la conférence JRES, et même un groupe de travail spécifique pour les
responsables réseaux d’organismes qui démarrent IPv6 …

b) Le GIP Renater

Le GIP Renater réunit de grands organismes de recherche et d'enseignement, ainsi que le

ministère en charge de l'éducation 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. Il est 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 GIP Renater est financé : par les contributions de ses membres, par des subventions
gouvernementales (et européennes pour certains projets spécifiques) et par les contrats passés
par les organismes utilisateurs non membres (y compris les ISP qui utilisent le service
SFINX). Ses dépenses concernent : les coûts de Renater 3 et des liaisons internationales, les
actions pilotes, le CERT, les services divers, les dépenses de fonctionnement, notamment les
coûts liés au personnel.

13
 3. Le projet ATHENA

Actions pour des Transmissions Harmonieuses et des

Echanges de Natures Académiques

a) Description

ATHENA est un projet mis en oeuvre par l'Association Aristote en association avec différents
partenaires pour l' étude et la validation de processus d'échanges interactifs via 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érom ou vidéocassette 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 en particulier 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ènement , 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 à contenus scientifiques consultables via Internet .

Ces échanges de contenus à caractères scientifiques avec des pays de l’Afrique francophone
contribue à 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 salle de cours dans beaucoup de pays africain pourrait être
compensée par cet enseignement à distance.

b) Partenaires

(1) Partenaires actuels

14
 - L’association Aristote et Renater que l’on à déjà définit auparavant :

- Université Paris VII Denis Diderot :

C’est le DESS Applications des Réseaux et de la Télématique dépendant de l’UFR

d’informatique qui participe au projet ATHENA.
Ce DESS, à travers le laboratoire Visio P7, est à la pointe dans les recherches sur les
technologies liées à la visioconférence.
Sa formation est ancrée sur la réalité du marché et la diversité des technologies, alliant :
Télématique, Télécommunications, Réseaux et Multimédia.

- Université d’Evry :

L’université d’Evry est représentée dans le projet Athena par le DESS Ingénierie
Documentaire et Multimédia. Les étudiants sortant de cette formation sont des informaticiens
capables de maîtriser à la fois les domaines techniques et organisationnels liés à la gestion, la
création et l'utilisation de l'information documentaire et multimédia dans des environnements
variés

- L’ESMT :

L'Ecole Supérieure Multinationale de Télécommunications (ESMT) située à Dakar, est née en

1981 de l'initiative de sept pays de la sous-région de l'Afrique de l'Ouest (Bénin, Burkina
Faso, Mali, Mauritanie, Niger, Sénégal, Togo), avec le concours de la coopération
internationale dans le cadre d'un projet du Programme des Nations Unies pour le
Développement (PNUD).
L'ESMT est maintenant une institution multinationale qui a pour vocation de former des
ingénieurs en télécommunications, spécialisés dans les domaines technique et commercial.
Elle accueille en formation initiale ou en formations continues des stagiaires issus des pays

15
membres et d'autres pays utilisateurs comme le Tchad, la Guinée-Conakry, le Burundi,
Djibouti, Madagascar, la Côte d'Ivoire, le Cameroun, le Congo...
L'ESMT offre également des possibilités de rencontres et d'échanges, en organisant des
forums, des séminaires et des réunions à l'échelle africaine et internationale tels que le forum
sur les radiocommunications mobiles regroupant opérateurs africains et consortiums
internationaux (1994 et 1997) ou le séminaire interrégional sur les techniques et usages de la
télématique (1996).

Les partenaires internationaux de l’ESMT sont :

- Le PNUD et l'UIT (Union Internationale des Télécoms) sont à l'origine de l'ESMT et ont
permis le développement de ses activités notamment par des experts pour la mise en place
des formations (dont celles des formateurs) et en permettant l'acquisition des équipements de
laboratoire et de divers matériels logistiques.
- La coopération avec la France s'est pratiquement mise en place dès la création de l'ESMT.
Elle s'est traduite par la mise à disposition d'experts (France Télécoms etc.), de CSN, d'aide au
développement des ressources humaines de l'école et de dons en matériels.
- L'appui de la Suisse à l'ESMT se manifeste de diverses manières : formation pédagogique
de formateurs, octroi de bourses d'études à des élèves, dons de matériels didactiques,
organisation en commun de séminaires. »
Dans le cadre de son programme d'appui institutionnel aux pays participant au projet
PANAFTEL-ACDI, le Canada soutient diverses actions (installations d'énergie solaire,
téléphonie rurale, transfert de compétences par des experts de CEGIBEL, etc. .).
L’ESMT est bénéficiaire du projet de création de centres d’excellence de l ‘UIT dans les pays
sous- développés. Le second centre en Afrique étant AFRATI située au Kenya.

- L’UCAD :

L'Université de Dakar a été créée le 14 février 1957. Elle a été inaugurée en décembre 1959.
Héritière de l'École africaine de Médecine qui avait été créée en 1915, l'Université de Dakar a
connu une longue évolution marquée en 1949 par la création d'un enseignement préparatoire
aux études médicales et par l'ouverture au début des années cinquante d'écoles supérieures
académiquement rattachées à l'Université de Bordeaux, puis érigées en 1957 en Facultés
indépendantes pour former l'Université de Dakar.
Devenue le 30 mars 1987, Université Cheikh Anta Diop de Dakar, l'Université Dakar est la
plus ancienne et la plus importante structure d'enseignement supérieur existant à l'heure
actuelle au Sénégal. En dehors des services administratifs centraux du rectorat, elle est
composée de trente établissements d'enseignement supérieur de recherche se répartissant
comme suit: Onze facultés, dix-neuf instituts d'université, ainsi que l'Ecole Inter- Etats des
Sciences et Médecine Vétérinaires qui dépend scientifiquement de l'Université.
C’est l’Ecole Supérieure Polytechnique rattachée à l ’UCAD qui participe au projet
ATHENA.
L’ Ecole Supérieure Polytechnique est repartie sur cinq départements: Génie Chimique, Génie
Civil, Génie Electrique, Génie Mécanique, et Génie Informatique qui participe à ATHENA.

- Le CIRAD :

16
Organisme scientifique français spécialisé en recherche agronomique appliquée aux régions
chaudes, le Cirad a pour mission de contribuer au développement rural des pays tropicaux et
subtropicaux par des recherches, des réalisations expérimentales, des actions de formation, en
France et à l'étranger, l'information scientifique et technique. Ses activités recouvrent les
domaines des sciences agronomiques, vétérinaires, forestières et agroalimentaires.

(2) Contacts en cours

- Le CCK :

Le CCK est un établissement sous la tutelle du Ministère de l’Enseignement Supérieur et

dépendant de l’Université de Tunis El Manar. Il a été créé en Octobre 1976 suite à
l’introduction de l’informatique en tant que discipline autonome dans les milieux
universitaires. Le Centre de Calcul El Khawarizmi a été désigné au mois de Juillet 1997
comme Fournisseur de Services Internet au profit des établissements d’enseignement
supérieur et de recherche.

La mission principale du Centre de Calcul El Khawarizmi est donc de mettre à la disposition

des enseignants, des chercheurs, des doctorants et des étudiants exerçant au sein des
institutions dépendant du Ministère de l’Enseignement Supérieur, les moyens et les services
nécessaires pour favoriser le développement de la recherche scientifique par l’informatique et
en informatique. Plus précisément, le CCK est appelé à offrir les principaux services
d’Internet à savoir : la messagerie électronique, la navigation sur le Web, Telnet, FTP,
l’hébergement des sites WEB. Il est aussi chargé de la gestion des ouvertures des comptes
Internet, des adresses IP, des ouvertures de domaines. Enfin, dans la mesure du possible, le
CCK s’occupe des configurations du matériel de connexion et d’accès ainsi que de la
supervision de la formation des utilisateurs.

17
 - Le réseau MARWAN :

Dérivant de l'expression MAROC Wide Area Network, MARWAN est un réseau

informatique national à but non lucratif, dédié à l'éducation, à la formation et à la recherche.

Sa mise en place, décidée par le Premier Ministre, est effectuée par le Ministère de
l’Enseignement Supérieur, de la Formation des Cadres et de la Recherche Scientifique ; le
Ministère de l’Education Nationale ; le Ministère du Développement Social, de la Solidarité,
de l’Emploi et de la Formation Professionnelle et le Secrétariat d’Etat auprès du Premier
Ministre, Chargé de la Poste et des Technologies de l’Information, en collaboration avec
Itissalat Al-Maghrib.

Ce réseau correspond à un choix stratégique qui consiste à fédérer l'infrastructure

d'information et de communication des établissements et à connecter ces derniers aux réseaux
internationaux équivalents. MARWAN facilite les échanges d'informations à l'échelle
régionale, nationale et internationale. Il permet la diffusion du savoir et offre également aux
établissements scolaires, universitaires et de formation professionnelle ainsi qu’aux centres de
recherches nationaux, la possibilité d'utiliser les technologies de l’information et de la
communication.

Le réseau MARWAN a pour objectifs :

• La généralisation de l’enseignement et l’amélioration de sa qualité par le

développement des différents modes d’enseignement et de formation à distance (Télé-
Enseignement, Télé Médecine…) ;
• Le développement de la recherche scientifique et technique grâce à la multitude des
formes de communications offertes par ce réseau et par la création de bases de
données et de bases documentaires spécifiques ;
• L’amélioration du transfert de technologie et de la coopération internationale en
connectant le réseau MARWAN aux autres réseaux internationaux similaires ;
• La généralisation et la vulgarisation de l’utilisation des technologies de l’information
et de communication par la couverture de l’ensemble des établissements
d’enseignement de formation et de recherche, de l’école à l’université, et sur la totalité
du territoire marocain ;
• L’amélioration et la rationalisation de la gestion des ressources par le partage et
l’échange de ces ressources et en réalisant d’importantes économies par le
remplacement des modes classiques de communication et de transfert et publication de
l’information par les Nouvelles Technologies de l’Information et de la
Communication ;
• La création d’emplois par la création de nouveaux métiers et nouveaux services autour
de ces Nouvelles Technologies.

18
Dans le même cadre d’Athena mais géographiquement plus éloigné, deux contacts ont été
établis :

- L’université de Guadalajara au Mexique :

L’université de Guadalajara a été fondée en 1792 sous le nom d’Université Royale de

Guadalajara.
C’est un organisme publique décentralisé du gouvernement de l´état de Jalisco, qui jouit de
son autonomie, de personnalité juridique et d´un patrimoine personnel. Ses objectifs sont de
former et d´actualiser des techniciens, lycéens, techniciens de carrières, universitaires de
carrières, et toutes les carrières qui requièrent un développement socio-économique ;
organiser, sauver, conserver, augmenter, diffuser la culture, la science et la technologie.

- L’Institut de Technologie de Kanpur en Inde :

L’institut Indien de Technologie de Kanpur est engagé dans la recherche et la mise en oeuvre
des nouvelles technologies. Il forme des scientifiques et des ingénieurs motivés et compétents.
L'institut célèbre la liberté de pensée, cultive la vision et encourage la croissance, mais
inculque également des valeurs humaines et le souci de l'environnement et de la société.
L'institut forme des bacheliers, des maîtres et des doctora,ts dans de diverses branches
technologiques et scientifiques. L’IITK a mis l’accent sur le recrutement d’un corps
enseignant compétent venant de différents points géographiques nationaux et internationaux,
ainsi qu’une sélection des étudiants indiens très strict.

Kanpur est un établissement technologique d'importance nationale pour l'éducation mais aussi
pour la recherche. Concernant les nouvelles technologies de l’Internet, l’IITK profite de
subventions du gouvernement, de projets, de personnes compétentes, étudiants et chercheurs.

4. Objectif du stage

Après une première phase de recherche de partenaires conduite par Mr Harouna Siby, alors
stagiaire du DESS ART durant l’année scolaire 2000/2001, ma mission était de développer
ces partenariats. Cette phase de développement du projet intégrait la pérennisation des
techniques déjà utilisées, l’ouverture vers de nouvelles technologies et l’extension vers de
nouveaux contacts.

19
II. Les technologies employées

Afin de prendre connaissance et comprendre les techniques employées pour la collaboration

avec les partenaires d’Athena, j’ai étudié les protocoles IP multicast, IPv6, les outils du
Mbone, les protocoles de routage et de temps réel. Voici des liens vers des présentations
vidéos qui m’ont beaucoup servis lors de mon apprentissage :

http://www.renater.fr/Video/Index.htm : IPv6, IP multicast, Mbone, Métrologie, QoS, DNS

http://aristote1.aristote.asso.fr/Presentations/ : Athena
http://aristote1.aristote.asso.fr/CSMIL/SMILtheque.htm : SMILthèques

ainsi que des présentations sous forme de transparents :

http://www.rennes.enst-bretagne.fr/~toutain/TutorialBudapest.htm (tutoriel on IPv6)
http://www.urec.cnrs.fr/cours/ (cours et tutoriaux de l’UREC15)
http://www.univ-valenciennes.fr/CRU/MBone/ (FMbone – définition)
http://www.res.enst.fr/~dax/conf/multicast/refer.html : IP multicast

1. IP multicast

a) Généralités

Les applications réseau fonctionnent pour une grande majorité dans le mode IP unicast : le
poste émetteur envoie des paquets IP dont chacun porte une adresse de destination explicite.
Le réseau transporte le paquet vers ce destinataire, et uniquement vers lui.
En multicast (ou diffusion de groupe), le réseau fonctionne d'une source vers un ensemble de
récepteurs. 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 E émet de la vidéo et 4 ordinateurs (R1, R2, R3 et R4)
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.

15
UREC : Unité REseau du CNRS

20
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. C'est une technologie vouée à un grand avenir à l'heure où l'on parle de radio et
même de télévision sur Internet. Ces diffusions se font aujourd'hui en unicast ce qui cause une
grande consommation de bande passante et qui nécessite des serveurs audio et vidéo
d'importante puissance.

b) Adressage

(1) IPv4

Les groupes d’hôtes sont identifiés par la classe D d’adressage IP. Les adresses de classe D
comportent pour les bits de poids forts « 1110 », ce qui donne en décimal une plage d’adresse
comprise entre 224.0.0.0 et 239.255.255.255.

Le format d’une adresse IPv4 multicast a le format suivant :

La plage 224.0.0.0 – 224.0.0.255 est réservé pour la diffusion sur le LAN. Quelques adresses
sont permanente, comme 224.0.0.1 qui est assigné pour tous les hôtes multicast du LAN,
224.0.0.2 pour tous les routeurs multicast du LAN, etc.

(2) IPv6

Les adresses IPv6 multicast comportent les bits de poids forts « 11111111 » ce qui donne en
décimal une plage d’adresse entre FF01:0:0:0:0:0:0:0 et
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF (cf. la partie sur le protocole IPv6).

21
Voici le format d’une adresse IPv6 multicast :

c) Les protocoles

Le multicast nécessite pour fonctionner des protocoles qui interviennent à différents niveaux.
Au niveau lien-local, un premier protocole nommé IGMP (Internet Group Management
Protocol) en IPv4 ou MLD (Multicast Listener Discovery) en IPv6 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.

(1) Au niveau lien-local

Ici, pour les explications, nous prendrons le protocole MLD en IPv6.

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. Sur chaque lien-local, un seul routeur peut avoir le statut de demandeur
(Querier en anglais) 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 qui est
demandeur, tous les autres deviennent non-demandeurs.

Il existe 3 types de message MLD :

Multicast listener report : Ce message est envoyé au groupe de tous les routeurs multicast sur
le lien (ff02::2). Quand une application désire s'abonner à un groupe, elle va émettre un
message multicast listener report qui contient l'adresse du groupe multicast dont elle veut
faire partie. Le routeur qui reçoit ce message ajoute une entrée pour le groupe multicast dans
sa table MLD si elle n'existe pas déjà et commencera à diffuser sur le LAN les données à
destination de ce groupe.

Multicast listener done : Quand une application veut quitter un groupe, elle envoie ce message
au groupe des routeurs multicast (ff02::2) en spécifiant dans un champ "IP Multicast Address"
l'adresse IP du groupe qu'elle veut quitter.

Multicast listener query : Il y a deux types de multicast listener query qui diffèrent par le
contenu du champ "IP Multicast Address"

General Query : utilisé par le routeur pour connaître tous les groupes auxquels sont
abonnées les différentes applications multicast sur le lien-local. Le champ "IP Multicast

22
Address" possède pour un General Query de valeur 0. Ce message est envoyé au groupe
multicast de toutes les stations sur le lien-local ff02::1)

Périodiquement, le routeur demande à toutes les stations sur le lien-local (groupe multicast
ff02::1) les groupes auxquels leurs applications sont abonnées. Quand elles reçoivent ce
message MLD, les stations déclenchent pour chacune des adresses multicast un compte à
rebours avec une valeur initiale aléatoire (comprise entre 0 et "Maximum Response Delay"
contenu dans le message MLD). Quand le compte à rebours d'une adresse est écoulé, la
station envoie un message multicast listener report pour ce groupe multicast si aucun report
pour ce groupe n'a été envoyé auparavant par une autre station. Ainsi, seule une réponse par
groupe est donnée.

G1 G1
A B
G2

3 Report (G1)

Report (G1) Multicast General Query

Report (G2) 1
2

Dans l'exemple ci-dessus, le routeur émet une requête générale. Des applications sur les
stations A et B veulent recevoir le trafic pour le groupe G1. La station A répond la première.
B voit que A a déjà répondu et annule sa réponse en attente. Si le routeur ne reçoit plus de
multicast listener report pour des groupes qu'il a dans sa table MLD, il supprime alors ces
groupes de sa table après un délai de l'ordre de 3 minutes.

Multicast-Address-Specific Query : utilisé pour savoir s'il y a des applications

abonnées à l'adresse multicast spécifique contenue dans le champ "IP 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.

A G2 B G1

3 Report (G1)

1
Done (G1) Multicast Specific Query (G1)
2
Dans cet exemple, une application multicast sur la station A quitte le groupe G1. Le routeur
envoie un specific query pour savoir s'il y a d'autres applications abonnées au groupe G1 sur
le lien. Une application multicast lancée sur B, qui est toujours abonné au groupe G1, envoie

23
alors un report pour le groupe G1 qui n'est donc pas effacé de la table MLD du routeur. Dans
le cas où seule une application sur la station A serait abonnée, le routeur n'aurait pas reçu de
report et aurait effacé le groupe G1 de sa table MLD.

(2) Au niveau inter-LANs (Domaine PIM)

Les LANs qui supportent le multicast peuvent se grouper en domaines afin d'échanger entre
eux du trafic multicast. Chaque domaine a une administration qui lui est propre. Les
protocoles de routage multicast inter-LANs ont été développés pour répondre aux problèmes
suivants :

Comment atteindre les membres des différents groupes de diffusion répartis sur tout un
domaine (arbres d'acheminement) ?
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 quels sont les
groupes que l'on souhaite recevoir ou ceux que l'on ne veut pas recevoir ?) ?

On peut actuellement répartir les protocoles de routage multicast en deux familles:

Ceux orientés «forte densité de clients» (dense-mode) comme DVMRP (Distance Vector
Multicast Routing Protocol) qui a aujourd'hui presque disparu, et PIM-DM (Protocol
Independant Multicast), plus récent. Ces protocoles supposent qu'il y a des membres des
groupes multicast sur la plupart des réseaux et que l'absence de membre 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 élagage en français). 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 du trafic multicast va passer son temps à
demander qu'on cesse de lui envoyer des flux multicast. C'est pour cela que cette approche a
presque disparu pour faire place au sparse mode.

Ceux orientés «faible densité de clients» (sparse-mode) comme PIM-SM (PIM Sparse-Mode).
Ces protocoles supposent, au contraire des précédents, que les membres de groupe 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 des différents groupes multicast du domaine. Ils
permettent aux sources et aux abonnés de se rencontrer sans inonder le réseau.

Le protocole PIM, comme son nom l’indique, repose entièrement sur la table de routage
unicast et ne nécessite pas de table de routage spécifique au protocole multicast comme c’est
le cas pour d’autres protocoles. Ceci suppose que les topologies unicast et multicast sont
identiques ce qui n’est pas le cas lorsque l’on a une architecture avec des tunnels. Dans ce cas,
on a recours à une table de routage spécifique au protocole multicast.

(3) Au niveau inter-domaines

24
Les domaines doivent pouvoir s'échanger entre eux le trafic multicast pour qu'il soit possible
de recevoir depuis n'importe quel site le trafic multicast de tout l'Internet. Deux protocoles
sont utilisés au niveau inter-domaine : MBGP (Multiprotocol BGP) et MSDP (Multicast
Source Discovery Protocol).

2. Le protocole IPv6

a) Introduction

L'explosion de l’Internet, dont la taille double tous les 12 mois, a deux conséquences :

- la consommation des adresses s'est fortement accélérée ces dernières années, et

l'on commence à parler d'épuisement des adresses IPv4 (la « fin du monde
IPv4 » est estimée aux environs de 2010 !)

- la taille des tables de routage des équipements qui doivent connaître toutes les
routes mondiales (full routing) est devenue gigantesque et n'est pas sans poser
quelques problèmes aux opérateurs de services IP.

Pour pallier ces difficultés inhérentes à la version actuelle du protocole (IPv4), un nouveau
protocole a été spécifié. Il doit permettre d'adresser un espace beaucoup plus grand (10 E+9
réseaux au moins) et fournir des techniques de routage plus efficaces (en lien avec un
adressage hiérarchique).

L'élaboration d'un nouveau protocole, qui a reçu pour nom IP version 6 (ou IPv6), pour
résoudre en premier lieu le problème d'adressage mentionné ci-dessus, a été l'occasion
d'inclure de nouvelles fonctionnalités qui faisaient défaut à son prédécesseur: la sécurité, le
support du temps réel et du multipoint ...).

Le rôle de l'IETF (Internet Engineering Task Force) a été prépondérant dans le processus
d'élaboration des spécifications du nouveau protocole. Il a d'abord fait publier un livre blanc
(RFC 1550) pour définir les fonctionnalités du nouvel IP. A l'issue d'un long travail d'analyse
et de débats, « les critères techniques pour choisir le nouvel IP » (RFC 1726) ont été publiés.
Trois propositions ont été retenues (sur les 21 recueillies), comme proches des critères
imposés. Il s'agit de CATNIP (Common Architecture for The Internet Protocol), SIPP (Simple
Internet Protocol Plus) et TUBA (TCP and UDP with Bigger Addresses).
Finalement, SIPP, moyennant un certain nombre de modifications, a été retenu.

b) Caractéristiques d’IPv6

(1) Le format des adresses a été au centre de vifs débats dans la phase de
sélection évoquée ci-dessus. Finalement c'est une adresse sur 16 octets qui a
été retenue (au lieu des 4 octets de IPv4).

25
Une partie de cette adresse est constituée de l'adresse MAC de l'équipement (6 octets). Enfin,
l'adressage est hiérarchique, c'est à dire qu'il est organisé par zone géographique et/ou par
prestataire de service...Cette organisation de l'espace d'adressage permet de réduire
considérablement la taille des tables de routage actuelles.

(2) L'en-tête du paquet IPv6 est fortement simplifié (7 champs au lieu de 14 dans
IPv4). Il inclut un champs d'extension pour les fonctionnalités optionnelles
(sécurité, source routing, ...).

Les options de IPv6 sont placées dans des en-têtes séparés, intercalés entre l'en-tête IPv6 et
l'en-tête de la couche transport.

c) Nouvelles fonctionnalités du protocole IPv6

- La sécurité, tant décriée ou réclamée, selon le point de vue où l'on se place,

est rendue par des fonctions d'authentification / intégrité des données
(SAID: Security Association Identifier, MD5...) utilisées entre les stations
source et destination.

- La fonction de confidentialité est réalisée par le chiffrement partiel

(données seules) ou complet du datagramme. Rappelons qu'en France, le
chiffrement est soumis à une autorisation préalable des autorités
compétentes. Pour plus de détails sur les mécanismes de sécurité retenus
pour IPv6 on peut consulter les RFC 1826 à 1829.

- le « Source Routing » ou routage en fonction de l'adresse de la source,

(IPv4 ne route qu'en fonction de l'adresse de destination) est implanté grâce
au SDRP (Source Demand Routing Protocol). Il permet le routage
différencié (ou « politique »).

- l'Autoconfiguration des équipements est rendue possible grâce à un

protocole antérieur à la spécification de IPv6 : DHCP (Dynamic Host
Configuration Protocol) (RFC 1541), qui est adapté. Cette fonctionnalité
vise à simplifier la phase de connexion d'un équipement au réseau, en
anglais "plug and play". Elle permet également de gérer la mobilité des
équipements en rendant aisée la (re)numérotation en cas de besoin.

- le Multipoint (ou multicast) est inclus nativement dans la spécification de

IPv6 pour les routeurs et les postes de travail. Cela signifie que dans le
monde IPv6 on peut se passer de mrouted sur les stations, et que le Mbone
n'a plus de raisons d'être: le trafic multipoint devient complètement
banalisé.

- les fonctionnalités de gestion des applications temps réel. Elle est rendue
possible par l'utilisation du champ d'en-tête « Flow Label », qui permet de
différencier certains flux de données par rapport aux autres. Cela nécessite

26
 la mise en oeuvre d'un mécanisme de contrôle, notamment sur les
équipements de routage, tel que RSVP (Resource reSerVation Protocol) par
exemple.

d) Transition IPv4 - IPv6

La transition de IPv4 vers IPv6, dont l'une des données majeures est la vitesse d'épuisement
des adresses IPv4, peut se découper en trois phases :

(1) phase où seuls des équipements IPv4 existent

On arrive aujourd'hui à la fin de cette phase, puisque de nombreux constructeurs proposent

déjà les premières versions d’ IPv6 pour les postes de travail et les routeurs (sans parler des
plates-formes de tests déjà en place).

(2) phase de coexistence d'équipements IPv4 et IPv6

Cette phase sera probablement très longue et caractérisera l'Internet des années à venir.

(3) enfin, phase où seuls subsisteront des équipements IPv6.

Les mécanismes de coexistence des équipements IPv4 et IPv6 dans la phase 2, sont d'une
importance extrême. Quatre techniques ont été spécifiées à ce jour, ce qui ne préjuge pas de
l'émergence d'autres possibilités :

- la « double pile IP » (dual stack), chaque équipement implante

complètement les deux protocoles IP (v4 et v6),

- l'encapsulation ou « tunneling » des paquets IPv6 dans des en-têtes IPv4

pour les acheminer à travers une infrastructure IPv4,

- des adresses compatibles IPv4,

- des passerelles de niveau application (ALG : Application Level Gateway).

27
 e) Format de l’en-tête du datagramme IPv6

(1) Version (« Version »)

Numéro de version du Protocole Internet (6) sur 4 bits.

(2) Classe du Trafic (« Traffic Class »)

Champ sur 8 bits relatif à la classe de trafic.

(3) Label du Flux (« Flow Label »)

Label sur 20 bits relatif au flux d’information.

(4) Longueur de la « Charge Utile » (« Payload Length »)

Entier non signé sur 16 bits. Longueur en octets de la charge utile, i.e., 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 partis de la charge utile, i.e., inclus dans le décompte de la longueur.)

(5) En-tête Suivant (« Next Header »)

Sélecteur sur 8 bits. 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

(6) Nombre de Sauts Maximum (Hop Limit)

Entier non signé sur 8 bits. Décrémenté de 1 par chaque nœud que le paquet traverse. Le
paquet est éliminé si le Nombre de Sauts Maximum arrive à zéro.

(7) Adresse Source (Source Address)

Adresse sur 128 bits de l’expéditeur initial du paquet.

(8) Adresse Destination (Destination Address)

28
Adresse sur 128 bits du destinataire projeté du paquet (qui peut ne pas être le destinataire
ultime, si un en-tête de routage est présent).

f) En-têtes d’extensions

Dans la nouvelle version 6 d'IP, des informations complémentaires sont codées dans des en-
têtes qui doivent être placés dans le paquet entre l'en-tête IPv6 et l'en-tête de la couche
transport. Il y a un petit nombre d'extensions d'en-tête, chacun identifié par une valeur de
« Next Header » distincte. Comme illustré dans les exemples suivants, un paquet IPv6 peut
comporter aucune, une ou plus d'en-têtes supplémentaires,

+------------------+------------------------
| En-tête IPv6 | En-tête TCP + données
| |
|En-tête Suivant |
| = TCP |
+-----------------+------------------------
+-----------------+-----------------+------------------------
| En-tête IPv6 | En-tête de | En-tête TCP + données
| | Routage |
|En-tête Suivant|En-tête Suivant|
| = Routage | = TCP |
+-----------------+-----------------+------------------------
+---------------+---------------+---------------+-------------
| En-tête IPv6 | En-tête de | En-tête de | fragment de
| | Routage | Fragmentation | l’en-tête TCP
|En-tête Suivant|En-tête Suivant|En-tête Suivant| données
| = Routage |=Fragmentation | = TCP |
+----------------------+----------------------+-----------------------+--------------------

A part une exception, les en-têtes d’extension ne sont pas examinés ou traités par un
quelconque nœud le long du chemin emprunté par le paquet, jusqu’à ce que le paquet
atteigne le nœud (ou l’ensemble de nœuds, dans le cas du multicasting) identifié par le
champ “ Adresse Destination ” de l’en-tête IPv6. Là, le démultiplexage normal à partir du
champ “ En-tête Suivant ” de l’en-tête IPv6 appelle le module pour gérer le premier en-tête
d’extension ou l’en-tête de plus haut niveau s’il n’y a pas d’en-tête d’extension. Le contenu
et la sémantique de chaque en-tête d’extension déterminent si oui ou non il faut poursuivre
l’analyse sur l’en-tête suivant. De plus, les en-têtes d’extension doivent être analysés dans
l’ordre exact où ils apparaissent dans le paquet ; un destinataire ne doit pas, par exemple,
commencer par chercher un type particulier d’en-tête d’extension et traiter cet en-tête avant
tous ceux qui le précèdent.
L’exception dont fait allusion le précédent paragraphe est l’en-tête des options sauts après
sauts (Hop-by-Hop Options Header), qui transporte les options qui doivent être examinées
et traitées par chaque nœud le long du chemin emprunté par le paquet, incluant les nœuds
source et destination. L’en-tête des options sauts après sauts, quand il est présent, doit
immédiatement suivre l’en-tête IPv6. Sa présence est indiquée par la valeur zéro dans le
champ “ En-tête Suivant ” de l’en-tête IPv6.

29
 Si, lors du traitement des en-têtes, un nœud atteint une valeur d’“ En-tête Suivant ” non
reconnue à l’intérieur de l’en-tête qu’il traite, il devrait éliminer le paquet et envoyer un
message ICMP “ Problème de Paramètre ” (ICMP Parameter Problem message) à la source
de ce paquet, avec un code ICMP de 1 (“ Rencontre d’un type d’En-tête Suivant inconnu ”
- “ unrecognized Next Header type encountered ”) et le champ “ Pointeur ” d’ICMP
contenant la position de la valeur inconnue à l’intérieur du paquet original. Il devrait être
fait la même chose si un nœud rencontre une valeur d’“ En-tête Suivant ” à zéro dans tout
en-tête autre qu’un en-tête IPv6.
Tout en-tête d’extension a une longueur multiple de 8 octets, dans le but de maintenir un
alignement sur 8 octets des en-têtes suivants. Les champs sur plusieurs octets à l’intérieur
de chaque en-tête d’extension sont alignés suivant leur propre longueur, i.e., les champs de
n octets de long sont placés tous les multiples entiers de n octets à partir du début de l’en-
tête, pour n=1, 2, 4 ou 8.
Une implémentation complète de IPv6 inclut l’implémentation des en-têtes d’extension
suivants :
Ø en-tête des options sauts après sauts
Ø en-tête de routage (type 0)
Ø en-tête de fragmentation
Ø en-tête des options de destination
Ø en-tête d’authentification
Ø en-tête d’encapsulation de charge utile sécurisée

g) Adressage IPv6 et hiérarchisation des adresses

Une adresse IPv6 est composée de 128 bits conte 32 bits pour IPv4. Le nombre d’adresses
IPv6 disponibles a été estimé entre 1564 et 3 911 873 538 269 506 102 adresses par mètre
carré (océans compris). On peut donc considérer le nombre d’adresses 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 :5d65 :e5c3 :32cf

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 peut donc s’écrire :

fedc ::400 :5d65 :e5c3 :32cf

L’objectif principal d’IPv6 a été de hiérachiser les adresses pour permettre de plus grands
agrégats et une réduction de la taille des tables de routage des routeurs de backbone.

30
Voici le schéma d’une adresse IPv6 :

001 TLA sTLA Res NLA SLA Interface ID

3 bits 13 bits 13 bits 6 bits 13 bits 16 bits 64 bits

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 address).
• 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. Cette partie de l’adresse IPv6 est attribuée par chaque Internet Registry
(entité allouant des blocs d’adresse IP et des préfixes IPv6 dans sa zone
géographique. Quand l’espace d’adressage assigné est épuisé, l’Internet
Registry se voit confier un nouvel espace par l’IANA (Internet Assigned
Numbers Authority).
• Les 6 bits suivants sont réservés pour pouvoir étendre la partie sTAL 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 hiérarchie 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 65536 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 routages 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.

h) Généralités sur le routage : protocoles RIP, BGP, OSPF en IPv6

Les principes de routage ne changent pas avec IPv6. Les travaux en cours consistent
principalement à les adapter aux nouveaux formats d’adresse. Ces protocoles de routage
profitent des propriétés maintenant incluses dans la nouvelle version du protocole IPv6
comme l’authentification ou le multicast.

31
 (1) Routage interne

Les protocoles dits de routage interne permettent une configuration automatique des tables de
routage. Les routeurs découvrent automatiquement la topologie du réseau et déterminent le
plus cours chemin pour atteindre un réseau distant. Les protocoles du routage interne
nécessitent une configuration minimale du routeur. Celui-ci doit connaître les réseaux
auxquels il est attaché.

- RIPng :

Les algorithmes appelés « distance vector », sont utilisés par le protocole de routage RIPv2
[RFC 2453]. Ils sont basés sur l’algorithme de Bellman-Ford et figurent parmi les premiers
algorithmes de routage interne utilisés dan l’Internet.

Les routeurs diffusent leurs tables de routage sur les liens auxquels ils sont connectés. Les
autres routeurs modifient une route dans leur table si la métrique reçue (dans ce cas le nombre
de routeurs à traverser pour atteindre une destination) est plus petite que celle déjà stockée
dans la table. Si une annonce de route n’est pas présente dans la table, le routeur la rajoute.
Ces modifications sont à leur tour diffusées sur les autres réseaux auxquels sont connectés les
routeurs. Elles se propagent donc sur l’ensemble du réseau. On montre que cet algorithme
converge et qu’en condition stable, aucune boucle n’est créée sur le réseau (c’est à dire qu’un
paquet ne sera pas transmis indéfiniment de routeur en routeur sans jamais pouvoir atteindre
sa destination).

Les tables sont émises périodiquement. Si un routeur tombe en panne ou si le lien est coupé,
les autres routeurs ne recevant plus d’information suppriment l’entrée correspondante de leur
table de routage.

RIPng est le premier protocole de routage dynamique proposé par IPv6 [RFC 2080]. RIPng
est une simple extension à IPv6 du protocole RIPv2 d’IPv4. Il en hérite les mêmes limitations
d’utilisations. De plus, l’agrégation des routes en IPv6 pose de nouveaux problèmes qui
nécessitent de configurer précisément les routeurs.

- OSPFng :

Le deuxième protocole de routage Internet, basé sur l’algorithme du plus court chemin
s’appelle OSPF (Open Shortest Path First).

Relativement plus difficile à mettre en œuvre, il est beaucoup plus efficace dans les détections
et la suppression des boucles dans les phases transitoires. Ce protocole est basé sur plusieurs
sous-protocoles. Le premier permet une inondation fiable du réseau. Chacun des routeurs
possède alors une copie des configurations de tous les autres routeurs présents sur le réseau.
Ils peuvent simultanément calculer le plus court chemin pour aller vers l’ensemble des
destinations.

Pour réduire la durée des calculs et surtout pour éviter un recalcul complet des routes à
chaque changement de configuration, OSPF offre la possibilité de découper le réseau en aires.

32
Une aire principale appelé backbone doit pouvoir relier toutes les autres aires. Les réseaux
trouvés dans les aires données sont envoyés aux autres routeurs en frontière d’aires.

OSPFng a été adapté à IPv6 en remplaçant la notion de sous-réseau par celle de liens. Les
informations d’adressages ont été retirées des formats de paquets et de LSA (Link State
Advertissement) afin de rendre le cœur d’OSPF indépendant du protocole réseau et de le
restreindre au transport d’informations sur la topologie. Dans le reste d’OSPF, le format des
adresses a été changé pour accepter des adresses IPv6. La notion de portée (lien, aire,…)
utilise le mécanisme de portée d’IPv6.

Un lien supporte plusieurs instances du protocole OSPFng ce qui permet de l’utiliser plus
facilement sur des liens partagés entre plusieurs domaines de routage. OSPFng utilise des
adresses lien-locales pour l’échange de paquets OSPFng sur les liens. Le mécanisme de
sécurité a été remplacé par les facilités d’authentification et confidentialité d’IPv6.

(2) Routage externe

La seconde famille de routage concerne le routage externe. Le terme externe vient du fait
qu’il s’agit d’un échange de tables de routage ente deux domaines d’administration distincts,
généralement entre un client et son fournisseur, un fournisseur et son transporteur
international ou entre fournisseurs ou transporteurs internationaux.

En IPv4 cette notion de domaine d’administration est représentée par un numéro de système
autonome (AS : Autonomous System).

Il n’est pas clair que cette notion sera encore utile en IPv6 puisque dans un plan d’adressage
hiérarchique, le préfixe peut jouer une notion équivalente au numéro d’AS.

Avec un protocole de routage externe, il ne s’agit plus de trouver la topologie du réseau, mais
d’échanger des informations d’accessibilité explicite entre routeurs configurés pour le faire.
Ceux-ci traitent les informations reçues pour éliminer celles qui ne sont pas pertinentes ou
contraires à la politique de routage définie pour le site. En effet, toute annonce de réseau par
un domaine implique qu’on accepte de router les paquets vers cette destination.

BGP-4 est le protocole de routage externe actuellement utilisé pour IPv4 (le numéro de
version 4, identique pour BGP et IP, est pure coïncidence). Dans le cas d’IPv6, deux
extensions de BGP4 ont été proposées : BGP4+ [RFC 2283] qui est un clone de BGP4
utilisant un transport TCP sur IPv6 et des nouveaux attributs pour coder les préfixes, et BGP5
qui, de plus, permet d’avoir des numéros de systèmes autonomes (AS) de taille variable.

Dans l’immédiat, BGP4+ s’est imposé car le seul nom de BGP5 rappelle trop de souvenirs
douloureux du passage de BGP3 à BGP4. Peu de nouvelles possibilités ont été introduites.
Les numéros d’AS utilisés pour IPv4 servent aussi pour IPv6.

BGP4+ introduit deux nouveaux attributs pour transporter des informations de routages autres
que les routes unicasts IPv4, en particulier des routes multicasts (BGP4+ sert ainsi de base au
routage multicast inter-domaines dans l’Internet dans le cadre d’expérimentations sur le nom

33
mBGP) et des routes pour d’autres protocoles, dont IPv6 qui est le seul réellement envisagé
dans les premières propositions.

Ces nouveaux attributs permettent d’annoncer l’accessibilité ou la non-accessibilité de

préfixes (NLRI Network Layer Reachability Informations dans la terminologie des protocoles
inetr-domaines). A un ensemble de NLRI est associé des attributs standards de BGP (comme
le chemin d’AS Autonomous Systems), la famille d’adresses, une sous-famille (unicast et/ou
multicast), une information sur le routeur à utiliser (next-hop) avec son adresse,
éventuellement son adresse locale au lien et une ou plusieurs adresses physiques.

i) Le serveur de nom

Depuis longtemps, l’utilisation des adresses numériques est déconseillée. La méthode normale
est d’utiliser un nom et de laisser au système le soin de faire la résolution du nom en adresse
IP. La taille des adresses IPv6, le fait qu’elles puissent être attribuées automatiquement ont
amplifié cette tendance. Les règles de configuration automatique relient l’adresse IPv6 à
l’adresse MAC de la machine. Si la carte Ethernet change alors l’adresse IP est modifiée.
Tout ceci rend fondamental le mécanisme de correspondance nom-adresse en IPv6. La
correspondance entre noms et adresses repose comme in IPv4 sur les fichiers (/etc/hosts), sur
le DNS, et éventuellement sur NIS/NIS+.

(1) Correspondance nom – adresse

- Les enregistrements AAAA

Le DNS est un mécanisme de bases de données réparties qui permet d’associer des
informations typées à des noms. Ainsi la correspondance nom – adresse en IPv4 est réalisée
en associant au nom de la machine un ou plusieurs enregistrements 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 établit la correspondance
entre le nom d’une machine et son adresse IPv4, l’enregistrement AAAA établit la
correspondance entre le nom d’une machine et son (ou une de ses) adresses(s) IPv6. Une
machine ayant plusieurs adresses IPv6 doit avoir plusieurs enregistrements AAAA. Toutes les
machines n’ont cependant pas leur place dans le service de nom :

Ø Les adresse de lien local,

Ø Les adresses compatibles IPv4,
Ø Les adresses IPv4 mappées.

- Format :

Le format textuel d’un enregistrement AAAA tel qu’il apparaît dans le fichier de
configuration de la base de données DNS est le suivant :
<nom> [ttl] IN AAAA <adresse>

34
 (2) Correspondance adresse-nom

La correspondance adresse IP->nom est traitée par le DNS en IPv4 grâce à des
enregistrements de classe IN et de type PR dans un domaine particulier in-addr.arpa.
De façon analogue, la correspondance entre une adresse IPv6 et le nom de la machine
associée est faite par un enregistrement de classe IN et de type PTR dans un domaine de nom
spécial, ip6.int. Une adresse est représentée par un domaine de nom dans le domaine ip6.int,
déterminé en prenant, en séparant chaque chiffre par un point et en rajoutant le suffixe
.ip6.int.

j) Nouveaux protocoles liés à IPv6

(1) Les nouveaux :

- RSVP : Resource ReSerVation Protocol, (RFC-2205)

- ND : Neighbor Discovery for IP version 6, (RFC-1970)
- IPv6 : Stateless Address Autoconfiguration (RFC-1971)

(2) Les protocoles rénovés:

- DHCPv6 : Dynamic Host Configuration Protocol for IPv6.

- pMTUv6 : Path MTU Discovery for IP version 6 (RFC-1981)
- OSPFv6 : Open Shortest Path First protocol for IP Version 6
- RIPng : Routing Information Protocol for IP version 6 (RFC-2080)

3. Visioconférence IP multicast

a) Le temps réel

On classe un grand nombre d’applications audio et vidéo sous l’appellation « temps-réel »

parce qu’elles nécessitent une transmission et une mise à disposition de l’information avec
des garanties temporelles.

Si l’on veut permettre une transmission et une reproduction effective de signaux numérisés
sur un réseau utilisant la sémantique IP il faut donc disposer de protocoles additionnels. En
effet, les datagrammes peuvent être dupliqués, retardés, ou arriver dans un ordre incorrect. La
variation dans le retard, la gigue, est particulièrement répandue dans les réseaux IP.

35
Chaque paquet transmis contiendra ainsi un numéro de séquence pour pouvoir traiter les
duplications de datagrammes et les erreurs de séquence mais aussi un horodatage (timestamp)
qui indiquera au récepteur à quel instant il doit présenter la donnée contenue dans le paquet.

Le protocole utilisé pour transmettre des signaux vidéo ou audio numérisés sur Internet est
RTP (Real-time Transport Protocole). Une des principales caractéristiques de RTP est de
permettre le transcodage (modification du codage d’un flux au niveau d’une station
intermédiaire) et le mixage (qui consiste à combiner en un seul flux des flux de données
provenant de plusieurs sources). Le protocole RTP a été conçu pour travailler avec du
multicasting IP, pour lequel la fonction de mixage est particulièrement adaptée. Imaginons,
par exemple, qu’une téléconférence regroupe plusieurs participants. Si on utilise de la
transmission point à point (unicast), chaque station doit envoyer une copie de chaque paquet
RTP à chacun des participants. En multicast, en revanche, la station n’envoie qu’un seul
paquet, qui sera transmis à chaque participant. Si l’on utilise, en plus, une fonction de mixage,
chacune des stations peut transmettre, en unicast, au mélangeur, qui combine les différents
flux en un seul, avant de retransmettre ce dernier, en multicast, à tous les participants.
Combiner le mixage et le multicast se traduit par une réduction substantielle du nombre de
datagrammes transmis à chaque participant.

RTP est un protocole de niveau application. Il s’appuie sur le protocole UDP, ce qui signifie
que chaque message RTP est encapsulé dans un datagramme UDP. L’avantage principal
d’UDP est la possibilité de parallélisme, un ordinateur peut avoir plusieurs applications
utilisant RTP sans qu’elles interfèrent.

RTCP, protocole de commande de RTP, permet une surveillance du réseau pendant une
session et l’établissement d’une communication hors bande entre les équipements
d’extrémités. Ainsi, une application peut choisir de réduire le débit de codage, en cas de
congestion réseau, ou un récepteur d’adapter la taille de son tampon de réception lorsque le
retard ou la gigue réseau changent. RTCP peut aussi être utilisé pour envoyer de l’information
en parallèle avec les données temps réel (par exemple des sous-titres avec un flux vidéo).

36
 b) Les outils du Mbone

(1) Généralités

Les outils du Mbone sont des utilitaires de visioconférence gratuit téléchargeable à partir du
site de l’UCL (http://www-mice.cs.ucl.ac.uk/multimedia/software). Plus précisément, ils
permettent de faire de la visioconférence, transmission de cours ou conférence en IP
multicast. En voici un aperçu :

Il existe cinq utilitaires composant les outils du Mbone, le premier est SDR ¬, il est destiné à
informer l’utilisateur de toutes les sessions multicast publiques existantes sur le Mbone, il
répertorie ainsi tout un nombre de sessions auxquels l’utilisateur peut participer. Lorsqu’il
veut joindre une session, une fenêtre s’affiche -, dans laquelle on a le choix entre plusieurs
médias (audio, vidéo…), en un tour de clique on se retrouve avec de nouvelles fenêtres.
Comme la fenêtre ®, pour l’utilitaire RAT correspondant au média audio, elle permet à deux
ou plusieurs participants de parler simultanément. La fenêtre ° est celle utilisée pour la vidéo
(utilitaire VIC), dans laquelle on retrouve toutes les vidéos de tous les participants émettant
une vidéo, la fenêtre ¯ est un agrandissement d’une des vidéos présente dans VIC. Enfin il

37
existe deux derniers outils appelés WBD (Whiteboard - tableau blanc partagé) permettant le
partage interactifs de schéma et NTE qui est un éditeur de texte permettant d’écrire sur un
même document partagé.

D’un point de vu « qualité de transmission », il faut indiquer que les outils du Mbone sont
sensibles à la gigue et aux pertes de paquets, mais pas au temps de transit, et que l’expérience
nous a montré qu’un temps de transit relativement élevé (1/2s) ne compromet pas du tout
l’interactivité entre individus.

(2) Utilisation des outils du Mbone

Les outils du Mbone sont disponibles sous de nombreux systèmes d’exploitations. Les plus
couramment utilisés sont Windows (98, 2000, XP), FreeBSD et Linux. Après téléchargement
et installation des utilitaires souhaités, il suffit de se mettre dans le répertoire d’installation et
de taper les commandes suivantes :

VIC : vic –t TTL addr/port

RAT : rat –t TTL addr/port
SDR : sdr

Idem pour NTE et WBD.

Dans le cas d’une visioconférence multicast, nous indiquons un TTL (Time To Live16), une
adresse de groupe et le port de destination.

Les outils du Mbone ont été développés pour faire de la visioconférence en IP multicast. Mais
il est tout à fait possible de s’en servir pour une visioconférence unicast. Prenons l’exemple de
« Bernard » voulant effectuer une visioconférence (VIC et RAT) avec « Jean-René ». Voici
les commandes à rentrer de chaque côté :

Du côté de Bernard :

VIC : vic [adresse IP Jean-René]/[port1]

RAT : rat [adresse IP Jean-René]/[port2]

Du côté de Jean-René :

VIC : vic [adresse IP Bernard]/[port1]

RAT : rat [adresse IP Bernard]/[port2]

16
Time To Live : Partie du datagramme IP donnant le nombre de saut (routeur) que le flux de données transmis à
le droit de passer. Si on donne un TTL de 63, cela correspond géographiquement à un rayon d’émission allant en
Europe, Afrique de Nord, USA. Pour un TTL mondial, il faut compter 127.

38
III. Point d’avancement sur ATHENA

Mon stage s’inscrivait dans la continuité de celui effectué l’année dernière par Mr Harouna
Siby, étudiant au DESS ART durant l’année scolaire 2000/2001. Ce dernier a conduit le projet
ATHENA dans une phase de recherche d’entités universitaires d’Afrique Francophone
susceptibles d’être intéressées par ce projet de développement de téléformations. Ses
recherches se sont concrétisées par deux premiers partenariats avec deux établissements
d’enseignement supérieur de Dakar. L’Ecole Supérieure Multinationale de
Télécommunications (ESMT) et l’Université Cheikh Anta Diop (UCAD). Le projet Athena
comptait alors deux partenaires du côté africain et cinq du côté français comprenant
l’association Aristote, Renater, le CIRAD, le DESS ART de Jussieu Paris VII et le DESS
IDM de l’Université d’Evry.

Ces partenariats gravitaient autour des nouvelles technologies de l’Internet permettant

l’utilisation de la visioconférence sur IP : le multicast, IPv6.

Les premières expériences avec Dakar qui se sont faites via RNIS ont donné des résultats de
transmission acceptables. Cependant, le RNIS s’est avéré une technologie trop coûteuse. C’est
ainsi que les expérimentations ont continué via le protocole IP multicast. Après mise en place
du multicast du côté de Dakar, des visioconférences en IP multicast ont pu se faire dans de
bonnes conditions (ex : retransmission du séminaire X-Aristote 17) et ont abouti sur le suivi des
cours DIM18 durant l’année scolaire 2001/2002. L’ESMT a d’ailleurs donné un cours portant
sur la voix sur IP suivit par les partenaires des cours DIM marquant ainsi le côté interactif du
projet Athena.

Le bilan pour la première année d’existence d’Athena était très positif et a donné lien à de
nouvelles actions rentrant dans une phase de développement, à laquelle j’ai participé,
intégrant la pérennisation des techniques déjà utilisées, l’ouverture vers de nouvelles
technologies et l’extension vers de nouveaux partenariats.

1. Partenaires actuels

a) Conventions de partenariats

Des conventions de partenariats ont été signées entre Renater et l’ESMT, Renater et l’UCAD,
Aristote et ESMT, Aristote et UCAD, le DESS ART et l’ESMT et DESS ART et UCAD.

17 Séminaire organisé par l’association Aristote se déroulant à l’Ecole Polytechnique.

18 Cours DIM : Diplôme Informatique et Multimédia, Cf. chapitre IV, partie 2)

39
 b) Validation du multicast

(1) Projet DIM

DIM est le diplôme d'ingénierie multimédia. C'est le partage en interactif de cours communs
organisés régulièrement le mardi après-midi et concernant les entités suivantes :

• DESS Ingénierie documentaire et multimédia de l'Université d'Evry Val d'Essonne

(UEVE),
• Option PAM de l'Institut National des Télécommunications à Evry (INT),
• DESS Applications des Réseaux et de la Télématique de l'Université Paris VII,
• DESS Technologies Nouvelles des Systèmes d’Information de l'Université de
Valenciennes et du Hainaut-Cambrésis (UVHC).
• L'Ecole Supérieure Multinationale de Télécommunications de Dakar (ESMT)
• Le GIP Renater qui apporte sa contribution au support technique de DIM : réseau et
service IP multicast, technologies de vidéo numérique sur IP.

Pendant toute l'année scolaire 2001 – 2002, chaque mardi après-midi était dédié à DIM : l'un
des partenaires émettait le cours, pour ses étudiants en présentiel et pour les étudiants des
autres sites DIM en téléprésence. Questions, débats regroupaient l'ensemble des étudiants, sur
place et à distance : DIM a réalisé une véritable salle de cours virtuelle à travers Renater.

Les objectifs que les partenaires de DIM se sont fixés initialement sont :

• Fédérer les enseignements, permettre un suivi distant et synchrone.

• Etendre les publics et les compétences : former plus d'étudiants à la fois,
• Mutualiser les efforts de conception de cours multimédia : répartition des
enseignements entre participants,
• Se conformer aux normes et aux standards, et contribuer à les promouvoir grâce à
l'utilisation qui en est faite dans l'opération de DIM,
• Démontrer la faisabilité opérationnelle d'une e-formation : aspects techniques, stabilité
opérationnelle.

(2) Tests Haut débit

Les tests hauts débits ont été effectué afin de tester la stabilité des outils du Mbone ainsi que
des différentes passerelles décrites dans la partie d), cf. en dessous. En collaboration avec
l’ESMT, des tests au niveau des outils du Mbone ont été réalisés et ont abouti à de bons
résultats, le seul problème venant du CPU des stations utilisées ne supportant pas à trop fort
débit l’acquisition vidéo.

(3) Les outils du Mbone

Jusqu’à présent, l’utilisation des outils VIC et RAT se sont surtout faites sous des systèmes
Windows. Le problème est que sous des systèmes Linux ou FreeBSD, les exécutables

40
téléchargés à partir du site de l’UCL ne se compilent pas correctement, le seul moyen pour
pouvoir les utiliser correctement est de retravailler soi-même les codes sources.

(4) Causerie du FMbone

Les Causeries du FMbone sont des conférences virtuelles interactives sur les aspects
techniques du réseau Renater, de ses services, de son environnement. Elles sont diffusées tous
les jeudis après-midi. Elles ont été suivies tout au long de l’année par l’ESMT.

(5) Séminiare X-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
X-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 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.

De même que pour les Causeries du FMbone, l’ESMT a suivi une grande partie de ces
séminaires.

(6) La conférence ATHENS

Cette conférence a pour but de présenter à une trentaine d'étudiants provenant de divers
instituts technologiques ou de grandes écoles de France et d'Europe de grands axes
d'évolution des technologies de l'Internet et d'importantes applications de la Société de
l'Information, et aussi de leur donner un aperçu des aspects légaux et des questions de
sécurité. Elle s’est déroulée du 19 au 23 novembre 2001.

Via transmission IP multicast, des spécialistes sénégalais de l’UCAD sont intervenus sur le
sujet de l’ « état d’Internet au Sénégal ».

41
 c) Evaluation du protocole IPv6

L’utilisation du protocole IPv6 pour les pays d’Afrique est particulièrement intéressant quand
on sait l’actuelle diminution d’allocation d’adresse IPv4. Ainsi, l’ESMT s’est équipé d’une
plate-forme IPv6, laquelle supporte aussi l’IPv6 mulitcast. L’ESMT est un des partenaires au
M6bone (réseau IPv6 multicast de test dans Renater) et a suivi avec succès le séminaire X-
Aristote de décembre 2001 en IPv6 multicast. A l’heure actuelle, l’ESMT ne possède qu’une
adresse temporaire IPv6.

La mise en place d’IPv6 au sein de l’UCAD est restée à l’étape de projet. Mais l’intégration
du nouveau protocole devrait être l’une des prochaines préoccupation de l’UCAD en terme de
réseaux.

d) Accessibilité au multicast pour les partenaires, mise en place de

passerelles

Grâce aux travaux effectués, des passerelles permettent de donner accès plus facilement au
multicast et donc à la visioconférence pour le téléenseignement à partir d’un réseau ne
supportant pas le protocole multicast, l’IPv6 ou ne présentant qu’un faible débit.

(1) Passerelle IPv4-IPv6 multicast

Une passerelle développée par Luc Beurton, de l’université de Bretagne Sud permet de faire
interagir les 2 versions de multicast (IPv4 et IPv6). En effet, cette passerelle convertit le flux
multicast IPv6 en un flux multicast IPv4 et vice-versa. Ainsi, on a pu prouver que la
communication entre les 2 communautés IPv4 et IPv6 marche parfaitement et que les 2 types
de multicast peuvent cohabiter.

42
 (2) Passerelle Haut/Bas débit

Beaucoup de pays en Afrique reste encore très peu desservis en terme de connexion à
Internet. Et c’est dans ce cadre que la passerelle Haut débit – Bas débit prend toute son
importance. Un très bon exemple est la connectivité du MARWAN qui n’est que de 64 kbit/s.
Cette faible bande passante est la raison pour laquelle les travaux communs entre Renater et le
MARWAN ce sont beaucoup moins développés qu’avec le CCK. Ainsi, le futur stagiaire du
DESS ART au GIP Renater sera chargé de développer une telle passerelle.

(3) Passerelle UTG

La passerelle UTG donne accès au multicast en visioconférence à des sites en unicast.

L’objectif était donc d’installer cette passerelle sur le réseau Renater afin d’ouvrir un service
permettant dans le cadre d’Athena d’adapter la technologie aux réalités des différents
partenaires d’ATHENA. Bien sûr cette passerelle pourra aussi bien être utiliser dans un autre
contexte qu’Athena.

43
 2. Extension d’ATHENA, nouveaux contacts, actions menées

a) Un point sur le projet EUMEDISCONNECT

EUro MEDiterranean Information Society CONNECTion

Ce projet est coordonné par DANTE19 en collaboration avec les réseaux nationaux de la
recherche des pays méditerranéen. Les objectifs de ce projet sont :

• De fournir aux pays méditerranéens une connectivité internationale au réseau de la

recherche européen GEANT20 et autres réseaux de la recherche
• D’augmenter les connexions internationales des réseaux de la recherche dans la
région méditerranéenne
• De favoriser une bonne pratique des réseaux en fournissant des services efficaces
dans chaque pays méditerranéen
• De s’assurer que les services réseaux et les structures internationales soient
soutenus après la fin du projet

Les secteurs auxquels s’applique le projet EUMEDISCONNECT sont l’éducation, la santé, le

e-commerce, l’industrie et l’innovation.

Les participants sont l’Algérie, Chypre, l’Egypte, Israël, la Jordanie, le Liban, le Maroc, les
autorités Palestiniennes, la Syrie, la Tunisie, et la Turquie.

Les NREN21 européen participants à EUMEDISCONNECT sont GRNET (Grèce), INFN

(Italie), REDiris (Espagne), RENATER (France).

b) CCK Tunisie

(1) L’Internet en Tunisie

La connexion Internet en Tunisie a connu des améliorations importantes. En effet, la liaison

nationale a évoluée de 19,2 Kbit/s en 1991 avec Eunet à 512 Kbit/s en 1996 avec Sprint Link
et en 1999 cette liaison était de 13 Mbit/s. Elle a atteint 40,5 Mbit/s avant la fin de l'an 2000.
Actuellement, la bande passante internationale est de 75,5 Mbit/s.
Un réseau Backbone national offre 7 points de présence (POP) et permet l'accès à Internet par
les technologies : ATM, Frame Relay, RTC, lignes spécialisées, X.25, RNIS et assure une
bonne qualité des services Internet sur tout le territoire tunisien.

19
DANTE : consortium qui regroupe les réseaux européens de la recherche
20
GEANT : Réseau multiGbit/s transeuropéen interconnectant les réseaux de la recherche nationaux européens
21
NREN : National REsearch Network

44
Dans le cadre d'une approche globale, visant à permettre l'accès du plus grand nombre aux
moyens modernes des télécommunications et grâce à des baisses tarifaires répétées, les
abonnés au réseau tunisien bénéficient de tarifs comparables aux meilleurs tarifs pratiqués par
les opérateurs à l'échelle de la Méditerranée (20 heures de communications locales à 12 dinars
tunisiens).
Un vaste programme d'action a démarré en 1997 visant la généralisation progressive de la
connexion au réseau Internet de l'ensemble des institutions universitaires et de recherche, des
lycées et des écoles préparatoires ainsi que la création de cyberespaces publics (Publinet) au
profit des jeunes promoteurs parmi les diplômés de l'enseignement supérieur et ce, pour
assurer une grande pénétration des services de l'Internet dans toutes les régions de la Tunisie
et toutes les couches sociales tunisiennes.

Il y a 7 fournisseurs de services Internet (FSI) pour le secteur public :

- ATI pour connecter les institutions publiques (Ministères, offices...)

- SOTETEL-IT (Institut régional des sciences informatiques et des télécommunications)
pour connecter les centres de recherches
- CCK (Centre de Calcul Khawarizmi) pour connecter les institutions universitaires
- INBMI (Institut National de Bureautique et de Microinformatique) pour connecter les
institutions relevant du Ministère de l'éducation
- CIMSP (Centre Informatique du Ministère de la Santé Publique) pour connecter les
institutions relevant du Ministère de la santé
- IRESA (Institut de la Recherche et de l'Enseignement Supérieur Agricole) pour
connecter les institutions relevant du Ministère de l'agriculture

45
 - Tunisie Telecom pour connecter les institutions relevant du Ministère des
Technologies de la Communication

Quelques chiffres sur l’Internet en Tunisie :

- Nombre d’internautes : 455000

- Nombre de site Publinets : 300
- Nombre de fournisseurs de services : 12 (7 publics et 5 privés)
- Nombre de comptes d’accès : 57000
- Taux de connexion des écoles :
o Secondaires : 100%
o Préparatoires : 40%
o Primaires : 10%
- Taux de connexion des universités :
o Education : 65%
o Administrations et entreprises : 18%
o Domicile : 15%
o Agriculture et santé : 2%

(2) Collaboration avec le CCK

Dans le cadre du projet EUMEDISCONNECT, une réunion s’est tenue au sein du GIP
Renater au courant de l’année 2002. C’est à cette occasion que le Centre de Calcul EL-
KHAWARIZMI de Tunis et le GIP Renater ont décidé de collaborer ensemble sur les projets
avancées en cours à Renater (IPv6, multicast, projet Athena).

(3) Actions menées avec le CCK

Les actions menées avec le CCK se sont effectuées en collaboration avec Sonia Zghal Kallel,
Ingénieur-chercheur au CCK. Ces actions ont pu êtres menées grâce à un premier contact
entre Mme Ben Ghezala, directrice du CCK et Jacques Prevost lors de la réunion Eumedi-
connect.

Comme prévu selon la définition des procédures de collaboration dans le projet nous avons
suivi le plan d’actions suivant :

Test de liaison Renater-CCK (visioconférence unicast VIC et RAT)

Test d’accès au multicast via UTG (Cf. partie V)
Mise en place du multicast au sein du CCK
Mise en place du protocole IPv6 au sein du CCK

- Tests de la liaison Renater-CCK (VIC et Rat en unicast)

Avant toute chose, une évaluation sommaire de la connexion entre Renater et le CCK a été
effectuée pour déterminé si un échange interactif était possible.
Tout d’abord, des traceroute ont été effectués durant le mois de juin et le mois de juillet afin
de se donner une idée de la stabilité de la liaison.

46
Les premiers résultats ont montrés un filtrage au niveau du CCK ne laissant passer une simple
requête ICMP (ping, traceroute). Après défiltrage, voilà les résultats synthétique des
traceroute effectués :

Round-trip time : environ 180 ms

Traceroute du 26 juillet 2002 :

47
Ces résultats montrent une certaine instabilité au niveau du réseau « Agence Tunisienne
Internet » où l’on peut observer des pertes de paquets ainsi que des temps de transit prohibitifs
chez un ISP en Angleterre.

Pour communiquer en visioconférence, des ports UDP doivent être ouvert de chaque côté.
Après obtention de mon côté d’une adresse non filtrée et l’ouverture des ports pour la station
de Sonia au niveau du routeur du CCK, des tests de visioconférence unicast par les outils VIC
et RAT pouvait enfin être possible.

Une visioconférence unicast entre les deux stations en utilisant les outils du Mbone a semblé
être le meilleur moyen de tester le chemin qu’empruntaient les données entre Renater et le
CCK puisque les utilitaires Vic et Rat peuvent fournir le taux de perte de paquet en temps
réel. Voici la copie d’écran d’une visioconférence unicast :

48
Durant cette session, la perte de paquet pour l’audio variait entre 0 et 5% (avec de temps en
temps des pointes vers 8%). Pour la vidéo, la perte de paquet se situait entre 0 et 3%. Il en a
résulté une visioconférence de bonne qualité, tant au niveau du média audio que du média
vidéo. En effet, VIC et RAT « récupèrent » correctement (sans trop de perte de qualité)
jusqu’à environ 3 à 5% de pertes.

Pour résumer, voici une représentation schématique de la manipulation effectuée :

49
 - Tests d’UTG

Dans un premier temps nous avons pensé à tester l’accès au multicast du CCK via la
passerelle UTG, plus de détails sont disponibles dans la partie V.

- Mise en place du multicast au CCK (tunnel entre le NIO de Renater et le

CCK)

Dans un premier, il est impératif que le CCK acquière les connaissances nécessaire à
l’établissement d’un tunnel avec Renater. Cela est du au fait que les techniciens du nœud
d’interconnexion de Renater ne doivent pas avoir un rôle de formateur au protocole multicast,
cela leur prendrait trop de temps. Dans le cas d’un problème quelconque, Renater veut
s’assurer que le CCK puisse maintenir sans aide le multicast sur son réseau.

J’ai donc indiqué à l’ingénieur du CCK une liste de RFC et de liens sur Internet à consulter
afin d’établir une base théorique solide et de pouvoir par la suite s’intéresser à la phase
pratique durant une semaine de visite à Paris du 7 au 11 octobre. Voici la liste que je lui ai
indiqué :

Tous les sites que j’ai indiqué au chapitre II m’ayant servi pour ma propre formation,
http://www.univ-valenciennes.fr/CRU/MBone/IPmulticast.pdf (présentation d’IP multicast)
http://www.crir.univ-avignon.fr/visio/pfe/protocoles/protocoles.htm (les protocoles multicast)

50
http://www.infres.enst.fr/~dax/guides/multicast/protocol.html (liste de RFCs et Drafts
concernant les protocoles pour le mutlicast)

- Le protocole IPv6

La mise en place du multicast devant attendre la venue de l’ingénieur du CCK à Renater et

l’acquisition de bonnes connaissances afin de bien superviser le multicast dans un réseau,
l’étape pour la mise en place de l’IPv6 n’interviendra qu’à partir de l’année scolaire 2002-
2003.

c) MARWAN Maroc

De même qu’avec le CCK, des relations avec M. Redouane Merrouch, responsable du comité
du MARWAN, se sont établies durant la réunion EUMEDISCONNECT au GIP Renater.
Malheureusement, le réseau MARWAN ne possède qu’une bande passante de 64 Kbit/s vers
l’international. Après quelques échanges, le MARWAN très intéressé par une collaboration
dans le cadre d’Athena, nous a proposé de reprendre des tests lorsque leur connectivité
passerait à 2 Mbit/s. Le passage à 2 Mbit/s devant intervenir au courant de l’automne 2002.

En attendant de nouveaux échanges, j’ai indiqué les différents sites pour s’informer sur les
outils du Mbone, le multicast, IPv6…

3. Autres contacts

a) IITK INDE

Suite à la visite d’une délégation indienne au ministère de la recherche et au GIP Renater, des
contacts se sont établis entre Renater et l’IITK (Institut de Technologie de Kanpur). Des
échanges ont abouti sur un projet de test de transmission en multicast entre l’IITK et Renater,
ceci dans le cadre d’un séminaire se déroulant à l’IITK.

Avant d’établir une connexion multicast entre l’IITK et Renater il fallait s’assurer de la
qualité de la liaison (traceroute, visioconférence unicast avec VIC, RAT et NTE).

Dans un premier temps les traceroutes ont révélé un round time trip d’environ 500 ms avec
0% de perte de paquets. Ces valeurs restant constantes, nous avons effectué une
visioconférence unicast via VIC, RAT et NTE dont voici une copie d’écran :

51
Les résultats de cette visioconférence ont présenté une bonne qualité vidéo ainsi qu’une très
bonne audibilité de par la perte de paquets très faible. Ces résultats positifs obtenus au début
du mois d’Août m’ont amené à demander rapidement une connexion via un tunnel en
multicast entre l’IITK et Renater puisque le projet de retransmission en multicast devait se
dérouler le 7 Août.

Après accord de Bernard Tuy, responsable du service IPv4 multicast de Renater, j’ai pu
collaborer avec le technicien au nœud d’interconnexion de Renater pour mettre en place ce
tunnel.

Je tiens à signaler que pour la mise en place d’un tunnel multicast avec Renater, l’entité
extérieure concernée doit avoir des connaissances suffisantes pour un maintien personnel du
multicast sur son réseau. Ceci était donc le cas de l’IITK, puisque leur réseau faisait déjà
l’objet d’une utilisation du multicast en local et à l’intérieur de leur système autonome
(utilisation de DVMRP, PIM).

Après plusieurs propositions enter Renater et l’IITK, nous avons opté pour la mise en place
d’un tunnel mBGP entre le routeur ERNET (réseau pour la recherche en Inde) et le routeur de
Renater. L’autre solution étant d’installer un tunnel à route unique entre l’IITK et Renater en
utilisant PIM.

Par manque de temps l’objectif n’a pu être atteint à temps. Mais cette première collaboration a
abouti sur une volonté de partenariat en terme de télé-enseignement. Dans l’attente d’une
stabilisation du tunnel mBGP entre Renater et IITK et de tests positifs pour le multicast, des

52
propositions de collaborations pourront se formuler et peut-être donner jour à des cours dans
le même cadre de DIM mais en anglais.

b) UDG Mexique

Au sein de l’Université de Guadalajara, une cellule chargée de s’occuper du déploiement du

protocole IPv6, en collaboration avec d’autres universités mexicaines et entités publiques
(réseaux…), s’est mise en relation avec Renater afin de se connecter au M6bone.

Pour le moment, notre contact « Netzahualcoyotl Ornelas Garcia VOL » s’est inscrit à la liste
de diffusion du M6bone. La mise en place d’un routeur IPv6 multicast sous FreeBSD est
l’étape suivante avec la demande d’une adresse pour un tunnel entre son routeur et le routeur
central du réseau M6bone.

A l’heure actuelle, l’UDG a accès au réseau mondial 6bone via un tunnel IPv6 dans IPv4 vers
le CERN en Suisse. Ce dernier étant connecté via le réseau GTPv6 au service IPv6 de
Renater, une liaison IPv6 est d’ors et déjà existante entre Renater et l’UDG.

Il s’agit maintenant de mettre en place un tunnel 6IN6 (IPv6 dans IPv6, le multicast IPv6
encapsulé par l’IPv6 unicast).

En ce qui concerne la liaison entre Renater et UDG, des traceroutes donne un Round Time
Trip de 195 ms en IPv4 et de 215 ms en IPv6. On observe une perte de paquet nulle et une
gigue quasi-inexistante (l’écart entre le RTT minimum et le RTT maximum est au maximum
d’1 ms sur un grand nombre de traceroute effectué) dans le cas d’IPv4 mais aussi dans le cas
d’IPv6. Nous pouvons expliquer cette bonne qualité de transmission par le passage des
données dans des réseaux tels que Renater, GEANT, Abilène (Internet 2 au USA). Voici deux
tracroutes effectués en IPv4 et en IPv6 :

53
Ce traceroute en IPv6 nous monte qu’il existe une liaison entre UDG (3ffe:0120::0:2) et le
CERN (2001 :660 :1102 :1003 ::2).

Ces résultats très satisfaisant s’avèrent prometteurs quant à une future collaboration en télé-
enseignement dans le cadre d’Athena.

54
IV. Mise en place d’une solution de visioconférence IPv6 multicast

1. Objectif

Cette partie du stage était consacrée à la mise en place d’une solution de visioconférence IPv6
multicast au sein du réseau Artémis du DESS ART de Jussieu, partenaire au projet ATHENA.

2. Contexte

a) Le projet DIM

L’idée est de retransmettre les sessions DIM en IPv6 multicast. Il y a deux raisons à cela, la
première est d’utiliser une technologie nouvelle et de montrer l’évolution de la transition vers
IPV6 via l’usage d’applications de plus en plus nombreuses en IPv6. La seconde tient du fait
que la distribution d’adresses réseaux en IPv4 est de plus en plus faible et cela se ressent
d’autant plus en Afrique. Ainsi, l’utilisation d’IPv6 pallie ce problème, l’exemple le plus
typique est la mise en place d’une plate forme de visioconférence en IPv6 multicast au sein de
l’ESMT.

b) Les Causeries du FMbone

De même que pour le projet DIM, les Causeries du FMbone se verront diffuser en IPv6
multicast. Ceci, avec l’intégration de la passerelle IPv4/IPv6 vu auparavant, permettant la
bonne réception au sein des deux communauté IPv4 et IPv6. Un plate-forme servant pour les
Causeries du FMbone ainsi que pour les séminaires X-Aristote est en cours de configuration.
Voici une représentation schématique du fonctionnement de cette plate-forme :

55
 c) IPv6 à l’ESMT

« IPv6 permet d’étendre les possibilités réduites données à l’ESMT par le manque
d’adressage d’IPv4 »

L’ESMT utilise deux stations IPv4 pour ses visioconférence sur le Mbone. Le problème est
que son préfixe IPv4 ne permet pas d’augmenter le nombre de stations dédiées à la
visioconférence. En effet, un des projets de l’ESMT est de répandre des applications de
visioconférence dans la globalité de l’école, pour cela, le protocole IPv6 constitue la solution
adaptée à ce problème d’adressage. Ainsi, plusieurs salles pourraient accueillir des
visioconférences et rendre cet outil plus utilisé au sein de l’ESMT.

C’est dans ce cadre que nous avons expérimenté au sein du DESS des visioconférences en
collaboration avec l’ESMT, puisqu’en effet l’ESMT participe activement au programme
DIM.

L’ESMT utilise de plus une translation d’adresse (NAT22), ce qui perturbe les sessions de
visioconférence. L’utilisation d’un NAT devenant inutile avec IPv6 la qualité de
transmissions et donc une participation en tant qu’orateur dans les sessions DIM de l’ESMT
deviendrait plus opérationnelle.

22
NAT : Network Address Translation

56
 d) Le GN6

Le GN6 est un groupe de travail qui met ensemble, à leur demande, des acteurs « réseau »
des organismes de la communauté Renater . Ses objectifs sont de :

- permettre de s’initier à le 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 devront ê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.

Les actions du GN6 sont complémentaires de celles du G6. Schématiquement :

- le G6 réunit des experts français pour étudier et recommander des stratégies concernant IPv6
au niveau national,
- le GN6 réunit des néophytes (pour ce qui est de IPv6) qui veulent démarrer une activité IPv6
dans leurs organismes ou institutions, et auxquels les experts du G6 n’ont peut-être pas la
possibilité de consacrer – individuellement – autant de temps qu’ils le désireraient. Une des
actions du GN6 est donc de contribuer au transfert de savoir-faire des experts du G6 vers les
organismes de la communauté Renater.»

Afin de mettre à disposition des membres du groupe des informations sur le protocole IPv6,
j’ai établi des Foires à Questions, une pour le protocole IPv6 en unicast et une pour le
protocole IPv6 en multicast, cette dernière est surtout basée sur l’utilisation d’une station
FreeBSD en tant que routeur IPv6 multicast.

e) Les réseaux de la recherche en Afrique

De même que pour l’ESMT, mais ici il s’agit de réseaux nationaux, la mise en place du
protocole IPv6 est devenue une action importante pour les prochaines années. Avec
l’augmentation de la bande passante grâce au projet EUMEDISCONNECT, on peut prédire
une amélioration considérable dans les prochaines années de la connectivité à Internet des
pays méditerranéens. De plus, pour les même raisons que pour lESMT, le protocole IPv6 est
la solution au manque d’allocation d’adresses IPv4 en Afrique. C’est dans ce cadre que le
CCK en Tunisie et le MARWAN au Maroc souhaite mettre en place sur leur réseaux le
protocole IPv6.

57
 f) Le réseau IPv6 multicast, architecture des sites

(1) Topologie du réseau IPv6 multicast de Renater, le M6bone

Le réseau de test « M6bone » a été mis en place dans le but d’établir un service multicast sur
IPv6 (Cf. http://mother6.ipv6.renater.fr/xcast/ ).

L'implémentation des protocoles de routage multicast IPv6 est encore très limitée dans les
routeurs commerciaux. La solution a été de mettre en œuvre un réseau de tunnels avec des
équipements d'extrémité qui supportent le multicast IPv6. Le protocole de routage multicast
déployé sur l'ensemble du réseau est PIM Sparse Mode compatible PIM SSM23. Les sites qui
le désirent peuvent gérer MLDv224 et PIM SSM (qui est compatible avec PIM SM). Le cœur
du réseau supporte ces 2 protocoles de routage multicast afin de délivrer les 2 services aux
sites distants (chacun étant libre de gérer ou non PIM SSM et MLDv2).

Cette topologie de tunnels a été réalisée à l’aide de PC FreeBSD transformés en routeurs IPv6
multicast. Avant de rentrer dans les détails de la mise en place d’une plate-forme de
visioconférence au sein du réseau Artémis (réseau pour le DESS ART de Jussieu), qui s’est
faite à l’aide d’un PC FreeBSD, il faut signaler que depuis Mars 2002, une implémentation
IPv6 multicast fonctionne sur les routeurs 6WIND25. Ainsi, c’est avec un routeur 6WIND
qu’a été réalisée la retransmission du séminaire X-Aristote du 6 juin 2002 dont voici une
représentation schématique :

23
PIM SSM : PIM Source Specific Multicast
24
MLDv2 : Nouvelle version du protocole MLD
25
6WIND : Constructeur de matériels réseaux d’accès IPv6

58
(2) Les sites déjà connectés à ce réseau

- Sites français :

59
 - Sites à l'étranger :

(3) Les différentes topologies de réseau pour accéder au réseau M6bone

Prenons l’exemple d’une visioconférence, il existe trois possibilités de se connecter au

réseau M6bone et d’avoir accès à la visioconférence en IPv6 multicast :

60
Plus de précisions sont disponibles à l’adresse http://sem2.renater.fr

(4) Topologie du site Artémis

Le site Artémis a accès au multicast en IPv4.

Dans notre site, il faut ajouter un PC FreeBSD (nous verrons par la suite pourquoi nous avons
choisi un système FreeBSD) qui jouera le rôle de routeur multicast IPv6 ainsi que de
passerelle IPv6. Ce routeur prendra en charge le trafic multicast et unicast. Il doit donc
envoyer des paquets "Router Advertisement".

L’utilisation d’une encapsulation IPv6 dans IPv4 par l’intermédiaire d’un tunnel permettra de
se connecter au réseau M6bone de RENATER (par le routeur central X-cast).

61
 3. Réalisation technique

a) Le routeur IPv6 multicast, configuration et fonctionnalités

(1) Demande d’adressage auprès de Renater

Pour obtenir un préfixe de réseau IPv6 il faut s’adresser au Point d’Interconnexion Régional,
pour ce faire, il suffit d’aller à l’adresse suivante et de suivre les instructions
http://www.renater.fr/Services/IPv6/Index.htm.

(2) Les OS disponibles pour le routage en IPv6

Voici deux tableaux permettant de voir les possibilités en matière d’IPv6 que donne les
différents systèmes d’exploitations :

62
63
 (3) Choix de l’OS : FreeBSD

FreeBSD est un système d'exploitation de type Unix fonctionnant notamment sur compatibles
PC Intel et systèmes Alpha. Son utilisation est libre de tout droit et l'intégralité du code source
est disponible gratuitement. Le développement est assuré par des centaines de programmeurs
et d'utilisateurs collaborant par l'intermédiaire de l'Internet.

FreeBSD offre aujourd'hui des fonctions avancées pour le réseau, les performances, la
sécurité et la compatibilité qui sont encore absentes d'autres systèmes d'exploitation, y
compris certains des meilleurs systèmes commerciaux.

La dernière version de FreeBSD est la 4.5, c’est celle que l’on prendra pour la réalisation du
routeur X-cast IPv6.

Cf. le site officiel de FreeBSD : http://www.freebsd.org.

Ce site est aussi disponible en français (http://www.freebsd-fr.org/index-trad.html), mais

attention quelques parties sont obsolètes, il vaut mieux se référer au site anglophone, surtout
pour le guide d’utilisation.

(4) Installation de FreeBSD

Toutes les instructions pour l’installation de FreeBSD sont à l’Url suivante :

http://docs.freebsd.org/handbook/fr/4.1.1R/install.html

Pour l’installation par FTP, la première chose à faire est de créer deux disquettes de boot.

Pour les récupérer, on télécharge fdimage.exe de :

ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.5-RELEASE/tools/.

Puis on télécharge (dans le même répertoire (ex BootFBSD)) kern.flp et mfsroot.flp à partir
de :
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.5-RELEASE/floppies/.

Ensuite, on tape :

cd BoootFBSD
C:\BootFBSD> fdimage kern.flp a:
C:\BootFBSD> fdimage msfroot.flp a:

On obtient deux disquettes sur lesquels on va « booter » avec le futur FreeBSD.

Une fois l'ordinateur démarré avec les deux disquettes, il faut répondre négativement à la
demande de reconfiguration du noyau.

64
On arrive ensuite dans un menu avec plusieurs options :

Ø Keymap : choix du clavier en français.

Ø Custom : options à ne pas toucher.
Ø Partitions : Il faut choisir la partition sur laquelle on veut faire l'installation, et bien
penser à en mettre une bootable.
Ø Install boot manager : l'installer en standard
Ø Label : permet la création des partitions. Bien penser à mettre la taille des différentes
partitions en MB en mettant MB à la fin. Ex : 840MB.
Ø Mettre chaque partition avec l'option File Sytem. Rajouter l'option S (Softupdate). On
doit voir en face de chaque partition UFS+S

Ø Partitionnement : dans notre cas nous utiliserons 4 partitions de base :

/
/tmp
/var
swap

Ensuite on choisit pour chacune de ces partitions la taille qui leur sera attribuée :

Suivant la taille de la RAM, on attribue plus ou moins d'espace au swap, var et tmp ne
demandent pas beaucoup de place. Nous mettons alors le maximum de place pour la partition
racine /.

Dans notre cas (512 Mo Ram, partition de 4Go), nous avons pris :
/ 3500 Mo
/tmp 200 Mo
/var 200 Mo
/swap 100 Mo

Dans Menu Distribution à Custom, on sélectionne : bin, compat4x, crypto, info, man,
catman, proflibs, local, ports, src (dans src, on sélectionne : base, etc, include, lib, libexec,
bin, sbin, scrypto, share, sys, ssecure, ubin, sbin, tools).

Une fois la configuration effectuée, on peut commencer l'installation proprement dite :

L'installation se fait dans notre cas en FTP passif (le choix de FTP passif s'explique par le fait
que notre routeur possède une access list qui joue plus ou moins le rôle de firewall).

A partir de maintenant, le PC télécharge tous les fichiers nécessaires et réalise l'installation.

Une fois l'installation terminée, nous arrivons sur un menu de configuration générale de l'OS.
Ce menu peut être récupéré par la suite en tapant /stand/sysinstall

Voici les différentes options :

Ø Distribution : en principe, ne pas toucher : déjà configuré auparavant
Ø Package : permet de télécharger les fichiers compilés et tous prêts d'applications.
(Nous avons choisi d'installer, Archiveurs : unzip, unrar, FTP Clients : curl, wget ipv6,
Shell : bash)

65
 Ø User Management : permet d'ajouter, de supprimer des groupes ou des utilisateurs
Ø Networking : AMD Flags, Gateway
Ø Mise en place d’une interface graphique :
xf86config : configure X-window
startx: Lance X-window
/usr/ports/x11
/usr/ports/x11-fonts
/usr/X11R6/lib
/etc/x11/XF86config
/usr/ports/x11-servers/Xfree86-4-FontServer

(5) Configuration du noyau

Pour des raisons simples comme par exemple l’ajout de devices (équivaut aux drivers) pour
l’installation d’une carte d’acquisition vidéo, il faut éditer le noyau GENERIC qui se situe
dans /sys/i386/conf/. A chaque édition il faut effectuer une compilation du noyau.

Il est très conseillé de renommer le noyau lors de sa première re-compilation afin de garder un
noyau GENERIC en cas de problème ultérieur avec le nouveau noyau.

Dans notre cas, nous renommons le noyau DIKE qui est le nom de la machine (le noyau
DIKE sera donc notre noyau effectif, le noyau GENERIC ne sera plus pris en compte par
FreeBSD), pour changer le nom du noyau il suffit d’inscrire en face de ident le nom désiré.

Récapitulatif avec les commandes :

cd /sys/i386/conf/
cp GENERIC DIKE
vi DIKE
(on change ou rajoute les paramètres souhaités en éditant DIKE, par exemple :
ident DIKE
maxusers 32
device « carte video »
device « carte audio »)

config DIKE
cd ../../compile/DIKE
make depend && make && make install
reboot

Remarques
Ø Avant chaque re-compilation du noyau effectif il faut faire un “make clean”.
Ø Toutes les options que l’on peut inclure au noyau sont disponibles dans le document
LINT qui se trouve dans le répertoire /sys/i386/conf/.

66
 (6) Implémentation des fonctionnalités à apporter au FreeBSD pour obtenir un
routeur X-cast IPv6

Ces configurations sont à prendre dans le cas ou le réseau n’a qu’une connexion IPv4 native
et que l’on veut faire du routeur IPv6 une passerelle pour le multicast et l’unicast (Des
configurations pour d’autres cas de figure sont disponibles à l’Url
http://mother6.renater.fr/Xcast).

- Activer IPv6 sur le routeur

- Déclarer les interfaces IPv6 actives (interfaces physiques et tunnels)
- Activer le routage IPv6 sur la machine. Quand une machine est configurée comme
routeur, elle ne fait plus l'autoconfiguration sur ses interfaces donc il est nécessaire de
donner manuellement une adresse IPv6
- Spécifier manuellement une adresse IPv6
- Spécifier manuellement les préfixes à annoncer
- Envoyer des paquets "Router Advertisements" sur l'interface du site pour que les
machines s'autoconfigurent avec le préfixe annoncé. Spécifier les interfaces sur
lesquelles ont veut annoncer le préfixe.
- Créer le tunnel IPv6 (multicast et unicast) dans IPv4 vers le point de présence du
réseau IPv6 multicast.
- Déclarer une route par défaut vers la sortie du tunnel.
- Lancer le démon de routage RIPng pour annoncer au réseau IPv6 multicast les
préfixes qui vont avoir besoin du multicast et pour récupérer les préfixes des sites
connectés au réseau IPv6 multicast. N'annoncer que les préfixes nécessaires au
multicast à travers les interfaces multicast.
- Lancer le démon pim6sd

Ce routeur multicast IPv6 doit être connecté à un point de présence du réseau IPv6 multicast
via un tunnel IPv6 (multicast et unicast) dans IPv4.

Pour que FreeBSD satisfasse ces fonctionnalités, il faut modifier les fichiers de configurations
décrit dans le paragraphe suivant.

(7) Les fichiers de configuration (rc.conf, rc.local, hosts, resolv.conf, pim6sd.conf)

- /etc/rc.conf :

Le fichier rc.conf décrit le nom de l'hôte local, la configuration des interfaces réseau
potentielles et les services à lancer lors du démarrage de l'ordinateur. Avec les
versions récentes, ce fichier est généralement initialisé par l'installeur
/stand/sysinstall.

67
Le but de rc.conf n'est pas de lancer des commandes ou d'effectuer des tâches
au démarrage. Il est plutôt utilisé par les divers scripts de démarrage de /etc
qui trouvent dedans les paramétrages nécessaires.

Il existe deux fichiers se nommant rc.conf, l’un dans /etc/ l’autre dans
/etc/defaults/, ce dernier est à configurer une fois. Par exemple, si on veut
que notre FreeBSD supporte le protocole IPv6 on doit changer le
IPv6_enable= « NO » en IPv6_enable= « YES », etc…

Le premier rc.conf est le fichier de configuration que l’on peut changer

autant de fois que l’on veut, par exemple si on veut créer des tunnels qui ne
sont pas définitifs…

On annonce dans le fichier rc.conf, la ou les interfaces réseaux IPv4 de la

machine ainsi que le routeur par défaut IPv4,

On active la pile IPv6.

On active la fonction de routage IPv6.

On active la fonction d’envoi de paquets « Router Advertissement » qui

permettent l’autoconfiguration des stations IPv6 du réseau IPv4.

68
 - /etc/rc.local :

Dans le fichier rc.local, on annonce la ou les interfaces tunnels et l’encapsulation dont il sont
responsables, ainsi dans notre cas, on annonce dans un premier temps l’interface réseau IPv6
xl0, puis on créer un tunnel gif0, on annonce la couche encapsulante (IPv4 dans notre cas)
avec comme adresses d’extrémités, celle de notre routeur et celle du routeur IPv6 multicast de
Renater ayant une connectivité IPv4.

Ensuite on annonce la couche encapsulée (donc IPv6) avec toujours les adresses d’extrémités
des deux mêmes machines qu’en IPv4 mais cette fois-ci en IPv6.

On annonce ensuite une route par défaut qui est celle du routeur de Renater (cette fois-ci
l’adresse n’est pas celle du tunnel mais bien celle du routeur).

On lance le démon de routage « route6d » via l’adresse IPv6 de notre routeur.

Puis on lance le démon de routage multicast pim6sd (sparse mode) en annonçant le chemin où
aller le chercher.

69
 - /etc/resolv.conf :

search artemis.jussieu.fr
nameserver 134.157.55.10

Le fichier /etc/resolv.conf sert à annoncer le domaine de recherche ainsi que l’adresse du

serveur de nom DNS.

- /etc/hosts :

::1 localhost.artemis.jussieu.fr localhost

127.0.0.1 localhost.artemis.jussieu.fr localhost
134.157.55.240 IPV6DIKE.artemis.jussieu.fr IPv6DIKE
134.157.55.240 IPV6DIKE.artemis.jussieu.fr.

Le fichier /etc/hosts sert à faire correspondre l’adresse IPv4 et IPv6 au nom hôte.
Il faut ajouter les deux mêmes lignes que les deux dernières mais avec l’adresse IPv6.

(8) Quelques précisions et astuces sur l’arborescence et les commandes à

connaître pour utiliser FreeBSD

- Les ports :

Les ports aussi nommés logiciels portés de FreeBSD permettent de compiler et d'installer une
grande variété d'applications avec un minimum d'efforts.

Les logiciels sont typiquement distribués sur l'Internet sous forme d'archives incluant un
fichier « Makefile », le code source du programme et habituellement quelques instructions
avec peut-être aussi une procédure de configuration.

Le scénario standard consiste à télécharger l'archive par FTP, l'extraire quelque part, parcourir
les instructions, faire les modifications qui vous paraissent nécessaires, lancer la procédure de
configuration pour mettre tout au point et utiliser la commande make habituelle pour compiler
et installer le programme à partir des sources.

Les logiciels portés de FreeBSD utilisent toujours le mécanisme des archives, mais se servent
d'un squelette qui renferme la « connaissance » nécessaire pour pouvoir obtenir un logiciel
utilisable sous FreeBSD, plutôt que d'attendre de l'utilisateur qu'il se débrouille. Ils

70
comportent aussi leurs propres « Makefile », de sorte que presque tous les logiciels portés se
compilent et s'installent de la même façon.

Exemple :

cd /usr/ports/devel/ElectricFence
make install

- Installation d’une carte d’acquisition vidéo et audio :

Sous FreeBSD n’importe quelle carte à base de puce Brooktree BT848/878 est compatible
(hauppauge wintv par exemple). On ajoute les devices de la carte vidéo qui possède la puce
Brooktree 878 dans le noyau et les devices génériques pour le son:

#devices vidéo (ceci est un commentaire)

device iicbus
device bktr
options BROOKTREE_SYSTEM_DEFAUL T = BROOKTREE_SECAM

#device audio

device pcm

On recompile le noyau et on redémarre, il faut ensuite créer les devices en entrant la

commande suivante :

./sh makefile bktr0 (pour le device bktr0 de la carte vidéo)

- Mot de passe perdu :

boot –s
mount /
passwd

- Monter une disquette formatée sous msdos :

mount –t msdos /dev/fd0 /mnt

- FTP (mode passif) :

La quasi-totalité des téléchargements de logiciels se font par FTP, si le réseau sur
lequel on se trouve comporte un Firewall, il faut passer en mode FTP passif, pour
cela il faut édité le fichier /usr/ports/Mk/bsd.port.mk et ajouter –p en face de la ligne
concernant le mode passif ou actif de ftp.

- df -k :
Cette commande permet d'afficher l'état des lecteurs (taille, pourcentage
d'utilisation).

- top :

71
 Commande qui indique en temps réel le taux de mémoire utilisée et par quelle(s)
application(s).

- dmesg :

Cette commande informe sur ce que reconnaît FreeBSD en périphériques et devices

- Mise à jour de la base de donnée de FreeBSD :

Faire la commande /usr/libexec/locate.updatedb

- Rebooter au niveau réseau : (évite de rebooter entièrement pour le changement

d’un paramètre réseau) :

/etc/sh rc

- Autres:
o netstat –rn (informe sur la totalité des adresses reconnus par le noyau (interfaces,
tunnels...)
o ifconfig –a (paramètres interfaces réseaux)
o reboot (pour rebooter)
o halt (arrêt de la machine)
o ps –aux (donne tous les processus actifs)

(9) Pile KAME pour IPv6 multicast (intégré dans FreeBSD 4.5)

Seule la pile Kame développée par le consortium WIDE26 permet actuellement le routage
multicast IPv6. Elle est développée pour les systèmes d'exploitation BSD (FreeBSD, NetBSD,
OpenBSD, BSD/OS).

Elle est intégrée par défaut dans FreeBSD .4.5

Voici l’Url du site officiel de Kame : http://www.kame.net./

La pile Kame par défaut sous FreeBSD 4.5 présente quelques erreurs au niveau des sources.
Pour éliminer ces erreurs, il faut télécharger la mise à jour (« snapshot ») la plus récente (ex :
kame-20020325-freebsd-snap.tgz) sur le site ftp ftp.kame.net, plus exactement
ftp.kame.net/pub/kame/snap/kame-AAAAMMJJ-freeBSD-snap.tgz.

Après un « tar zxfv kame-AAAAMMJJ-freeBSD-snap.tgz », il faut suivre les

instructions se situant dans /kame/INSTALL et /kame/freebsd4/INSTALL en commençant
par /kame/INSTALL,

26
WIDE : Widely Integrated Distribued Environnement est un consortium existant depuis 1998, il regroupe 90
entreprises et 40 universités. Son objectif est de développer des environnements informatiques distribués de
grande échelle. WIDE est implanté au Japon où il dispose d’un réseau allant jusqu’à 1Gbit/s et d’ une
connectivité vers STAR TAP de 100Mbit/s.

72
Après avoir suivit ces instructions et rebooter, les commandes relatives à IPv6 se situent dans
/usr/local/v6/, il faut alors indiquer le chemin de ces commandes dans les fichiers /etc/rc.conf,
/etc/rc, /root/.cshrc,

Pour rc.conf cela est indiqué dans la documentation /kame/freebsd4/INSTALL,

Pour /etc/rc :

PATH=/usr/local/v6/sbin:/usr/local/v6/bin:/sbin/:/bin:/usr/
sbin:/usr/bin:/usr/local/sbin

Pour /root/.cshrc:
set path = (. /usr/local/v6/sbin /usr/local/v6/bin /sbin
/bin /usr/sbin /usr/bin /usr/games /usr/local/sbin
/usr/local/bin /usr/X11R6/bin $HOME/bin)

b) Station en IPv6 multicast

(1) OS supportant le protocole IPv6

On a vu dans la partie théorie qu’IPv6 inclut nativement le multicast.

Pour les sites voulant gérer MLD (pour PIM SM), tous les systèmes d'exploitations avec une
pile IPv6 qui supporte le multicast peuvent être utilisés. Il faut s'assurer également que les
outils multicast pour faire de la visioconférence sont disponibles sur ces OS. Pour cela, vous
pouvez vérifier sur le site de l'UCL qui développe ces logiciels.

Les systèmes d’exploitation supportant sont Windows 2000, XP, Linux, …BSD, AIX (cf.
chapitre 6.3).

(2) Installation de la pile IPv6

La station utilisée pour la visioconférence en IPv6 multicast est mutli-OS, les systèmes
d’exploitations installés sont Windows 2000, Windows XP et Windows 98. La pile IPv6
s’installe sur Windows 2000 et XP, par contre pour Windows 98 reste moins évident, il
semble que quelques travaux soit disponibles. Voici donc comment installer la pile IPv6 sous
différents systèmes d’exploitations :

- Windows 2000 :

Microsoft met en ligne sa propre version de pile IPv6. Pour Windows 2000 server et
professionnel la mise en place de la pile IPv6 est la même. Pour l’installation, suivre le
parcours suivant :

73
 o Se rendre à l’url :
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp,
o Télécharger l’exécutable tpipv6-001205.exe en cliquant sur Download the
Microsoft IPv6 Technology Preview puis sous Windows, lancer
l’installation et mettre le résultat de l’exécution dans un répertoire IPv6kit
par exemple.
o Se loguer en tant qu’utilisateur ayant les droits d’administrateur,
o Lancer le setup.exe se trouvant dans le fichier IPv6kit,
o Dans Menu démarrer, Paramètres, cliquer sur Connexions réseau et accès à
distance, Clique droit sur Connexion au réseau local puis cliquer sur
Installer,
o Dans la fenêtre « Sélection du type de composant réseau », sélectionner
Protocole et cliquer sur Ajouter,
o Dans la fenêtre Sélection de protocole réseau, sélectionner « Microsoft
IPv6 Protocol » et cliquer sur Ajouter ,

(Toutes ces instructions se retrouvent à l’url :

http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/readme.asp)

La pile IPv6 de Microsoft est ajoutée automatiquement sur toutes les interfaces réseau de la
machine.

Si le Service Pack 2 est installé sur la machine, il faut alors se référer à la FAQ de Microsoft :
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/faq.asp ou suivre les instructions
suivantes :

Après avoir téléchargé l’exécutable tpipv6-001205.exe et effectué l’installation dans un

répertoire IPv6kit :

o Lancer une invite MS-DOS, se mettre dans le répertoire IPv6kit ,faire un

setup.exe –x et extraire le contenu dans un répertoire « files » dans IPv6kit,
o Dans le répertoire files, ouvrir le fichier Hotfix.txt, et, dans la section
[Version], changer la ligne NTServicePackVersion=256 par
NTServicePackVersion=512 et sauver,
o Toujours le répertoire files, lancer Hotfix.exe,
o Redémarrer la machine,
o Dans Menu démarrer, Paramètres, cliquer sur Connexions réseau et accès à
distance, Clique droit sur Connexion au réseau local puis cliquer sur
Installer,
o Dans la fenêtre « Sélection du type de composant réseau », sélectionner
Protocole et cliquer sur Ajouter,
o Dans la fenêtre « Sélection de protocole réseau », sélectionner « Microsoft
IPv6 Protocol » et cliquer sur Ajouter,

Pour vérifier si l’installation s’est effectuée correctement, on peut faire un ipv6 if, commande
qui nous donne les paramètre de l’adressage de la station en IPv6.

- Windows XP :

74
Se Connecter administrateur et lancez la commande « ipv6 install ».

Pour vérifier si l’installation s’est effectuée correctement, on peut faire un ipv6 if.

Note : Pour Windows, il faut aussi rentrer une adresse dans le fichier
Windows/system32/etc/hosts comme indiqué dans l’exemple suivant :

- Sun-Solaris :

La pile IPv6 n’est disponible qu’à partir de la version 8 de Solaris. Durant l’installation, il
suffit de mettre Enable = Yes dans la fenêtre IPv6.

Pour d’autres renseignements se référer à l’url :

http://wwws.sun.com/software/solaris/ipv6/

- FreeBSD :

Dans les dernières versions téléchargeables à partir du site http://www.freebsd.com, la pile

IPv6 kame est installée par défaut. Pour activer la pile IPv6 après que l’installation de
FreeBSD soit terminée, il suffit d’ajouter (ou de remplacer) la ligne IPv6_enable= « YES »
dans le fichier rc.conf se trouvant dans le répertoire /etc.
Pour obtenir une version de la pile kame plus récente il faut installer le snapshot le plus récent
à partir du site ftp.kame.net (Cf. partie 6.4 f).

75
 (3) Visioconférence

Pour les outils du Mbone, ils sont aussi disponibles à partir du site de l’UCL en IPv6. Mais ils
ne se compilent pas correctement.
Il faut donc bien télécharger ces utilitaires à partir du site de l’UCL, mais il faut ensuite
remplacer les fichiers exécutables, vic, rat et sdr par ceux que l’ont peut trouver sur le site
http://www.kabassanov.com (pour information, les codes sources de ces exécutables
téléchargés à partir de ce second site ont été recompilés par Konstantin Kabassanov, ingénieur
de recherche et développement dans l'équipe Réseaux et Performances du laboratoire LIP6 au
sein de l'Université Pierre et Marie Curie).

Voici donc la procédure à suivre pour installer les outils du Mbone IPv6 sur une plate forme
Windows 2000 :

- Téléchargement des sources de VIC, RAT et SDR à partir du site de l’UCL

et les installer dans un répertoire m6bone par exemple,

- Téléchargement des sources de VIC, RAT et SDR sous forme d’archive à

partir de http://www.kabassanov.com,

- Extraction de ces archives dans le répertoire mbone6,

- Placer dans la variable d'environnement utilisateur de Windows

HOMEDIR le chemin vers mbone6 (D:/Program Files/mbone6/) :

o Dans panneau de configuration,

o Aller dans Système,
o Une fenêtre « Propriétés Système » s’affiche,
o Aller sur l’onglet « Avancé »
o Aller dans « Variables d’environnement »,
o Créée une nouvelle variable HOMEDIR avec pour path le chemin vers
le répertoire m6bone,

- Ajout d’une route multicast par défaut sur l’interface réseau (Créer pour
cela un fichier .bat que l’on relancera à chaque fois que l’on veut changer
ses paramètres) :

o Editer un fichier texte dans lequel on met :

ipv6 rtu 0::/0 4/2001:660:10a:4002:2d0:b7ff:febb:50d0

ipv6 rtu FF00::/8 4

(4 est le numéro d’interface de la carte réseau déterminé par la commande

« ipv6 if », 2001 :660 :10a :4002 :2d0 :b7ff :febb :50d0 est l’adresse IPv6
du routeur par défaut, FF00 est le préfix IPv6 pour les adresses IPv6
multicast).

76
 o Enregistrer le fichier texte .txt en .bat,
o Lancer le fichier .bat,

- Résolution du nom d’hôte de la station dans le serveur DNS IPv6 (cf.

partie (4)),

- Ligne de commande pour exécuter vic, rat et sdr:

o Pour Windows 2000:

Lancer une commande MS-DOS, se placer dans le répertoire mbone6 et

inscrire les lignes suivantes :

rat –t TTL addIPv6/port

vic –n ip6 Xcast-addr/Port

sdr

o Pour FreeBSD 4.5:

rat –t TTL addIPv6/port

vic –t TTL addIPv6/port

c) Le serveur DNS

La mise en place d’un réseau IPv6 au sein du site d’Artémis inclue la configuration d’un DNS
en IPv6.

Pour qu'une machine Unix puisse faire office de DNS (Domain Name Server), il faut installer
le logiciel BIND (Berkeley Internet Name Domain).BIND est l'implémentation la plus
courante du protocole DNS. Le rôle du DNS est de faire la correspondance entre les noms de
domaine et les adresses IP. BIND utilise d'une part un fichier de configuration et d'autre part
un fichier de données par zone. De plus un fichier contient aussi la liste des serveurs de noms
pour la racine. C’est à partir de la version 9 que BIND accepte l’adressage des stations en
IPv6.

Pour télécharger le BIND, il suffit de se connecter au site ftp.isc.org (aller dans le répertoire
/isc/bind9.

77
 (1) Arborescence des fichiers de DNS sous FreeBSD

(2) Description des fichiers et répertoires essentiels

- Le répertoire /etc :

• Le fichier /etc/namedb/named.conf :

Le fichier de configuration principal de BIND est /etc/namedb/named.conf. La syntaxe de ce

fichier ressemble au C :

options {
directory "/var/namedb";
listen-on-v6 { any; };
listen-on {
134.157.55.62;
127.0.0.1;
};

# Fichier de configuration pour la zone "."

zone "." {
type hint;

78
 file "named.root";
};

# Domaines pour lesquels on est DNS server

# Notre propre machine :
zone "0.0.127.in-addr.arpa" {
type master;
file "primary/reverse/localhost.rev";
};

#Notre propre machine en 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 "primary/reverse/localhost.rev";
};

# Le domaine artemis.jussieu.fr
zone "artemis.jussieu.fr" {
type master;
file "primary/forward/artemis.jussieu.fr";
zone-statistics yes;
};

#La zone reverse

zone "55.157.134.in-addr.arpa" {
type master;
file "primary/reverse/55.157.134.in-addr.arpa";
zone-statistics yes;
};

La ligne directory indique l'endroit où doivent se trouver les fichiers de définition du serveur,
en l'occurence dans /var/namedb.

La déclaration du nom de domaine qu’on veut gérer se trouve dans une section zone. Dans
cette section, file indique le nom du fichier de configuration du domaine (qui doit se trouver
dans le répertoire /var/namedb).

• Le fichier rndc.conf :

BIND contient un utilitaire appelé rndc qui permet d'administrer, localement ou à distance, le
démon named grâce à des déclarations en lignes de commandes. Le programme rndc utilise le
fichier /etc/rndc.conf pour ses options de configuration qui seront outrepassées par la priorité
des options de lignes de commandes.

- Le répertoire /var :

• Le fichier /var/namedb/primary/forward/artemis.jussieu.fr :

Voici le fichier correspondant à artemis.jussieu.fr,

$ORIGIN artemis.jussieu.fr.
$TTL 172800

79
 ; SOA machine personne en charge
; ------- --------------------- -------------------------
@ IN SOA neso.artemis.jussieu.fr. sol.artemis.jussieu.fr. (
2002060601 ; Version
21600 ; Refresh (6h)
3600 ; Retry (1h)
3600000 ; Expire
172800 ) ; Minimum (2j)
;
; Designation des serveurs primaire et secondaires
;
IN NS neso.artemis.jussieu.fr.
IN NS unix.artemis.jussieu.fr.
IN NS shiva.jussieu.fr.
IN NS cendrillon.lptl.jussieu.fr.
IN NS soleil.uvsq.fr.
;
; Le MX de la zone
;
IN MX 100 shiva.jussieu.fr.
IN MX 200 soleil.uvsq.fr.
;
; Designation des noeuds du domaine artemis.jussieu.fr.
;

unix IN A 134.157.55.10
IN MX 100 shiva.jussieu.fr.
IN MX 200 soleil.uvsq.fr.

neso IN A 134.157.55.198
IN MX 100 shiva.jussieu.fr.
IN MX 200 soleil.uvsq.fr.

localhost IN A 127.0.0.1
IN AAAA ::1

TTL (Time To Live) :

C'est la limite de fraîcheur des informations. Lorsque le serveur fournit une réponse depuis ce
fichier, il indique que l'information n'est valide qu'un certain temps.

SOA (Start Of Authority) :

C'est l'acte de naissance de la zone. Y figure :

• Le nom du serveur primaire pour cette zone ;

• L'adresse mél du responsable technique de la zone (l'@ étant remplacé par un .) ;
• Des informations permettant de gérer les taux de rafraîchissement entre un serveur
primaire et des serveurs secondaires.

La ligne contenant le SOA commence par un @ qui indique toujours le nom de la zone en
cours dans un fichier de zone.

80
Après l'entête, on trouve les enregistrements. Les enregistrements peuvent être de plusieurs
types. Les plus utilisés sont :

NS (Name Server) :

Un enregistrement de ce type indique les serveurs de noms qui peuvent répondre pour cette
zone. Le nom situé en correspondance doit être terminé par un . s'il est complètement qualifié.
Si le nom du serveur est dans la zone, seule la partie hôte du nom suffit et le point doit être
omis.

A (Address) :

Un enregistrement de ce type permet d'associer un nom d'hôte à une adresse IP.

AAAA :

Idem que A pour IPv6.

MX (Mail Exchange) :

Un enregistrement de ce type permet d'associer le nom du serveur de courrier à un domaine.

Le nom du serveur est préfixé par un chiffre qui indique l'ordre de préférence. Si plusieurs
serveurs peuvent gérer le domaine de courrier c'est celui qui est préfixé par le chiffre le plus
faible qui sera préféré.

CNAME (Canonical Name) :

Un enregistrement de ce type permet d'indiquer le nom canonique d'un hôte qui possède des
aliases. Les règles concernant l'écriture du nom de l'hôte décrites pour les enregistrements de
type A sont les mêmes pour ceux de type CNAME.

Dans notre cas il suffit donc d’indiquer dans le fichier forward, les adresses IPv6 des stations
concernées en dessous des adresses IPv4 (car notre DNS gère aussi bien l’IPv4 que l’IPv6)
grâce aux quad A comme ceci :

DIKE A 134.157.55.240
AAAA 3ffe:0304:1000:5555::254

AITHER A 134.157.55.37
AAAA 3ffe:0304:1000:5555:250:daff:fe5c:313a

Pour prendre en compte les changements effectués dans le fichier forward, il faut ensuite faire
un : # rndc reload.

• Le fichier /var/namedb/primary/reverse/55.157.134.in-addr.arpa :

Le reverse DNS permet de convertir une adresse IP en nom de domaine. Ce service permet
d'identifier plus facilement une machine. Au lieu de voir apparaître une adresse IP (qui ne sera
pas parlante) on voit apparaître un nom de domaine et dans la plupart des cas un nom de
machine.

81
 • Le répertoire /var/namedb/secondary :

Ce répertoire contient de même que pour le répertoire primary, un sous-répertoire forward et

un sous-répertoire reverse, ceci pour une zone secondaire.

• Le répertoire /var/namedb/log :

Répertoire contenant les fichiers des messages de connexions…

• Le fichier named.root :

Ce fichier contient les informations pour les serveurs DNS au-dessus de notre serveur (on dit
root server, ou encore serveurs racines). Le fichier named.root contient une liste de root
servers, qui sont les serveurs de noms en charge de la racine, comme le montre les lignes NS.
C'est donc grâce à eux que notre serveur de nom saura retrouver les serveurs en charge des
"top level domains" (fr, com, uk, ...), puis ceux du niveau inférieur jusqu'à résolution du nom
demandé.

- Le répertoire /usr :

• Le fichier /usr/libexec/named-xfer :

Exécutable utilisé pour les transferts de zone.

• Le répertoire /usr/sbin :

Ce répertoire contient les commandes named, named.reload, named.restart, la première

permet de lancer le démon named (pour que la fonction de DNS soit prise en compte dès, la
seconde, dans le cas d’un changement dans le fichier de zone permet de prendre en compte ce
qui à été changé, la troisième, permet d’arrêter le démon named en cours et d’en relancer un
nouveau directement.

82
V. Mise en place d’une passerelle de transcodage multicast -
unicast pour la visioconférence IP multicast : UTG

Cette passerelle dont je préciserai les fonctionnalités plus loin est développée par l’UCL27 qui
l’a met à la disposition de la communauté académique gratuitement.

1. Objectif

La passerelle UTG donne accès au multicast en visioconférence à des sites en unicast.

L’objectif était donc d’installer cette passerelle sur le réseau Renater afin d’ouvrir un service
permettant dans le cadre d’Athena d’adapter la technologie aux réalités des différents
partenaires d’ATHENA. Bien sûr cette passerelle pourra aussi bien être utiliser dans un autre
contexte qu’Athena.

2. Contexte

a) Nouveaux partenaires

Les nouveaux contacts pour le projet ATHENA ne sont pas équipés du multicast, l’idée est
donc d’avoir une solution de remplacement. Grâce à la passerelle UTG, les partenaires ont
accès à la visioconférence multicast.

b) Projet DIM

Donner la possibilités de suivre les cours DIM sans avoir accès au multicast directement.

3. Réalisation technique

a) Serveur UTG

Le réseau multicast n'est pas accessible à tous. UTG, UCL Transcoding Gateway, permet de
pallier ce handicap en servant de passerelle entre le Mbone et ceux qui n'y ont pas accès. Il
permet, pour toute personne connectée à l'Internet, d'établir une liaison unicast avec un
serveur ayant accès au multicast. Ce serveur sert de relais et envoie l'émission voulue sur

27
UCL : University College of London

83
chaque liaison unicast. Il route également les annonces Sdr. Pour le client UTG, il suffit
d'avoir accès à un serveur UTG (celui de l'UCL par défaut) et tout se passe quasiment comme
si on était sur le Mbone. Par ailleurs le serveur UTG peut servir de relais dans les deux sens et
l'utilisateur n'ayant pas accès au Mbone pourra émettre sur ce réseau par le biais du serveur.

(1) Solaris8

- Installation :

A partir du CD-rom, Boot-cd-rom

Dans mon cas j’ai effectué une installation en mode core, c’est à dire sans interface graphique
afin d’optimiser le mieux possible l’utilisation d’une SUN Sparc20, qui n’est pas toute
récente.

Customize
Dans la fenêtre « Select Products », tout desactiver
None
64-bit support : non
dans la fenêtre « Select Solaris Cluster Configuration » :
Core

- Configuration :

Annoncer un routeur par défaut dans /etc/defaultrouter (à créer)

Cd /etc
Vi defaultrouter

193.49.160.126 (renater)

Ou bien echo 193.49.160.126 > defaultrouter

Annonce d’une route par défaut :

Route add default 193.49.160.126

Changement d’adresse IP:

84
 Faire un sys-unconfig

Dans /etc/inet/hosts :

127.0.0.1 localhost loghost

193.49.160.132 utg.renater.fr
193.49.160.132 utg

Ajouter un utilisateur :

Useradd –g utg –d /UTG –s /sbin/sh utg

Su –utg

Passwd utg (chgt de mot de passé)

Chown utg :utg /UTG/utg-relaunch.sh

Ps –edf | grep sdr_relay | grep –v grep | awk ‘{print $2}’

Changer la date: (en root)

Date 1533.00 (c’est un point ou un tiret, à vérifier)

- Sécurisation :

Dans /etc/rc2.d

#mv s74autofs _s74autofs

#mv s73nfs.client _s73nfs.client
#mv s71ldap.client _s71ldap.client
#mv s71rpc _s71rpc
#mv s73cachefs.daemon _s73cachefs.daemon

Vi s74syslog :

/usr/sbin/syslogd –t >/dev/msglog 2 >&1 &

Dans s72inetsvc:

Commenter la dernière ligne :

#/usr/sbin/inetd –s &

Après tout ça : rebooter !

85
 (2) UTG-svr v1.3

Un serveur UTG permettant le passage d’un flux unicast vers multicast est composé de cinq
agents de relais. En effet, ce serveur à été développé par l’UCL afin de donner accès à la
visioconférence IP muliticast à partir d’un réseau unicast. Les outils du Mbone pour la
visioconférence en IP multicast sont donc répertoriés au nombre de cinq : Sdr, Vic, Rat, Nte,
Wb. Il y a donc un premier agent fournissant à l’hôte sur un réseau unicast un accès à la
fenêtre Sdr répertoriant les sessions multicast du Mbone. Un second , le relais audio, qui
fournit la connectivité audio et les équipements de transcodage. Ensuite on a une passerelle
vidéo qui fournit la connectivité vidéo avec un contrôle du flux et quelques équipements de
transcodage. Enfin, les deux derniers concernent les utilitaires Nte pour le partage de texte et
Wb pour le tableau blanc.

- Description détaillée des fonctionnalités :

o Le relais du traffic multicast :

Pour envoyer/recevoir du traffic multicast, des agents de relais ont été développés. Sur
demande, ces agents transforment et relaient les paquets appropriés entre le serveur et les
clients.
Pour joindre une session multicast, l’hôte en unicast à besoin d’une simple connexion à
Internet (via PPP). Les agents de relais présents sur l’hôte se lancent et appellent le serveur
UTG, lequel est connecté au Mbone. Le serveur de relais ne doit pas être nécessairement sur
le même réseau que l’hôte.

Voilà une idée de comment procède le serveur UTG :

o SDR via relais :

L’utilitaire répertoriant les sessions multicast SDR remplit deux fonctions : la première est
d’écouter et annoncer les sessions multicast sur le Mbone ; la seconde est de permettre à
l'utilisateur d'appeler les outils correspondants aux médias utilisés pour joindre une session.

86
Un agent de relais pour SDR a été développé par l’UCL pour écouter les sessions et les
annoncer à un hôte situé sur un réseau unicast. L’ agent de relais SDR permet aussi de garder
des sessions en cache (visible sur le SDR en permanence) pour se connecter plus rapidement.
L’utilisation d’un client UTG ajoute une fenêtre lors de l’utilisation des outils du Mbone :

o Le transcodage vidéo et le régulateur de flux :

Lorsqu’un utilisateur rejoint une session du SDR, une requête pour sélectionner la vidéo est
envoyée au serveur de relais avant que l’utilitaire VIC ne se lance en local. Sur réception de
cette requête, le serveur de relais lance un mécanisme de filtrage de la vidéo. Ce dernier alors
adapte le flux multicast au flux unicast au travers d’une « passerelle vidéo ». Celle-ci
accomplit deux tâches principales :
La première est de collecter les informations sur les participants aux sessions et accepter les
informations de l’interface. Le mécanisme écoute la session multicast intéressant le client et
garde alors en cache les informations sur les autres connectés à cette session. Sur demande, il
fournit les dernières informations à l’interface de l’utilisateur qui l’a demandé. Cette
information permet à l’utilisateur de choisir le flux vidéo qui l’intéresse. Il écoute aussi sur le
« bus des conférences » pour recevoir les instructions de contrôle de la part des clients.
La seconde est de manipuler et expédier les paquets RTP et RTCP entre le Mbone et le site
unicast. Pour les paquets RTP, deux opérations sont effectuées : Le passage au travers du
serveur avec ou sans réduction de flux et le transcodage (JPEG vers H.261, NV vers H.261).
Dans les deux cas, la modification ou la non-modification des paquets RTP est
immédiatement expédiée au recepteur. Pour les paquets RTCP, expéditeur et receveur
reçoivent des rapports sur la qualité de distribution du flux par le serveur.

87
 o Transcodage et mixage audio :

Lorsqu’un utilisateur joint une session du SDR, comme pour VIC, une requête pour le relais
audio est envoyée avant de démarrer l’utilitaire RAT localement. Sur réception de cette
requête, le serveur lance un mécanisme de transcodage/mixage audio. Le serveur exécute
deux fonctions : le mixage de tous les flux audio venant des participants en multicast pour
donner en sortie un flux unique (il est aussi possible de transcoder ce flux pour obtenir une
bande passante optimisée). Le transcodage permet de convertir n’importe quel de ces
formats : PCM, DVI, GSM et LPC en n’importe quel autre afin d’optimiser le flux vers le
client en unicast.
De même que pour la vidéo, le flux issu du transcodage/mixage peut être copié pour être
envoyé à plusieurs clients simultanément.

o Contrôle à distance :

Les agents de relais (transcodeur/mixeur audio et filtrage vidéo) ont besoin d’être contrôlés
par les utilisateurs à partir de leur site en unicast. Pour ce faire, l’interface d’un agent de
relais est divisé en deux parties : une interface opérationnelle et une interface de management

88
TCP. L’interface opérationnelle permet aux agents de relayer les paquets RTP/RTCP , de les
transcoder ou filtrer, alors que l’interface de management permet le contrôle des tâches à
effectuer.

- Installation :

Système requis : Station SUN Sparc est la seule station assez stable pour générer un tel
serveur (OS=Solaris 8)

Download sur le site de l’UCL (http://www-mice.cs.ucl.ac.uk/multimedia/software/)

Désarchiver le package :

gunzip utg-server-1.2-a-solaris.tar.gz
tar xvf utg-server-1.2a-solaris.tar

dans un répertoire utg-1.2-server créer automatiquement dans lequel on retrouve 7 fichiers:

server-installation : documentation sur l’installation et l’utilisation d’UTG

audio_relay : agent de relais audio
video_relay : agent de relais vidéo
sdr_relay : agent de relais pour sdr
vgw : démon exécutant le transcodage/adaptation de débit vidéo
rat : démon de mixage/transcodage du son

- Lancement du serveur :

Pour lancer les serveur UTG, il suffit d’éditer un script shell de la forme :

#!/bin/sh
# PATH=$PATH:.
# export PATH
#/UTG/utg-1.2-server/start

o Script en cas d’arrêt d’un des transcodeur (vidéo, audio, sdr) :

/UTG/utg.sh

89
# !/bin/sh

pwd= “/UTG/utg-1.2-server”

### STARTING UTG

if [ “x$1” = “xstart” ]; then
$pwd/sdr_relay $
$pwd/audio_relay $
$pwd/video_relay $
$pwd/blind_relay 6016 $
$pwd/blind_relay 6018 $
echo “UTG successfully launched”
exit 0
fi
###

### GETTING PIDs

pid_sdr= ‘ps –edf | grep sdr_relay | grep –v grep | awk ’{ print $2 }’ ‘

pid_audio= ‘ps –edf | grep audio_relay | grep –v grep | awk ’{ print $2 }’ ‘
pid_video= ‘ps –edf | grep video_relay | grep –v grep | awk ’{ print $2 }’ ‘
pid_blind1= ‘ps –edf | grep “blind_relay 6016” | grep –v grep | awk ’{ print $2 }’ ‘
pid_blind2= ‘ps –edf | grep “blind_relay 6018” | grep –v grep | awk ’{ print $2 }’ ‘

### STOPPING UTG

if [ “x$1” = “xstop” ]; then

kill $pid_sdr
kill $pid_audio
kill $pid_video
kill $pid_blind1
kill $pid_blind2
echo “UTG has been stopped”
exit 0
fi
###

### NORMAL BEHAVIOR (RELAUNCH IF DIED)

if [ “x$pid_sdr” = “x” ]; then
$pwd/sdr_relay &
fi

if [ “x$pid_audio” = “x” ]; then

$pwd/audio_relay &
fi

if [ “x$pid_video” = “x” ]; then

$pwd/video_relay &
fi

90
 if [ “x$pid_blind1” = “x” ]; then
$pwd/blind_relay 6016 &
fi

if [ “x$pid_blind2” = “x” ]; then

$pwd/blind_relay 6018 &
fi
###

Ce script permet donc dans le cas ou une ou plusieurs des applications (video_relay,
audio_relay…) se soit interrompue de redémarrer (toutes les 5 minutes grâce à la crontab, cf
plus loin).

On veut maintenant que ce script se lance toutes les 5 minutes toutes les heures de tous les
jours, il faut éditer la crontab:

En root :

Faire un crontab –e

0,5,10,15,20,25,30,35,40,45,50 * * * * <tab> /UTG/utg.sh

Pour éditer le crontab avec vi (car par défaut c’est l’éditeur ed), il faut dans /etc/profile mettre
EDITOR=vi
Export EDITOR vi

On peut aussi grâce à la commande utg.sh stop, interrompre soi-même les applications en
cours d’exécution et les redémarrer avec la commande utg.sh start.
Pour information sur les connections, les lancements des applications, ou leur interruption, on
à éditer un autre script shell « checkmsg » :

# !/bin/sh
tail –f /var/adm/messages

Et un script « msg » pour les messages d’erreurs :

# !/bin/sh
echo
echo « erreurs ? »
tail –20 /var/adm/messages
echo
echo
echo « mails ? »
tail –20 /var/mail/utg

91
 b) Station UTG

(1) Mise en place d’un client UTG

Le client UTG n’a été testé que sur des stations Windows 98 et 2000. Il est bien sûr possible
de l’utiliser sur d’autres OS comme Solaris, Linux, FreeBSD.

Télécharger les outils du Mbone SDR, VIC et RAT à partir du site de L’UCL (University
College of London) : http://www-mice.cs.ucl.ac.uk/multimedia/software

Les installer dans un même répertoire, par défaut « C:\Program Files\mbone »

Télécharger, toujours à partir du site de l’UCL, UTG-cli et le Java Runtime Environnement

(JRE).

Effectuer les installations d’UTG et de JRE, par défaut dans « C:\Program Files\mbone » et
« C:\Program Files\JRE »

A ce stade, on a
un répertoire nommé « Mbone » dans le quel on retrouve sdr.exe, vic.exe, rat.exe, rat_utg,
vic_utg.

Ces installations créent par défaut des raccourcis dans le menu démarrer.

Demarrer\Programmes\Mbone Tools\sdr

Demarrer\Programmes\UCL Transcoding Gateway\

92
Il reste à configurer le path d’UTG pour que l’application trouve le jrew.exe permettant
d’afficher les fenêtres d’UTG. Il suffit d’éditer les .bat « UTG Configuration », « UTG (SDR
relay enabled) », « UTG (SDR relay disabled) » et de rajouter le chemin vers l’exécutable
jrew.exe qui est par défaut ; « C:\Program Files\JRE\bin\jrew.exe. Ou bien lancer les trois à la
suite, sans avoir spécifier le chemin de JRE, et dans ce cas une fenêtre de recherche apparaît :
faire parcourir et rentrer le chemin d’accès vers jrew.exe.

La version du JRE peut créer des problèmes. Lorsque l’on installe UTG-cli sur une station
comportant déjà un JRE, les applications d’UTG vont le détecter et s’en service pour se lancer
(du moins pour windows 2000). Le résultat de l’utilisation d’une mauvaise version de JRE est
l’absence de la fenêtre Vic malgré que l’on reçoit bien la fenêtre de transcodage vidéo, et
l’absence de la fenêtre Rat. La version téléchargeable à partir du site de l’UCL est la 1.1.5. Si
on installe cette version de JRE et que l’on donne aux applications d’UTG le path vers cette
version de JRE, les applications doivent fonctionner. Le fait de dire que les applications
d’UTG ne fonctionnent qu’avec la version 1.1.5 de JRE n’est qu’une hypothèse, puisque je
n’ai tester l’application qu’avec la version 1.1.8 autrement, je ne peux donc pas affirmer que
seule la version 1.1.5 de JRE est compatible avec UTG-cli.

(2) Utilisation d’UTG

Interface de configuration d’UTG (UTG Configuration) :

Dans le menu démarrer, lancer UTG Configuration.

93
 Ici, il faut rentrer l’adresse de la
passerelle UTG (Relay Server
Address) , son nom d’hôte (Host
Address) ou adresse IP (afin d’être
identifier au niveau de la passerelle
par l’administrateur). On peut aussi
indiquer des adresses de sessions
audio et vidéo par défaut ainsi que
pour les utilitaires « Whiteboard et
« nte », mais cela n’est pas
obligatoire. Rentrer des adresses
Audio et Video dans ce panneau de
configuration permet d’avoir une
session par défaut au démarrage
d’UTG.

Il faut ensuite configurer la bande passante limite (Total bandwidth) que l’on désire utiliser,
par défaut on à une bande passante de 50 Kbit/s, dans ce cas on obtient une bande passante
maximum de 18 Kbit/s pour la vidéo, ceci dans le cas ou on à configurer une bande passante
de 32 Kbit/s pour l’audio en dvi (cf schémas ci-dessous). La configuration de la bande
passante limite se fait donc en fonction de la bande passante disponible sur son réseau.

On configure aussi l’utilisation de SDR, avec SDR Relay enable, on peut par la suite choisir
une session dans le SDR sans connaître les adresses pour Vic et Rat.

Une fois la configuration terminée, il suffit de lancer SDR puis UTG (SDR relay enabled) (ou
disabled si on ne sert pas de SDR) :

- SDR Relay enabled :

Attention : le rafraîchissement des sessions est assez lent. Il faut donc patienter avant de voir
les sessions qui ne sont pas par défaut dans le cache de SDR apparaître. On obtient à l’écran :

94
si on cherche une session dans le SDR et qu’on la trouve, on cliquer dessus et une nouvelle
fenêtre apparaît :

95
Pour rejoindre la session, Sdr nous donne la possibilité de passer par la passerelle UTG grâce
aux fenêtres suivantes :

Le rafraîchissement des sessions sur SDR pouvant être très long, on peut ainsi, dans le cas ou
l’on connaît les adresses de sessions Vic et Rat, utiliser SDR Relay disabled.

- Sans SDR Relay :

On lance UTG without Sdr Relay et on rejoint les sessions en tapant les adresses multicast, les
ports et les ttl dans les cases prévues à cet effet.

96
Dans les deux cas on obtient à la suite de ces saisies :

97
avec ou sans le Sdr en fonction de la méthode choisie.

Pour vic, une fenêtre affiche le transcodage effectué entre la ou les stations émettrice en
multicast et le flux unicast reçu :

c) Tests effectués

(1) En local

Les stations que j’utilise pour faire les tests se trouvant sur un réseau multicast, j’ai utilisé un
logiciel de firewall me permettant de filtrer toute la plage d’adresse de classe D que j’ai
installé sur ma station réceptrice. Après installation du firewall, la réception se faisait sans
difficulté.

(2) UREC

Afin de tester UTG dans un rayon plus large, j’ai collaboré avec Philippe LECA, ingénieur à
l’UREC. J’ai collaboré avec cette personne car la passerelle UTG avait déjà fait l’objet de
tests au sein de l’UREC, et donc elle connaissait déjà les utilitaires UTG. Basé à Grenoble sur
un réseau unicast, Philippe LECA a bien reçu la vidéo et l’audio transmise via la passerelle
UTG.

(3) CCK

Le but de l’installation d’un service UTG au sein de Renater étant d’ offrir l’accès au
multicast aux partenaires n’y ayant pas accès, j’ai effectué de nombreux tests avec le CCK. Le
CCK a réussit à obtenir durant une session la vidéo. C’est le meilleur résultat que nous ayons

98
obtenu. La plupart du temps, le CCK recevai bien les flux audios et vidéos mais uniquement
les flux. C’est à dire que par exemple, dans la fenêtre informant des flux vidéos (la fenêtre
blanche), il était indiqué la totalité des participants à une session multicast, mais rien ne
s’affichait dans la fenêtre VIC, de même pour l’audio, la totalité des participants était bien
présente dans la fenêtre RAT mais aucun son n’était disponible.

(4) Conclusion à ce stade

En disposant d’une liaison trop peu stable entre le CKK et Renater, il paraît logique de dire
que l’accès à une session multicast via UTG est sensible à la gigue, la perte de paquets, au
RTT trop important et à la distance. D’autres tests doivent être effectués afin de confirmer ces
problèmes et de les résoudre.

99
Conclusion

L’évolution des contacts et des partenariats cette année a montré que le projet Athena était
actif et obtenait des résultats très satisfaisants. Après des partenariats signés avec deux sites
académiques de Dakar, L’ESMT et l’UCAD, le projet Athena s’est étendu vers la Tunisie et
le Maroc (ceci grâce au projet EUMEDISCONNECT). A l’heure actuelle le projet Athena
s’est étendu plus loin que l’Afrique francophone, puisque des collaborations et des
expérimentations ont eu lieu avec l’IITK en Inde et que la même chose est à prévoir avec
l’UDG au Mexique. L’année scolaire 2002/2003 devrait même voir naître une collaboration
avec un site en Chine.

Le projet Athena est en train d’évoluer à un niveau international. Une des applications du
projet étant les cours DIM, on peut à moyen terme parler de collaboration interactive
universitaire entre des pôles à répartition géographique mondiale. Le stage a démontré la
faisabilité technique pour de telles collaborations et ceci à très faible coût. Il s’agit maintenant
de régler le problème humain ! En effet, il faut gérer le fait que tous les participants ne soit
pas francophones mais surtout savoir comment gérer le décalage horaire, et sans doute mettre
en œuvre des nouvelles méthodes de travail et de collaboration.

100
Bibliographie

• http://www.renater.fr/Video/Index.htm :
Serveur vidéo de Renaetr : IPv6, IP multicast, Mbone, Métrologie, QoS, DNS

• http://aristote1.aristote.asso.fr/Presentations/ :
Serveur vidéo contenant la présentation du projet Athena

• http://aristote1.aristote.asso.fr/CSMIL/SMILtheque.htm :
SMILthèques

• http://www.rennes.enst-bretagne.fr/~toutain/TutorialBudapest.htm
Tutoriel on IPv6- ENST Rennes

• http://www.crir.univ-avignon.fr/visio/pfe/protocoles/protocoles.htm
Les protocoles multicast

• http://www.infres.enst.fr/~dax/guides/multicast/protocol.html
Liste de RFCs et Drafts concernant les protocoles pour le mutlicast

• http://www.urec.cnrs.fr/cours/
Cours et tutoriaux de l’UREC

• http://www.univ-valenciennes.fr/CRU/MBone/
Définition du FMbone

• http://www.res.enst.fr/~dax/conf/multicast/refer.html :
Présentation sur IP multicast par ENST

• http://sem2.renater.fr
« Projet Multicast IPv6 - Déploiement du M6Bone »
Auteurs : Jérôme Durand, Pierre-Emmanuel Goiffon.

• « IPv6, Théorie et Pratique » :

Ouvrage Collectif du G6 - 2ème édition, Juin 1999.

• « Deploying IP Multicast Networks (Volume 1)

Beau Williamson, Cisco Press

• http://freebsd.org:
Site officiel de FreeBSD (Le site francophone : http://www.freebsd-fr.org/).

• http://www.kame.net :
Site officiel du projet Kame.

101
• http://www-rp.lip6.fr/~kabassan :
Auteur : Konstantin Kabassanov (Ingénieur de recherche et développement, Equipe
Réseaux et Performances, Laboratoire LIP6, Université Pierre et Marie Curie, Paris)

• http://www-mice.cs.ucl.ac.uk/multimedia/software :
Site de l’University College of London.

• www.microsoft.com:
Site officiel de microsoft.

• http://www.ipv6.rennes.enst-bretagne.fr/applis-v6.html :
« Applications et Fonctionnalités disponibles sur IPv6 »
Auteur : ENST Bretagne.

• http://abcdrfc.free.fr/rfc-vf/rfc2460.html
« Internet Protocol, Version 6 (IPv6)-Specification - le Protocole Internet Version 6-
Spécification » traduction du RFC 2460 sur IPv6 : http://www.ietf.org/rfc/rfc2460.txt.

• www.renater.fr:
Site officiel de Renater.

102