• Aucun résultat trouvé

Transports nouvelle génération dans les réseaux à très haut débit

N/A
N/A
Protected

Academic year: 2021

Partager "Transports nouvelle génération dans les réseaux à très haut débit"

Copied!
167
0
0

Texte intégral

(1)

HAL Id: tel-00010643

https://tel.archives-ouvertes.fr/tel-00010643

Submitted on 14 Oct 2005

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

haut débit

Pawel Hadam

To cite this version:

Pawel Hadam. Transports nouvelle génération dans les réseaux à très haut débit. Réseaux et télé- communications [cs.NI]. Institut National Polytechnique de Grenoble - INPG, 2005. Français. �tel- 00010643�

(2)

INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE

No attribu´ e par la biblioth` eque

TH` ESE

pour obtenir le grade de

DOCTEUR DE L’INPG

Sp´ecialit´e : « Informatique : Syst`emes et Communications »

pr´epar´ee au laboratoireLSR – IMAG dans le cadre de l’ ´Ecole Doctorale

« Math´ematiques, Sciences et Technologies de l’Information »

pr´ esent´ ee et soutenue publiquement par

Pawe l Hadam

Le 29 Juin 2005

Transports nouvelle g´ en´ eration dans les r´ eseaux ` a tr` es haut d´ ebit

Directeur de th` ese : M. Andrzej Duda Co-directeur de th` ese : M. Jean-Luc Richier

JURY :

M. Jacques Mossi` ere , Pr´ esident M. ´ Eric Fleury , Rapporteur M. Laurent Toutain , Rapporteur

M. Andrzej Duda , Directeur de th` ese

M. Jean-Luc Richier , Co-directeur de th` ese

M. Franck Rousseau , Examinateur

(3)
(4)

Remerciements

Je tiens tout d’abord ` a remercier particuli` erement M. Andrzej Duda pour m’avoir accueilli au sein de l’´ equipe Drakkar au laboratoire LSR et pour avoir encadr´ e ma th` ese pen- dant ces trois ann´ ees. Je tiens ´ egalement ` a remercier M. Jean-Luc Richier, co-directeur de cette th` ese, pour toute sa coop´ eration et toutes les discussions qui ont beaucoup contribu´ e

`

a la forme finale de mon travail.

Je remercie les deux rapporteurs M. ´ Eric Fleury et M. Laurent Toutain d’avoir accept´ e de lire et ´ evaluer ma th` ese. Je voudrais aussi remercier M. Jacques Mossi` ere d’avoir accept´ e d’ˆ etre le pr´ esident du jury.

Je remercie toutes les personnes que j’ai rencontr´ ees au cours du projet VTHD++, surtout l’´ equipe de l’ENST Bretagne pour leur support et leur coop´ eration pendant les exp´ eriences men´ ees sur le r´ eseau VTHD.

Je voudrais remercier aussi l’ensemble des coll` egues du laboratoire LSR pour leur amiti´ e et leur sympathie. Mes remerciements vont surtout aux membres de l’´ equipe Drakkar, Gilles Berger-Sabbatel, Jacques Chassin de Kergommeaux, Dominique Decouchant, Martin Heusse, Pascal Sicard, ainsi qu’aux th´ esards qui ont partag´ e avec moi la vie de jeune cher- cheur, notamment Laurentiu-Sorin Paun, Cristina Pop, Vincent Untz, Justinian Oprescu, Fabrice Salp´ etrier, Phuong-Hoang Nguyen, Hoa-Binh Nguyen, Leyla Toumi et Stephan Lo-Presti.

Je remercie plus particuli` erement Franck Rousseau pour tous ses commentaires et ses remarques qui ont guid´ e et bien am´ elior´ e ma recherche. Je remercie aussi Paul Starzetz qui m’a beaucoup aid´ e pendant le travail avec le noyau Linux.

Je voudrais remercier M. Roland Groz avec qui j’ai pu gagner mes premi` eres exp´ eriences p´ edagogiques. Son professionnalisme et ses remarques pr´ ecieuses ont beaucoup apport´ e ` a mon travail p´ edagogique avec les ´ etudiants du D´ epartement T´ el´ ecommunication de l’INP Grenoble.

Je voudrais adresser aussi un grand merci ` a tous mes amis polonais, fran¸cais et ceux

venant du diff´ erents pays du monde que j’ai rencontr´ e ` a Grenoble : Marta, Magda, Wik-

(5)

mon s´ ejour ` a Grenoble inoubliable.

Finalement, je souhaite remercier ma femme Monika pour son soutien constant dans mon travail et pour avoir ´ et´ e toujours ` a mes cˆ ot´ es tout au long de cette th` ese.

A toutes ces personnes je dis un grand merci.

(6)

Table des mati` eres

1 Introduction 1

1.1 Motivation . . . . 1

1.2 Contexte et objectif de cette th` ese . . . . 3

1.3 Contribution . . . . 4

1.4 Organisation du manuscrit . . . . 5

I Transport concurrent et multichemin 7 2 Introduction 9 3 Probl´ ematique du multi-acc` es 11 3.1 Adresse source . . . . 12

3.2 Adresse destination . . . . 12

3.3 Changement d’une adresse . . . . 13

3.4 S´ ecurit´ e . . . . 13

3.5 Gestion d’adresses . . . . 13

4 Solutions existantes au probl` eme du multi-acc` es 15 4.1 Homeless Mobile IP . . . . 15

4.2 Host Identity Payload . . . . 16

4.3 LIN6 . . . . 17

4.4 Multi Homing Aliasing/Translation Protocol . . . . 18

4.5 Stream Control Transmission Protocol . . . . 19

4.6 End-Point Control Protocol . . . . 20

4.7 Multi6 shim . . . . 20

5 SCTP 23 5.1 Format de l’unit´ e de protocole . . . . 24

5.2 Initialisation s´ ecuris´ ee . . . . 25

5.3 Fermeture d’une association . . . . 29

5.4 Multistreaming . . . . 30

5.5 Multi-acc` es . . . . 31

i

(7)

6 Mesures de performance 35

6.1 Description des environnements de test . . . . 35

6.1.1 Environnement local . . . . 36

6.1.2 Environnement VTHD++ . . . . 37

6.1.3 Logiciels de mesures - sctpperf . . . . 39

6.2 Le surcoˆ ut des entˆ etes protocolaires . . . . 40

6.3 Tests effectu´ es . . . . 42

6.3.1 Taille de message . . . . 42

6.3.2 Nombre de flots . . . . 44

6.3.3 Taille des tampons d’envoi et de r´ eception . . . . 45

6.3.4 Associations SCTP simultan´ ees . . . . 48

6.3.5 Associations concurrentes . . . . 49

6.3.6 Calcule du code de d´ etection d’erreurs . . . . 51

6.4 Conclusion . . . . 53

7 Multi-acc` es dans SCTP 55 7.1 Configuration de tests . . . . 55

7.2 Exemple de bon fonctionnement . . . . 56

7.3 Exemple d’un fonctionnement incorrect . . . . 58

8 Extensions du multi-acc` es dans SCTP 61 8.1 Utilisation de toutes les adresses accessibles . . . . 61

8.1.1 Id´ ee du prototype . . . . 62

8.1.2 Gestion du routage . . . . 63

8.1.3 Exp´ eriences avec le prototype . . . . 63

8.2 Transmissions concurrentes . . . . 65

8.2.1 Prototype . . . . 65

8.2.2 Exp´ erience avec le prototype . . . . 65

9 Conclusion sur le transport concurrent et multichemin 69 II Transport de distribution de contenu 71 10 Introduction 73 11 Probl´ ematique 75 12 Le multicast IP 77 12.1 Les principes du multicast IP . . . . 77

12.2 Techniques de construction de l’arbre de distribution . . . . 78

ii

(8)

12.2.1 ´ Eviter les boucles . . . . 78

12.2.2 Inondation-et-´ elagage . . . . 79

12.2.3 L’arbre partag´ e . . . . 79

12.3 Les protocoles de routage multicast . . . . 80

12.3.1 Protocoles du type dense . . . . 80

12.3.2 Protocoles du type dispers´ e . . . . 82

12.4 Allocation d’adresses de groupes . . . . 84

12.4.1 Multicast sp´ ecifique ` a la source . . . . 85

12.5 Gestion de groupes . . . . 85

12.6 Gestion de sessions . . . . 87

12.6.1 Annoncer des sessions . . . . 87

12.6.2 Initier des sessions . . . . 88

12.6.3 Description de sessions . . . . 88

12.7 Conclusion . . . . 89

13 L’architecture orient´ ee contenu 91 13.1 Le canal - format de contenu . . . . 92

13.1.1 Le corps . . . . 92

13.1.2 L’´ etiquette . . . . 93

13.1.3 Les identificateurs . . . . 95

13.1.4 Le transport du canal . . . . 97

13.2 L’architecture de r´ eseau . . . . 98

13.2.1 R´ eseau du cœur . . . . 99

13.2.2 R´ eseau local d’acc` es . . . . 99

13.3 Routage orient´ e contenu . . . . 101

13.3.1 Table de routage . . . . 101

13.3.2 Les messages de contrˆ ole . . . . 102

13.3.3 L’arbre du diffusion dans le r´ eseau du cœur . . . . 103

13.3.4 Le multicast s´ electif dans des r´ eseaux locaux d’acc` es . . . . 105

