Vous êtes sur la page 1sur 16

See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/228716836

Gestion Hirarchique de la Mobilit IPv6


Contrle par le rseau
Article

CITATIONS

READS

119

6 authors, including:
Karine Guillouard

Jean-Marie Bonnin

Orange Labs

Institut Mines-Tlcom, Telecom Bretagne

49 PUBLICATIONS 297 CITATIONS

192 PUBLICATIONS 1,202 CITATIONS

SEE PROFILE

All in-text references underlined in blue are linked to publications on ResearchGate,


letting you access and read them immediately.

SEE PROFILE

Available from: Jean-Marie Bonnin


Retrieved on: 12 October 2016

Gestion Hirarchique de la Mobilit IPv6


Contrle par le rseau
Youssef Khouaja1, Karine Guillouard1, Philippe Bertin1 - France Tlcom R&D
Jean-Marie Bonnin2 - ENST Bretagne
1

prnom.nom@francetelecom.com
2
jm.bonnin@enst-bretagne.fr

Mots cls
Mobile IP, Micro-mobilit, HMIPv6, NC-HMIPv6.

Introduction
Grce la popularit dInternet, le protocole IP s'impose comme incontournable pour les futurs
rseaux de tlcommunications. Par ailleurs, la miniaturisation des quipements informatiques
et le dveloppement des rseaux et services de transmission de donnes sans fil contribuent
dvelopper les services de mobilit.
Dans un rseau IP, chaque nud connect est localis par rapport son point dattachement
avec son adresse IP. Lorsqu'un tel nud est dot de fonctions de mobilit et donc qu'il se
dplace en changeant de point dattachement, il doit imprativement : soit changer dadresse
IP, ce qui l'oblige interrompre les connexions en cours ; soit informer tous les routeurs du
rseau Internet que son adresse IP localise un nouveau point dattachement. La premire
solution ne fournit qu'une solution de nomadisme permettant un terminal de se raccorder
successivement au rseau IP partir de points d'accs distincts sans fournir de continuit de
service entre ces points. Elle peut tre mise en uvre travers les protocoles d'auto
configuration permettant notamment l'allocation d'adresse dynamique comme le protocole
DHCP [5] trs couramment utilis. Par contre, la seconde solution est irraliste l'chelle de
l'Internet. L'IETF a donc standardis Mobile IP [15] pour intgrer le support de services de
mobilit dans les rseaux IP tendus. Mobile IP permet un routage transparent des paquets IP
destins aux nuds mobiles et permet d'assurer par consquent la continuit des
communications en cours. Il s'applique parfaitement des besoins de gestion de mobilit peu
contraignants en termes de dlais de mise jour, typiquement pour des services dits de "macromobilit" qui assurent la continuit de service pour un terminal se dplaant d'un rseau d'accs
un autre (par exemple basculement d'un rseau local sans fil un rseau cellulaire public).
Cependant, si Mobile IP est utilis pour grer la "micro-mobilit", c'est dire la mobilit
localise dans un mme rseau d'accs (typiquement un rseau de campus tendu) et surtout
lorsque ce rseau d'accs est distant du rseau principal du terminal, les dlais de diffusion de
la nouvelle localisation ainsi que le trafic de contrle gnr pour joindre le rseau principal
sont pnalisants. En effet, ils entranent des interruptions de services de plusieurs secondes, des

pertes de paquets de donnes correspondants aux connexions en cours et des changes de


signalisations qui chargent inutilement le cur de rseau.
Ainsi, plusieurs protocoles de micro-mobilit ont t dvelopps [7] pour remdier ces
problmes. Nanmoins, les temps d'interruption de service dus la procdure de handover
restent importants du fait que ces protocoles n'incluent pas de mcanisme de prdiction de
mouvement. De plus, le rseau n'tant pas impliqu dans la procdure de dcision de la cellule
cible lors d'un handover, il n'est pas possible de mettre en place de mcanisme global de
gestion des ressources radio et rseau ncessaire au maintien dun haut niveau de qualit de
service. Afin de lever ces limites, nous proposons dans cet article un nouveau protocole de
gestion de la micro-mobilit IP driv de HMIPv6 [1] [18] appel NC-HMIPv6 (Network
Controlled Hierarchical Mobile IP version 6). Il sappuie sur un contrle de la mobilit
effectu dans le rseau et inclut la phase de prise de dcision de lexcution du handover.
Cet article comporte trois sections principales. Dans la premire section, nous dcrivons
rapidement le protocole Mobile IPv4 et nous dveloppons une brve comparaison avec Mobile
IPv6. A partir de [7], la deuxime section prsente une classification en deux familles des
protocoles de gestion de la micro-mobilit : les protocoles avec une architecture base sur une
hirarchie dagents de mobilit et les protocoles avec un routage propritaire localis. Puis, les
limites de ces protocoles sont dtailles. Dans la troisime section, nous prsentons
larchitecture, le fonctionnement et lvaluation de NC-HMIPv6 faite en comparaison avec
HMIPv6 lors de tests effectus sur notre implmentation et de simulations.

Macro-mobilit IP
Mobile IPv4
Mobile IPv4 [Perk01] dfinit trois entits fonctionnelles : le nud mobile et deux agents de
mobilit, lagent mre et lagent tranger. Le nud mobile est configur avec une adresse IP
permanente, appele adresse mre et appartenant son rseau mre. L'agent mre est un
routeur spcifique du rseau mre, il enregistre la localisation du mobile lorsque celui-ci est en
visite dans un rseau externe. Lagent tranger est un routeur du rseau externe (rseau
"visit") dans lequel le nud mobile est localis un moment donn. Il est gnralement utilis
par le nud mobile pour obtenir ladresse IP temporaire correspondant sa nouvelle
localisation, adresse qu'il enregistre auprs de son agent mre. Le fonctionnement du protocole
Mobile IP est le suivant : le nud mobile coute en continu les annonces dagents diffuses par
les agents de mobilit ; lorsqu'il s'aperoit que le prfixe rseau diffus dans ces annonces
change, il en dduit quil a chang de rseau ; il cherche alors acqurir une nouvelle adresse
temporaire. Cette nouvelle adresse peut tre celle de lagent tranger ou tre obtenue par un
mcanisme d'auto configuration tel que DHCP [5]. Dans le premier cas, le nud mobile
senregistre auprs de son agent tranger qui lenregistre ensuite auprs de son agent mre.
Dans le deuxime cas, le nud mobile annonce sa nouvelle adresse temporaire directement
son agent mre en changeant des requtes et rponses denregistrement. Une fois
lenregistrement termin, lagent mre intercepte les paquets envoys ladresse mre du nud
mobile et les encapsule pour les rediriger via un "tunnel IP" vers la nouvelle adresse
temporaire. Lorsque cette adresse temporaire est celle de l'agent tranger, celui-ci doit

dcapsuler les paquets du mobile avant de les lui livrer. Lorsque l'adresse temporaire est celle
obtenue par auto configuration du nud mobile, il dcapsule lui-mme les paquets. Afin de
maintenir son enregistrement valide auprs de ses agents de mobilit, le nud mobile doit
priodiquement le renouveler. Lorsquil retourne dans son rseau mre, il annule
l'enregistrement en cours et indique ainsi son agent mre de ne plus intercepter les paquets
qui lui sont destins.
En outre, dans Mobile IP, le nud mobile doit utiliser son adresse mre comme adresse source
des paquets mis afin dassurer la continuit de ses connexions. Cependant, dans des rseaux
utilisant des routeurs filtrants [8] et pour des raisons de scurit, on impose que ladresse
source dun paquet mis appartienne au rseau. Lextension Tunnel inverse [13] propose de
rsoudre ce problme en livrant les paquets IP mis via un tunnel entre ladresse temporaire du
nud mobile et lagent mre ; les paquets sont ensuite dcapsuls par lagent mre et livrs aux
nuds correspondants en utilisant ladresse mre du nud mobile comme adresse source.
Enfin, la version de base de Mobile IPv4 impose que les paquets adresss aux nuds mobiles
soient routs travers lagent mre. Ils suivent donc des chemins qui peuvent tre assez longs
et non optimaux. Lextension nomme Optimisation de routage [16] remdie ce problme en
permettant un nud correspondant de maintenir un cache dassociations qui pointe
continuellement sur ladresse temporaire courante du nud mobile. Il peut alors router
directement les paquets sans passer par lagent mre. Ces caches dassociations sont crs et
mis jour par des nouveaux types de messages.
Comparaison de Mobile IPv4 avec Mobile IPv6
La conception de Mobile IPv6 [12] sest base sur les expriences acquises du dveloppement
de Mobile IPv4 et sur les nouvelles opportunits offertes par le protocole IPv6 [4], telles que le
nombre plus important dadresses et les mcanismes dauto configuration.
Lutilisation des options destination dIPv6, qui fournissent des informations au nud
destinataire final, permet aux informations de contrle de Mobile IPv6 dtre transportes dans
l'entte des paquets IP contrairement Mobile IPv4 o un paquet UDP spcifique doit tre
utilis pour chaque type de message de contrle. Loptimisation de routage est intgre dans le
protocole Mobile IPv6 puisqu'elle est assure, comme lenregistrement avec lagent mre, par
des messages de mise jour dassociations. Le protocole IPv6 permet aux nuds mobiles
excutant Mobile IP de communiquer travers des routeurs filtrants en utilisant ladresse
temporaire comme adresse source. Ladresse mre est indique dans une option de destination,
appele option adresse mre, du paquet IPv6. Enfin, Mobile IPv6 ne requiert pas le
dploiement d'agents trangers. Les nuds mobiles utilisent les mcanismes d'auto
configuration IPv6 fonctionnant dans tous rseau IPv6 visit.

Micro-mobilit IP
La micro-mobilit, mobilit restreinte un mme rseau ou limite un mme site, est
caractrise par des dplacements locaux, frquents et rapides. Lorsque Mobile IP est utilis
pour la gestion de ce type de mouvement, le nud mobile doit mettre chaque dplacement,
mme local, des messages de mise jour dassociations vers son agent mre et ses nuds
correspondants qui peuvent tre trs loigns de son rseau visit. Le cur du rseau IP est
alors charg par les messages de mise jour et la prise en compte de la nouvelle localisation

peut tre considrablement longue. Les sessions en cours subissent alors des interruptions de
service de plusieurs secondes ainsi que dimportantes pertes de paquets. Un protocole de
micro-mobilit est ncessaire pour pallier ces inconvnients.
Ces dernires annes plusieurs solutions ont t dveloppes. Nous pouvons les rpartir en
deux catgories : celles qui sont bases sur une hirarchie dagents de mobilit et celles qui
mettent en uvre un routage propritaire localis.
Protocoles avec une architecture base sur une hirarchie dagents de mobilit
Ces protocoles tendent lide de Mobile IP en utilisant une hirarchie dagents de mobilit.
Un nud mobile senregistre auprs de son agent local du plus bas niveau de la hirarchie ;
puis lagent local senregistre auprs de lagent suprieur dans la hirarchie et les
enregistrements remontent la hirarchie jusqu atteindre lagent mre. Lorsque le nud
mobile se dplace, il nmet quune requte denregistrement localise dans un domaine,
fonction de la nature de son dplacement. Les paquets qui lui sont destins suivent alors la
hirarchie des agents de mobilit et sont livrs dun agent un autre via un tunnel. Les
protocoles les plus connus sont lEnregistrement Rgional Mobile IP [10] et la Gestion
hirarchique de la mobilit HMIPv6.
Protocoles avec un routage propritaire localis
Ces protocoles dfinissent une architecture de rseaux deux niveaux : le niveau le plus haut
est le rseau standard Internet implmentant Mobile IP et le niveau le plus bas est compos de
domaines capables de grer la micro-mobilit. Le routeur reliant les deux niveaux masque les
dplacements locaux par rapport au reste du rseau Internet. A lintrieur dun domaine, un
protocole de routage spcifique est introduit. Les paquets mis par le nud mobile mettent
jour les entres de routage dans les nuds intermdiaires. Une entre de routage fait alors
correspondre ladresse du nud mobile avec ladresse du routeur voisin par lequel a transit le
dernier paquet responsable de la mise jour de cette entre. La chane de ces correspondances
reprsente le chemin parcouru par les paquets destins au nud mobile. Les protocoles les plus
connus sont Cellular IP [3] et HAWAII [17].
Limites des protocoles de micro-mobilit
Ces protocoles de micro-mobilit offrent des solutions performantes pour le support de la
mobilit localise. Ils prsentent lavantage de rsoudre les principales limites de Mobile IP
sans complexifier le mcanisme de gestion de la mobilit. Cependant, des amliorations sont
encore possibles surtout en ce qui concerne la phase de dcision de lexcution dun handover,
la procdure de dtection du mouvement et le temps dexcution du handover.
En effet, dans ces solutions de mobilit, la phase de prise de dcision de lexcution du
handover est exclue du protocole. Un nud mobile subit simplement le handover dcid au
niveau liaison. Par exemple, dans un rseau local sans fil, chaque fois que la qualit de la
liaison radio avec son point daccs courant se dgrade, le mobile change de point daccs. Au
niveau IP, le nud mobile doit attendre la rception dune annonce de routeur pour dtecter
son mouvement et entamer la mise jour de sa localisation. Il y a donc un intervalle de temps
non ngligeable entre le dplacement physique du nud mobile (couches 1 et 2 du modle

OSI) et la dtection du mouvement IP (couche 3), ce qui accrot le temps dexcution du


handover.
Dans la partie suivante, nous prsentons un nouveau protocole NC-HMIPv6 qui est une
volution du protocole HMIPv6 [1]. NC-HMIPv6 propose de rsoudre les problmes dcrits cidessus en incluant la phase de prise de dcision de lexcution du handover dans le protocole
de gestion de la mobilit et en introduisant le concept de gestion du handover contrle par le
rseau.

NC-HMIPv6
Architecture considre
Un domaine NC-HMIPv6 comporte cinq entits fonctionnelles : le routeur daccs RA, le point
daccs PA, le gestionnaire de mobilit GM, la base de donnes BD et le nud mobile NM.
RA est le routeur daccs du nud mobile au rseau IPv6. Chaque routeur daccs est associ
un gestionnaire de mobilit. PA assure la liaison radio avec le nud mobile. Chaque point
daccs est attach un unique routeur daccs. GM intercepte et livre les paquets destins aux
nuds mobiles du domaine (fonctionnalit identique celle du serveur de mobilit dans
HMIPv6). Il intervient, entre autres, dans la prise de dcision de lexcution dun handover
ainsi que dans le choix du point daccs cible lu du handover. BD hberge des informations
sur les points daccs du domaine et des paramtres utiles la gestion des handovers.
GM
NM
PA
RA
BD

Internet

GM

Gestionnaire de mobilit
Nud mobile
Point d'accs
Routeur d'accs
Base de donnes

BD

Domaine
PA

RA

NC-HMIPv6

RA
PA

PA
PA
NM

Le nud mobile
se dplace

Figure 1: Modle darchitecture dun domaine NC-HMIPv6


Initialisation
Dans un domaine NC-HMIPv6, chaque point daccs est associ une interface dun routeur
daccs et un gestionnaire de mobilit et possde un ensemble de points daccs voisins. La

liste des points daccs voisins dun point daccs est maintenue dans une base de donnes
hberge par son gestionnaire de mobilit. Cette base de donnes maintient aussi des
informations utiles la prise de dcision de lexcution des handovers. Un point daccs est
identifi avec un identifiant unique, le prfixe rseau de linterface du routeur daccs associe
et la longueur de ce prfixe.
Le gestionnaire de mobilit annonce son support de NC-HMIPv6 en diffusant priodiquement
ses routeurs daccs un paquet dinformation contenant son mode de fonctionnement NCHMIPv6, son adresse et la longueur de son prfixe rseau. Lorsquun nud mobile entre dans
un domaine NC-HMIPv6 (tape 0 dans la Figure 2), il reoit une annonce de routeur de son
routeur daccs avec des options signalant le support de NC-HMIPv6 et des informations sur le
gestionnaire de mobilit.
1. @mre @V

NC

Signalisation

Internet

NC Nud correspondant

1
1. @V @L

BD

GM

Domaine
1

RA
PA
PA

3
Etapes dinitialisation

1. @L @mre

NM
1. Mise jour d'association
0. Le nud mobile
accde au domaine

1. Enregistrement de l'association
2. GM consulte BD
3. Acquittement + envoi de la
liste de PAs

Figure 2 : Initialisation dun nud mobile dans un domaine NC-HMIPv6


Le nud mobile acquiert alors deux nouvelles adresses IP temporaires. La premire adresse,
adresse temporaire virtuelle @V, est valide au niveau du gestionnaire de mobilit ; elle est
dtermine en concatnant lidentifiant de linterface physique du nud mobile avec le prfixe
rseau du gestionnaire de mobilit recueilli dans lannonce de routeurs. La deuxime adresse,
adresse temporaire locale @L, identifie la liaison locale ; elle est obtenue en concatnant
lidentifiant de linterface physique du nud mobile avec le prfixe rseau du routeur daccs
courant.

Ladresse temporaire virtuelle joue le rle de ladresse temporaire primaire de Mobile IPv6. Le
nud mobile informe alors son agent mre et ses nuds correspondants NC de cette adresse
temporaire en utilisant des messages de mise jour dassociations Mobile IPv6 (tape 1 dans
la Figure 2). En outre, pour que le gestionnaire de mobilit soit capable de livrer ces paquets, il
doit tre inform de la correspondance entre ladresse virtuelle et ladresse locale. Pour cela,
ds lacquisition de ces deux adresses temporaires, le nud mobile informe le gestionnaire de
mobilit de la correspondance entre ladresse virtuelle et ladresse locale (@V,@L) en lui
transmettant une requte denregistrement HMIPv6 (tape 1). Ainsi, tous les paquets
adresss au nud mobile sont routs vers son adresse temporaire virtuelle @V, jusquau
gestionnaire de mobilit. Ensuite, le gestionnaire de mobilit intercepte ces paquets et les livre
ladresse locale @L du nud mobile. Le gestionnaire de mobilit, aprs avoir consult sa
base de donnes (tape 2), acquitte la requte denregistrement en renvoyant au nud mobile
un message dacquittement dassociations Mobile IPv6, qui doit inclure, en outre, la liste
des points daccs voisins du point daccs courant du nud mobile dans une nouvelle option
NC-HMIPv6 (tape 3).
Gestion du handover
Dans un domaine NC-HMIPv6 (cf. Figure 3), un nud mobile contrle en continu la qualit de
la liaison radio avec son point daccs courant. Si elle se dgrade sous un seuil S1 (tape 1), le
nud mobile recueille les mesures de la qualit avec les points daccs voisins (tape 2) et les
renvoie son gestionnaire de mobilit dans une requte de handover NC-HMIPv6 (tape 3).
Le nud mobile nmet dans cette requte que les qualits de liaison des points daccs inclus
dans sa liste de points daccs voisins. Cela permet de rduire le temps de traitement des
mesures et la taille du message de requte grce une premire slection ralise par le
gestionnaire de mobilit.
Le gestionnaire de mobilit examine ces mesures, consulte sa base de donnes et slectionne le
PA cible optimal pour le nud mobile (tape 4). La base de donnes maintient diverses
informations qui peuvent aider dans la prise de dcision de lexcution du handover. Par
exemple, si des informations sur la charge courante des points daccs sont stockes, le
gestionnaire de mobilit peut faire de la rpartition de charge. Le choix de lalgorithme est
spcifique loprateur.
Le gestionnaire de mobilit renvoie ensuite au nud mobile une rponse de handover NCHMIPv6 en spcifiant le point daccs cible lu, ladresse de linterface du routeur daccs et
la longueur du prfixe rseau correspondants (tape 5). En parallle, il cre une nouvelle
association de ladresse virtuelle courante avec la future adresse locale du nud mobile
(@V1,@L2). La nouvelle adresse peut tre prdite puisquelle est construite partir de la
concatnation du prfixe rseau de la nouvelle interface du routeur daccs et lidentifiant
physique du nud mobile (dduit de celui utilis dans l'adresse virtuelle courante).
Le nud mobile reoit la rponse de handover, construit sa future adresse temporaire locale
@L2 et s'attache au nouveau point d'accs (tape 6). Ds son attachement termin, le nud
mobile met des annonces de voisins afin dinformer ses voisins de sa nouvelle adresse locale
et une sollicitation de routeurs pour recevoir immdiatement lannonce de routeurs de son
routeur daccs (tape 7). Cela permet de diminuer la frquence de diffusion des annonces de
routeurs dans un domaine NC-HMIPv6 et minimise par consquent la charge des liaisons
radio. Le routeur daccs reoit lannonce de voisins du nud mobile avec la nouvelle adresse

temporaire locale. Il met jour sa table de routage en faisant correspondre la nouvelle adresse
IP locale du nud mobile ladresse couche liaison diffuse dans lannonce de voisins. A
partir de cet instant, les communications vers le nud mobile peuvent reprendre puisque les
paquets sont redirigs vers la nouvelle localisation par le gestionnaire de mobilit depuis
ltape 5. A la rception de lannonce de routeurs de son nouveau routeur daccs, le nud
mobile complte et met jour les paramtres de sa nouvelle adresse temporaire locale (dure
de validit, paramtres de configuration...).
Signalisation

0. @mre @V1

Internet

NC

0. @V1 @L1.
5. @V1 @L1,
@V1 @L2.
8. @V1 @L2.

Etapes du gestion du handover


1. Qualit < S1

GM

2. Collection des mesures


3. Requte de handover

4. GM consulte BD

8
9

5. Rponse de handover
6. MN se dplace

RA
PA

8. Requte denregistrement

PA
7
2

6. @L2 @mre

RA

7. Annonce de voisins
ou paquets ARP

9. Acquittement
+ Liste de PAs

BD

NM
6

NM
1

0. @L1 @mre.
5. @L1 @mre.
@L2 @mre.

Figure 3 : Gestion du handover dans un domaine NC-HMIPv6


Le nud mobile doit aussi vrifier la nature du mouvement. Sil sagit dun mouvement
lintrieur dun mme domaine, il met une requte denregistrement HMIPv6 vers son
gestionnaire de mobilit afin de confirmer la nouvelle association (@V1, @L2) et dliminer
lancienne association (@V1, @L1) (tape 8). Sil sagit dun mouvement entre domaines, le
nud mobile acquiert, en plus de son adresse locale @L2, une nouvelle adresse virtuelle @V2
et lannonce son nouveau gestionnaire de mobilit et ses nuds correspondants en leur
mettant respectivement une requte de denregistrement HMIPv6 et des messages de mise
jour dassociations Mobile IPv6. Le gestionnaire acquitte la requte par un message
dacquittement dassociations Mobile IPv6 contenant, en outre, une mise jour de la liste
des points daccs voisins dans une option NC-HMIPv6 (tape 9).

Pendant toute la phase de gestion du handover, le nud mobile continue contrler la qualit
de liaison radio avec son point daccs courant. Si la qualit se dgrade sous un seuil critique
S2, le nud mobile garde la possibilit dexcuter un handover vers le point daccs prsentant
la meilleure qualit radio, sans attendre la rponse de handover du gestionnaire de mobilit.
Cela permet dassurer une qualit minimale pour une communication tablie.
A titre de comparaison, dans HMIPv6 l'initiative du handover est laisse l'interface de niveau
2 (par exemple la carte radio dans le cas d'usage sur un rseau local sans fil). Ainsi, le nud
mobile contrle en continue la qualit de la liaison radio avec son point daccs courant.
Lorsqu'elle se dgrade sous un seuil "constructeur" impos par la carte daccs radio, le nud
mobile identifie si la qualit peut tre meilleure sur un autre point d'accs et le cas chant
change de point daccs. Une fois associ sur le nouveau point d'accs, le nud mobile reoit
une annonce de routeur provenant du routeur daccs, auquel est rattach son nouveau point
daccs, et dcouvre un nouveau prfixe rseau. Il met alors en uvre la procdure d'auto
configuration IPv6 (avec ou sans tat) qui consiste acqurir ou construire sa nouvelle
adresse locale @L2. Il la diffuse ensuite dans des annonces de voisins et met une sollicitation
de routeurs afin de sassurer quil a bien chang de sous-rseau. Si lancien routeur daccs ne
renvoie pas d'annonce de routeur, le nud mobile en dduit quil sest dplac, dprcie son
ancien prfixe et entame la procdure de mise jour de localisation dfinie par le protocole
HMIPv6 (enregistrement auprs de l'agent de mobilit du domaine) l'issue de laquelle il
reoit nouveau les paquets qui lui sont destins.
Interruption de service lors d'un handover
Comme nous venons de le voir, dans NC-HMIPv6 le rseau prend l'initiative du handover sur
la base d'informations de qualit radio mesures par la carte du terminal et remontes dans le
protocole de niveau 3 vers le gestionnaire de mobilit. Ainsi, le rseau prvoit la nouvelle
localisation du mobile et lui transfre les paquets au plus tt durant la procdure de handover.
Au contraire, dans HMIPv6, l'initiative du handover est laisse au niveau 2 et le protocole
ragit a posteriori lorsqu'il dtecte qu'il est dans un nouveau sous-rseau IP et doit mettre en
uvre les mcanismes d'auto configuration avant d'enregistrer sa nouvelle localisation.
Pour un protocole sans prdiction de mouvement tel que HMIPv6, la dure d'interruption de
service lie au handover est donc fonction de diffrents paramtres tels que:
- le temps d'excution du handover radio (niveau 2) ;
- le dlai de dtection de mouvement qui dpend de la frquence de diffusion des
annonces de routeurs ;
- les temps de rponse des routeurs ;
- les dlais de transmission des messages d'auto configuration et d'enregistrement de la
localisation ;
- la nature du mouvement (handover inter ou intra domaine de micro-mobilit).
Ces paramtres dpendent directement de l'environnement rseau (configuration des routeurs,
niveaux de charge, dlais des liens de transmission, topologie), ce qui conduit observer des
dlais de handover trs variables.
Pour un protocole qui anticipe le mouvement dans le rseau tel que NC-HMIPv6, la dure
d'interruption de service lie au handover correspond essentiellement la dure de la procdure

de handover radio, ce qui permet de rduire au maximum la fois le temps dinterruption et sa


variabilit.
Afin de comparer les temps dinterruption de service lors d'un handover, nous avons mis en
place une plate-forme de test de la mobilit IPv6 reposant sur limplmentation HMIPv6 de
lINRIA sous FreeBSD 3.4 [6][2], sur laquelle nous avons dvelopp le protocole NCHMIPv6. Les nuds mobiles utilisent des cartes radio IEEE802.11b [11] pour communiquer
avec des points daccs attachs des brins Ethernet.
Dans cette maquette, nous disposons d'une application client/serveur MPEG1 qui permet
d'analyser le comportement des protocoles de mobilit lors de la diffusion de streaming vido.
Les films sont changs avec un dbit UDP constant de 33 kbit/s et une taille de paquet fixe
gale 1 kbit. La perte des paquets est value grce au fichier gnr au lancement de chaque
film. Le nombre de paquets perdus lors dun handover correspond la diffrence entre le
numro du premier paquet reu sur le nouveau point daccs et le numro du dernier paquet
reu sur lancien point daccs. Pour chaque protocole des mesures de pertes de paquets sont
faites pour trois types de mouvements distincts :
1. dplacement du terminal entre deux points d'accs du mme sous-rseau IP (mise en
uvre du handover de niveau 2 uniquement) ;
2. dplacement du terminal entre deux points d'accs de sous-rseaux IP distincts du
mme domaine de micro-mobilit (mise en uvre du handover de niveaux 2 et 3
intra-domaine de micro-mobilit) ;
3. dplacement du terminal entre deux points d'accs de sous-rseaux IP et de domaines
de micro-mobilit distincts (mise en uvre du handover de niveaux 2 et 3 interdomaines de micro-mobilit).
Les mesures ainsi recueillies sont dcrites dans le Tableau 1.
Tableau 1 : nombre de paquets UDP perdus lors de chaque type de mouvement
Mouvement
Protocole
HMIPv6
NC-HMIPv6

Handover de
niveau 2
14
14

Handover de
niveau 2/3
intra-domaine
149
15

Handover de
niveau 2/3
inter-domaine
151
15

Lanalyse de ce tableau montre que:


- pour le protocole HMIPv6, la perte de paquets est trs variable puisque la dure
d'interruption de service dpend du temps dexcution de l'ensemble de la procdure de
handover;
- pour le protocole NC-HMIPv6, quel que soit le type de mouvement, la perte de paquets
due une procdure de handover reste relativement constante, ce qui s'explique par le
fait qu'elle ne dpend essentiellement que de la dure d'interruption au niveau 2.

Simulations mettant en oeuvre NC-HMIPv6 avec une application FTP


Dans cette deuxime partie de lvaluation, nous avons dvelopp les protocoles HMIPv6 et
NC-HMIPv6 avec loutil de simulation OPNET et nous avons tudi le comportement dune
application de transfert de fichier FTP durant la procdure de handover pour chacun des deux
protocoles. Pour cela, nous utilisons une connexion TCP avec une bande passante du rseau
suppose infinie ce qui nous permet dviter les pertes de paquets dues une congestion. Nous
avons opt pour ce choix afin de pouvoir nous concentrer uniquement sur les pertes dues la
mobilit.
La Figure 4 prsente larchitecture du modle de tests de simulation que nous avons adopt.
Nous disposons dun nud mobile qui est connect initialement son sous-rseau mre
travers le hub_1. A linstant t0, parmi les quatre liens du nud mobile, seul le lien avec hub_1
est activ. Ensuite, le nud mobile se dplace dans un sous-rseau visit. Nous simulons le
mouvement en dsactivant le lien "nud mobile - hub_1" et en activant celui "nud mobile routeur_6".

Figure 4: Architecture du modle de tests de simulation


Le sous-rseau visit est constitu de trois routeurs daccs et dun gestionnaire de mobilit
NC-HMIPv6 (ou serveur de mobilit HMIPv6). Une fois que le nud mobile est enregistr
dans le rseau visit, il tablit une connexion TCP avec un nud correspondant, le serveur_1,
pour le transfert dun fichier FTP dune taille de 500 Koctets. Le transfert dbute linstant t0 +
60 secondes. A linstant t0 + 66 secondes, le nud mobile se dplace et se connecte

routeur_7. Le lien du nud mobile avec routeur_6 est alors dsactiv. Puis, celui avec
routeur_7 est activ. Entre la dsactivation de lancien lien et lactivation du nouveau, nous
imposons un temps dinterruption de 0,3 secondes pour simuler le handover radio. Ce dlai a
t choisi suite des tests maquette permettant d'estimer le temps d'interruption de service lors
du mouvement d'un terminal 802.11 entre deux points d'accs.
Les paramtres TCP utiliss dans la simulation sont les suivants : la taille maximum de
segment est de 1360 octets ; la taille de la fentre maximale est de 13600 octets ; les
algorithmes de Kann et de Nagle sont actifs ; lalgorithme du dmarrage lent slow start est
actif avec un compteur initial de 1 segment ; lalgorithme de retransmission rapide est activ ;
loption acquittement slectif est valide et un acquittement peut tre retard dun maximum de
0,2 secondes.

Figure 5 : Rsultats de simulation de transfert FTP


Les rsultats de simulation obtenus sont dcrits dans la Figure 5. Ils montrent que le temps de
transmission du fichier FTP dans NC-HMIPv6 est meilleur que celui dans HMIPv6 (11,194
secondes contre 15,023 secondes). Les courbes des numros de squence des segments reus
expliquent que cette amlioration est la consquence dune interruption de rception plus

courte dans NC-HMIPv6. En outre, la reprise de la connexion de NC-HMIPv6 est effectue


normalement, tandis que celle de HMIPv6 est ralise avec lalgorithme "slow-start".
L'analyse des traces d'changes TCP durant la procdure de handover montre que :
- Pour HMIPv6, lors de l'excution du handover, 10 segments de donnes arrivs
l'agent de mobilit sont routs vers l'ancienne localisation et sont ainsi perdus. Le
serveur TCP ne recevant aucun acquittement met en oeuvre l'algorithme de "slow
start".
- Pour NC-HMIPv6, le gestionnaire de mobilit est inform du mouvement
pralablement l'excution du handover. Les 10 segments sont ainsi routs vers la
future localisation et arrivent au niveau du nouveau routeur d'accs (router_7) qui les
stocke dans son tampon. Lorsque le mobile excute son handover, il met un message
d'annonce de voisin sur le lien de son nouveau routeur. Les segments lui sont alors
transmis et il arrive les acquitter temps. Pour les besoins des simulations, les
tampons du nouveau routeur d'accs sont dimensionns de manire conserver tous
les segments et aucune perte de paquet n'est introduite.
Limites de NC-HMIPv6
Le protocole NC-HMIPv6 introduit la notion de contrle dans le rseau de la procdure de
handover des nuds mobiles, en particulier afin de planifier les mouvements en fonction des
ressources rseau et radio disponibles. Chaque terminal se voit donc aiguill non
ncessairement vers la cellule radio pour laquelle il reoit le meilleur signal mais vers celle
pouvant assurer la meilleure qualit de service. Ceci suppose :
- la gestion d'un serveur de micro-mobilit, de bases de donnes adquates et la mise en
uvre d'un algorithme de prise de dcision plus ou moins complexes ;
- des temps de prise de dcision et de rponse permettant de s'assurer que le handover
soit dclench temps dans le cas de mouvements rapides, c'est dire avant que la
qualit radio sur la cellule quitte par le mobile ne soit trop dtriore pour recevoir la
rponse du serveur de micro-mobilit (perte de couverture). Dans ce cas le mobile doit
choisir lui-mme la cellule cible.
NC-HMIPv6 et, d'une manire plus gnrale, les approches de contrle par le rseau
s'appliquent donc essentiellement des rseaux d'accs tendus paramtrs et administrs par
des oprateurs.
Par ailleurs, la remonte de mesures rend le protocole dpendant de l'interface radio sousjacente. Un effort d'abstraction des donnes radio permettant de remonter des paramtres
gnriques quelle que soit la technologie sous-jacente est envisageable afin de conserver
l'indpendance et un partage clair des fonctionnalits entre couches 2 et 3. Par exemple, ce type
d'abstraction peut tre fait grce une interface de service telle que l'interface "IP to Wireless"
considre en [8].

Conclusion
Dans cet article, nous avons prsent NC-HMIPv6 un protocole de gestion de la mobilit
hirarchique contrle par le rseau. Ce protocole propose dinclure la phase de prise de

dcision de lexcution du handover dans le mcanisme de gestion de la mobilit contrle


par le rseau. Il permet ainsi de rduire le temps dexcution du handover et de diminuer
considrablement la perte des paquets. De plus, le concept du contrle du handover par le
rseau offre la possibilit de faire de la rpartition de charge entre cellules du rseau d'accs
et dlire intelligemment le point daccs cible du handover (prdiction du mouvement,
affectation de priorits, ...).
Les mesures ralises sur maquettes pour une application reposant sur UDP ainsi que les
rsultats de simulation concernant du trafic TCP montrent l'efficacit du protocole, en
particulier en ce qui concerne la rduction du temps d'interruption de service survenant lors
d'un handover et donc de la perte de paquets en dcoulant.
Nous avons finalement expliqu certaines limites qui encouragent les protocoles de ce type
tre mis en place surtout dans des rseaux d'accs tendus grs par des oprateurs. La
dfinition de moyens d'abstraction de donnes radio pouvant tre remontes la couche IP
du terminal et changes avec le rseau pourrait accrotre la capacit du systme prendre en
compte diffrentes technologies.

Rfrences
[1] Castelluccia, An Hierarchical Mobile IPv6 Proposal, INRIA, November 1998.
[2] Bellier, http://www.inrialpes.fr/planete/people/bellier/hmip.html.
[3] Campbell, A., Gomez, J., Kim, S., Turanyi, Z., Wan, C-Y., Valko, A., Design,
Implementation and Evaluation of Cellular IP, Communication IEEE, Juillet 2000.
[4] Deering, S., Hinden, R., Internet Protocol, Version 6 (IPv6) Specification, RFC 2460
IETF, Decembre 1998.
[5] Droms, R., Dynamic Host Configuration Protocol, RFC 2131 IETF, Mars 1997.
[6] Dupont, F., ftp://ftp.inria.fr/network/ipv6/.
[7] Eardly, P., Mihailovic, A., Suihko, T., A Framework for The Evaluation of IP Mobility
Protocols, In Proceedings of PIMRC 2000, London, UK, Septembre 2000. www.istbrain.org.
[8] Servane Bonjour, Sven Hischke, Antti Lappetelinen , Mika Liljeberg , Matthias Lott, IP
Convergence Layer with QoS Support for HIPERLAN/2, IST Global Summit 2001,
Barcelona, September 2001. www.ist-mind.org.
[9] Ferguson, P., Senie, D., Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing, RFC 2267 IETF, Janvier 1998.
[10] Gustafsson, E., Jonsson, A., Perkins, C., Mobile IP Regional Registration, Draft IETF,
Septembre 2001.
[11] IEEE Std 802-11-1997, Wireless LAN Medium Access control (MAC) and Physical
Layer (PH) Specification.
[12] Johnson, D., Perkins, C.,Mobility Support in IPv6, Draft IETF, Juillet 2001.
[13] Montenegro, G.,Reverse Tunneling for Mobile IP, revised, RFC 3024 IETF, Janvier
2001.
[14] Narten, T., Nordmark, E. Simpson, W.,Neighbor Discovery for IP Version 6 (IPv6),
RFC 2461 IETF, Decembre 1998.
[15] Perkins, C.,IP Mobility Support for IPv4, revised, RFC 2002 IETF, Septembre 2001.

[16] Perkins, C., Johnson, D.,Route Optimization in Mobile IP, Draft IETF, Septembre
2001.
[17] Ramjee, R., La Porta, T., Thuel, S., Varadhan, K.,IP micro-mobility support using
HAWAII, Draft IETF, Juillet 2000.
[18] Soliman, H., Castelluccia, C., El-Malki, K., Bellier, L.,Hierarchical MIPv6 mobility
management, Draft IETF, Juillet 2001.

Vous aimerez peut-être aussi