Vous êtes sur la page 1sur 102

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.

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

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

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.

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’UCAD 2 à Dakar au Sénégal. Nous avons ensemble validé les transmissions en visioconférence multicast, par l’intermédiaire des cours DIM 3 , des séminaires X-Aristote 4 , de la conférence ATHENS 5 . 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 CCK 6 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 MARWAN 7 au Maroc, L’IITK 8 en Inde, le pôle IPv6 de l’UDG 9 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

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

9 UDG : Université de Guadalajara au Mexique

Séminaires X-Aristote : Séminaires organisés par l’association Aristote sur les nouvelles technologies

IITK : Indian Institute of Technology Kanpur

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.

I. Contexte

1. ARISTOTE

I. Contexte 1. ARISTOTE Aristote est une association régie par la loi 1901. Elle a été

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 SMIL 10 d’Aristote), C-UIML (le club UIML 11 d’Aristote), GIHM 12 , Multimédia, PIN 13 , 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

2. RENATER

2. RENATER a) Le Réseau National de Télécommunications pour la Technologie, l'Enseignement et la Recherche (1)

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.

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.

11
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, 6 e 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.

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.

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

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

et Renater que l’on à déjà définit auparavant : - Université Paris VII Denis Diderot :

- Université Paris VII Denis Diderot :

auparavant : - Université Paris VII Denis Diderot : C’est le DESS Applications des Réseaux et

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 :

Réseaux et Multimédia. - Université d’Evry : L’université d’Evry est représentée dans le projet

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 :

et multimédia dans des environnements variés - L’ESMT : L'Ecole Supérieure Multinationale de

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

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,

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.

etc.

.).

- L’UCAD :

étant AFRATI située au Kenya. etc. .). - L’UCAD : L'Université de Dakar a été créée

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 :

Organisme scientifique français spécialisé en recherche agronomique appliquée aux régions chaudes, le Cirad a pour

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 :

et agroalimentaires. (2) Contacts en cours - Le CCK : Le CCK est un établissement sous

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.

- Le réseau MARWAN :

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

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.

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

- L’université de Guadalajara au Mexique :

établis : - L’université de Guadalajara au Mexique : L’université de Guadalajara a été fondée en

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 de Technologie de Kanpur en Inde : L’institut Indien de Technologie de Kanpur est

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.

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’UREC 15 ) 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

Le multicast permet de consommer moins de bande passante et diminue la charge des processeurs

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 :

format d’une adresse IPv4 multicast a le format suivant : La plage 224.0.0.0 – 224.0.0.255 est

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

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

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

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

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.

Multicast-Address-Specific

Query : utilisé pour savoir s'il

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.

1

A G2 B G1 3 Report (G1) Done (G1) Multicast Specific Query (G1)
A
G2
B
G1
3
Report (G1)
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

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

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

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

organisation de l'espace d'adressage permet de réduire

prestataire de service

considérablement la taille des tables de routage actuelles.

Cette

(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 source et destination.

)

utilisées entre les stations

- 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

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

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

e) Format de l’en-tête du datagramme IPv6 (1) Version (« Version ») Numéro de version du

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

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.

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.

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

bits 13 bits 6 bits 13 bits 16 bits 64 bits Topologie publique Topologie privée Chaque
bits 13 bits 6 bits 13 bits 16 bits 64 bits Topologie publique Topologie privée Chaque
bits 13 bits 6 bits 13 bits 16 bits 64 bits Topologie publique Topologie privée Chaque

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.

(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éfinime nt 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.

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

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>

(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

- ND : Neighbor Discovery for IP version 6, (RFC-1970)

- IPv6

: Resource ReSerVation Protocol, (RFC-2205)

: Stateless Address Autoconfiguration (RFC-1971)

(2) Les protocoles rénovés:

- : Dynamic Host Configuration Protocol for IPv6.

- : Path MTU Discovery for IP version 6 (RFC-1981)

- : Open Shortest Path First protocol for IP Version 6

- RIPng : Routing Information Protocol for IP version 6 (RFC-2080)

DHCPv6

pMTUv6

OSPFv6

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.

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

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 :

cours ou conférence en IP multicast. En voici un aperçu : Il existe cinq utilitaires composant

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

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 Live 16 ), 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.

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 DIM 18 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)

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.

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

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

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.

(2) Passerelle Haut/Bas débit Beaucoup de pays en Afrique reste encore très peu desservis en

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

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 DANTE 19 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 GEANT 20 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 NREN 21 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

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

20

Dans le cadre d'une approche globale, visant à permettre l'accès du plus grand nombre aux

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

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

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

résultats synthétique des traceroute effectués : Round-trip time : environ 180 ms Traceroute du 26 juillet

Traceroute du 26 juillet 2002 :

Ces résultats montrent une certaine instabilité au niveau du réseau « Agence Tunisienne Internet »

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 :