13.4 Les services - la mise ` a la disposition du contenu . . . . 107

13.4.1 Annonceur - annoncer le contenu . . . . 107

13.4.2 Navigateur - choisir et demander le contenu . . . . 108

13.4.3 Player - recevoir et consommer le contenu . . . . 109

13.5 S´ ecurit´ e . . . . 109

13.5.1 Authentification . . . . 110

13.5.2 Autorisation . . . . 110

13.6 Fiabilit´ e de transmission . . . . 112

13.7 Conclusion . . . . 113

14 Sc´ enario d’application 115

iii

(9)

15.2 Exp´ eriences et r´ esultats . . . . 122

15.2.1 D´ elai de traitement . . . . 122

15.2.2 D´ ebit . . . . 123

15.2.3 Fonctionnement . . . . 123

15.3 Conclusion . . . . 123

16 Conclusion sur le transport de distribution de contenu 125 17 Conclusion de la th` ese et perspectives 127 III Annexes 131 A Abr´ eviations 133 B Le routage orient´ e contenu 137 B.1 LOCAL ANNOUNCE . . . . 137

B.2 LOCAL TRAFFIC . . . . 138

B.3 LOCAL REQUEST . . . . 139

B.4 LOCAL STOP . . . . 140

B.5 CORE TRAFFIC . . . . 141

B.6 CORE PRUNE . . . . 142

B.7 CORE RENEW . . . . 143

B.8 CORE FAILURE . . . . 144

C Bibliographie 145

iv

(10)

Table des figures

3.1 Deux machines b´ en´ eficiant du multi-acc` es . . . . 11

4.1 Une socket et les structures Cache d’Hˆ ote . . . . 16

4.2 “La couche 3,5” dans HIP . . . . 17

4.3 La r´ epartition d’une adresse IPv6 dans LIN6 . . . . 17

4.4 La sous-couche multi6 shim dans la couche r´ eseau . . . . 21

5.1 Format g´ en´ eral d’un message SCTP . . . . 26

5.2 Initialisation de l’association SCTP . . . . 27

5.3 Fermeture d’une association SCTP . . . . 29

5.4 Une association SCTP avec deux chemins . . . . 32

5.5 Une association SCTP avec un seul chemin . . . . 33

6.1 L’environnement pour des tests locaux . . . . 36

6.2 L’environnement VTHD++ . . . . 38

6.3 Le pourcentage du d´ ebit nominal disponible pour des donn´ ees . . . . 41

6.4 Effet de la taille de message sur le r´ eseau local . . . . 43

6.5 Effet de la taille de message sur le r´ eseau VTHD++ . . . . 44

6.6 L’identificateur de flot dans une portion de donn´ ees . . . . 45

6.7 D´ ebit de plusieurs flots par association . . . . 46

6.8 D´ ebit par rapport aux tampons d’envoi et de la r´ eception . . . . 47

6.9 Le d´ ebit cumul´ e des associations simultan´ ees sur le r´ eseau VTHD++ . . . 48

6.10 Deux associations SCTP concurrentes . . . . 50

6.11 Une association TCP concurrente avec SCTP (messages de 10 et 1450 octets) 52 7.1 La configuration utilis´ ee pour les tests . . . . 56

7.2 Le cas de bon fonctionnement du multi-acc` es . . . . 57

7.3 Le cas d’un fonctionnement incorrect du multi-acc` es . . . . 58

8.1 Les quatre chemins possibles entre le client et le serveur . . . . 62

8.2 La table de routage sp´ ecifique . . . . 63

8.3 Configuration de l’exp´ erience . . . . 64

8.4 Le changement de chemin pendant l’association . . . . 64

8.5 La transmission de donn´ ees pendant l’exp´ erience . . . . 66

v

(11)

13.3 Des paquets UDP portant des donn´ ees d’un canal . . . . 98

13.4 La partie locale de l’architecture . . . . 100

13.5 La table de routage . . . . 102

13.6 L’abonnement d’utilisateurs . . . . 107

15.1 Le routage par contenu dans le noyau Linux . . . . 119

15.2 L’environnement pour les m´ esures du d´ elai de traitement de paquets . . . . 120

15.3 L’environnement pour les tests du routage par contenu . . . . 121

15.4 D´ elai de traitement introduit par le module du routage par contenu . . . . 122

vi

(12)

Liste des tableaux

5.1 Les types des portions de SCTP . . . . 25

6.1 Configuration de la machine no.1 - client . . . . 36

6.2 Configuration de la machine no.2 - serveur . . . . 37

6.3 Configuration de la machine no.3 - client ` a Rennes . . . . 38

6.4 Les tailles des entˆ etes . . . . 41

6.5 L’influence du code de d´ etection d’erreurs sur le d´ ebit . . . . 53

8.1 Les d´ ebits sur plusieurs chemins . . . . 66

vii

(13)
(14)

Chapitre 1 Introduction

1.1 Motivation

Aujourd’hui nous pouvons observer une ´ evolution tr` es importante des r´ eseaux. Cette

´

evolution prend deux formes : le nombre et la diversit´ e de technologies et le d´ ebit offert par les nouvelles technologies. Les ordinateurs personnels commercialis´ es actuellement sont

´

equip´ es d’office de plusieurs interfaces r´ eseau. Il s’agit, par exemple, de cartes Ethernet 1Gb, de cartes sans fils 802.11g ou de modems ADSL. La t´ el´ ephonie mobile arrive avec UMTS.

Le d´ ebit ant´ erieurement mesur´ e en Kb/s se mesure maintenant en Gb/s et le progr` es n’a pas l’air de pouvoir s’arrˆ eter ` a ce point. Ce progr` es peut continuer et le d´ ebit peut plus que doubler chaque ann´ ee pendant au moins 30 ans qui viennent [1]. Il est clair que le tr` es haut d´ ebit devient aujourd’hui la r´ ealit´ e et qu’il est disponible pour tout le monde sous des formes diverses et ´ economiques.

D’un autre cˆ ot´ e, l’Internet d’aujourd’hui est toujours principalement bas´ e sur le pro- tocole IPv4 (Internet Protocol, version 4 )[2] dans la couche r´ eseau et sur les protocoles TCP (Transmission Control Protocol)[3] et UDP (User Datagram Protocol )[4] dans la couche transport. Ces protocoles ont ´ et´ e propos´ es et d´ evelopp´ es dans les ann´ ees 70 pour des technologies qui peuvent ˆ etre aujourd’hui consid´ er´ ees comme des technologies anciennes.

A cette ´ ` epoque, qui est consid´ er´ ee comme l’´ epoque de la naissance de l’Internet dans sa forme moderne, le r´ eseau ´ etait une innovation et a vite ´ evolu´ e vers un r´ eseau global com- prenant une centaine de machines. Sa bande passante ´ etait fortement limit´ ee et tr` es ch` ere.

Les interfaces r´ eseau n’´ etaient pas aussi populaires qu’elles le sont aujourd’hui. Tout cela a provoqu´ e la naissance de protocoles adapt´ es au contexte existant. Les protocoles ´ etaient optimis´ es pour ne pas gaspiller des ressources pr´ ecieuses. Alors qu’aujourd’hui l’Internet global est pass´ e ` a des millions d’utilisateurs ` a l’´ echelle globale et que les technologies sont plus avanc´ ees, les protocoles TCP/IP (Internet Protocol ) fonctionnent toujours et assurent la connectivit´ e pour ses utilisateurs. Cela prouve que les concepts de bases ´ etaient solides et ont bien r´ esist´ e au temps et ` a l’´ evolution constante. N´ eanmoins, l’h´ eritage historique de

1

(15)

TCP/IP peut provoquer certaines contraintes. Il est difficile d’´ etendre les fonctionnalit´ es ou d’en ajouter de nouvelles, par exemple le multi-acc` es, la communication multipoint et les m´ ecanismes de qualit´ e de service (QoS). Mˆ eme si certains m´ ecanismes et protocoles one ´ et´ e propos´ es, leur d´ eploiement ` a l’´ echelle globale est fortement limit´ e. Le protocole IPv6 (Internet Protocol, version 6 )[5] a apport´ e un espoir en proposant un nouvel adres- sage. Malgr´ e cela, une adresse IP garde toujours deux fonctions diff´ erentes, la localisation et l’identification, qui ne coop` erent pas bien dans toutes les situations.

Cette th` ese a ´ et´ e motiv´ ee par les questions qu’on peut se poser en observant ce progr` es technologique. Nous avons voulu savoir comment on peut apporter de nouvelles fonctionnalit´ es dans le contexte de r´ eseaux ` a tr` es haut d´ ebit. Nous pensons qu’avec l’apparition des r´ eseaux ` a tr` es haut d´ ebit, les paradigmes de transmission de donn´ ees peuvent ´ evoluer. Auparavant, quand le d´ ebit ´ etait une ressource rare est ch` ere, on ´ evitait de transf´ erer inutilement les donn´ ees. On pr´ ef´ erait les traiter et transf´ erer uniquement les r´ esultats ou les donn´ ees explicitement demand´ ees et n´ ecessaires. Maintenant les moyens de transmission sont aussi abondants que les moyens de traitement de donn´ ees. Cette situation permet de transf´ erer plus de donn´ ees avant de les avoir trait´ ees, dans leur forme brute.

Nous laissons le traitement et la s´ election des donn´ ees aux r´ ecepteurs qui s’en occupent, une fois les donn´ ees entr´ ees en leur possession.

Dans cette th` ese nous cherchons des propositions qui peuvent apporter deux fonction- nalit´ es :

