NEMO et la multi-domiciliation

45 Le Chapitre II, section III.4 présente les améliorations relatives à la multi-domiciliation dans MIPv6 qui permettent d’utiliser les multiples interfaces réseaux d’un nœud mobile. Au vu de la dégradation

de performances lors du changement de point d’accès avec un routeur mobile, des chercheurs ont

suggéré d’ajouter le support de la multi-domiciliation à NEMO. L’extension mCoA pour MIPv6 ayant été proposée alors que le groupe de travail NEMO était encore actif, des propositions similaires ont été effectuées pour les réseaux mobiles. Un document du groupe de travail discute des différents scénarios envisageables pour la multi-domiciliation dans un réseau mobile (voir [41]). Les scénarios sont

distingués suivant la configuration du réseau : nombre de réseaux d’accès, nombre de routeurs mobiles

présents dans le réseau mobile et nombre de préfixes d’adresse IP définis dans le réseau mobile. Deux

cas sont particulièrement intéressants pour nous :

 Cas classique : 1 Routeur, multiples interfaces réseaux, 1 préfixe.

 Cas avec sous-réseaux : 1 Routeur, multiples interfaces réseaux, multiples préfixes.

Le premier cas correspond à un réseau mobile multi-domicilié de base et correspond à la topologie étudiée dans le Chapitre III, section III. Le second cas est celui utilisé dans notre proposition du Chapitre V.

Suite à l’expérience décrite dans [40] et présentée précédemment, une expérience avec NEMO et

mCoA dans des conditions réelles a été réalisée en 2006 lors d’une conférence du projet WIDE [39].

Les mesures effectuées sont présentées dans [42] et comparées à celles faites l’année précédente sur

un réseau NEMO mono-domicilié [40] (détaillée dans IV.1). La mobilité dans ce contexte n’est pas

réelle mais elle est « simulée » en changeant le point d’accès utilisé par le routeur. Les conclusions de

cette expérience sont prévisibles : l’utilisation de plusieurs interfaces réseaux permet de réduire le

délai nécessaire au changement de réseau, les pertes sont limitées lors du basculement (de 30% à moins de 10%) et la Qualité d’Expérience (QdE) ne semble pas affectée par la pseudo-mobilité. Afin de déterminer la QdE, les auteurs ont demandés aux utilisateurs s’ils avaient ressenti le changement de point d’accès. Il en est ressorti que seulement 10% des participants avaient remarqué certains basculements.

Une autre expérience sur un banc de test réel a été réalisée dans [43]. Ici, les auteurs visent à comparer la version basique de NEMO avec sa version multi-domiciliée lors de la réalisation de changements de réseaux. Les résultats sont sans équivoque : la latence introduite par le changement de réseau est de

13s avec NEMO et de 75ms en utilisant la multi-domiciliation. L’impact sur les communications est

donc largement moins important, le débit et l’évolution des numéros de séquence étant peu affectés. En même temps que pour mobile IPv6, la possibilité de lier un flux à une interface est définie dans [34]. Cette fonctionnalité est encore plus intéressante dans un réseau mobile car le nombre de flux en présence est beaucoup plus élevé qu’avec un nœud mobile unique. La mise en place de mécanismes de différenciation de flux est alors plus rentable et il est possible de mettre en place une vraie politique d’admission ce qui revient à définir des services de QdS.

Une implémentation de « Flow Binding » est faite dans [43] en se basant sur une implémentation de

Nemo appelée « Nemo BS Implementation for Linux » (NEPL) [46] ; NEPL est aujourd’hui

remplacée par UMIP [47] qui propose une implémentation de MIPv6 et de NEMO. L’étude faite sur le

« Flow Binding » permet de déterminer deux moyens pour améliorer le débit des connexions TCP : en répartissant les flux entre les interfaces actifs et en définissant un seul chemin pour la connexion (données et acquittements). La première technique se base logiquement sur des mécanismes de partage de la charge. Avec la seconde technique, les auteurs présentent une solution à une faille de la multi-domiciliation : si les accords ne sont pas bien faits entre le routeur et son agent, un flux peut emprunter un tunnel pour les données et un autre tunnel pour les acquittements. Si les deux tunnels ne possèdent

46

pas les mêmes caractéristiques, les performances de TCP peuvent être affectées car les paquets de données et les acquittements ne vont pas être soumis aux mêmes contraintes, ce qui peut entrainer un déséquilibre.

47 V Protocoles de Transport et mobilité

Les solutions présentées dans la section précédente permettent de gérer la mobilité au niveau Réseau. Les changements de réseau sont alors totalement transparents pour les applications et la couche

Transport. Néanmoins, le changement de point d’accès revient à changer les caractéristiques du lien

utilisé pour les communications, ce qui affecte les performances des protocoles de Transport (voir le

Chapitre II, section I.1.3). Nous reviendrons sur ce point dans cette section en détaillant l’impact du

changement de réseau transparent sur TCP. La plupart des solutions de mobilité intervenant au niveau de la couche Transport présentées dans cette section proposent de meilleures performances à la suite du changement des caractéristiques du réseau. De plus, le principal avantage de ces solutions est le faible besoin d’implémentation dans les réseaux d’accès. En effet, les solutions de la couche Réseau

nécessitent des entités de type « Home Agents ». Il est donc nécessaire d’avoir une architecture

spécifique et de choisir le fournisseur d’accès en fonction des services proposés. D’un autre côté, les solutions de la couche Transport ont seulement besoin d’être implémentées dans les terminaux. En

contrepartie, il peut être nécessaire d’utiliser un protocole de Transport particulier ou une version

spécifique ce qui peut rendre difficile le déploiement mais aussi l’utilisation suivant les entités traversées dans le réseau (pare-feux par exemple).

Dans cette section, deux protocoles de Transport ayant des approches différentes de la mobilité sont présentés. Transmission Control Protocol (TCP) est le protocole de Transport le plus commun et des versions adaptées à la mobilité existent. Nous décrirons la gestion de la communication de bout-en-bout qui est faite par TCP, puis nous introduirons les mécanismes permettant la mobilité qui ont été implémentés dans ces différentes versions. Nous présenterons ensuite Multipath TCP (MPTCP), un protocole de Transport basé sur TCP et permettant la multi-domiciliation.