Durant cette session, la perte de paquet pour l’audio variait entre 0 et 5% (avec

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 ma nipulation effectuée :

- Tests d’UTG Dans un premier temps nous avons pensé à tester l’accès au multicast

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

http://www.infres.enst.fr/~dax/guides/multicast/protocol.html concernant les protocoles pour le mutlicast)

- Le protocole IPv6

(liste

de

RFCs

et

Drafts

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 :

Les résultats de cette visioconférence ont présenté une bonne qualité vidéo ainsi qu’une très bonne

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

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 :

Ce traceroute en IPv6 nous monte qu’il existe une liaison entre UDG (3ffe:0120::0:2) et le
Ce traceroute en IPv6 nous monte qu’il existe une liaison entre UDG (3ffe:0120::0:2) et le

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.

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 :

c) IPv6 à l’ESMT « IPv6 permet d’étendre les possibilités réduites données à l’ESMT par

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 (NAT 22 ), 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

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.

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

sur IPv6 (Cf. http://mother6.ipv6.renater.fr/xcast/ ). L'implémentation des protocoles de routage multicast

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 SSM 23 . Les sites qui le désirent peuvent gérer MLDv2 24 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 6WIND 25 . 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

MLDv2 : Nouvelle version du protocole MLD 25 6WIND : Constructeur de matériels réseaux d’accès IPv6

24

(2) Les sites déjà connectés à ce réseau - Sites français : 59

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

- Sites français :

(2) Les sites déjà connectés à ce réseau - Sites français : 59

- Sites à l'étranger :

- Sites à l'étranger : (3) Les différentes topologies de réseau pour accéder au réseau M6bone

(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 :

trois possibilités de se connecter au réseau M6bone et d’avoir accès à la visioconférence en IPv6

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.

Artémis Le site Artémis a accès au multicast en IPv4. Dans notre site, il faut ajouter

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

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 :

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.

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)

ÿ 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 /

make depend && make && make install

reboot

/compile/DIKE

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

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

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…

si on veut créer des tunnels qui ne sont pas définitifs… On annonce dans le fichier

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.

- /etc/rc.local :

- /etc/rc.local : Dans le fichier rc.local, on annonce la ou les interfaces tunnels et l’encapsulation

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.

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

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

d'utilisation).

- top :

permet

d'afficher

l'état

des

lecteurs

(taille,

pourcentage

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

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 :

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 :

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 :

Windows/system32/etc/hosts comme indiqué dans l’exemple suivant :

Pour

Windows,

il

faut

aussi

rentrer

une

adresse

dans

le

fichier

Windows, il faut aussi rentrer une adresse dans le fichier - Sun-Solaris : La pile IPv6

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

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

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.

(1) Arborescence des fichiers de DNS sous FreeBSD

(1) Arborescence des fichiers de DNS sous FreeBSD (2) Description des fichiers et répertoires essentiels -

(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;

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

; SOA machine

; ------- --------------------- -------------------------

@ IN

personne en charge

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.

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

peuvent être de plusieurs types. Les plus utilisés sont : NS ( Name Server) : Un

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 ) :
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 enregistreme nt 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.

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, demandé.

),

puis ceux du niveau inférieur jusqu'à résolution du nom

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

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’UCL 27 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

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.

pourra émettre sur ce réseau par le biais du serveur. (1) Solaris8 - Installation : A

(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

Vi

/etc

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:

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 !

(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 :

Voilà une idée de comment procède le serveur UTG : o SDR via relais : L’utilitaire

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.

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 :

une fenêtre lors de l’utilisation des outils du Mbone : o Le transcodage vidéo et le
une fenêtre lors de l’utilisation des outils du Mbone : o Le transcodage vidéo et le

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.

o Transcodage et mixage audio : Lorsqu’un utilisateur joint une session du SDR, comme pour

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.

pour être envoyé à plusieurs clients simultanément. o Contrôle à distance : Les agents de relais

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

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.

de management permet le contrôle des tâches à effectuer. - Installation : Système requis : Station

- 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

# !/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

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

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\

Il reste à configurer le path d’UTG pour que l’application trouve le jrew.exe permettant d’afficher

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.

Ici, il faut rentrer l’adresse de la passerelle UTG (Relay Server Address) , son nom

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 :

si on cherche une session dans le SDR et qu’on la trouve, on cliquer dessus
si on cherche une session dans le SDR et qu’on la trouve, on cliquer dessus

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

Pour rejoindre la session, Sdr nous donne la possibilité de passer par la passerelle UTG

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

par la passerelle UTG grâce aux fenêtres suivantes : Le rafraîchissement des sessions sur SDR pouvant
par la passerelle UTG grâce aux fenêtres suivantes : Le rafraîchissement des sessions sur SDR pouvant

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.

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

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

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 :

stations émettrice en multicast et le flux unicast reçu : c) Tests effectués (1) En local

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

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.

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.

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.

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.