Le multi-acc` es - Du point de vue de la multitude de technologies, une machine poss´ edant plusieurs interfaces r´ eseau n’est plus identifi´ ee par une adresse unique.

Elle peut profiter du multi-acc` es

1

. Le multi-acc` es donne la possibilit´ e d’utiliser plu- sieurs interfaces r´ eseau d’une machine terminale pour profiter de plusieurs chemins de transmission ind´ ependants entre deux extr´ emit´ es.

La distribution du contenu - En consid´ erant la bande-passante offerte par les r´ eseaux ` a tr` es haut d´ ebit, nous pensons tout de suite ` a en profiter pour la distribution de donn´ ees multim´ edia. Cela implique l’utilisation de protocoles de communication multipoint qui permettent une transmission de donn´ ees entre plusieurs utilisateurs ` a chaque extr´ emit´ e (plusieurs ´ emetteurs et/ou plusieurs destinataires).

Nous cherchons des protocoles qui peuvent fournir ces deux types de fonctionnalit´ es.

Dans cette th` ese, nous voulons explorer des m´ ethodes diff´ erentes de transport r´ eseau

2

.

1Nous utilisons ce terme pour le terme anglais multihoming. Dans la litt´erature francaise on peut

´

egalement trouver le termemulti-domiciliation.

2Dans ce contexte la notion de transport englobe les couches r´eseau et transport. Nous consid´erons le transport comme l’ensemble de m´ecanismes qui assurent l’adressage, le routage et la gestion de la transmission de donn´ees entre les ´emetteurs et les r´ecepteurs des donn´ees. Le transport offre sa fonctionnalit´e aux applications de mani`ere transparente.

(16)

1.2. CONTEXTE ET OBJECTIF DE CETTE TH ` ESE 3 Pour les deux probl` emes pr´ esent´ es, il existe plusieurs propositions, surtout dans la couche application. Nous pensons ici aux r´ eseaux CDN (Content Distribution Network )[6]

ou peer-to-peer. Dans les deux cas, les solutions permettent d’´ etablir plusieurs connexions ind´ ependantes pour une application, ce qui peut offrir une solution aux probl` emes du multi-acc` es et de la communication multipoint. Les propositions qui utilisent des caches (des copies de donn´ ees r´ eparties g´ eographiquement) facilitent la distribution de contenu multim´ edia, en le rapprochant des utilisateurs potentiellement int´ eress´ es.

N´ eanmoins, les solutions impl´ ement´ ees dans la couche d’application pr´ esentent des inconv´ enients. Elles ne coop` erent pas correctement entre elles et ne sont pas facilement r´ eutilisables dans d’autres applications. Cela nous a motiv´ e ` a chercher des solutions dans les couches r´ eseau et transport. De cette fa¸con, nous gagnons l’universalit´ e d’une solution qui peut servir comme une base solide pour des applications diverses, par exemple pour les CDN ou peer-to-peer.

1.2 Contexte et objectif de cette th` ese

Le travail de la recherche de cette th` ese a ´ et´ e effectu´ e au sein de l’´ equipe Drakkar du laboratoire LSR-IMAG et financ´ ee par le projet VTHD++ (Vraiment Tr` es Haut D´ ebit).

VTHD++ [7] est un projet scientifique soutenu par le R´ eseau National de Recherche en T´ el´ ecommunications et men´ e entre les diff´ erents organismes de recherche fran¸cais sur une plate-forme d’exp´ erimentation IP/WDM. Les organismes de recherche suivants ont parti- cip´ e ` a ce projet : France T´ el´ ecom R&D, l’ENST, l’ENST Bretagne, l’Institut EURECOM, l’INRIA et l’IMAG. Le projet a eu pour ambition de d´ evelopper des techniques, des ap- plications et des services pour l’Internet nouvelle g´ en´ eration. Il s’agit, entre autres, du multicast, du multi-acc` es (multihoming), de la qualit´ e de service, de l’exploitation des ou- tils d’ing´ enierie de trafic ou d´ eploiement d’IPv6. Le projet se d´ eroulait sur une plate-forme VTHD qui a ´ et´ e cr´ e´ ee pour donner une possibilit´ e d’exp´ erimentation ` a tr` es haut d´ ebit. Le r´ eseau dorsal de la plate-forme VTHD couvrait plusieurs centres de recherche en France et comportait des routeurs interconnect´ es par des liens ` a tr` es haut d´ ebit, des liens op- tiques longue distance ` a 1 ou 2,5 Gbit/s. L’infrastructure dorsale de la plate-forme a ´ et´ e emprunt´ ee ` a l’infrastructure de transport de France T´ el´ ecom. Pendants nos travaux, nous avons exp´ eriment´ e avec un lien ` a tr` es haut d´ ebit entre Grenoble et Rennes.

L’objectif de cette th` ese ´ etait d’´ etudier le changement des concepts r´ eseau apparaissant

avec le progr` es technologique observ´ e. Les concepts existant jusqu’` a maintenant ne sont

plus suffisants, ´ etant donn´ e qu’ils ont ´ et´ e con¸cus dans un autre contexte et pour une

r´ ealit´ e technologique diff´ erente. C’est pourquoi, les protocoles existants peuvent freiner le

d´ eveloppement de nouveaux services r´ eseau et des possibilit´ es ouvertes par une nouvelle

technologie. Nous nous sommes donc orient´ es vers de nouvelles fonctionnalit´ es au niveau

r´ eseau et transport : le multi-acc` es et la diffusion.

(17)

1.3 Contribution

Le travail r´ ealis´ e pendant cette th` ese s’ins` ere dans le domaine de l’ing´ enierie de pro- tocoles r´ eseau. Notre objectif est de proposer aux utilisateurs des solutions qui leur permettent de profiter pleinement, facilement et efficacement de nouvelles technologies.

Plus particuli` erement, nous pensons ici aux r´ eseaux ` a tr` es haut d´ ebit offerts aux utilisa- teurs. Nous partons du constat que cet av` enement de nouvelles technologies n´ ecessite un changement de certains concepts du r´ eseau. Dans cette th` ese, nous traitons deux aspects li´ es ` a la red´ efinition de l’adressage et de la notion de connexion. Tout d’abord, nous nous effor¸cons de trouver une solution qui permet ` a l’utilisateur d’utiliser plusieurs interfaces r´ eseau pour pouvoir augmenter la capacit´ e et la fiabilit´ e de ses connexions. Ensuite, nous cherchons ` a proposer un protocole qui, grˆ ace ` a un r´ eseau ` a tr` es haut d´ ebit, facilite la dis- tribution du contenu multim´ edia. Nous essayons d’apporter nos solutions dans les couches r´ eseau et transport pour qu’elles soient universelles pour les applications.

Le multi-acc` es donne la possibilit´ e d’utiliser plusieurs interfaces r´ eseau dans une ma- chine terminale o` u l’utilisateur est capable de changer les interfaces sans interrompre les transmissions de donn´ ees en cours. On d´ efinit ´ egalement le multi-acc` es simultan´ e. C’est la possibilit´ e d’utiliser plusieurs interfaces r´ eseau pour acheminer diff´ erents flots de donn´ ees par des interfaces diff´ erentes selon le choix de l’utilisateur. Le multi-acc` es est introduit pour atteindre une meilleure qualit´ e de service, une meilleure fiabilit´ e et une transmission plus optimale en profitant de plusieurs chemins dans le r´ eseau. Dans cette situation, une connexion entre deux utilisateurs ne peut plus ˆ etre d´ efinie par une adresse source et une adresse destination ; la d´ efinition devrait changer. Les extr´ emit´ es d’une connexion sont des groupes d’adresses fonctionnant ´ egalement pour permettre la transmission de donn´ ees. Plu- sieurs chemins ind´ ependants sont possibles entre deux extr´ emit´ es de la connexion. Dans cette partie de la th` ese nous pouvons r´ esumer les principales contributions de mani` ere suivante :

– Nous avons ´ etudi´ e et d´ efini les exigences qui doivent ˆ etre satisfaites par un proto- cole de multi-acc` es. Apr` es un ´ etat de l’art, nous avons constat´ e que le protocole SCTP (Stream Control Transmission Protocol )[8] propose des bases propres et so- lides pour le multi-acc` es au niveau transport. Des ´ etudes plus approfondies de SCTP et des exp´ eriences avec son support pour le multi-acc` es nous ont amen´ es ` a constater que SCTP souffre d’un probl` eme dans son comportement. Nous avons identifi´ e ce probl` eme et propos´ e une modification du protocole qui le r´ esout. Un prototype a

´ et´ e ´ elabor´ e et ´ evalu´ e. Nous l’avons test´ e en effectuant une exp´ erience qui n’´ etait pas possible auparavant avec le SCTP classique.

– Nous avons con¸cu et ´ elabor´ e un outil de mesure de performance de SCTP. Cet outil ` a

´ et´ e utilis´ e pour mener une s´ erie de mesures de performance de SCTP sur des r´ eseaux

`

a tr` es haut d´ ebit de types diff´ erents. Dans certains mesures, SCTP a ´ et´ e confront´ e ` a

(18)

1.4. ORGANISATION DU MANUSCRIT 5 TCP.

– Nous avons propos´ e une extension du protocole SCTP qui permet d’effectuer la transmission simultan´ ee et multichemin dans une seule connexion en profitant du multi-acc` es. Un prototype a ´ et´ e r´ ealis´ e et une exp´ erience a montr´ e ces avantages. Les r´ esultats sont encourageants et ouvrent des perspectives int´ eressantes.

La bande-passante offerte par des r´ eseaux ` a tr` es haut d´ ebit permet d’aborder la dis- tribution de donn´ ees multim´ edia, par exemple vid´ eo et audio. Cela implique l’utilisation des protocoles de communication multipoint qui permettent une transmission de donn´ ees entre plusieurs utilisateurs ` a chaque extr´ emit´ e (plusieurs ´ emetteurs et/ou plusieurs desti- nataires). Dans les approches actuelles, un adressage sp´ ecifique est utilis´ e : une extr´ emit´ e est d´ efinie par une adresse qui d´ esigne un groupe d’utilisateurs. Si nous disposons d’une tr` es grande bande-passante, nous pouvons ´ etudier d’autres mod` eles de distribution de contenu multim´ edia. Au lieu d’avoir une gestion explicite de groupes o` u chaque utilisateur demande l’adh´ esion au groupe, nous pr´ ef´ erons des groupes implicites o` u l’´ emetteur cr´ ee un groupe en d´ ecidant d’envoyer un contenu. Le contenu est propos´ e par d´ efaut ` a tous les utilisateurs susceptibles d’ˆ etre int´ eress´ es par ce contenu, qui n’ont pas besoin d’adh´ erer explicitement au groupe. Cette approche implique certainement une plus grande utilisation de la bande-passante. Cependant, en profitant du tr` es haut d´ ebit, nous pouvons consacrer une partie de la bande-passante ` a la recherche de la simplicit´ e et de l’universalit´ e de la solution. La contribution de cette partie de la th` ese se r´ esume de mani` ere suivante :

– Une architecture de distribution du contenu multim´ edia a ´ et´ e d´ efinie. Cette architec- ture est orient´ ee contenu et propose un nouveau concept d’une session multim´ edia.

La notion de session int` egre le contenu v´ ehicul´ e ainsi que l’adressage et le routage orient´ ee contenu. La distribution de session se fait en mode “forc´ e”

3

, dans lequel l’´ emetteur envoie le contenu aux utilisateurs sans demande pr´ ealable du cˆ ot´ e utilisa- teur. Un prototype simple a ´ et´ e ´ elabor´ e et des exp´ eriences ont ´ evalu´ e le coˆ ut de son fonctionnement.

Les contributions de cette th` ese montrent une ´ evolution des services offerts par des protocoles r´ eseau et transport. Notre approche s’appuie sur de nouvelles d´ efinitions de l’adressage, de routage et de la notion de connexion.

1.4 Organisation du manuscrit

Cette th` ese comprend deux parties principales.

La premi` ere partie, qui aborde la probl` ematique du transport multichemin et concur- rent, comprend 8 chapitres et est organis´ ee de la fa¸con suivante. Apr` es une courte intro-

3Nous utilisons ce terme pour le terme anglaispush mode.

(19)

duction dans le chapitre 2, le chapitre 3 pr´ esente la probl` ematique du multi-acc` es. Les probl` emes apparaissant dans le multi-acc` es y sont d´ ecrits et discut´ es. Pour situer notre

´

etude, nous proposons d’abord une revue des solutions les plus int´ eressantes dans le do- maine du multi-acc` es (chapitre 4). Ensuite, nous ´ etudions en d´ etails le protocole SCTP (chapitre 5). Dans le chapitre 6, nous pr´ esentons l’outil de mesure de performance ainsi que les mesures de performance effectu´ ees sur des r´ eseaux ` a haut d´ ebit et leurs r´ esultats.

La partie qui suit (chapitre 7) porte sur les exp´ eriences avec le multi-acc` es dans SCTP.

Nous y montrons deux sc´ enarios diff´ erents, un o` u le multi-acc` es de SCTP s’av` ere b´ en´ efique, et l’autre o` u il n’apporte pas d’am´ eliorations. Le chapitre 8 est consacr´ e ` a nos deux ex- tensions propos´ ees pour le multi-acc` es dans SCTP. Ce chapitre d´ ecrit les extensions et les prototypes r´ ealis´ es, des exp´ eriences men´ ees et les r´ esultats obtenus. Cela nous am` ene ` a formuler des conclusions et ` a r´ efl´ echir sur les perspectives dans le chapitre 9.

La deuxi` eme partie de notre th` ese est consacr´ ee au transport de contenu. Elle comprend 7 chapitres et est organis´ ee comme suit. L’introduction est suivie de l’exposition de la probl` ematique (chapitre 11). Notre proposition ´ etant ancr´ ee dans les travaux existants, nous pr´ esentons l’architecture actuelle des protocoles multicast existants (chapitre 12).

Nous consacrons la suite du travail ` a la description de notre architecture orient´ ee contenu (chapitre 13). Pour mieux illustrer nos propos, nous pr´ esentons un sc´ enario d’application pour notre architecture dans le chapitre 14. L’´ evaluation du prototype et l’analyse des exp´ erimentations sont expos´ ees dans le chapitre 15. La conclusion et la pr´ esentation des perspectives clˆ oturent cette deuxi` eme partie de la th` ese.

Enfin, une conclusion g´ en´ erale termine la th` ese.

Les annexes contiennent la bibliographie, la liste des abr´ eviations utilis´ ees et les algo-

rithmes du routage orient´ e contenu.

(20)

Premi` ere partie

Transport concurrent et multichemin

7

(21)
(22)

Chapitre 2 Introduction

La premi` ere contribution de cette th` ese concerne le probl` eme du transport concurrent et multichemin bas´ e sur le multi-acc` es. Comme nous pouvons distinguer deux types de multi-acc` es, une explication est n´ ecessaire pour situer nos travaux.

Nous distinguons le multi-acc` es pour un site et le multi-acc` es pour les stations. Le premier refl` ete le fait qu’un r´ eseau local se connecte ` a un r´ eseau externe, public (par example l’Internet) par deux (ou plus) fournisseurs d’acc` es. Par cons´ equent, ce r´ eseau poss` ede plusieurs routeurs de sortie

1

. De cette fa¸con, plusieurs chemins vers des machines externes sont possibles pour des machines locales. Le deuxi` eme cas du multi-acc` es, celui qui nous int´ eresse, est celui des stations. Il concerne une situation particuli` ere o` u une machine poss´ edant plusieurs interfaces r´ eseau les utilise pour avoir plusieurs connexions simultan´ ees au r´ eseau. Elles restent pourtant ind´ ependantes et diff´ erentes.

Pour commencer, nous discutons la probl´ ematique du multi-acc` es pour les stations.

Nous formulons et discutons les caract´ eristiques qu’une solution doit avoir pour ce type de multi-acc` es. Ensuite, un chapitre pr´ esente des solutions existantes. Nous ne pr´ etendons pas pr´ esenter une liste exhaustive, nous discutons seulement des solutions qui, ` a notre avis, sont int´ eressantes et qui nous ont inspir´ ees dans nos travaux. Certaines d’entre elles viennent plutˆ ot du domaine de mobilit´ e - ´ etant donn´ e qu’elles traitent d’aspects similaires ` a celles du multi-acc` es, nous les prenons en compte dans notre recherche. Les autres peuvent ˆ etre appliqu´ ees aussi bien au multi-acc` es pour un site qu’au multi-acc` es pour des machines car elles pr´ esentent une approche plus g´ en´ erale.

Dans notre recherche, nous nous concentrons sur une proposition du multi-acc` es dans la couche transport. D’un cˆ ot´ e, cette orientation permet ` a notre proposition de rester invisible pour les applications : elles peuvent ´ etablir des connexions qui profitent du multi-acc` es de

1Nous pouvons imaginer une situation o`u un r´eseau local est connect´e `a plusieurs r´eseaux externes par un seul routeur. Nous consid´erons aussi ce cas comme multi-acc`es pour un site, mˆeme s’il y a certaines diff´erences entre eux. Nous ne pr´esentons pas ici ces diff´erences, parce que dans cette th`ese nous n’abordons pas ce type de multi-acc`es.

9

(23)

mani` ere transparente. D’un autre cˆ ot´ e, cette orientation est aussi invisible pour la couche r´ eseau qui reste inchang´ ee. C’est la couche transport qui g` ere plusieurs connexions au niveau r´ eseau

2

et donne ` a l’application la vision d’une connexion unique. Tout cela nous am` ene ` a proposer une solution sur la base d’une extension du protocole SCTP [8].

Etant donn´ ´ e que les r´ eseaux ` a tr` es haut d´ ebit sont au centre de notre int´ erˆ et, nous consacrons une partie de travaux ` a des exp´ eriences avec SCTP sur des r´ eseaux de ce type.

Dans ce but, un logiciel de mesure de performance a ´ et´ e ´ elabor´ e pour mener des exp´ eriences diverses. Les r´ esultats des mesures obtenus sur un r´ eseau ` a tr` es haut d´ ebit (local et aussi global) sont pr´ esent´ es dans la suite. Des exp´ eriences sur le multi-acc` es dans SCTP sont aussi pr´ esent´ ees et discut´ ees. Dans une de ces exp´ eriences nous observons un probl` eme que nous analysons et montrons comment le r´ esoudre. Notre premi` ere proposition permet d’´ eviter ce probl` eme alors que le multi-acc` es original ne donne pas de r´ esultats satisfaisants.

Notre deuxi` eme proposition permet d’augmenter la performance d’une connexion SCTP en profitant de transmissions simultan´ ees sur plusieurs chemins ind´ ependants entre deux machines. Nous d´ ecrivons ensuite deux prototypes ainsi que des r´ esultats d’exp´ eriences. Nos r´ esultats sont encourageants et ouvrent des perspectives int´ eressantes dans le domaine du multi-acc` es. Ces perspectives, discut´ ees dans la conclusion de cette partie, sont propos´ ees pour le protocole SCTP, mais elles peuvent ´ egalement ˆ etre appliqu´ ees dans d’autres solutions de multi-acc` es au niveau transport.

2Nous utilisons ici le termeconnexions au niveau r´eseaupour unchemindans le r´eseau qui interconnecte une adresse IP locale avec une adresse IP distante.

(24)

Chapitre 3

Probl´ ematique du multi-acc` es

La connexion d’une station ´ equip´ ee de plusieurs interfaces r´ eseau pose plusieurs probl` emes. Certains d’entre eux sont ´ evidents, d’autres ne peuvent ˆ etre aper¸cus qu’apr` es une ´ etude plus approfondie.

En g´ en´ eral, les probl` emes apparaissent quand une machine a plusieurs adresses IP ob- tenues de plusieurs op´ erateurs r´ eseau diff´ erents. Toutes ces adresses sont op´ erationnelles et peuvent ˆ etre utilis´ ees pour transmettre et recevoir des donn´ ees. N´ eanmoins, ces connexions peuvent avoir des caract´ eristiques diff´ erentes.

Fig. 3.1 – Deux machines b´ en´ eficiant du multi-acc` es

L’autre extr´ emit´ e de la connexion peut aussi b´ en´ eficier du multi-acc` es : il peut avoir plusieurs interfaces r´ eseau et plusieurs adresses IP. Sur la figure 3.1 on voit une situation classique o` u deux machines sont connect´ ees directement ` a l’Internet grˆ ace ` a plusieurs op´ erateurs r´ eseau. Cela veut dire qu’une carte r´ eseau dans une machine est directement reli´ ee ` a un routeur d’op´ erateur sans nœuds interm´ ediaires. Il peut y avoir alors entre les

11

(25)

deux machines plusieurs chemins dans le r´ eseau qui interconnectent des adresses de chaque cˆ ot´ e (chaque chemin interconnecte une adresses locale avec une adresse distante).

Parmi les probl` emes qui se posent dans cette situation, nous consid´ erons :

– le choix de l’interface de sortie et de l’adresse source pour des paquets d’une connexion,

– le choix de la meilleure adresse destination pour des paquets d’une connexion, – le passage progressif d’une adresse ` a l’autre (source ou destination),

– la s´ ecurit´ e pendant le changement d’adresses,

– l’ajout et la suppresion dynamique des adresses sur une machine - ce dernier probl` eme touche ` a la mobilit´ e. Dans nos travaux nous le consid´ erons comme probl` eme secon- daire et nous n’essayons pas de le r´ esoudre.

D’autres probl` emes non ´ etudi´ es dans cette th` ese sont par exemple : la mise en relation de plusieurs adresses sur une machine, le maintien de coh´ erence de cette mise en relation ou l’identification unique d’une machine poss´ edant plusieurs adresses pouvant changer.

Dans la suite, nous discutons les probl` emes annonc´ es.

3.1 Adresse source

Une machine qui b´ en´ eficie du multi-acc` es poss` ede plusieurs interfaces r´ eseau connect´ ees

`

a des op´ erateurs r´ eseau diff´ erents. Cela donne ` a la machine plusieurs connexions ind´ epen- dantes ` a l’Internet global. Chaque connexion peut avoir des caract´ eristiques diff´ erentes (prix, d´ ebit, charge). Pour choisir la meilleure connexion pour un paquet, la machine doit choisir l’interface de sortie qui offre les meilleures conditions d’envoi pour ce paquet. On doit utiliser une adresse de l’interface choisie. Si on choisit une adresse qui ne lui appartient pas, on risque le filtrage des paquets avec des adresses source ´ etrang` eres (ingress filtering

1

[9]).

3.2 Adresse destination

Chaque fois que nous envoyons un paquet, nous avons le choix entre plusieurs adresses du destinataire sur la base de l’accessibilit´ e, de la bande passante disponible ou d’un autre param` etre ou crit` ere. Notre machine peut r´ eguli` erement v´ erifier et ´ evaluer toutes les adresses du destinataire pour mieux savoir quelle adresse utiliser.

1L’ingress filteringest une m´ethode pour r´eduire le nombre de paquets avec de fausses adresses source.

Un op´erateur r´eseau filtre des paquets sortant de son r´eseau en v´erifiant leurs adresses source. Seuls les paquets portant des adresses source appartenant `a l’op´erateur sont autoris´es `a sortir du r´eseau de l’op´erateur. Un paquet portant une adresse source ´etrang`ere est rejet´e.

(26)

3.3. CHANGEMENT D’UNE ADRESSE 13

3.3 Changement d’une adresse

Si les param` etres du r´ eseau peuvent changer, la configuration d’une machine doit suivre les changements : par exemple changer aussi bien l’adresse source que l’adresse destination pour atteindre une meilleure bande passante ou une meilleure performance de la connexion.

Ces changements doivent ˆ etre effectu´ es d’une mani` ere invisible pour une connexion d´ ej` a

´

etablie. Des applications doivent ˆ etre inconscientes des changements d’adresse (ou des adresses) et doivent fonctionner sans perturbation.

3.4 S´ ecurit´ e

Le probl` eme de s´ ecurit´ e du multi-acc` es se pose quand on veut changer d’adresse pendant une connexion d´ ej` a ´ etablie (par exemple dans le cas de la mobilit´ e). Nous devons ˆ etre sˆ urs que la machine qui demande le changement d’adresse est vraiment celle de notre interlocuteur et non pas une fausse machine d’un tiers. En mˆ eme temps, nous devons savoir si toutes les adresses annonc´ ees par notre interlocuteur appartiennent vraiment ` a sa machine.

Le m´ ecanisme de changement d’adresses doit ˆ etre s´ ecuris´ e et insensible aux attaques et aux perturbations externes.

3.5 Gestion d’adresses

Si une nouvelle adresse apparaˆıt sur une machine (la machine se connecte ` a un nouveau

op´ erateur par une autre interface r´ eseau) ou si elle disparaˆıt, la configuration de la machine

doit ˆ etre adapt´ ee de mani` ere ad´ equate. Apr` es avoir ajout´ e une adresse, l’´ evaluation de

toutes les chemins rendus possibles par cette adresse doit ˆ etre effectu´ ee. Une fois l’adresse

supprim´ ee, toutes les connexions ayant utilis´ e cette adresse doivent ˆ etre transf´ er´ ees ` a une

autre adresse d’une mani` ere transparente. Le routage peut aussi ˆ etre modifi´ e apr` es l’ajout

ou la suppression d’une adresse.

(27)
(28)

Chapitre 4

Solutions existantes au probl` eme du multi-acc` es

Le probl` eme d’am´ eliorer TCP pour prendre en compte du multi-acc` es (et de la mobilit´ e) a ´ et´ e beaucoup ´ etudi´ e ces derni` eres ann´ ees. Plusieurs solutions ont ´ et´ e publi´ ees. La plupart sont exp´ erimentales et n’ont pas d´ epass´ e le stade de la proposition. Dans ce chapitre, nous pr´ esentons les approches qui proposent une solution pour le multi-acc` es. Comme ce probl` eme est assez proche du probl` eme de la mobilit´ e, ils sont souvent discut´ es ensemble.

Certaines solutions sont sp´ ecialement con¸cues pour la mobilit´ e, n´ eanmoins, elles peuvent aussi servir pour le multi-acc` es. Chaque approche sera bri` evement discut´ ee en pr´ ecisant les caract´ eristiques les plus importantes.

4.1 Homeless Mobile IP

Cette solution a ´ et´ e propos´ ee par Pekka Nikander [10]. L’id´ ee principale est d’attacher une socket ` a une nouvelle structure cache d’hˆ ote (host cache) qui contient plusieurs adresses IP au lieu d’une adresse dans la socket classique. Sur la figure 4.1 on voit une socket qui est attach´ ee localement ` a un cache d’hˆ ote et connect´ ee ` a un cache d’hˆ ote distant.

Les adresses dans les caches d’hˆ ote peuvent ˆ etre ajout´ ees et supprim´ ees ` a l’aide de messages de mise ` a jour (binding update) similaires ` a ceux de Mobile IPv6 [11] [12]. Cela permet aussi un support pour la mobilit´ e, car une machine peut se d´ eplacer d’un r´ eseau ` a un autre, donc changer son adresse IP.

Comme cette proposition a ´ et´ e plutˆ ot con¸cue pour la mobilit´ e, elle ne donne pas de support suffisant pour le multi-acc` es. Elle n’offre pas ni de choix, ni d’´ evaluation d’adresses.

15

(29)

Fig. 4.1 – Une socket et les structures Cache d’Hˆ ote

4.2 Host Identity Payload

La proposition suivante est HIP (Host Identity Protocol ). Elle a ´ et´ e propos´ ee dans trois documents d´ ecrivant l’architecture [13], le protocole [14] et l’impl´ ementation [15]. Cette proposition introduit une nouvelle couche HIP ` a la pile r´ eseau classique, plac´ ee au-dessous de la couche du transport et au-dessus de la couche du r´ eseau. C’est pour cela qu’elle est appel´ ee “la couche 3,5”. Elle est responsable de la gestion des identificateurs des machines.

Les identificateurs sont uniques et ne changent jamais pour une machine.

Sur la figure 4.2 on voit un sch´ ema des couches qui montre le principe de fonction- nement. Dans la couche transport une socket est attach´ ee ` a l’adresse IH (Identificateur d’Hˆ ote ). Ensuite, la couche HIP traduit cette adresse ` a une adresse IP. L’adresse IP est transmise ` a la couche du r´ eseau et le paquet est envoy´ e directement vers cette adresse, comme dans la pile r´ eseau classique.

Pour initier une connexion, HIP n´ ecessite des services suppl´ ementaires, notamment un r´ epertoire (de type DNS (Domain Name System) [16][17]) qui permet de trouver un serveur rendez-vous qui transmet ensuite le paquet initial ` a la destination. Le serveur rendez-vous transmet aussi les paquets dans le cas o` u les deux machines changent leur localisation en mˆ eme temps.

Mˆ eme si les machines peuvent facilement changer leurs adresses IP, ` a un moment donn´ e

une seule adresse IP est en relation avec l’identificateur IH de la machine. Cela n’est pas une

m´ ethode de multi-acc` es o` u une machine b´ en´ eficie de plusieurs adresses IP ` a tout moment.

(30)

4.3. LIN6 17

Fig. 4.2 – “La couche 3,5” dans HIP

4.3 LIN6

Cette solution propose de diviser la couche r´ eseau en deux sous-couches : la couche livraison (Delivery Sublayer) et la couche identification (Identification Sublayer) [18].

Comme cette solution est bas´ ee sur IPv6 [5], elle exploite l’adresse IPv6 sur 128 bits en la divisant en deux parties. La premi` ere partie de l’adresse contient l’identificateur de nœud (Node Identifier - LIN6 ID) et la deuxi` eme contient une localisation d’interface (Interface Locator). Les deux parties ont chacune 64 bits de longueur (cf. figure 4.3).

Fig. 4.3 – La r´ epartition d’une adresse IPv6 dans LIN6

L’identificateur de nœud fait partie de l’adresse d´ efinie dans la couche identification.

(31)

Cette partie stable et inchangeable identifie la machine d’une mani` ere unique. L’identifi- cateur du nœud est attribu´ e globalement et de cette fa¸con il est globalement unique.

Le pr´ efixe r´ eseau est d´ efini dans la couche livraison pour la localisation d’une machine.

Cette partie de l’adresse identifie le r´ eseau auquel la machine est actuellement attach´ ee.

Chaque fois que la machine se d´ eplace, le pr´ efixe r´ eseau change.

Pour permettre aux autres machines de trouver une machine, un service sp´ ecial appel´ e agent m` ere (MA - Mapping Agent) est introduit pour maintenir la correspondance entre les identificateurs de nœud (globalement connus) et les pr´ efixes r´ eseau actuels des machines.

Chaque machine a un MA o` u il est engistr´ e. Chaque MA peut servir plusieurs machines.

Le syst` eme DNS est utilis´ e pour trouver un MA pour un identificateur de nœud donn´ e.

Donc, c’est le DNS qui fait la correspondance entre l’identificateur de nœud et son MA, et c’est le MA qui fait ensuite la correspondance entre l’identificateur de nœud et le pr´ efixe r´ eseau actuel d’une machine. Une fois qu’on a l’identificateur de nœud et le pr´ efixe r´ eseau, on peut construire une adresse IP valide pour y envoyer directement des paquets.

Comme cette proposition a ´ et´ e con¸cue plutˆ ot pour la mobilit´ e, elle ne permet pas d’avoir plus d’une adresse IP en mˆ eme temps. Bien sˆ ur, on peut avoir deux interfaces r´ eseau, mais comme deux identificateurs de nœud diff´ erents seront attribu´ es aux interfaces, ils ne seront pas reconnus comme une seule machine. Cette proposition ne permet donc non plus d’avoir ni un identificateur de nœud pour plusieurs interfaces ni plusieurs pr´ efixes r´ eseau pour un identificateur nœud.

En fait, cette proposition montre une approche int´ eressante bas´ ee sur la division d’une adresse en deux parties. La premi` ere, responsable de l’identification d’une machine et la deuxi` eme, responsable de la localisation d’une machine dans le r´ eseau. Comme l’identification et la localisation sont deux fonctions compl` etement s´ epar´ ees, cette id´ ee peut ˆ etre aussi int´ eressante pour le d´ eveloppement du multi-acc` es.

4.4 Multi Homing Aliasing/Translation Protocol

Cette proposition n’est pas vraiment une solution pour le multi-acc` es [19] [20]. Les machines peuvent avoir plusieurs adresses (interfaces r´ eseau), mais ` a cˆ ot´ e de chaque extr´ emit´ e (l’´ emetteur et le destinataire), on trouve un routeur (passerelle) sp´ ecialis´ e qui transforme le cas de multi-acc` es en une connexion standard. Entre les deux passerelles le trafic est envoy´ e d’une mani` ere classique en utilisant une seule adresse de chaque passerelle.

Cela permet de b´ en´ eficier de plusieurs interfaces sur une machine, mais ne donne pas

plusieurs chemins ind´ ependants entre l’´ emetteur et le destinataire.

(32)

4.5. STREAM CONTROL TRANSMISSION PROTOCOL 19

4.5 Stream Control Transmission Protocol

SCTP est un protocole de transport r´ ecemment propos´ e [8]. Il a ´ et´ e con¸cu pour offrir de nouvelles caract´ eristiques par rapport aux protocoles de transport existants TCP et UDP.

En mˆ eme temps, il a gard´ e certaines caract´ eristiques de TCP, par exemple la fiabilit´ e et le contrˆ ole de congestion. Comme de nouvelles fonctionnalit´ es, le SCTP introduit le multi-acc` es, le multistreaming et renforce la s´ ecurit´ e des connexions. Nous d´ ecrivons ces caract´ eristiques rapidement dans la suite :

Multi-acc` es : une connexion SCTP peut utiliser plusieurs adresses de la couche r´ eseau.

En cas de rupture de connectivit´ e ` a travers l’adresse utilis´ ee, elle peut ˆ etre r´ etablie avec une autre.

Multistreaming : SCTP permet d’envoyer plusieurs flots de donn´ ees ind´ ependants sur une connexion au niveau transport. La fiabilit´ e et le contrˆ ole de congestion sont g´ er´ es ind´ ependamment pour chaque flot. S’il y a des probl` emes qui apparaissent dans un flot, ils ne d´ erangent pas les autres.

S´ ecurit´ e : SCTP propose des proc´ edures s´ ecuris´ ees d’initiation et de fermeture d’une connexion. Ces proc´ edures permettent d’´ eviter les probl` emes qui peuvent se produire dans TCP (attaques de d´ eni du service, connexions semi-ouvertes).

Interface de programmation : SCTP utilise des sockets de mani` ere similaire ` a TCP et UDP. De cette fa¸con, il est tr` es facile de r´ ecrire des applications existantes (utilisant TCP ou UDP) pour qu’elles puissent utiliser SCTP.

Les caract´ eristiques cit´ ees ci-dessus montrent que SCTP est un protocole qui garde les fonctionnalit´ es de TCP, renforce la s´ ecurit´ e des connexions et ajoute de nouvelles fonctions, notamment le multi-acc` es et multistreaming. En se situant dans la couche de transport, le protocole reste ind´ ependant de la couche r´ eseau et de l’adressage IP.

Du cˆ ot´ e des applications, SCTP est facile ` a utiliser grˆ ace ` a l’interface socket. Pour toutes ces raisons, SCTP peut ˆ etre un concurrent r´ eel de TCP en tant que protocole du transport d’utilisation g´ en´ erale. Il est bien possible que SCTP puisse remplacer TCP au moins dans certains contextes grˆ ace ` a ses nouvelles fonctionnalit´ es (le multi-acc` es, le multistreaming et la s´ ecurit´ e am´ elior´ ee). Ces constatations nous ont amen´ es ` a nous int´ eresser plus particuli` erement ` a ce protocole dans cette partie de notre travail.

Comme dans la suite de notre travail nous nous occupons plus particuli` erement de

SCTP, nous d´ ecrivons dans le chapitre 5 les d´ etails de ce protocole.

(33)

4.6 End-Point Control Protocol

Finalement, nous pr´ esentons EPCP (End-Point Control Protocol) [21]. EPCP est prin- cipalement bas´ e sur le protocole SCTP. Il propose un nouveau protocole de signalisation plac´ e entre la couche transport et la couche r´ eseau. En principe, il est ind´ ependant du niveau transport et du r´ eseau, il peut donc travailler avec des protocoles diff´ erents. Ceci est son avantage le plus important par rapport ` a SCTP.

Les machines utilisant EPCP ´ etablissent une association pour ´ echanger les adresses IP et pour les mettre ` a jour pendant les connexions en cas de besoin. Trois types d’adresses sont possibles :

– L’adresse principale (main address) - chaque machine poss` ede une seule adresse de ce type. Cette adresse est statique et ne change jamais pour une machine. Chaque machine est responsable pour annoncer cette adresse aux autres. La couche trans- port utilise cette adresse pour identifier une association et pour ´ etablir une connexion.

– L’adresse primaire (primary address) - chaque machine poss` ede une seule adresse de ce type. Cette adresse peut ˆ etre chang´ ee dynamiquement ` a tout moment.

C’est cette adresse qui est utilis´ ee par la couche r´ eseau pour envoyer des paquets. Au d´ ebut d’une association l’adresse primaire est ´ egale ` a l’adresse principale. Chaque machine doit annoncer son adresse primaire.

– L’adresse alternative (alternative address) - chaque machine peut poss´ eder z´ ero ou plusieurs adresses de ce type. Ces adresses peuvent ˆ etre dynamiquement ajout´ ees ou supprim´ ees ` a tout moment. Toutes les adresses ajout´ ees ` a une association sont d’abord class´ ees comme adresses alternatives. Plus tard, le statut d’une adresse alternative peut ˆ etre chang´ e en adresse primaire.

Il n’y a pas de r´ epertoire pour stocker les adresses, les machines doivent annoncer leurs adresses directement ` a leurs interlocuteurs.

4.7 Multi6 shim

La solution “multi6 shim” a ´ et´ e r´ ecemment propos´ ee pour le multi-acc` es des sites dans le groupe de travail IETF (Internet Engineering Task Force) multi6 [22][23]. Mais comme son approche est aussi int´ eressante pour le multi-acc` es de machines, nous la pr´ esentons ici.

Cette proposition est bas´ ee sur une couche introduite au milieu de la couche r´ eseau

(figure 4.4). Plus pr´ ecis´ ement, multi6 shim se place entre la sous-couche d’extr´ emit´ e IP

(endpoint sublayer), qui est responsable de la fragmentation, rassemblage et IPsec, et la

(34)

4.7. MULTI6 SHIM 21 sous-couche de routage (routing sublayer), qui est responsable du choix des chemins pour les paquets. Ce placement permet d’utiliser un identificateur unique de la machine (ULID - upper layer identifier) dans la sous-couche d’extr´ emit´ e, et plusieurs adresses diff´ erentes (locateurs) dans la sous-couche de routage. Multi6 shim s’occupe de la traduction de l’identificateur en diff´ erents locateurs. De cette fa¸con, du point du vue du transport et des applications, un paquet poss` ede toujours un identificateur statique (ULID), mˆ eme si finalement, pour transmettre le paquet, il est traduit en un locateur. Les paquets sont transmis dans le r´ eseau en utilisant des locateurs. ` A l’arriv´ ee ` a l’autre extr´ emit´ e, le locateur du paquet est traduit en identificateur, et le paquet est livr´ e ` a la couche sup´ erieure.

Fig. 4.4 – La sous-couche multi6 shim dans la couche r´ eseau

Ce protocole permet de g´ erer des pannes dans le r´ eseau en adaptant la traduction entre l’identificateur et le locateur. Quand une machine d´ etecte qu’il n’y a plus de communi- cation (` a cause d’une panne), le protocole peut changer le locateur et essayer de r´ etablir la communication en utilisant un autre locateur mais en gardant toujours le mˆ eme iden- tificateur. Il est propos´ e que le protocole v´ erifie et ´ evalue le chemin avant de changer de locateur.

Cette solution est ind´ ependant de la couche transport et ne traite pas des interactions

avec celle ci. Par exemple, pour le protocole TCP, il va exister de mani` ere invisible plusieurs

chemins et l’effet sur le traitement des paquets (r´ eordonnancement, d´ elais de r´ e´ emission,

calcul du RTT) n’est pas clair. Cela est acceptable dans le cas de pannes franches, mais peut

poser probl` eme si on ´ etendait cette solution ` a l’optimisation des chemins (QoS, partage de

charge, ...).

(35)
(36)

Chapitre 5 SCTP

SCTP (Stream Control Transmission Protocol ) a ´ et´ e initialement con¸cu pour transpor- ter des messages de signalisation dans des r´ eseaux de t´ el´ ecommunication. Les premi` eres exigences demand´ ees pour ce nouveau protocole ont ´ et´ e les suivantes :

– la transmission des donn´ ees en messages,

– la possibilit´ e d’assembler plusieurs messages dans un seul trame, – la livraison de paquets en s´ equence ou sans,

– la fiabilit´ e de la transmission,

– plusieurs adresses IP pour une association

1

, – plusieurs flots de messages dans une association.

Avec le temps, SCTP est devenu un protocole d’utilisation g´ en´ erale du niveau transport, comme TCP et UDP, et a ´ et´ e sp´ ecifi´ e dans RFC 2960 [8]. Les principales caract´ eristiques de SCTP sont maintenant les suivantes :

– initiation d’une association s´ ecuris´ ee - utilisation du m´ ecanisme COOKIE pour la protection contre les attaques de d´ eni du service du type SYN-flood,

– fermeture d’une association s´ ecuris´ ee - la proc´ edure ´ evite des connexions semi-ouvertes, – multi-acc` es - possibilit´ e d’utiliser plusieurs adresses IPv4 ou/et IPv6 pendant une

association,

– multistreaming - pour la transmission de donn´ ees, SCTP utilise des flots de messages ; le protocole permet d’avoir plusieurs flots ind´ ependants dans une association.

Les diff´ erences de SCTP par rapport ` a TCP sont les suivantes :

– code de d´ etection d’erreurs CRC sur 32 bits au lieu de 16 bits en TCP,

– flot de messages (appel´ es portions ou chunks) au lieu d’un flot d’octets en TCP.

Chaque message de donn´ ees porte un num´ ero de s´ equence - TSN (Transmission

1La notion d’association dans SCTP correspond `a la notion de connexion dans TCP, n´eanmoins la notion d’association est plus large, par exemple elle peut comprendre plusieurs adresses IP.

23

(37)

Sequence Number ). TSN est un identificateur unique de message dans une association.

Le contrˆ ole de la congestion est effectu´ e sur la base du TSN.

Les principales caract´ eristiques sp´ ecifiques au SCTP sont d´ ecrites plus pr´ ecis´ ement dans les sections suivantes.

5.1 Format de l’unit´ e de protocole

La structure d’une unit´ e de protocole SCTP (dans la suite nous allons utiliser la notion de message SCTP) est modulaire. Il contient une en-tˆ ete de format commun pour tous les types possibles. Il comprend aussi une ou plusieurs portions. Deux types de portions existent : la portion de donn´ ees et les portions de contrˆ ole. Il y a un seul type de portion pour contenir des donn´ ees. Pour transporter les diff´ erents messages de contrˆ ole utilis´ es pendant de diff´ erentes ´ etapes d’une association, il y a plusieurs types de portions de contrˆ ole. La sp´ ecification initiale [8] d´ efinit 14 types des portions de contrˆ ole, mais avec des extensions [24] [25], il y en a actuellement 17. Le tableau 5.1 pr´ esente tous les types de portions.

VALEUR NOM DESCRIPTION

0 DATA Les donn´ ees d’utilisateur

1 INIT Initiation d’une association

2 INIT ACK Acquittement de la portion INIT

3 SACK Acquittement de la r´ eception de

donn´ ees

4 HEARTBEAT V´ erification d’accessibilit´ e d’une adresse IP de l’autre extr´ emit´ e

5 HEARTBEAT ACK Acquittement de la portion HEARTBEAT

6 ABORT Fermeture imm´ ediate

d’une association

7 SHUTDOWN D´ ebut de la fermeture normale d’une association

8 SHUTDOWN ACK Acquittement de la portion SHUTDOWN

9 ERROR Notification d’une erreur

10 COOKIE ECHO Porte le COOKIE pendant l’initialisation d’une association 11 COOKIE ACK Acquittement de la portion

COOKIE ECHO

(38)

5.2. INITIALISATION S ´ ECURIS ´ EE 25

12 ECNE R´ eserv´ e pour utilisation dans Explicit Congestion Notification 13 CWR R´ eserv´ e pour utilisation dans

Explicit Congestion Notification 14 SHUTDOWN Acquittement de la portion

COMPLETE SHUTDOWN ACK

15-62 Non attribu´ es dans RFC2960

63 Extension r´ eserv´ ee par l’IETF

64-126 Non attribu´ es dans RFC2960

127 Extension r´ eserv´ ee par l’IETF

128-190 Non attribu´ es dans RFC2960

128 ASCONF-ACK Acquittement de la portion ASCONF

191 Extension r´ eserv´ ee par l’IETF

192-254 Non attribu´ es dans RFC2960

192 FORWARD TSN Gestion avanc´ ee des acquittements

193 ASCONF Configuration des adresses

255 Extension r´ eserv´ ee par l’IETF

Tab. 5.1: Les types des portions de SCTP

Les portions de donn´ ees peuvent ˆ etre mises dans un message avec des portions de contrˆ ole. Il y a pourtant certaines contraintes :

– les portions du type INIT, INIT ACK et SHUTDOWN COMPLETE doivent ˆ etre seules dans un paquet,

– la portion ABORT ne peut pas ˆ etre mise dans le mˆ eme message que les portions des donn´ ees (du type DATA),

– la taille totale du message ne peut pas exc´ eder le MTU (la taille maximale de trame - Maximal Transmission Unit).

La figure 5.1 pr´ esent le format g´ en´ eral d’un message SCTP qui montre l’en-tˆ ete commune et plusieurs portions diff´ erentes.

5.2 Initialisation s´ ecuris´ ee

Un des points faibles de TCP est la possibilit´ e d’effectuer une attaque de d´ eni du service

de type SYN-flood. Il s’agit d’une attaque o` u un attaquant commence plusieures connexions

(39)

avec de fausses adresses source. Comme ces adresses sont fausses, voire n’existent pas, le serveur TCP ne peut pas r´ epondre et donc ´ etablir la connexion compl` ete. Dans cette situation, le serveur consomme des ressources (m´ emoire) pour maintenir les connexions semi-ouvertes. Cela provoque un ´ epuisement de la m´ emoire et finalement un blocage du serveur.

Fig. 5.1 – Format g´ en´ eral d’un message SCTP

Pour se prot´ eger contre ce type d’attaques, le protocole SCTP pr´ evoit un m´ ecanisme d’initialisation s´ ecuris´ ee bas´ e sur un COOKIE. C’est une valeur calcul´ ee par le serveur pour v´ erifier le client qui a demand´ e l’initialisation d’une association. Le sch´ ema d’initialisation avec un COOKIE est pr´ esent´ e dans la figure 5.2, suivi d’une explication d´ etaill´ ee du m´ ecanisme.

INIT

Le client qui veut ´ etablir une association envoie vers le serveur un message INIT qui contient obligatoirement les informations suivantes :

– Initiate Tag - la valeur qui sera utilis´ ee par le client comme ´ etiquette de v´ erification

(Verification Tag) dans tous les messages ´ emis pendant l’association.

(40)

5.2. INITIALISATION S ´ ECURIS ´ EE 27

Fig. 5.2 – Initialisation de l’association SCTP

– Advertised Receiver Window Credit - le nombre d’octets que le client peut recevoir du serveur.

– Number of Outbound Streams - le nombre de flots sortants propos´ es par le client pour cette association.

– Number of Inbound Streams - le nombre de flots entrants propos´ es par le client pour cette association.

– Initial TSN - la valeur initiale du TSN pour le client. La valeur du Initiate Tag peut ˆ etre utilis´ ee comme le TSN initial.

Dans le message INIT le client peut aussi mettre optionnellement :

– IPv4/IPv6 Address Parameter - si le client veut utiliser plusieurs adresses pendant une association, il peut inclure des adresses suppl´ ementaires IPv4 ou/et IPv6. Les deux types d’adresses peuvent ˆ etre utilis´ es en mˆ eme temps dans une association.

– Host Name Address - le client peut mettre son nom au lieu de son adresse IP.

L’autre extr´ emit´ e doit convertir ce nom en adresse IP pour ´ etablir une association.

On peut utiliser cette option pour ´ etablir une association en pr´ esence d’un serveur NAT (Network Address Translation).

– Supported Address Types - le client peut sp´ ecifier les types d’adresse support´ es : IPv4, IPv6 ou Hostname.

– Cookie Preservative - la dur´ ee de validit´ e des COOKIES. Par d´ efaut un COOKIE

est valable pendant 60 secondes.

(41)

INIT-ACK

Un serveur qui re¸coit un message INIT ne cr´ ee aucune structure de donn´ ees dans sa m´ emoire et ne stocke aucune information concernant cette association. En se basant sur les donn´ ees re¸cues dans le message INIT, il calcule un COOKIE. La longueur et la m´ ethode de la calcul du COOKIE ne sont pas pr´ ecis´ ees dans la sp´ ecification et elles peuvent ˆ

etre diff´ erentes pour chaque impl´ ementation de SCTP. En fait, le COOKIE est important seulement pour le serveur, car c’est lui qui doit le reconnaˆıtre dans l’´ etape suivante. Le client ne traite pas de COOKIE, mais le renvoie simplement au serveur. Cela ne d´ epend pas du format de COOKIE.

Dans le message INIT-ACK le serveur met aussi obligatoirement les informations suivantes :

– Initiate Tag - la valeur qui sera utilis´ ee par le serveur comme ´ etiquette de v´ erification (Verification Tag) dans tous les messages ´ emis pendant l’association.

– Advertised Receiver Window Credit - le nombre d’octets que le client peut recevoir du serveur.

– Number of Outbound Streams - le nombre de flots sortants propos´ es par le serveur pour cette association.

– Number of Inbound Streams - le nombre de flots entrants propos´ es par le serveur pour cette association.

– Initial TSN - la valeur initiale du TSN pour le serveur. La valeur du Initiate Tag peut ˆ etre utilis´ ee comme le TSN initial.

Le serveur peut ajouter des param` etres optionnels :

– IPv4/IPv6 Address Parameter - si le serveur veut utiliser plusieurs adresses pendant une association, il peut inclure dles adresses suppl´ ementaires IPv4 ou/et IPv6 comme un param` etre optionnel.

– Host Name Address - le serveur peut mettre son nom au lieu d’adresses IP. Le client doit convertir ce nom en adresse IP pour terminer l’initialisation.

– Error - si le serveur n’a pas reconnu un des param` etres dans le message INIT, il envoie un message d’erreur.

COOKIE-ECHO

En troisi` eme phase d’initialisation le client renvoie au serveur le COOKIE trouv´ e dans le message INIT-ACK. Ce message ne contient rien de plus, mais le client peut mettre une portion des donn´ ees (DATA chunk) dans le mˆ eme paquet avec le message COOKIE-ECHO.

Apr` es la r´ eception du message COOKIE-ECHO, le serveur calcule encore une fois le

COOKIE de la mˆ eme fa¸con qu’apr` es la r´ eception du message INIT. Si le COOKIE calcul´ e

est identique avec le COOKIE re¸cu dans le message COOKIE-ECHO, le serveur peut ˆ etre

(42)

5.3. FERMETURE D’UNE ASSOCIATION 29 sˆ ur que l’adresse du client est r´ eelle et qu’il peut ´ etablir une association avec ce client.

Dans le cas contraire, le serveur supprime silencieusement le message COOKIE-ECHO et termine l’initialisation sans ´ etablir une association.

COOKIE-ACK

D` es que le serveur re¸coit un message COOKIE-ECHO il cr´ ee toutes les structures n´ ecessaires pour servir cette association et termine l’initialisation par un message COOKIE- ACK. Dans le mˆ eme message le serveur peut mettre aussi une portion de donn´ ees.

5.3 Fermeture d’une association

La proc´ edure de fermeture d’une association peut ˆ etre initi´ ee par les deux cˆ ot´ es d’une association (dans notre description nous supposons que c’est le client qui commence la proc´ edure de la fermeture). Elle est s´ ecuris´ ee en utilisant trois messages comme montr´ e sur la figure 5.3 et d´ ecrit ci-dessous.

Fig. 5.3 – Fermeture d’une association SCTP

Références

Documents relatifs

On ne peut pas toujours aller d’un sommet quelconque du graphe ` a un autre par un chemin de longueur inf´ erieure ou ´ egale ` a 3. Parmi ces trois propositions, lesquelles sont

très haut débit mobile sont comparables à celles qui ont accompagné le déploiement de chacune des grandes accompagné le déploiement de chacune des grandes infrastructures de

Comme il a ´ et´ e dit dans les sections pr´ ec´ edentes, Linux peut ˆ etre configur´ e en tant que client ou serveur NCP, et donc, permettre l’acc` es ` a ses fichiers et

Le Conseil départemental souhaite mettre en place, d’ici 2021, un véritable plan de développement du Numérique éducatif, s’appuyant sur l’accès au Très Haut Débit,

Ainsi, la collectivité territoriale ne pourra solliciter le soutien de l’État pour son projet s’il envisage le développement de réseaux de boucle locale optique

Pour les logements existants, le raccordement final consiste à faire passer un câble de fibre optique depuis le boîtier situé dans la rue ou dans votre

Dans le script principal, où peut-on insérer l’ins- truction ajouter 2 à la taille du stylo de façon à obtenir le dessin

Il est possible de t´ el´ echarger les documents (via un clic droit) et aussi d’envoyer sur le serveur de l’´ etablissement dans son espace personnel ou le r´ epertoire