Mobilité

Nicolas Montavont
2000/2001
Rapport de D.E.A.Informatique
LA MOBILITE DANS LES RESEAUX IP

Universit Louis Pasteur de Strasbourg
Matre de stage : Thomas Nol Matre de confrences
REMERCIEMENTS
Je remercie Thomas Nol, mon matre de stage, pour mavoir encadr durant mon
stage de DEA, et mavoir fait bnficier de ses conseils et de son exprience.
Un grand merci tous les membres de lquipe de recherche Rseau du LSIIT qui
mont initi au monde de la recherche.
Enfin, une pense pour Sbastien et Christelle pour leur soutient.
Table des matires
TABLES DES MATIERES

Introduction 1
1
LA MOBILITE ........................................................................................................... 4
1.1
Introduction ......................................................................................................... 4
1.2
Terminologie et architecture ............................................................................... 4
1.2.1
Modle OSI ................................................................................................. 4
1.2.2
Nouveaux quipements ............................................................................... 5
1.2.3
Adressage .................................................................................................... 6
1.3
MIPv4 [1] ............................................................................................................ 7
1.3.1
Dcouverte des agents de mobilit.............................................................. 7
1.3.2
Enregistrement auprs de lagent mre ....................................................... 7
1.3.3
Communication ........................................................................................... 9
1.4
MIPv6 [2] .......................................................................................................... 11
1.4.1
Fonctionnalits requises ............................................................................ 11
1.4.2
Dcouverte des routeurs daccs ............................................................... 11
1.4.3
Enregistrement .......................................................................................... 12
2 HANDOFF ET MICRO MOBILITE........................................................................ 15
2.1
Dfinitions......................................................................................................... 15
2.2
Fast handoff....................................................................................................... 18
2.2.1
Scnario..................................................................................................... 20
2.3
Bi casting........................................................................................................... 22
2.3.1
Bi casting par lagent mre........................................................................ 23
2.3.2
Bi casting ralis par lutilisation dun tunnel .......................................... 25
2.4
Architecture hirarchique.................................................................................. 25
2.4.1
Mobile IP Hirarchique............................................................................. 26
2.4.2
Bi casting dans une architecture hirarchique........................................... 28
2.5
Protocoles intgrant le paging ........................................................................... 28
2.5.1
Cellular IP ................................................................................................. 28
2.5.1.1 Dtail du protocole ................................................................................ 30
2.5.1.2 Traitement du handoff........................................................................... 31
2.6
Conclusion......................................................................................................... 31
3 Prsentation du simulateur rseau NS-2.................................................................... 34
3.1
Introduction ....................................................................................................... 34
3.2
Architecture et implmentation......................................................................... 36
3.2.1
Implmentation du simulateur................................................................... 36
3.2.1.1 Composants de la topologie .................................................................. 37
3.2.1.2 La gestion des files dattente................................................................. 38
3.2.1.3 Les agents.............................................................................................. 38
3.2.1.4 Le routage.............................................................................................. 40
3.2.1.5 Les rseaux locaux (LAN) .................................................................... 41
3.2.1.6 La mobilit dans NS.............................................................................. 42
3.3
Moteur du simulateur ........................................................................................ 47
3.4
Point de vue de lutilisateur............................................................................... 48
3.5
Statistiques et visualisation ............................................................................... 50
ii
Table des matires

3.5.1
Systme de suivi........................................................................................ 50
3.5.2
NAM.......................................................................................................... 53
3.6
Extension pour la mobilit ................................................................................ 57
3.6.1
NOAH ....................................................................................................... 57
3.6.2
CIMS ......................................................................................................... 57
3.6.2.1 Scnario................................................................................................. 58
3.6.2.2 Tests sur Cellular IP .............................................................................. 59
3.6.3
Mobiwan.................................................................................................... 64
3.6.3.1 Gnration et manipulation de grandes topologies ............................... 66
3.6.3.2 Mobile IPv6 et IPv6 .............................................................................. 69
3.6.3.3 Mobilit dans un WAN ......................................................................... 73
3.7
Conclusion......................................................................................................... 75
4 Gestion dinterfaces multiples................................................................................... 77
4.1
Description du projet de gestion dinterfaces multiples sans fil ....................... 77
4.1.1
Les objectifs .............................................................................................. 77
4.1.2
Etat de lart ................................................................................................ 78
4.1.3
Cadre du projet et partenaires.................................................................... 79
4.2
Prsentation de larchitecture MIMP ................................................................ 79
4.3
Normes prises en considrations ....................................................................... 81
4.3.1
IEEE 802.11 .............................................................................................. 82
4.3.2
HiperLAN/2 .............................................................................................. 83
4.3.3
Bluetooth ................................................................................................... 84
4.3.4
Comparatif des trois normes et porte des solutions technologiques........ 85
4.4
Introduction de larchitecture MIMP dans NS-2............................................... 86
4.4.1
Planification .............................................................................................. 86
4.4.2
Implmentation dun nouvel objet ............................................................ 87
4.4.3
Conclusion................................................................................................. 88
Conclusion.................................................................................................................... .89
Rfrences bibliographiques 91
Rfrences Internet 93
Glossaire
97
iii
Liste des illustrations
LISTE DES ILLUSTRATIONS

Figure 1-1 : modle des couches OSI.................................................................................. 5
Figure 1-2 : architecture de base ......................................................................................... 6
Figure 1-3 : configuration DHCP ........................................................................................ 8
Figure 1-4 : enregistrement v4 ............................................................................................ 8
Figure 1-5 : ds-enregistrement auprs de lagent mre ..................................................... 9
Figure 1-6 : routage triangulaire : du correspondant au mobile .......................................... 9
Figure 1-7 : routage triangulaire : du mobile au correspondant ........................................ 10
Figure 1-8 : communication v6 ......................................................................................... 12
Figure 2-1 : niveaux du handoff ........................................................................................ 17
Figure 2-2 : initialisation du handoff................................................................................. 20
Figure 2-3 : enregistrement MIP ....................................................................................... 21
Figure 2-4 : enregistrement MIPv6 ................................................................................... 22
Figure 2-5 : bi casting par lagent mre ............................................................................ 24
Figure 2-6 : explicite multicast pour le bi casting ............................................................. 25
Figure 2-7 : architecture hirarchique ............................................................................... 26
Figure 2-8 : architecture Cellular IP .................................................................................. 29
Figure 3-1 : projet VINT ................................................................................................... 34
Figure 3-2 : structure dun lien .......................................................................................... 38
Figure 3-3 : structure dun nud unicast .......................................................................... 39
Figure 3-4 : exemple de composition dune application ................................................... 40
Figure 3-5 : structure dun LAN ....................................................................................... 41
Figure 3-6 : composants dun nud mobile (sauf pour DSR) .......................................... 43
Figure 3-7 : architecture dun scenario wired-cum-wireless ......................................... 45
Figure 3-8 : structure dun nud point dattache pour MIP ............................................. 46
Figure 3-9 : diagramme de NAM ...................................................................................... 54
Figure 3-10 : fentre danimation NAM ........................................................................... 55
Figure 3-11 : animation de paquets dans NAM ................................................................ 55
Figure 3-12 : simulation souhaite .................................................................................... 56
Figure 3-13 : Simulation observe .................................................................................... 56
Figure 3-14 : topologie des tests ....................................................................................... 59
Figure 3-15 : plate-forme de test Cellular IP..................................................................... 60
Figure 3-16 : paquets perdus pour un flux CBR ............................................................... 62
Figure 3-17 : numro de squence TCP pendant un handoff (mobile rcepteur) ............. 63
Figure 3-18 : numro de squence TCP pendant un handoff (mobile metteur) .............. 64
Figure 3-19 : aires de mobilit locale et de mobilit globale ............................................ 65
Figure 3-20 : topologie attendue ....................................................................................... 67
Figure 3-21 : nouvelle structure dun nud filaire ........................................................... 70
Figure 3-22 : nouvelle structure dun nud mobile ou dun point daccs ...................... 71
Figure 3-23 : mouvement lintrieur dune grille ........................................................... 74
Figure 4-1 : vue gnrale de larchitecture intgrant MIMP ............................................. 81
Figure 4-2 : topologie utilise dans IEEE 802.11 ............................................................. 83
Figure 4-3 : modle de rfrence de HiperLAN/2 ............................................................ 84
iv
Liste des illustrations
Figure 4-4 : dbit et porte de diffrentes modes de connexion ....................................... 86

Figure 4-5 : gestion dinterfaces multiples dans NS-2 ...................................................... 87
Liste des tableaux
LISTE DES TABLEAUX

Tableau 1 : : format du fichier de sortie .tr........................................................................ 51
Tableau 3 : fonctionnalit de limplmentation CIMS ..................................................... 58
Tableau 4 : comparatif des trois normes ........................................................................... 85
vi
Introduction
INTRODUCTION
LInternet sans fil est actuellement en pleine expansion. En effet, on voit arriver sur le
march divers produits permettant la communication entre quipements mobiles. Ces
produits utilisent des technologies diffrentes et peuvent grossirement se classer en deux
catgories : les rseaux cellulaires pour la tlphonie mobile et les rseaux IP pour
lInternet. Les rseaux cellulaires [19] comme GPRS [20] se focalisent sur la meilleure
gestion possible de la mobilit, cest--dire permettre aux utilisateurs de pouvoir se
dplacer sans rompre les communications en cours. En contre parti, le dbit offert est trs
limit, ce qui limite la porte de ces quipements cellulaires la tlphonie. A lheure
actuelle, de nouvelles technologies sont en train dmerger (UMTS [21][22][23][24]),
offrant un dbit plus lev. Cela devrait permettre dtendre le domaine dapplication.
Les rseaux IP ont t mis en place initialement par linterconnexion dhtes fixes
relis par un rseau filaire. Lobjectif tait doffrir une communication rapide haut
dbit. De nos jours, on essaye de plus en plus de rendre ces quipements IP mobiles.
Diffrentes technologies de communication sans fil (IEEE 802.11, HiperLAN/2) sont en
train de voir le jour. Elles offrent des dbits suffisants pour la connexion dhtes mobiles
des rseaux IP. Cependant, la gestion des dplacements nest pas encore suffisamment
optimise pour permettre ces htes mobiles dexcuter certaines applications en temps
rel comme par exemple la vido.
La mobilit dans lInternet a t introduite par lorganisme de standardisation IETF1
qui sest principalement pench sur la gestion des dplacements dun ordinateur mobile
sur lInternet, c'est--dire du passage dun rseau local un autre rseau local. Ce travail
a permis de dfinir un protocole appel Mobile IP. Les travaux rcents qui tudient
lutilisation des rseaux cellulaires (Cellular IP, Hawaii ) montrent les diffrents
problmes poss par la gestion des diffrentes mobilits des terminaux et la prise en
compte rapide des dplacements. La plupart de ces travaux sont proposs par des
universits amricaines et ne sont qu leur dbut : ils ntudient lheure actuelle que les
problmes de handoffs lintrieur dune seule technologie daccs.
LInternet du futur aura plusieurs objectifs :
Utiliser les nouveaux protocoles afin de supporter de plus en plus de rseaux et

dutilisateurs : cela passera par ladoption dIPv6 et des protocoles associs.
Exprimenter de nouvelles solutions et des nouvelles fonctionnalits. La

mobilit des utilisateurs est lun des points forts de cet aspect. LInternet
mobile nouvelle gnration nexiste pas encore et il convient de dfinir
rapidement les protocoles qui permettront sa dmocratisation au sein des
communauts dutilisateurs mais galement son adoption par les diffrents
oprateurs.
Il existe ce jour peu de projets qui proposent, tudient et dveloppent des solutions
pour lInternet Mobile nouvelle gnration. Il est donc essentiel de pouvoir proposer une
1
IETF : Internet Engeenering Task Force, http://www.ietf.org
Introduction
vision globale de la prise en compte sur les terminaux mobiles de la mobilit aussi bien
au niveau IPv6 quau niveau de la gestion des interfaces multiples sans fil.
Lobjet de ce stage de DEA est ltude de terminaux mobiles communicants dans des
rseaux IP. Lobjectif est de faire un tat de lart complet de toutes les solutions
mergentes pour rsoudre les problmes lis la mobilit des htes. Cet tat de lart
servira pour des travaux futurs sur lintra mobilit ; lintra mobilit est la mobilit interne
un quipement, cest--dire la gestion du changement dinterface communicante. Le
stage a dur cinq mois, de fvrier fin juin 2001. Il sest dcompos en deux parties
quivalentes qui taient ltude des solutions pour la mobilit, notamment par le suivi des
groupes de travail Seamoby et MobileIP de lIETF, et ltude du simulateur rseau NS-2.
Le rapport est structur de la manire suivante : tout dabord une premire partie est
consacre ltude du protocole Mobile IP [1][2] qui gre le dplacement des htes
mobiles dans les rseaux IP. Les versions 4 (actuellement utilis dans lInternet) et 6 (en
train dtre mise en place) seront tudies. Ensuite, les optimisations Mobile IP
envisages seront exposes dans la partie 2. Ces optimisations concernent lamlioration
des techniques de dplacement pour minimiser les impacts sur les applications. Ces
amliorations sont essentiellement prsentes par des groupes de travail de lIETF. Puis,
le simulateur rseau NS-2 (Network Simulator) sera tudi. NS-2 est le simulateur le plus
utilis dans la communaut de recherche en rseau et permet de simuler diffrentes
caractristiques de protocoles en cours de ralisation. On sintresse de trs prs NS car
nos travaux futurs concerneront dans un premier temps lintgration dune nouvelle
architecture dans NS-2. Le projet de cette nouvelle architecture nomme MIMP2 sera
prsent dans une quatrime et dernire partie.
2
MIMP : Multiple Interfaces Management Protocol, protocole de gestion dinterfaces multiples.
PARTIE 1
LA MOBILITE
Partie 1 : La Mobilit
1 LA MOBILITE
1.1
Introduction
Le terme de mobilit dfini la situation intermdiaire entre le nomadisme et les

rseaux ad hoc. Le nomadisme reprsente le dplacement d'un quipement IP3 [29] entre
des communications. Le nomadisme doit permettre l'utilisateur de ne pas avoir
reconfigurer son quipement lui-mme aprs chacun de ses dplacements ; Cette
fonctionnalit passe par une gestion centrale d'adressage. Ce mcanisme est utilis
principalement par les fournisseurs de service Internet.
l'oppos, les rseaux ad hoc reprsentent des rseaux composs uniquement dhtes
mobiles. Chaque hte mobile a une fonctionnalit de routage et les htes mobiles
maintiennent des routes entre eux en fonction de leur joignabilit.
Enfin, la mobilit d'un quipement IP dans l'Internet est le cas intermdiaire ; C'est la
possibilit pour un hte mobile de poursuivre ses communications pendant un
changement de point d'attache l'Internet. Les communications deviennent donc
indpendantes de la localisation et lhte mobile doit toujours pouvoir continuer utiliser
son adresse IP principale. Le protocole qui rsout les problmes associs la mobilit est
Mobile IP [1][2]. Bien entendu, ce protocole doit permettre des communications avec
des htes correspondants qui ne l'implmentent pas.
L'objet de cette partie est de donner un aperu de la mobilit IP telle que dcrite dans
le protocole Mobile IP, son fonctionnement et ses limites. On verra donc dans la partie
suivante, quelques nouveaux termes associs Mobile IP. Dans les deux parties
successives, on dtaillera tout d'abord l'change de messages qui a lieu lors du
changement de point d'attache d'un mobile puis on explicitera le droulement des
communications des mobiles sur l'Internet, aussi bien pour la version 4 que pour la
version 6 du protocole Internet IP [29].
1.2
Terminologie et architecture
Dans cette partie sont dcrits les principaux termes utiliss dans Mobile IP [1][2]. De
plus, une architecture type y sera expose pour une meilleure vision des fonctions de
chaque quipement. Pour de plus amples dfinitions, voir le glossaire.
1.2.1 Modle OSI

LInternet est le plus grand rseau existant lheure actuelle. Il rassemble plusieurs
millions dordinateurs et dutilisateurs. Pour que ces machines puissent cooprer, il a t
ncessaire de dfinir un certain nombre de standards. Larchitecture des machines de
lInternet repose sur une approche en couches, similaire au modle OSI4 (Interconnexion
des Systmes Ouverts) en 7 couches [26]. Ces septs couches sont dcrites dans la Figure
3
4
IP : Internet Protocol
OSI : Open Systems Interconnexion Interconnexion des systmes ouverts
1-1.
Application
Couche n7 : comprend les programmes dapplication qui utilisent

le rseau. La messagerie lectronique, ou le transfert de fichiers
Prsentation
Couche n6 : est destine supporter les fonctions dont beaucoup

de programmes ont besoin, comme la compression de texte ou la
conversion dimages graphiques.
Session
Couche n5 : dfinit la manire dont les protocoles peuvent tre

organiss pour fournir toutes les fonctionnalits dont les
programmes dapplication se servent
Transport
Couche n4 : assure un contrle de bout en bout, en permettant

un processus destinataire de communiquer directement avec le
processus source
Couche n3 : dfinit lunit de donnes de base transfre sur le
rseau entre deux sites extrmes et inclut les concepts dadressage
et de routage
Rseau
Liaison
Couche n2 : soccupe de lacheminement de trames de donnes

entre deux quipements voisins
Physique
Couche n1 : soccupe de la connexion physique dune machine

avec le rseau
Figure 1-1 : modle des couches OSI

Lensemble de ce rapport sappuie sur larchitecture OSI de la Figure 1-1. On
sintressera plus particulirement aux couches liaison et rseau. La couche liaison car
elle gre laccs au mdium physique et certaines informations peuvent tre trs utiles
dans la gestion de la mobilit. La couche rseau est actuellement implmente par le
protocole IP dans lInternet. Lobjet de ce rapport est principalement de constater et de
proposer des solutions aux impacts causs par la mobilit sur le fonctionnement de ce
protocole. On parlera aussi quelque fois des couches transport et application pour tester
les effets des protocoles de la couche rseau sur les couches suprieures.
1.2.2 Nouveaux quipements

Tout d'abord, on distingue deux types de rseaux selon la position du nud mobile.
On appellera rseau mre ou rseau principal le rseau auquel est rattach le nud mobile
administrativement. Cest le rseau dans lequel il est dclar dans le DNS [35][36] et sur
lequel il obtient une adresse IP principale. D'un autre ct, on appelle rseau visit ou
rseau tranger un rseau o le nud mobile se trouve un moment donn lors de ses
dplacements.
Dans Mobile IP, quatre nouveaux acteurs sont dfinis :
Noeud mobile : quipement IP qui est capable de se dplacer sur Internet et

implmentant le protocole Mobile IP
Agent mre : routeur d'accs avec une interface sur le mme lien que le
noeud mobile (dans le rseau mre du mobile)
Agent visit : routeur d'accs avec une interface sur le lien courant du
noeud mobile (dans un rseau visit). Cet agent nexiste que dans Mobile
IPv4.
Point daccs : quipement intermdiaire entre le rseau filaire et le noeud

mobile qui offre la connexion aux nuds mobiles qui lui sont rattachs
L'architecture de base des ces quipements est prsente dans la Figure 1-2.
Agent mre
INTERNET
Point daccs
Correspondant
Rseau mre
Foreign agent
Point daccs
Nud mobile
Rseau visit
Nud mobile
Figure 1-2 : architecture de base

Les agents de mobilit (agent mre et agent visit) maintiennent une liste des nuds
mobiles quils grent. Cette liste est appele cache dassociation ; elle associe ladresse
principale du mobile son adresse temporaire. Le rle principal de ces agents de mobilit
est dencapsuler (resp. dcapsuler) les paquets en transit entre les correspondants et les
nuds mobiles en ajoutant (resp. en enlevant) un en-tte dadressage (voir le dtail de
lencapsulation et de la dcapsulation dans les parties MIPv4 et MIPv6). Dans MIPv6, les
correspondants dun nud mobile dtiennent aussi un cache dassociation ce qui leur
permet de connatre ladresse temporaire du mobile associe son adresse principale. De
plus amples dtails seront donns dans la section suivante.
1.2.3 Adressage
Un noeud mobile peut avoir plusieurs adresses simultanment. L'adresse qu'un nud
6
mobile acquiert lors de sa premire connexion dans son rseau mre est dite adresse
principale. Cest ladresse qui sera toujours utilise par le mobile et ses correspondants
pour identifier les communications au niveau applicatif. Effectivement, le protocole TCP5
[30] utilise les adresses source et destination pour identifier une communication. Si lon
prcisait tous les correspondants la nouvelle adresse temporaire du nud mobile
chaque dplacement, la communication ncessiterait dtre r-initialise chaque fois. La
communication serait donc rompue chaque dplacement du nud mobile ce qui est
compltement inefficace. Cest pourquoi cest cette adresse principale que les
correspondants utiliseront comme adresse de destination, quelque soit la position du
noeud mobile.
En plus, le noeud mobile peut dtenir de(s) adresse(s) temporaire(s), dite(s) adresse
temporaire. Cette adresse est obtenue par le noeud mobile chaque entre dans un rseau
visit. Le noeud mobile devra indiquer cette adresse son agent mre (et ventuellement
ses correspondants dans MIPv6) priodiquement pour qu'il puisse maintenir une
correspondance entre adresse principale et adresse temporaire.
A prsent tudions plus spcifiquement le fonctionnement des protocoles MIPv4
[1] et MIPv6 [2].
1.3
MIPv4 [1]
1.3.1 Dcouverte des agents de mobilit

Comme on la soulign plus haut, une caractristique propre au mobile est de
pouvoir se dplacer en cours dune communication. Pour cela, un nud mobile doit
pouvoir dtecter ses dplacements, cest--dire dtecter le changement de sous-rseau, ce
qui ncessite lobtention dune nouvelle adresse temporaire. Le protocole de Dcouverte
des Agents [1] met en place un change de messages permettant cette dtection : les
agents de mobilit envoient priodiquement des messages annonant leur disponibilit
sur le lien par lmission de messages Agent Advertisement contenant linformation
ncessaire pour lidentification du sous-rseau. Cette information peut tre le prfixe
rseau par exemple. Par ailleurs, un nud mobile ne dsirant pas attendre un tel message
peut explicitement en demander un par lmission dun Agent Solicitation (cas o lagent
tombe en panne par exemple). Ces messages sont authentifis et sont envoys en
broadcast ou multicast.
1.3.2 Enregistrement auprs de lagent mre

Lorsque le nud mobile dtecte quil a chang de sous-rseau ( travers les messages
explicits ci-dessus), il doit acqurir une nouvelle adresse temporaire et senregistrer
auprs de son agent mre et du agent visit du rseau visit. Lacquisition de cette
nouvelle adresse se fait grce au protocole DHCP6 [32] (voir Figure 1-3).
5
6
TCP : Transmission Control Protocol

DHCP : Dynamic Host Configuration Protocol
Base
de
donnes
Serveur DHCP
Recherche dinformations de configuration
Ton adresse IP est

Client DHCP
Figure 1-3 : configuration DHCP

Une fois que le nud mobile a une adresse temporaire valide, il met un message
Registration Request (tape 1 dans la Figure 1-4) en indiquant la correspondance entre
son adresse principale et son adresse temporaire et ventuellement dautres options. Ce
message passe par le agent visit qui le transmet lagent mre du mobile sil accepte les
requtes du nud mobile. Lagent mre doit acquitter le Registration Request pour bien
confirmer la rception (message UDP7 [31]) et pour informer le nud mobile de
lacceptation ou du refus de la requte par un Registration Reply (tape 2). A rception du
Registration Request, aussi bien lagent mre que le agent visit mettent jour leur cache
dassociation pour ce nud mobile.
1. Registration Request
Agent mre
Foreign agent
INTERNET
2. Registration Reply
Dplacement
Figure 1-4 : enregistrement v4

Ensuite, tant que le nud mobile reste dans le mme sous-rseau tranger, il doit
uniquement envoyer un Registration Request intervalle rgulier pour viter que son
entre dans le cache dassociation des agents de mobilit nexpire. Par contre, chaque
nouveau dplacement dans un autre sous-rseau tranger, il devra reprendre les mmes
oprations que celles dcrites ci-dessus.
Si le nud mobile retourne dans son sous-rseau mre, il doit se ds-enregistrer auprs
de son agent mre. Il envoie alors un De-Registration Request (tape 1 dans la Figure
7
UDP : User Data Protocol
1-5) jusqu ce quil reoive un De-Regitration Reply (tape 2) qui spcifie que lagent
mre a bien reu le message et quil a supprim lentre pour ce nud mobile.
INTERNET
Agent mre
1. De-registration Request
2. De-registration Reply
Figure 1-5 : ds-enregistrement auprs de lagent mre
1.3.3 Communication
La communication entre un nud mobile et un correspondant quelconque sur Internet
est trs spcifique et requiert plusieurs mcanismes des agents de mobilit. Comme un
nud correspondant dun nud mobile ne connat que ladresse principale du nud
mobile, les paquets destination du nud mobile sont toujours envoys dans le sousrseau mre du nud mobile. Si le nud mobile ne sest pas dplac, les paquets lui
seront livrs de la mme manire quun nud fixe, cest--dire sans oprations
supplmentaires. Par contre, si le nud mobile est dans un sous-rseau visit, son agent
mre devra capturer tous les paquets destins au nud mobile et les lui transmettre son
adresse temporaire, grce son cache dassociation (comme illustr Figure 1-6).
Correspondant
Donnes
Dcapsulation
enlve
len-tte ajoute
Foreign agent
Encapsulation
par lajout
dune en-tte
INTERNET
Agent mre
Donnes
Figure 1-6 : routage triangulaire : du correspondant au mobile
De lautre ct, les paquets envoys par le noeud mobile ont ladresse du
correspondant comme adresse destination et ladresse principale du mobile comme
adresse source. Ceci prsente une entorse au modle de lInternet puisque ladresse
source des paquets envoys par le nud mobile ne correspond pas au prfixe du sousrseau visit. Les paquets devront alors obligatoirement passer par lagent visit pour
viter quils ne soient dtruits (ingress filtering [37]). Par contre, une fois que les paquets
ont t routs hors du sous-rseau visit, ils vont directement du nud mobile au
correspondant sans passer par le rseau mre. Cest ce quon appelle le routage
triangulaire (voir Figure 1-7).
Correspondant
Donnes
Vrifie quil a une entre
pour ce mobile dans son
cache dassociation
Foreign agent
INTERNET
Agent mre
Donnes
Figure 1-7 : routage triangulaire : du mobile au correspondant

Etudions plus en dtail les oprations ncessaires pour effectuer ce routage
triangulaire : tout dabord, lorsque le nud mobile se dplace dans un sous-rseau visit,
il doit en informer son agent mre travers un Registration Request. A la rception de ce
message, si lagent mre accepte la requte, en plus de crer ou de mettre jour lentre
pour ce nud mobile, il envoie une requte ARP [27][28] sur le rseau principal afin de
faire correspondre ladresse IP du mobile avec son adresse MAC [27]. Ainsi il peut
intercepter les paquets destination du mobile. Ensuite, lagent mre doit faire suivre ces
paquets la position courante du mobile. Pour cela, il encapsule chaque paquet en
ajoutant un en-tte de destination rempli avec ladresse temporaire courante du mobile
comme adresse destination et avec son adresse comme adresse source avant de les
tunnells lagent visit. Enfin, chaque paquet est dcapsul par lagent visit
(suppression de len-tte) et dlivr au nud mobile. Ces oprations sont dcrites dans les
Figure 1-4 et Figure 1-6.
10
1.4
MIPv6 [2]
Une nouvelle version du protocole IP est en train dmerger depuis quelques

annes : il sagit de la version 6 du protocole IP. Ce protocole inclut entre autres la
mobilit en standard. Lobjectif de MIPv6 est doffrir une communication directe entre
un nud mobile et ses correspondants (limination du routage triangulaire) et viter les
ruptures des communications pendant les dplacements. Bien que MIPv6 reprenne des
mcanismes de MIPv4, de nombreuses fonctionnalits supplmentaires ont t mises en
place.
1.4.1 Fonctionnalits requises

Dans MIPv6, le agent visit dcrit dans MIPv4 nexiste plus. Par contre, lagent mre
est encore un routeur daccs du sous-rseau principal du nud mobile. Son rle est le
mme que dans le cas de MIPv4, savoir capturer les paquets destination du mobile et
les lui tunneller sa localisation courante.
Par contre, les correspondants doivent mettre en uvre certains
mcanismes supplmentaires : tout dabord, ils doivent disposer dun cache dassociation
tout comme lagent mre ; dans ce cache sera stocke la correspondance entre ladresse
principale dun nud mobile avec lequel il a une communication et son adresse
temporaire courante. Il devra donc tre capable de traiter des messages de registration
envoys par un nud mobile. De plus, il devra tre capable deffectuer le routage
directement vers le mobile (routing header). Ceci constitue un apport important dans le
fonctionnement de la mobilit puisque les paquets des correspondants nauront pas
passer par le rseau mre systmatiquement. Mais toutes ces fonctionnalits
supplmentaires ne sont faites quau niveau de la couche IP ; ladresse identifiant la
communication au niveau applicatif sera toujours ladresse principale du noeud mobile, la
couche IP cahant ladresse temporaire source (ou destination selon quon se situe sur le
noeud mobile ou le correspondant).
Dun autre ct, un nud mobile doit toujours conserver la liste des correspondants
auxquels il envoie un message de registration (pour les mises jour ventuelles) et doit
tre capable de dcapsuler lui-mme les paquets qui lui sont transmis ; au niveau
application, un nud mobile utilise toujours son adresse principale, cest pourquoi la
couche IP doit pouvoir dcapsuler len-tte indiquant ladresse temporaire. Cette
opration tait excute par le agent visit dans MIPv4.
1.4.2 Dcouverte des routeurs daccs

Le protocole de dcouverte des voisins [33] offert par IPv6 joue un rle important
dans MIPv6. Il permet entre autres des quipements situs sur le mme lien physique de
se dcouvrir mutuellement, de dcouvrir leurs adresses niveau 2 et de localiser les
quipements de routage. Le processus de dcouverte des routeurs daccs se droule de
manire similaire au protocole de dcouverte des agents ; tout routeur daccs met
priodiquement des Router Advertisment contenant la liste des prfixes sur le lien. Un
nud mobile peut ventuellement en demander un explicitement, travers un Router
Solicitation.
11
Les routeurs daccs offrant des fonctionnalits pour la mobilit mettent des
Router Advertisement quelque peu modifi (pour avertir les mobiles de leur capacit). En
outre, linformation contenue dans ces Router Advertisement permet aux noeuds mobiles
de crer une adresse temporaire (auto configuration offerte par IPv6). Ensuite il leur
faudra vrifier lunicit de celle-ci grce au protocole de dtection de duplication
dadresse [34]. La dcouverte des voisins ainsi que la dcouverte de ladresse de niveau 2
dun quipement voisin savre aussi trs utile dans la mobilit, notamment pour
effectuer des registrations plus rapides. Lutilisation des ces donnes sera dtaille plus
tard dans le rapport car le protocole MIPv6 ne prend pas encore en compte ces donnes.
1.4.3 Enregistrement
De la mme manire que dans MIPv4, lorsquun nud mobile se dplace hors de son
sous-rseau mre, il doit en informer son agent mre. Le nud mobile signale la
correspondance entre son adresse principale et son adresse temporaire courante dans un
message Binding Update. Ce message peut ventuellement tre envoy en piggybacking8 . En rponse une telle requte, lagent mre envoie un Binding
Ackowledgement pour indiquer sil peut rpondre la requte du mobile. Pour le
moment, tout se passe comme dans MIPv4. Cependant, le mobile a par la suite la
possibilit dinformer ses correspondants de sa position courante ; Lorsquil reoit un
paquet dun correspondant, il dtermine si le paquet a transig par le rseau mre en
regardant si le paquet contient un routing header ou sil a t tunnel par lagent mre
(encapsulation). Sil ne contient pas de routing header, le nud mobile en dduit que le
correspondant metteur na pas dentre dans son cache dassociation pour lui. Il peut
alors lui envoyer un Binding Update pour quil lui envoie les paquets directement, sans
plus passer par son sous-rseau mre (F
Figure 1-8).
Correspondant
3. Mise jour
du cache
dassociation
1. Donnes
1.
INTERNET
1. Donnes
Agent mre
2. Binding
Update
Figure 1-8 : communication v6

8
Piggy-backing : fait de mettre des informations de control dans des paquets de donnes
12
Le fait que les correspondants aient la possibilit denvoyer les paquets directement au
mobile offre une meilleure rsistance au facteur dchelle et fiabilit. La communication
entre nuds mobiles et correspondants engendre moins de charge sur le rseau et est plus
rapide. Comme lagent mre est peu sollicit pour la retransmission des paquets, il y a
beaucoup moins de risque de congestion au niveau de lagent mre et une panne de
lagent mre aura un effet moindre.
Un nud mobile peut dtenir plus dune adresse temporaire un instant donn. Celle
enregistre auprs de lagent mre (une seule) est dite principale. Lutilisation de
plusieurs adresses temporaires peut tre utile pour amliorer les performances lors dun
dplacement lorsque par exemple deux cellules de points daccs se recouvrent
fortement ; le nud mobile peut alors acqurir une nouvelle adresse temporaire tout en
utilisant son ancienne le temps de lopration.
13
PARTIE 2
HANDOFF ET MICRO MOBILITE
14
Partie 2 : Handoff et Micro Mobilit
2 HANDOFF ET MICRO MOBILITE

Laccs sans fil risque de devenir de plus en plus frquent dans les prochaines annes.
Les utilisateurs mobiles demanderont videmment des niveaux de qualit de service
identiques ceux offerts aux utilisateurs de postes fixes. Dun autre ct, le protocole
utilis actuellement pour grer la mobilit IP (MIP) [1][2] fait cruellement ressentir ses
limites dans un tel environnement. Une telle vision prsente donc un certain nombre de
dfis techniques pour la mobilit IP en terme de performance et de mise lchelle.
Cest donc pour cela que rcemment un certain nombre de protocoles de micromobilit visant amliorer les performances de MIP ont t prsents dans le groupe de
travail de lIETF9. Ces protocoles de micro-mobilit sont conus pour des
environnements o les nuds mobiles changent leur point dattache lInternet si
frquemment que le tunneling de MIP savre insuffisant : surcharge de la signalisation,
perte de paquets, livraison des donnes aux applications retardes. Ces retards sont
directement lis au temps daller-retour des messages denregistrement. Les protocoles de
micro-mobilit aspirent grer les dplacements locaux ( lintrieur de domaines) des
nuds mobiles sans interagir avec MIP, cest--dire cacher au reste de lInternet les
mouvements des nuds mobiles lintrieur dun domaine. Cela a lavantage de rduire
le retard et la perte des paquets pendant un dplacement et limine lenregistrement entre
un nud mobile et son agent mre qui peut tre loign.
Par ailleurs, la signalisation engendre par la gestion de la mobilit saccrot avec le
nombre dutilisateurs. Dans les rseaux cellulaires, lenregistrement et les techniques de
pagination10 sont employs pour rduire au maximum la signalisation et optimiser les
performances de la gestion de la mobilit. Actuellement, MIP supporte lenregistrement
mais pas la pagination. Une caractristique importante des protocoles de micro-mobilit
(cf. section 2.1) est leur capacit rduire la signalisation lie aux migrations frquentes
des mobiles et de rduire la consommation des quipements en tenant compte du mode
oprationnel de cet quipement (actif ou inactif). Le support dune connectivit
passive lInternet (par une localisation approximative) savre imprative puisquil
permet de rduire la charge notamment sur les interfaces ariennes.
Dans ce qui suit, on commencera par dfinir les termes lis la micro-mobilit et au
handoff. Ensuite, on verra les solutions mergentes visant rsoudre les problmes
dcrits ci-dessus : fast handoff [4][5], bi-casting [4][5], MIP hirarchique [11][12], puis
une approche plus proche des rseaux cellulaires avec Cellular IP [14][15][16][17] qui
intgrent la pagination.
2.1
Dfinitions
Dans cette partie sera dcrit la terminologie lie au handoff [19] pour expliciter au
9
IETF : Internet Engeenering Task Force, http://www.ietf.org

Pagination : signalisation mise en uvre pour la localisation des nuds mobiles. Le protocole de
localisation est dpendant du type de liaison utilise.
10
15
mieux ce que chaque protocole essaie de rsoudre. Les termes employs dans ce rapport
sont ceux utiliss par le groupe de travail de lIETF, principalement dcrits dans [3].
Le handoff est le processus enclench quand un mobile actif (en cours de
communication) change son point dattache lInternet. On peut dcouper un handoff de
la manire suivante : handoff de niveau 3 (couche IP) et handoff de niveau 2 (couche
liaison), daprs le modle OSI prsent partie 1 section 1.2.1. Le handoff de la couche 2
est lopration effectue par un nud mobile qui change de point daccs sans fil, cest-dire que cest le passage dun point daccs un autre. Ce handoff peut engendrer ou non
un handoff de la couche suprieure selon le lien filaire des points daccs (si elles sont sur
le mme lien rseau ou non). Plus gnralement, on distingue trois types de handoff :
Handoff intra-routeur daccs : handoff gnr par le changement

dinterface rseau du routeur daccs par laquelle il communique avec le
mobile. Ladresse IP du mobile ne change pas.
Handoff lintrieur dun rseau daccs : Opration effectue quand le

nud mobile change de routeur daccs en restant dans le mme rseau
daccs. Ce handoff est invisible pour un point extrieur au sous-rseau et
ladresse du mobile ne change toujours pas, mais le chemin pour latteindre
est modifi.
Handoff entre rseaux daccs : Dplacement du mobile hors du rseau

daccs ; cette fois le nud mobile a besoin dacqurir une nouvelle adresse
IP.
Les travaux de recherche concerne surtout lamlioration du dernier type de handoff,

cest--dire celui qui ncessite des messages denregistrement et qui peut provoquer une
rupture de communication. On verra par la suite que lutilisation des informations de
niveau 2 (couche liaison du modle OSI prsent dans la premire partie) peut savrer
fort util pour anticiper un handoff de niveau 3 (couche IP du modle OSI). Ces trois types
de handoff sont illustrs dans la Figure 2-1 ci-dessous.
16
Rseau daccs 1
Rseau daccs 2
Gateway
routeur
Routeur
daccs 1
Gateway
routeur
Routeur
daccs 3
Routeur
daccs 2
Point
Point
Point
daccs
Point
Gateway
routeur
daccs
daccs
daccs
Handoff intra-routeur daccs

Handoff lintrieur dun rseau daccs
Handoff entre rseaux daccs
Figure 2-1 : niveaux du handoff

On parlera par la suite de la latence du handoff pour exprimer les performances sur
celui-ci. La latence du handoff est le laps de temps entre le dernier moment o le mobile
peut recevoir et mettre des paquets IP travers lancien routeur daccs et le premier
moment o il peut recevoir et mettre des paquets travers le nouveau routeur daccs.
Cest donc le temps pendant lequel un nud mobile ne peut ni recevoir, ni mettre un
trafic IP.
Par ailleurs, le processus de handoff peut tre amlior soit en rduisant le nombre de
paquets perdus, soit en diminuant la charge de la signalisation, soit encore en rendant le
processus le plus rapide possible. On parlera alors de :
Smooth handoff : handoff qui a pour but principal de minimiser la perte de

paquets, sans condition sur le dlai de forwarding des paquets.
Fast handoff : handoff qui a pour but principal de minimiser les dlais, sans
conditions sur le nombre de paquets perdus.
Seamless handoff : la dfinition absolue est un handoff o il ny a pas de
17
changement dans la capacit, la scurit ou la qualit du service. En pratique,

une dgradation est tout de mme observe ; La dfinition pratique est que les
applications ou les utilisateurs ne remarquent pas ces dgradations.
De plus en plus on parle de micro mobilit dans le domaine de la recherche sur la
mobilit des htes. La micro mobilit est la gestion fine de la mobilit, souvent dans une
aire ou un domaine limit en taille. Des protocoles distincts peuvent tre utiliss pour
grer la micro mobilit et la mobilit globale (entre aires ou domaines). Un protocole de
micro mobilit raffine la gestion de la mobilt en fonction des besoins spcifiques dans
laire ou le domaine en question.
Une plus ample terminologie est donne dans le glossaire. Par la suite, on sera encore
amener dfinir quelques termes spcifiques chaque protocole. Dans un souci de clart,
dans le cas de MIPv4 [1], on appelle ancien agent visit (AV) lagent visit auquel le
nud mobile est attach et quil est sur le point de quitter pour le nouveau AV. Dans le
cas de MIPv6 [2], on parle dancien routeur daccs (RA) et de nouveau RA.
2.2
Fast handoff
Le support du fast handoff [4][5], qui rduit le retard et la perte de paquet pendant un
handoff, est un apport important aux protocoles de micro-mobilit. Un certain nombre de
choix dans la structure des protocoles influencent les performances du handoff, comme le
contrle du handoff, le buffering et les techniques de forwarding, le comportement radio,
la dtection et la prdiction de mouvement et l'accouplement et la synchronisation entre
les couches IP et radio. Lobectif sous-jacent lintroduction du fast handoff est
dessayer de combiner tous ces choix dans un mme protocole.
La solution de fast handoff est la minimisation de la latence du handoff. Le principe
est dtablir une nouvelle adresse temporaire avant de rompre la liaison du nud mobile
avec son ancien AV/RA. Ensuite, quand le mobile se rattache au nouvel agent de
mobilit, il peut continuer ses communications avec sa nouvelle adresse dj dtermine.
Si lenregistrement anticip choue, le mobile peut toujours raliser une opration de
handoff traditionnel . On verra de plus que le fast handoff met en place un systme de
forwarding des paquets entre lancien et le nouveau routeur daccs.
Ltablissement de la nouvelle adresse temporaire avant que le nud mobile ne se
dplace implique une anticipation sur le mouvement du mobile. Cette anticipation peut
tre faite partir des messages changs au niveau physique ou simplement par la
remonte dinformations pertinentes de niveau 2 (mesure dintensit du signal).
Lobjectif est de raliser le handoff de niveau 3 avant que celui ne la couche 2 nai fini.
Le fait de faire interagir plus fortement les deux couches peut rduire au minimum la
latence du handoff mais peut avoir un effet nfaste sur l'applicabilit gnrale de la
solution. Comme nous allons le voir, beaucoup de propositions exposes par les groupes
de travail Mobile IP11 et Seamoby12 de lIETF discutent de seamless handoff o les
donnes sont changes entre les anciens et nouveaux points d'accs pendant le handoff.
La plupart de ces approches utilisent une signalisation assez complexe, du buffering et
11
12
Mobile IP : groupe de travail de lIETF cherchant normaliser des protocoles pour optimiser Mobile IP.
Seamby : groupe de travail de lIETF cherchant normaliser des protocoles de micro-mobilit.
18
des procdures de synchronisation. La dtection de mouvement au niveau 3 joue un rle

important dans les performances du handoff. Le retard induit par la reconnaissance et
l'enregistrement un nouveau point d'accs peut avoir un impact significatif sur la
livraison des donnes et la mobilit. Le schma du handoff bas sur la mesure de
lintensit du signal peut fournir de meilleures solutions ; Cest le cas lorsque le handoff
de la couche 3 est dclench par un vnement de la couche 2. Cependant, tant donn la
grande diversit des quipements sans fil, il est difficile de dfinir les oprations et les
interactions de ces protocoles radio dans une mobilit globale, sans tomber dans des
dfinitions spcifiques. Il est donc ncessaire de dfinir une API radio qui capture
l'essence de chaque technologie sans fil sans exposer des dtails spcifiques. Cette API
faciliterait la couche 2 "a dclench" le handoff indpendamment de la technologie radio.
Ce point sera mis plus en avant dans le partie 3 du rapport puisquil constitue lobjet de
mes futurs travaux.
Dans un souci defficacit, lanticipation peut concerner plus dun agent de mobilit
[4]. On peut mme se retrouver dans des cas o on a un chanage de AV/RA lorsque le
nud mobile se dplace rapidement.
Le nouveau routeur daccs (agent visit dans le cas de MIPv4) doit stocker les htes
voisins qui sont capables de venir dans son sous-rseau pour dfendre les adresses
alloues. Nanmoins, ce type dentre a besoin dtre gard moins longtemps quune
ente pour un hte appartenant rellement au sous-rseau. Cest pourquoi le nouveau
routeur daccs utilise un cache des voisins pour stocker les nuds mobiles susceptibles
dentrer dans le sous-rseau.
Le protocole de fast handoff fonctionne dans les cas du handoff initialis par le mobile
et dans le cas du handoff initialis par le rseau, la diffrence tant dans lordre des
messages. Cinq nouveaux messages ont t dfinis en plus de ceux de MIP, dont trois
entre routeur daccs et nud mobile :
Router Solicitation For Proxy : envoy par le nud mobile pour demander
son ancien AV/RA un Proxy Router Advertisement. Le nud mobile doit
indiquer sa destination (par exemple en donnant ladresse physique du
nouveau point dattache)
Proxy Router Advertisement : envoy par lancien AV/RA un nud mobile

pour linformer sur son nouveau sous-rseau potentiel ; Lancien AV/RA peut
indiquer au mobile quil ne connat pas le sous-rseau potentiel, que le
nouveau point dattachement appartient en fait au mme sous-rseau ou avec
une adresse ou un prfixe rseau. Ce message peut tre non sollicit (cas du
handoff contrl par le rseau) ou en rponse un Router Solicitation For
Proxy.
Neighbor Advertisement : envoy par le nud mobile pour informer le

nouveau AV/RA quil est arriv dans le nouveau sous-rseau.
Les deux autres messages du protocole sont changs entre les agents de
mobilit :
Handover Initiate : envoy par lancien routeur daccs au nouveau pour

demander une adresse temporaire ou pour en valider une.
19
Handover Acknowledgement : envoy par le nouveau AV/RA lancien en

rponse un Handover Initiate pour valider ou rejeter une adresse.
2.2.1 Scnario
On considre deux agents de mobilit, un ancien auquel le nud mobile est attach et
un nouveau vers lequel le mobile se dplace. Ces agents de mobilit sont des agents
visits (AV) dans le cas de MIPv4 et des routeurs daccs (RA) dans le cas de MIPv6. On
admet que le nouveau AV/RA a t dcouvert par anticipation. Dans ce qui suit, on
considre uniquement le cas o le nouveau AV/RA est connu par lancien, o
lattachement du nud mobile au nouveau sous-rseau est accept par le nouveau
AV/RA et o ladresse temporaire propose est valide. Dans le cas contraire, le fast
handoff choue et le nud mobile peut raliser un handoff comme dcrit dans MIP. De
plus, on admettra que les routeurs daccs utilisent lautoconfiguration dadresse sans
tat, comme cest la plupart du temps le cas aujourdhui (le cas dautoconfiguration
dadresse avec tat sera dvelopp juste aprs).
Dans le cas du handoff contrl par le mobile, le nud mobile envoie un Router
Solicitation For Proxy (tape 1a dans la Figure 2-2) quand il dtecte quun handoff va
avoir lieu. Comme dit prcdemment, le nud mobile inclus des informations permettant
lidentification du nouveau AV/RA. Lancien AV/RA rpond avec un Proxy Router
Advertisement (tape 1b) qui contient une nouvelle adresse temporaire. Dans le mme
temps, lancien AV/RA envoie un Handover Initiate au nouveau AV/RA avec cette
nouvelle adresse pour validation (tape 1b).
Dans le cas du handoff contrl par le rseau, une entit spcifique du rseau dcide
quand le mobile a besoin de se rattacher un nouveau point daccs. Quand le mobile
semble se dplacer, lancien AV/RA envoie la fois un Proxy Router Advertisement
Unsolicited (tape 1b) avec une nouvelle adresse pour le mobile et un Handover Initiate
(tape 1b) au nouveau AV/RA.
Puis, le nouveau AV/RA confirme la validit de la nouvelle adresse dans un Handover
Acknowledgement (tape 2) destination de lancien AV/RA.
1b. Handover Initiate
Ancien
AV/RA
1b. PRA
1a. RSP
2. Handover Ack
Figure 2-2 : initialisation du handoff
20
Nouveau
AV/RA
Ensuite, le nud mobile doit enregistrer sa nouvelle adresse avec son agent mre (et
ventuellement avec ses correspondants dans MIPv6). Cet enregistrement diffre quelque
peu entre les versions 4 et 6 de MIP. Dans MIPv4, le nud mobile envoie un
Enregistrement Request (tape 3 dans la Figure 2-3) son agent mre travers lancien
agent visit ou le nouveau suivant sa localisation. Le Enregistrement Reply (tape 4) est
envoy au nouveau agent visit qui le transmet la nouvelle adresse temporaire du
mobile et lancien agent visit.
4. Reg Rep
Ancien
AV/RA
4. Reg Rep
Nouveau
AV/RA
3. Reg Req
4. Reg Rep
4. Reg Rep
mouvement
Figure 2-3 : enregistrement MIP
Dans le cas de MIPv6, le nud mobile envoie un Binding Update (tape 3 dans la
Figure 2-4) lancien routeur daccs juste avant son dplacement pour lui indiquer son
mouvement. Ce message dclenche le forwarding des paquets entre les routeurs daccs,
paquets que le nouveau routeur daccs met en buffer. Le Binding Acknowledgement
(tape 4) est envoy par lancien routeur daccs lancienne adresse temporaire du
mobile et au nouveau routeur daccs, qui le fait suivre la nouvelle adresse temporaire
du mobile. Si le mobile reoit cet acquittement, aprs son dplacement, il doit envoyer un
Binding Update (tape 5) son agent mre et ses correspondants travers le nouveau
routeur daccs. Sil ne reoit pas lacquittement, il doit renvoyer un Binding Update
lancien routeur daccs et un autre son agent mre et ses correspondants.
21
Ancien
AV/RA
4. Propagation
packets
Nouveau
AV/RA
5. BU to HA
3. BU au AR
4. BAck
mouvement
Figure 2-4 : enregistrement MIPv6

Finalement, le nud mobile envoie un Neighbor Advertise au nouveau routeur daccs
pour lui indiquer son arrive. Cest alors que le nouveau routeur daccs transmet les
paquets mis en buffer au mobile.
Dans le cas de configuration dadresse tat, lancien routeur daccs doit envoyer un
Handover Initiate avant le Proxy Router Advertisement. Le message Handover Initiate
est utilis pour demander une nouvelle adresse temporaire pour le mobile et non pour en
valider une. Le message Handover Acknowledgement contient une adresse valide qui peut
tre transmise au mobile dans le Proxy Router Advertisement.
Si la procdure de fast handoff dcrite ci-dessus termine sans erreur, ltablissement
du service au nouveau point daccs est plus rapide. Un transfert de contexte entre les
deux routeurs daccs, en utilisant le tunnel cre, pourrait encore amliorer la rapidit de
ltablissement de service au nouveau point dattachement. Par contexte on entend les
caractristiques utilises par le noeud mobile pour sa communication, comme la
compression den tte ou des informations de scurit quil partaga avec lancien routeur.
Les dtail du transfert de contexte ne fait pas lobjet de ce prsent rapport. De plus
amples informations peuvent tre trouves dans [6][7][8].
Bien que ce protocole permette de rendre le handoff plus rapide, des paquets peuvent
tre perdus. Pour rsoudre ce problme, on peut utiliser le bi casting vers les deux
AV/RA comme dcrit dans la section suivante.
2.3
Bi casting
Le bi casting [4] est la duplication du mme trafic destin au mobile son ancienne et
sa nouvelle localisation. Cette mthode est utilise pour rduire le nombre de paquets
perdus pendant un handoff pour obtenir un smooth handoff. On parle alors de handoff
proactif. Cette solution peut tre utilis en plus du protocole de fast handoff dcrit cidessus pour envoyer des copies du trafic aux potentielles localisations du nud mobile
[4][5]. Avec certes une augmentation de la charge du rseau, cette solution tend
procurer un seamless handoff. De plus, le bi casting est une bonne solution contre leffet
ping-pong [4] ; quand un nud mobile se dplace entre deux agents de mobilit
22
plusieurs fois et frquemment, MIP ncessite que le nud mobile cre une nouvelle
adresse temporaire et lenregistre chaque attachement. Le Bi casting permet au nud
mobile dtre enregistr avec les deux AV/RA simultanment.
Pour raliser le bi casting, le nud mobile doit tre enregistrer avec plus dun agent de
mobilit. Il doit donc tre capable de grer plusieurs adresses temporaires. Dun autre
ct, les agents de mobilit doivent tre capable de grer des associations multiples. Pour
demander le bi casting, le nud mobile charge un bit spcifique dans son message
denregistrement indiquant sa demande. Quand un agent de mobilit reoit ce type de
message, il ajoute une entre pour le mobile sans en enlever.
Aucun nouveau message nest ncessaire puisque toutes les requtes et rponses lies
au bi casting peuvent tre mis en piggy-backing dans les messages dj utilis dans MIP.
Si le nud mobile sollicite le bi casting auprs dun AV/RA qui ne supporte pas
dassociation simultane, le AV/RA ignore loption et le nud mobile ralise un handoff
comme spcifi dans MIP.
Dans cette section, on dcrit le bi casting partir de deux agents de mobilit
diffrents ; tout dabord on traitera le bi casting gnr par lagent mre. Cette solution
est plus un cas dcole pour introduire les mcanismes du bi casting quune relle
opportunit pour un nud mobile puisquelle prsente des problmes de mise lchelle.
Ensuite on verra le bi casting effectu grce un tunnel entre les deux AV/RA. On
considrera dans tous les scnarios qui vont suivre que le bi casting est ralis en
complment du fast handoff explicit dans la section prcdente.
2.3.1 Bi casting par lagent mre

Aprs avoir procd aux messages du fast handoff (Router Solicitation For Proxy,
Proxy Router Advertisement, Handover Initiate, Handover Acknowledgement), le nud
mobile a juste senregistrer en chargeant le bit indiquant lassociation simultane dans
son message. Dans le cas de MIPv4, le nud mobile envoie un Enregistrement Request
(avec le bit charg) son agent mre. Si lagent mre accepte la requte, il enregistre
deux associations pour ce mobile et enverra dsormais lensemble du trafic aux deux
adresses temporaires du mobile. Les deux agents visits propagent le trafic dans leur
sous-rseau respectif bien que le nud mobile nen coute quun (voir Figure 2-5).
23
Agent mre
trafic
trafic
2 associations
pour le mobile
Ancien
AV/RA
Nouveau
AV/RA
trafic
1. Reg Req
avec le bit S
trafic
Figure 2-5 : bi casting par lagent mre

Bien que le bi casting semble tre efficace et rduise le nombre de paquets perdus,
cette manire de le mettre en uvre nest pas ralisable ; effectivement, lensemble du
trafic pour le nud mobile est dupliqu sur tout le chemin allant de lagent mre au
mobile alors que les paquets prennent exactement le mme chemin, except quelques
derniers sauts. Pour rsoudre ce problme, on peut penser envoyer les paquets en
multicast [9]. Cependant, la gestion de groupe doit tre lgre, dynamique et lajout ou le
retrait dune adresse destinatrice doit se faire rapidement. La technique du Small Group
Multicast (SGM) [10] rpond parfaitement ces besoins ; SGM est bas sur le multicast
explicite : les datagrammes multicast sont routs daprs les informations de routage
unicast et chaque datagramme contient la liste des adresses destination. A chaque saut, le
routeur identifie si pour chaque destination le datagramme peut prendre la mme
direction. Si une adresse indique que le datagramme doit prendre une autre direction que
les autres, le routeur duplique le paquet. Sinon il forward simplement le paquet sans
aucune modification (voir Figure 2-6).
24
paquets
Routeur daccs
2 destinations diffrentes
duplication
Toutes les
destinations ont la
mme direction
Agent mre
Points daccs
Localisation
potentielle pour
le mobile
Figure 2-6 : explicite multicast pour le bi casting

Dautres mthodes pour rduire la charge du rseau tout en faisant du bi casting
existent. Lune dentre elles est de raliser le bi casting partir dun autre point du
rseau. Le bi casting partir de lancien routeur daccs est dcrite dans la sous-section
suivante.
2.3.2 Bi casting ralis par lutilisation dun tunnel

Le tunnel mis en place entre lancien et le nouveau AV/RA par la procdure de fast
handoff (section 2.2) peut tre utilis pour faire du bi casting. Dans le cas de MIPv6, tant
que lentre pour le nud mobile dans lancien routeur daccs na pas expire ou tant
que lagent mre du mobile na pas reu de Binding Update avec la nouvelle adresse
temporaire, le trafic du nud mobile arrive lancien routeur daccs. Une fois que le
mobile envoie un Binding Update avec le bit B (indiquant la demande de bi casting)
charg son ancien routeur daccs, ce dernier peut commencer le bi casting : lancien
routeur daccs forward les paquets lancienne et la nouvelle adresse temporaire.
Comme on vient de le voir, le fast handoff associ au bi casting tend obtenir un
seamless handoff. Cependant, de nombreux changements doivent tre fait dans les
quipements (agent mre, routeurs daccs). Finalement, la mthode de bi casting peut
encore tre enrichi dans un modle hirarchique. Le modle hirarchique, ainsi que la
ralisation du bi casting dans MIP hirarchique sont prsents dans la section suivante.
2.4
Architecture hirarchique
Lobjectif de mettre en place une hirarchie est de cacher certains mouvements des
nuds mobiles ; si un mobile se dplace lintrieur dun domaine, il lui incombe
uniquement de faire un enregistrement rgional, sans indiquer quoique ce soit
lextrieur du domaine. Par contre, lorsque le mobile change de domaine, il lui faudra
faire un enregistrement global [11][12]. Un domaine est dfini comme tant une aire de
mobilit locale [3]. Gnralement un domaine est indpendant des sous-rseaux et sa
taille est choisi par loprateur rseau.
25
La mise en place dune hirarchie permet de minimiser le trafic entre lagent mre et
les agents de mobilit, sans pour autant introduire de signalisation supplmentaire entre le
nud mobile et les agents de mobilit. Le modle hirarchique offre aussi des dlais pour
lenregistrement plus petits. Ce modle est bien adapt pour raliser le fast handoff et le
bi casting.
La dfinition dune architecture hirarchique passe par lintroduction dun nouveau
type de nud qui agit comme un point dancrage pour les nuds mobiles ; Dans MIPv4
[11], il sagit dun agent visit passerelle et dans MIPv6 [12] cest un Mobility Anchor
Point. Ces points dancrage sont des agent visits dans MIPv4 et des routeurs daccs
dans MIPv6 au sommet de plusieurs agent visits (resp. routeurs daccs), avec une
adresse IP publique (voir Figure 2-7).
INTERNET
AV passerelle dans MIPv4

MAP dans MIPv6
Agent mre

AV dans MIPv4
RA dans MIPv6
Points daccs
Domaine
Figure 2-7 : architecture hirarchique

Cette dfinition permet de mettre en uvre une hirarchie avec plus dun niveau.
Lorsquun nud mobile entre dans un domaine, un tunnel est cre entre lui et le point
dancrage. Dans MIPv4, ce tunnel est par dfaut unidirectionnel de lagent visit
passerelle jusquau nud mobile. Si le nud mobile dsire tablir un tunnel bidirectionnel, il lui faut positionner un bit T dans son message denregistrement.
Dans la prochaine sous-section, le fonctionnement de la hirarchie et lchange de
messages occasionns seront explicits. Ensuite dans une dernire sous-section, on verra
comment raliser le bi casting dans une telle architecture.
2.4.1 Mobile IP Hirarchique

Chaque point dancrage est annonc dans les Agent Advertisement envoys par les
AV/RA. Dans MIPv4, les Agent Advertisement contiennent toutes les adresses des agent
26
visits entre le nud mobile et lagent visit passerelle. Dans MIPv6, en plus de ladresse
du Mobility Anchor Point, il y a le prfixe du domaine du Mobility Anchor Point, la
distance au nud mobile ainsi que les prfrences du Mobility Anchor Point.
Dans MIPv4, quand un nud mobile entre pour la premire fois dans un domaine, il
doit senregistrer avec son agent mre en indiquant ladresse de lagent visit passerelle
comme adresse temporaire. Ensuite lorsque le nud mobile se dplace lintrieur du
domaine (comme celui de la Figure 2-7 par exemple), il a juste besoin de faire des
enregistrements locales en chargeant un bit spcifique dans ses Enregistrement Request.
Ces Enregistrement Request ont ladresse de lagent visit passerelle comme adresse de
destination et ladresse du agent visit courant (ou 0 si le agent visit na pas annonc son
adresse) comme adresse temporaire.
Dans MIPv6, la plupart des oprations sont les mmes. Ceci dit, un nud mobile a le
choix entre deux modes lors de ses enregistrements dans un domaine : il sagit des modes
basique et tendu. Ces deux modes diffrent dans le nombre dadresses du nud mobile.
Dans le mode basique le nud mobile a deux adresses : une adresse temporaire rgionale
base sur le prfixe du Mobility Anchor Point et une adresse temporaire locale. Dans ce
schma, le Mobility Anchor Point agit comme un agent mre. Il intercepte les paquets
destination de ladresse temporaire rgionale et les tunnelle ladresse temporaire locale
correspondante. Ces oprations sont totalement transparentes lagent mre qui na
besoin daucune modification.
Cependant, dans un soucis de mise lchelle ou pour des raisons de gestion, tous les
nuds mobiles ne peuvent pas acqurir leur propre adresse rgionale. Dans le mode
tendu, ladresse temporaire rgionale est celle du Mobilty Anchor Point. Le Mobility
Anchor Point tient une table des associations entre ladresse principale des nuds
mobiles et leur adresse local. Quand le Mobility Anchor Point reoit des paquets
destination dun nud mobile, il doit les dcapsuler et les r-encapsuler ladresse
locale. Ceci implique que chaque paquet doit contenir ladresse principale du nud
mobile. Le Mobility Anchor Point joue donc le mme rle quun agent mre. Le mode
tendu supporte aussi bien les nuds mobiles que les rseaux mobiles.
Aussi bien dans MIPv4 que dans MIPv6 le nud mobile doit faire une enregistrement
mre quand il change de domaine. Ce changement de domaine est dtect par le mobile
dans les annonces des agents de mobilit. Effectivement, chaque AV/RA sous un point
dancrage annonce ladresse IP du point dancrage. Le nud mobile compare ladresse
annonce avec celle de son point dancrage courant. Si elles diffrent, cest quil a chang
de domaine.
Toute cette procdure permet tout de mme un nud mobile nimplmentant pas
MIP hirarchique dappliquer MIP. De manire symtrique, un nud mobile qui
demande faire une enregistrement locale un AV/RA nimplmentant pas MIP
hirarchique aura la possibilit de faire une enregistrement telle que dcrite dans MIP
[1][2].
27
2.4.2 Bi casting dans une architecture hirarchique

Comme il a t montr dans la section 2.3, le bi casting partir de lagent mre nest
pas scalable et peut gnrer une congestion. Le modle hirarchique permet de faire le bi
casting partir du point dancrage. Quand un nud mobile se dplace lintrieur dun
domaine, il peut demander le bi casting dans ses messages denregistrements rgionales.
Cette demande est transmise au point dancrage qui ajoute une entre pour le nud
mobile (association simultane). Ensuite le point dancrage propage le trafic lancienne
et la nouvelle localisation du nud mobile.
Seuls les messages dfinis dans la section 2.3 sont ncessaires au nud mobile pour
demander le bi casting. Lchange de messages est donc le mme. Le modle
hirarchique permet donc de raliser le bi casting plus rapidement et de manire efficace.
Si un problme de mise lchelle se pose (par un nombre trop important de nuds
mobiles) il suffit dajouter des points dancrage.
2.5
Protocoles intgrant le paging
Typiquement, les htes connects l'Internet (par exemple, des ordinateurs de bureau
connects un rseau local) restent en ligne pendant plusieurs heures bien que la plupart
du temps ils ne communiquent pas. Etre "toujours connect" de cette manire aboutit
tre accessible tout instant et de pouvoir accder aux ressources Internet. Les
utilisateurs mobiles connects l'Internet sans fil sattendront un service semblable.
Malheureusement, le maintien de l'information de localisation par les mobiles pour rester
continuellement accessible, exigeraient des mises jour de localisations frquentes, ce
qui consommerait de la bande passante prcieuse et lnergie de la batterie. Ce surplus de
signalisation et cette consommation lectrique d'hte mobile peut tre rduite par
l'introduction de la pagination. Gnralement, les htes mobiles fonctionnent sur des
batteries de faible autonomie, cest pourquoi il savre impratif dviter que les htes
mobiles inoccups naient transmettre des messages de mise jour de localisation
frquemment. Cela exige l'appui explicite de protocoles rseau, comme la capacit de
suivre la localisation des mobiles de manire approximative et la capacit de paginer des
htes mobiles inactifs. Des htes mobiles inactifs ne doivent pas enregistrer leur
dplacement dans la mme aire de pagination pour ne signaler que leur changement
daire de pagination. La pagination a t mise en oeuvre dans un certain nombre de
protocoles de micro-mobilit dont Cellular IP [14][15][16][17] et Hawaii [18]. Cellular
IP est prsent ci-dessous.
2.5.1 Cellular IP
Le protocole Cellular IP [14][15][16][17] utilise aussi une architecture hirarchique ;
lInternet globale est divis en domaine constituant des aires de micro mobilit. Chaque
niveau de mobilit est trait par un protocole diffrent, adapt aux besoins du niveau.
Cellular IP, inspir des systmes cellulaires, se propose de rsoudre la gestion de la
mobilit lintrieur dun domaine. Ce protocole a t conu pour rpondre rapidement
un grand nombre de nuds mobiles qui migrent frquemment. Par contre, cest MIP qui
gre la mobilit entre domaines. Cellular IP interagit donc avec MIP, que ce soit dans sa
version 4 [14] ou 6 [17] (avec des changements mineurs).
28
Dans une aire de micro mobilit, linformation de routage est totalement distribue,
cest--dire quaucun des nuds ne garde une information globale sur la topologie du
rseau. Ceci rend la solution robuste. De plus, Cellular IP peut tre utilis dans un
domaine allant dun bureau un rseau stendant sur une ville et peut supporter un
grand nombre dhtes. Le but de Cellular IP est de procurer un seamless handoff
lintrieur dun domaine et de cacher les mouvements des nuds mobiles au reste de
lInternet.
Cellular IP fonctionne avec une hirarchie compose dun routeur passerelle et de
nuds cellular IP, qui sont des points daccs et des nuds mobiles implmentant le
protocole Cellular IP (voir Figure 2-8). Le routeur passerelle assure la liaison entre le
rseau cellulaire IP et le reste dInternet. Il filtre, contrle et propage les paquets en
provenance et destination du rseau cellulaire IP. Les points daccs sont connectes
ensemble par un rseau filaire et ont une interface sans fil pour communiquer avec les
nuds mobiles. Bien que cette structure soit bien adapt pour le fast handoff, des
traitements spcifiques pour le seamless handoff ont t mis en place tel que le semi-soft
handoff [14][16] ou le indirect semi-soft handoff [17], quon dtaillera plus tard.
INTERNET
Agent mre
Routeur passerelle
Points daccs
Port
montant
Port
descendant

Rseau cellulaire IP
Figure 2-8 : architecture Cellular IP

La gestion de la localisation est trs diffrente de celle utilise par MIP. Ladresse IP
nest plus utilise pour localiser un quipement mais uniquement pour lidentifier. De ce
fait, il nest plus ncessaire de faire des encapsulations ou des conversions dadresse. La
localisation des nuds mobiles est contenue dans deux diffrents caches dans les points
daccs. Lutilisation de deux caches permet de diffrencier le traitement des nuds
mobiles actifs de ceux inactifs. On dira quun hte est actif quand il change des paquets
de donnes avec au moins un correspondant. Le cache de pagination est utilis pour
29
localiser les htes mobiles inactifs et le cache de routage pour la localisation des htes
actifs. Ces caches sont des mappings entre ladresse IP du nud mobile et linterface de
le point daccs utilis pour atteindre ce nud. Ces mappings sont construits par le
chemin inverse des paquets envoys par le nud mobile (aussi bien les paquets de
donnes que ceux de control). Le routage se fait donc en saut-par-saut sur le plus court
chemin.
La localisation des nuds mobiles inactifs est approximative : les points daccs sont
organises en aires de pagination et cherchent uniquement savoir dans quelle aire se
situe le noeud mobile. La gestion de la localisation est dcrite plus tard. Dans un rseau
cellulaire IP donn, chaque aire de pagination a un identifiant unique. Cet identifiant est
annonc par toutes les points daccs mais toutes les points daccs nont pas de cache de
pagination.
Dans ce schma, un nud mobile na pas de point dattache ddi, il utilise le meilleur
tout moment. Il ny a donc pas dauthentification entre les points daccs. Cependant,
un controle est effectu lors de lentre des nuds mobiles dans le rseau cellulaire IP et
seuls les messages de controle peuvent crer des nouvelles entres dans les caches pour
assurer une scurit.
2.5.1.1 Dtail du protocole
Trois messages de contrle sont ncessaires pour le fonctionnement du protocole :
Route Update, Paging-Update et Paging-Teardown. Lutilisation de ces messages est
dcrite au fil de ce paragraphe. Le routeur passerelle envoie priodiquement des
messages aux points daccs pour leur indiquer leur port montant (uplink port), cest-dire le port utilis pour atteindre le routeur passerelle (voir Figure 2-8). Ceci rend le
protocole plug-and-play puisque aucune configuration pralable nest requise sur les
points daccs. Tous les autres ports des points daccs sont des ports descendants (voir
Figure 2-8). Les points daccs envoient aussi des beacons13 contenant entre autres
lidentificateur du rseau cellulaire IP, ladresse IP du routeur passerelle et un identifiant
daire de pagination sur leur interface radio.
Quand un nud mobile entre pour la premire fois dans un rseau cellulaire IP, il
envoie une authentification et des informations utilisateur dans un Paging-Update
destination du routeur passerelle. Si le routeur passerelle accepte la demande du nud
mobile, celui-ci doit faire une enregistrement mre. Dans le cas de MIPv4, ladresse
indique dans cette enregistrement est celle du routeur passerelle, alors que dans MIPv6,
cest une adresse temporaire locale cre partir du prfix rseau.
Comme on la dit plus haut, un nud mobile peut tre dans deux tats. Lorsquil est
inactif, il doit mettre jour les caches de pagination chacune de ses entres dans une
nouvelle aire de pagination ou juste avant que son entre nexpire (cas o le nud mobile
ne sest pas dplac). Cette mise jour est assure par lmission dun Paging-Update.
Un Paging-Update dtruit aussi les entres dans les caches de routage. Un nud mobile
peut par ailleurs demander explicitement la destruction de son entre dans un cache de
pagination pour viter tout conflit. La suppression explicite dune entre dans le cache de
13
Beacon : message de synchronisation envoy priodiquement par les points daccs, contenant des
informations pour lidentification.
30
pagination est faite par lenvoie dun Paging-Teardown.

Dans son tat actif, un nud mobile envoie des paquets de donnes, en reoit ou fait
les deux. Les paquets de donnes envoys par le nud mobile mettent jour les caches
de routage sans que le mobile naie besoin denvoyer dautres paquets de control. Par
contre, quand un nud mobile ne fait que de recevoir des donnes, il lui faut envoyer
priodiquement un Route-Update pour viter que son entre dans les caches de routage
nexpirent. Ceci dit, que le nud mobile soit en mission ou en rception, il doit envoyer
un Route-Update chaque fois quil change de point daccs. Ce paquet cre une nouvelle
entre dans toutes les nouvelles points daccs sur le chemin allant du nud mobile au
routeur passerelle. Les oprations spcifiques au handoff sont dtaills dans la soussection suivante.
Quand un flux de donnes arrive pour un nud mobile inactif, le premier paquet est
utilis pour faire la pagination (pagination implicite). Le paquet est transmis suivant les
informations contenues dans les caches de pagination. Si jamais un point daccs reoit
un paquet pour un nud mobile dont elle na aucune entre (pas de cache de pagination),
elle duplique le paquet sur tous ses ports descendants. Quand le nud mobile reoit ce
premier paquet, il envoie un Route-Update pour crer une entre dans les caches de
routage et devient actif.
2.5.1.2 Traitement du handoff
Le changement de point daccs, appel hard handoff, est automatiquement gr par
le protocole. Cependant, des paquets peuvent tre perdus pendant le temps que le RouteUpdate atteigne le point daccs qui doit raliser le changement de route. Quand un nud
mobile peut interagir simultanment avec deux points daccs, il peut faire un semi-soft
handoff. Quand un nud mobile dcide de se dplacer un nouveau point daccs, il
envoie un Route-Update avec un flag spcifique travers le nouveau point daccs et
retourne couter lancien. Quand le Route-Update atteint le premir point daccs qui doit
modifier et non crer lentre pour le nud mobile, une nouvelle entre est cre sans
remplacer lancienne. Les paquets de donnes sont alors envoys lancienne et la
nouvelle localisation du nud mobile. Quand le nud mobile dcide par la suite de se
rattacher au nouveau point daccs, il envoie un Route-Update pour dtruire lentre avec
lancien point daccs.
Pour les nuds mobiles ne pouvant pas tre connects simultanment deux points
daccs, la technique de indirect semi-soft handoff se rapproche du semi-soft handoff.
Quand le nud mobile dcide de changer de point daccs, il envoie un Route-Update
avec un flag I travers son ancien point daccs avec ladresse du nouveau point
daccs dans le champ de ladresse destination. Ce paquet est transmis au routeur
passerelle qui lenvoie au nouveau point daccs. A rception de ce paquet, le nouveau
point daccs envoie un Route-Update avec ladresse du nud mobile comme adresse
source et on se retrouve alors dans la mme situation que dans le semi-soft handoff.
2.6
Conclusion
On vient de voir un ensemble de protocoles de gestion des handoffs IP. Le but final est
datteindre le seamless handoff, cest--dire que les dplacements ne se fassent pas
31
ressentir dans les applications en cours. Nous avons vu que le fast handoff permettait de
rduire le temps dattache au nouveau routeur daccs, que le bi casting permettait de
rduire la perte des paquets et que le modle hirarchique rduisait la signalisation par
une gestion locale de la mobilit. Bien que le bi casting semble tre une bonne solution et
trs adaptable, sa ralisation est difficile grande chelle.
Lensemble de cette partie a fait lobjet dun article qui est en cours de soumission
[25].
On peut remarquer quaucun de ces protocoles ne traitent les problmes intertechnologies, cest--dire le passage dune technologie une autre sans forcment se
dplacer. La gestion dinterface sera lobjet de la partie 4, gestion quon dsirerait
intgrer dans un premier temps dans le simulateur rseau NS-2 prsent dans la partie 3.
32
PARTIE 3
PRESENTATION DU SIMULATEUR RESEAU NS-2
33
Partie 3 : Prsentation du simulateur rseau NS-2
3 Prsentation du simulateur rseau NS-2

3.1
Introduction
Le simulateur rseau NS (Network Simulator) est un simulateur vnements discrets

orient objet, base sur le simulateur rseau REAL14. Au dpart, la version 1.0 de NS a
t dveloppe au Laboratoire National de Lawrence Berkeley15 (LBNL) par le groupe de
recherche rseau. Son dveloppement fait maintenant partie du projet VINT sous lequel
la version 2.0 est sortie.
Le projet VINT [46]
Figure 3-1 : projet VINT

Le projet VINT16 (Virtual InterNetwork Testbed) est dirig par l'universit de
Californie du sud et est financ par le DARPA17 en collaboration avec Xerox PARC18 et
LBNL. Le but de ce projet est la construction d'un simulateur rseau qui offre des outils
et des mthodes innovatrices dans un environnement proche de la ralit. Ce simulateur
essaie de rpondre aux questions de mise lchelle (simulation de grandes topologies) et
dinteraction entre protocoles dans des services intgrs l'Internet (problmes
dhtrognit).
Lobjectif n'est pas de concevoir un nouveau simulateur rseau, mais dunifier les
efforts de toutes les personnes travaillant dans le domaine de la simulation de rseau. La
plupart des simulateurs rseau se focalisent seulement sur des protocoles simples et
simulent des protocoles indpendamment. Ils ne se proccupent pas des interactions avec
d'autres composants de l'architecture. Le rsultat est donc souvent limit, primitif et
applicable uniquement des cas particuliers. Ceci engendre aussi un manque de
14
Simulateur rseau REAL : http://www.cs.cornell.edu/skeshav/real/overview.html

LBLN : http://www-nrg.ee.lbl.gov/
16
Projet VINT : http://www.isi.edu/nsnam/vint/index.html
17
DARPA : http://www.darpa.mil
18
Xerox PARC : http://www.parc.xerox.com/parc-go.html
15
34
comparabilit dans chaque simulateur.

En outre, les divers composants d'un rseau (type d'application, charge, topologie...)
sont de plus en plus impliqus dans les protocoles. A mesure que lInternet devient de
plus en plus complexe en termes de mise l'chelle, de nombre de protocoles et au
niveau matriel et systme dexploitation, il est plus dur de concevoir ou de prouver des
protocoles. Les cots pour crer un tel simulateur sont si importants qu'ils sont au-del de
la porte de n'importe quelle socit commerciale ou universit.
Enfin, les simulateurs courants fournissent rarement des outils pour la visualisation et
l'interprtation des rsultats. Le projet VINT se fonde sur NS pour le simulateur et
NAM19 pour la visualisation. Le projet VINT propose d'augmenter la synergie dans la
communaut de simulation. Chaque apport dun groupe de chercheurs doit pouvoir
profiter tous et augmenter la structure initiale au fur et mesure. Ce simulateur est
notamment inspir de NETSIM de MIT, de MARS de l'universit du Maryland, de REAL
de UC Berkeley, de NEST de la Colombie et NS-1 de LBNL.
Le projet VINT a pour objectif lvaluation la fois de la justesse et des performances
de protocoles allant des protocoles de routage aux protocoles de transport et de session
dans des grandes aires de rseaux Internet et ceci tous les niveaux. Le projet sest
notamment concentr sur les points suivants :
Repousser les capacits de mise lchelle aussi loin que possible.
Offrir une simulation rseau composable pour modliser la modularit de

l'Internet et pour supporter des nouveaux modules de diffrents
collaborateurs.
Utiliser diverses techniques d'abstraction pour permettre de faire varier le

niveau d'abstraction.
Mettre en place des techniques de visualisation pour mieux interprter les

rsultats, selon le niveau de granularit.
Proposer une interface d'mulation pour permettre aux nuds dinteragir avec
le simulateur.
Crer des bibliothques vastes et extensibles de topologie de rseau et de

gnrateurs de trafic.
Le projet VINT est utilis par plusieurs groupes de travail comme lIRTF ou lIETF
pour valuer les protocoles en cours de normalisation. NS est ainsi couramment utilis
dans la communaut des chercheurs pour des comparaisons de simulation dans les
publications.
NS est bien adapt pour simuler la circulation de paquets dans des rseaux commuts.
Il est principalement utilis pour tester des algorithmes de file dattente, des contrles de
congestion, des protocoles de transport, le multicast et la mobilit.
Dans ce qui va suivre, on tudiera tout dabord la structure interne du simulateur, son
19
Network Animator , outil d'animation pour visualiser les rsultats de simulations et des traces des
paquets
35
implmentation de manire gnrale et le moteur du simulateur. Ensuite, une partie sera

consacre son utilisation pour mieux sapercevoir des fonctionnalits, avec un premier
aperu de scripts de simulation. Enfin, on exposera les outils dinterprtation et de
visualisation offerts avec le simulateur. Enfin, on sintressera plus particulirement la
mise en uvre de la mobilit ; trois extensions au modle de base ont t implmentes
par des quipes de recherche. Aprs avoir expliquer en quoi consistent ces apports,
quelques tests seront excuts sur ces extensions dans une dernire partie.
3.2
Architecture et implmentation
Larchitecture rseau de NS-2 est fortement base sur le modle des couches OSI. Ce
modle a brivement t expliqu dans la partie 1. Il sagit de la dcomposition de la pile
rseau en couches. Tout au long de cette section on retrouvera donc les lments de ces
couches avec plus ou moins de dtails.
La dernire version de NS-2 est sortie le 7 juin 2001 dans sa version 8 (ns-2.1b8). Les
sources sont disponibles sur le site ISI20 dans la section nsnam
[http://www.isi.edu/nsnam/ns]. Les sources se prsentent sous deux formes : lune dite
tout en un qui contient le code NS-2 et dautres composants utiliss (comme OTcl,
NAM), soit par morceaux, cest--dire quon peut choisir uniquement les composants
dont on a besoin. Le package comprend aussi des exemples de script ainsi que des
modles de mouvement pour les nuds mobiles ou de gnration de trafic.
NS-2 est un simulateur vnements temps discrets orient objet. Il est dvelopp en
C++ et en OTcl21 ; Le paquage inclus une hirarchie de classe compile d'objets crits en
C++ et une hirarchie de classe interprte d'objets crits en OTcl. Ces deux hirarchies
sont troitement lies ; quand l'utilisateur cre un nouvel objet par l'interprteur OTcl, un
objet correspondant appel objet reflet est aussi cre dans la hirarchie compile. On dit
que ces objets sont des objets fendus . Bien entendu, les objets peuvent tre accds
aussi bien en OTcl quen C++ grce la mise en place de procdures dappel entre OTcl
et C++.
Le langage OTcl est un langage interprt qui ne demande pas de compilation. Il est
principalement utilis pour concatner des objets, accder aux objets partir de
linterprteur et configurer des simulations (dbut et arrt des vnements, perte rseau,
rassemblement de statistiques). Son utilisation est rapide et assez conviviale. Dun autre
ct, C++ est utilis pour crer les classes de base et pour traiter un grand nombre de
donnes (tel que calcul des tables de routage, mouvement des mobiles).
3.2.1 Implmentation du simulateur

Au plus bas niveau, il y a six classes qui dfinissent lensemble de la structure du
programme et fournissent les mthodes lmentaires. Il sagit des classes Tcl, TclObject,
TclClass, TclCommand, EmbeddedTcl, InstVar. Elles dfinissent entre autres les
mthodes utilises par C++ pour accder linterprteur, la hirarchie, les principales
commandes de haut niveau et les mthodes pour accder aux variables C++ et OTcl.
20
21
ISI : Information Sciences Institute

OTcl : extension objet du langage interprt Tcl
36
La simulation est configure, contrle et gre l'aide des interfaces fournies par la
classe OTcl Simulator. Cette classe fournit des procdures pour crer et grer la
topologie, initialiser le format des paquets et choisir le planificateur dvnements (voir
3.). Elle stocke intrieurement des rfrences chaque lment de la topologie. Un script
devra donc toujours commencer par linstanciation dune variable de cette classe.
L'utilisateur cre ensuite la topologie travers OTcl en utilisant les classes node et link,
composants essentiels de la topologie. Ces lments sont dcrits dans la sous section
suivante.
3.2.1.1 Composants de la topologie
La topologie NS-2 est essentiellement compose de nuds et de liens. La dfinition
des nuds se fait dans un premier temps travers linstance de Simulator puis travers
linstance de la classe Node. La fonction d'un nud est de recevoir des paquets, les
examiner et les mapper ses interfaces sortantes appropries (voir Figure 3-3). Cette
classe est compose dun classificateur et de mthodes pour configurer un nud. Les
mthodes proposes sont des fonctions de contrle, de gestion dadresse et de port, de
gestion dagents et de reprage des voisins. Le classificateur est la partie du nud qui
traite chaque segment des paquets reus. Il en existe donc plusieurs, chacun tant
spcifique au champ examin (ex : le classificateur dadresse est utilis pour supporter la
propagation des paquets). Nous verrons plus loin limplmentation de deux nuds
spciaux (sous-classe de Node) qui permette la mise en uvre des sous-rseaux locaux de
manire simple et la mise en uvre de la mobilit.
Les liens constituent la deuxime partie de la topologie. Les liens entre les nuds sont
dfinis dans la classe Link et SimpleLink plus prcisment lorsquil sagit de relier deux
nuds. Plusieurs types de liaisons sont supports, comme le point point, le broadcast ou
les liaisons sans fil pour la mobilit. Cette classe dfinie cinq variables cls (reprsente
dans la Figure 3-2) :
La file dattente de connecteurs
La tte de file
Le lien
La dure de vie (TTL)
Elimination de la tte
37
LIEN
EnqT
Queue
DeqT
DropHead
Lien
TTL
rcvT
DrpT
Figure 3-2 : structure dun lien

Note sur la Figure 3-2 : EnqT, DeqT, DrpT et rcvT sont des procdures qui
manipulent la file dattente (enfilement, dfilement, destruction et rception).
Une liaison est dfinie par une squence de connecteurs (classe Connector) qui sont
rangs dans une file dattente. Ces connecteurs font suivre les paquets qui leur sont
envoys dans une seule direction ; Le paquet est alors dlivr au voisin cible ou il est
dtruit.
A prsent, voyons les structures mis en place autour de la topologie pour faire interagir
les nuds entre eux.
3.2.1.2 La gestion des files dattente
La gestion des files dattente et la simulation des dlais sur les liens sont implments
dans les classes Queue et LinkDelay respectivement. Les files dattente actuellement
disponible dans NS sont :
FIFO
RED buffer management
CBQ (priorit et circulaire)
Plusieurs variantes de file dattente juste (Fair Queue)
Pour simuler un quelconque dlai dans la rception ou lmission dun paquet, la file
dattente correspondante est simplement bloque.
3.2.1.3 Les agents
A un niveau suprieur, on retrouve les agents (classe Agent) qui jouent un rle
important dans les simulations. Les utilisateurs crent de nouvelles sources ou rcepteurs
partir de la classe Agent. Ils font partie intgrante dun nud et sont les points
terminaux vis vis des paquets couche rseau ; leur rle est de gnrer et rceptionner
des paquets suivant les protocoles de transport (TCP [30], UDP [31], RTP). La Figure
3-3 montre les interactions entre ces diffrents composants dans NS.
38
Classificateur de
port
NOEUD
Agent
Agent
Entre du noeud
Classificateur
dadresses
Lien
Lien
Lien
Figure 3-3 : structure dun nud unicast

La gnration de trafic dans NS peut se faire de deux manires diffrentes et est dcrit
dans la classe Application. Il est possible de gnrer des paquets par un gnrateur de
trafic (classe TrafficGenerator) ou par la simulation dapplications existantes (classe
prenant le nom de lapplication), toutes ces classes tant drives dans la classe
Application. Les gnrateurs de trafic peuvent tre de quatre types :
Classe Exponential : gnre un trafic ON/OFF22 intervalle de temps

rgulier.
Classe Pareto : gnre un trafic ON/OFF intervalle de temps alatoire.
Classe CBQ : dbit de bit constant.
Classe Trace : permet de lire la gnration de trafic dans un fichier.
Tous ces gnrateurs de trafic peuvent tre associs au protocole de transport UDP.
Actuellement, seules les applications existantes FTP, Telnet et rcemment HTTP sont
disponibles dans NS pour simuler des applications TCP. Le schma entre ces deux
mthodes de gnration de trafic est prsent dans la Figure 3-4.
22
Trafic ON/OFF : un noeud qui gnre du trafic ON/OFF est un noeud qui alternativement met des
paquets et stoppe son mission.
39
Gnrateur de trafic
Simulation des applications
Application/
Trafic/
Exponentiel/
Application/FTP
API
API
Agent/UDP
Agent/TCP/FullTcp
Figure 3-4 : exemple de composition dune application

La simulation de HTTP diffre quelque peu de FTP et Telnet ; Alors que FTP et
Telnet simulent la circulation de donnes en donnant simplement la taille des paquets et
le dbit, HTTP change rellement des donnes. Ceci peut par exemple servir voir
limpact des caches pour le web. Des serveurs et clients HTTP ont donc t mis en place
ainsi quun cache de proxy qui fonctionnent au-dessus dUDP ou TCP.
3.2.1.4 Le routage
Lors dune simulation, lutilisateur doit spcifier un protocole de routage, cest--dire
indiquer au simulateur comment construire les routes entre les nuds. NS offre trois
types de routage dans un rseau filaire :
Routage statique : routage utilis par dfaut suivant lalgorithme SPF de

Dijkstra [43]. Il est excut au dbut de la simulation une fois pour toutes.
Routage session : routage identique au routage statique mais r-excute

lalgorithme chaque changement de topologie.
Routage dynamique : une valeur est assigne chaque route et un tableau

stocke toutes les routes les plus courtes. Il est possible de faire du routage
asymtrique ou multi-chemin. Cest le protocole vecteur de distance [44]
(Distant Vector) qui est utilis.
Il est possible dindiquer le protocole de routage uniquement un sous-ensemble des

nuds constituant la topologie (par dfaut il sapplique la totalit des nuds). Il existe
aussi une implmentation de protocoles de routage multicast (PIM-SM, PIM-DM) mais
leur tude et leur utilisation ne font pas lobjet de ce rapport.
NS permet de provoquer des erreurs dans les simulations pour tester la robustesse des
protocoles. Pour cela, il existe un modle derreur implment dans la classe ErrorModel
qui simule les erreurs au niveau liaison par lenvoie des paquets des agents destructeurs.
Lunit derreur peut tre spcifie en terme de paquets, bits ou temps.
Maintenant que les modules de base ont t prsents, nous allons voir comment lon
peut spcifier des caractristiques au niveau des nuds pour toffer les simulations. Nous
40
verrons alors comment simuler les rseaux locaux et les nuds mobiles.
3.2.1.5 Les rseaux locaux (LAN)
Pour permettre des simulations plus grande chelle, NS permet dutiliser la notion de
LAN23. Cette nouvelle entit a t introduite en tant que nouveau type de nud. Les
composants dun LAN sont la couche liaison, la couche MAC et la couche physique (voir
Figure 3-5).
Couches suprieures
Nud
Nud
Queue
Queue
Nud
Queue
Couche liaison
LinkLayer
Couche Mac
LinkLayer
Mac
Mac
LinkLayer
Mac
Couche physique
Channel
Classifier/Mac
Figure 3-5 : structure dun LAN

Au niveau de la couche physique, lobjet Channel simule le mdium partag et
supporte des mcanismes daccs au mdium des objets Mac (phase dmission). Lobjet
Classifier/Mac est responsable de la livraison et de la rplication des paquets pour des
objets Mac (phase rception). Les dtections de collisions se font au niveau de la couche
MAC o sont implments les protocoles daccs au mdium (CSMA). La couche
liaison est compose de deux objets : Queue qui simule linterface de file dattente et
LinkLayer qui implmente un protocole de couche de donnes. Un LAN contient en plus
un seul objet LanRouter qui est cre automatiquement que le nud LAN est initialis.
Tous les nuds dun LAN ont un pointeur sur cet objet qui joue le rle de routeur.
23
Local Area Network : rseau local
41
3.2.1.6 La mobilit dans NS

Dans un premier temps, la mobilit a t introduite dans NS-2 par les chercheurs de
luniversit Cartegie Mellon24 de Pittsburgh (CMU) dans la volont de simuler des
rseaux ad hoc. Le lecteur doit particulirement faire attention la terminologie. Dans les
deux premires parties, on a parl de point daccs comme tant un quipement de niveau
2 fournissant laccs Internet aux nuds mobiles. Dans la terminologie Ns-2, on parle de
point daccs non seulement pour spcifier un tel nud mais aussi pour parler dagent
mre ou dagent visit.
Lapport de la mobilit passe par lajout dun nouveau type de nuds dfinis dans la
classe MobileNode, qui ne sont pas connects entre eux . Les caractristiques de la
mobilit telles que le mouvement des nuds, les mises jour de localisation ou les
limites de la topologie sont implmentes en C++. Par contre, les composants rseaux
comme le nud mobile lui-mme (classificateur, couche liaison) sont implments en
OTcl.
Comme lobjectif tait de simuler des rseaux entirement mobiles, il a fallu mettre en
place des protocoles de routage. Actuellement, il y a quatre protocoles de routage mis en
uvre dans NS-2 :
Squence de destination vecteur de distance (DSDV) : des messages de

routage sont changs entre nuds mobiles voisins. Les mises jour peuvent
tre dclenches (par une information sur un nud voisin qui change la table
de routage) ou priodique. Tout paquet destination dun nud inconnu est
mis en buffer pendant que des Query sont envoys.
Routage par source dynamique (DSR) : utilise un objet particulier de la classe

SRNode. Toutes les entres de lobjet SRNode pointent sur cet agent de
routage. Ce modle savre intressant pour une future implmentation de
protocole utilisant le piggy-backing.
Algorithme de routage ordonn temporaire (TORA) : protocole de routage

distribu bas sur lalgorithme Link Reversal [44]. A chaque nud, une
copie spare de TORA tourne pour chaque destination. TORA opre audessus de IMEP25 qui procure la liaison des messages de routage et informe le
protocole de routage des changements des liens aux voisins travers
lmission de beacons.
Vecteur de distance sur demande (AODV) : combinaison des protocoles DSR

pour la dcouverte et la maintenance des routes et DSDV pour le routage saut
par saut, numro de squence et lalgorithme des beacons.
Lorsquun un nud mobile est cre dans une simulation, le simulateur cre un objet
MobileNode, un agent de routage et la pile rseau qui sera dcrite plus loin. Ensuite ces
composants sont interconnects et la pile est connecte au canal. Ces composants sont
illustrs dans la Figure 3-6.
24
25
CMU : http://www.cmu.edu
IMEP : Internet MANET Encapsulation Protocol
42
Dmultipleur de
port
entre
Src/rcpteur
Dmultipleur
dadresse
255
Agent de
routage
Cible par dfaut
cible
Cible montante
Table ARP
LL
ARP
Cible descendante
mac
Interface
de la file
Cible descendante
Cible montante
MAC
Cible descendante
Cible montante
Modle de
propogation
radio
propagation
Interface
rseau
canal
Cible montante
canal
Figure 3-6 : composants dun nud mobile (sauf pour DSR)

La Figure 3-6 vaut pour tous les protocoles de routage except pour DSR. Lorsque ce
dernier est utilis, les fonctionnalits du nud mobile sont diffrentes ; Tous les paquets
reus par le nud mobile sont dirigs vers lagent DSR. Cest lobjet SRNode, driv de
MobileNode, qui ralise cette redirection. Cet objet nutilise pas de d multiplexeur
dadresses ou de classificateur.
Une caractristique forte des nuds mobiles est bien sr de pouvoir se dplacer. NS-2
a t conu pour excuter des dplacements en 3D, mais actuellement la troisime
dimension nest pas utilise (Z=0). Il existe deux mcanismes pour lutilisateur pour
43
donner du mouvement aux nuds mobiles :
Indiquer le point dorigine, la destination et la vitesse explicitement pour

chaque nud mobile. Les mises jour sont dclenches chaque fois que lon
exige la position du nud mobile un moment donn. Cette solution est
plutt faite pour des petites simulations.
Gnrer des mouvements alatoires : lappel dune procdure, le nud

mobile dmarre partir dune position alatoire et excute des dplacements.
Le nud mobile excute des mises jour de routage pour changer de
destination et de vitesse.
Indpendamment des mthodes utilises pour gnrer les mouvements des

nuds mobiles, il faut dfinir une topographie ; Lespace est considr
comme tant une grille dont il faut donner les frontires (valeurs de x abscisse
et y ordonne).
Voyons prsent plus en dtail les composants rseaux dun nud mobile :
Lobjet LinkLayer est le mme que celui utilis par les nuds unicast, avec un
module ARP en plus. Ce module est implment dans le style BSD. Il traite
des demandes de lobjet LinkLayer en utilisant une table de correspondance
entre ladresse IP et ladresse MAC. Il se sert dun buffer pour mettre les
paquets pour lesquels il ne connat pas de correspondance.
Linterface de file dattente a t augmente dun nouvel algorithme de

priorit : PriQueue. Cette gestion de file dattente donne priorit aux paquets
de routage.
La couche MAC implmente uniquement la norme 802.11 pour les nuds

mobiles. Dautres normes sont en train dmerger mais ne font pas partie de la
distribution de NS-2 pour le moment. Par exemple, IMB26 a dvelopp une
extension Bluehoc27 qui implmente la norme Bluetooth dans la version 6 de
NS-2. Cette norme sera brivement prsente dans la partie 4.
On arrive aux interfaces rseaux. Lobjectif est de simuler linterface

matrielle quun nud mobile utilise pour accder au canal. Ces interfaces
sont implmentes dans les fichiers wirelessPhy.{cc,h}. Ces interfaces sont
soumises aux collisions et enregistrent lintensit du signal, la longueur
donde
Le modle de propagation radio utilis est lattnuation espace-Friss ( 1 2 )

r
pour les courtes distances et Two Ray Ground ( 1 4 ) pour les grandes
r
distances. Lantenne simule est une antenne omnidirectionnelle.
Les limitations de ce modle se sont vite fait ressentir. Effectivement, le modle

original de la mobilit permet des simulations de rseaux locaux sans fil et de rseaux ad
26
27
IBM : http://www.ibm.com/
Bluehoc : http://oss.software.ibm.com/developerworks/opensource/bluehoc/
44
hoc uniquement. Cest pourquoi une premire extension a t ajoute au modle, toujours
fonde sur le travail des chercheurs de CMU, qui permet de faire des simulations
impliquant des nuds filaires et des nuds sans fil la fois. Cette extension, appele
wired-cum-wireless , utilise le modle de base de la mobilit dcrit ci-dessus.
Lobjectif est donc de relier des rseaux locaux sans fil par un rseau filaire. Il se pose
immdiatement un problme pour le routage ; Le routage des nuds filaires se fait
daprs la topologie grce au concept de liaison, alors que dans la mobilit le concept de
liaison nexiste pas. Un nouveau type de nud est alors cre pour assurer la liaison entre
le rseau filaire et le rseau sans fil. Ce nud est appel BaseStationNode (reprsent
dans la Figure 3-7). Ce nud est un hybride entre un nud hirarchique et un nud
mobile. Lintroduction de tel point daccs a un impact sur ladressage. Chaque domaine
de nuds mobiles a une adresse unique de domaine et un domaine est dfini comme
lensemble des nuds mobiles qui sont attachs au point daccs du domaine. Les nuds
mobiles doivent donc supporter le routage hirarchique (except le SRNode). Un paquet
destin un correspondant situ en dehors du domaine sans fil sera transmis au point
daccs, si toute fois il existe un chemin jusqu celui-ci. La hirarchie de domaine est
montre dans la Figure 3-7.
W(0)
noeuds filaires
W(1)
AP(0)
Nud (0)
Point daccs
Nud (1)
Nuds mobiles
Nud (2)
Figure 3-7 : architecture dun scenario wired-cum-wireless

Ladressage hirarchique fonctionne donc de la manire suivante : il est compos de
trois niveaux et not ainsi : 1.0.1. le premier chiffre indique le domaine, le deuxime
indique le cluster et le dernier est lidentifiant du nud. Prochainement, il est prvu
dtendre le niveau hirarchique dadressage n, cest--dire laisser lutilisateur choisir le
nombre de niveau suivant les besoins de sa simulation.
Une autre extension a t ajoute dans NS-2 pour supporter limplmentation de Sun
Microsystem28 de Mobile IP. Cette extension est uniquement base sur le modle des
nuds filaires et non sur le modle de la mobilit fait par CMU. Le scnario de Mobile IP
consiste en des agents mre, des agents visits et des htes mobiles qui se dplacent de
lun lautre, comme prsent dans la partie 1. Les agents mres et les agents visits sont
grossirement des points daccs comme ceux dcrits plus haut. Ils sont dfinis dans
28
Sun microsystem : http://www.sun.com
45
MobileNode/MIPBS. Ils contiennent un agent denregistrement qui envoie les beacons et

effectue lencapsulation et la dcapsulation des paquets. Leur structure est dcrite dans la
Figure 3-8. Lhte mobile est dfini dans MobileNode/MIPMH qui a aussi un agent
denregistrement qui rceptionne et met des beacons. Leur structure est la mme que
celle dcrite dans la Figure 3-8, sans lencapsuleur et le dcapsuleur.
Cible
Encapsulateur
0
@ du MH
Niveau n
Agent
denregistrement
Niveau 2
Son @ IP
Niveau 1
255
entre
dcapsulateur
Agent de
routage
Cible par dfaut
Cible
Cible montante
LL
Cible descendante
canal
Figure 3-8 : structure dun nud point dattache pour MIP

Pour sapercevoir de la porte et du niveau de simulation quil est possible de faire,
voici la liste des configurations possibles pour un nud mobile :
Type dadressage : plat ou hirarchique
Type du routage ad hoc
Type de lobjet LinkLayer
Type du protocole utilis par la couche MAC
Type de propagation radio
Interface de la file dattente
Type de support physique
46
Type de lantenne
Type du canal
Activer ou non les fonctionnalits de routage filaire
Activer ou non le protocole MIP sur le nud
Type de modle dnergie / nergie initiale
Activer ou non un agent de trace sur le nud
Activer ou non un agent de trace de routage sur le nud
Activer ou non les traces des mouvements des mobiles
Pour le moment, certains de ces paramtres ne peuvent prendre quune seule valeur.
Par exemple, la couche MAC nest implmente que par le protocole 802.11 [38] dans
NS-2 de base.
3.3
Moteur du simulateur
Le moteur de simulation est extensible, configurable et programmable. La mise en

oeuvre actuelle est un chanage simple dvnements (un seul vnement est excut un
instant donn). Il ne supporte pas l'excution partielle d'vnements, ni la premption.
Les vnements sont dcrits par des renvois et une fonction manipulatrice. Le type du
planificateur d'vnements utilis pour conduire la simulation peut tre choisie parmi
quatre actuellement disponibles : une liste lie simple (par dfaut), le tas, la file d'attente
de calendrier et un type spcial appel temps rel. Chaque mthode est implmente avec
une structure de donnes diffrente :
Le planificateur liste lie simple fournit une liste d'vnements tenue dans
lordre chronologique, du plus premier au dernier. Pour insrer ou supprimer
une entre, il faut alors balayer toute la liste pour trouver l'entre approprie.
L'entre en tte est toujours excute en premire. Les entres avec le mme
temps simul sont extraites selon leur ordre dans la liste.
Le code du planificateur de tas est emprunt au simulateur MARS-2.0 (qui

lui-mme a emprunt le code de NETSIM DE MIT). Cette implmentation est
plus efficace que le planificateur de liste lie quand le nombre d'vnements
est grand. Les temps dinsertion et de suppression sont en O (log n) pour n
vnements.
Dans la mise en oeuvre du planificateur de file d'attente de calendrier, les

vnements avec le mme "mois/jour" de diffrentes "annes" sont
enregistrs dans un mme "jour".
Le planificateur en temps rel essaie de synchroniser l'excution

d'vnements en temps rel. Il est actuellement mis en oeuvre comme une
sous-classe du planificateur de liste. La capacit temps rel dans ns est
toujours en dveloppement, mais elle est employe pour introduire un rseau
simul dans une topologie relle pour exprimenter de manire simple des
47
topologies rseau, la traverse de trafic Les travaux raliss jusqu prsent

fonctionnent pour des taux de trafic de donnes relativement lents. Or le
simulateur doit tre capable de suivre le taux darrive des paquets du rseau
rel. Cette synchronisation entre le rseau simul et le rseau rel n'est
actuellement pas mise en uvre.
3.4
Point de vue de lutilisateur
Afin de mettre en application toute la structure prsente ci-dessus, voici quelques

exemples de scripts Tcl. Dans cette partie ne sera expose que les commandes principales
pour mieux comprendre le fonctionnement du simulateur. Pour une plus ample prise en
main de NS-2 se rfrer au tutorial de Marc Greis (http://www.isi.edu/nsnam/ns/tutorial/).
Comme le simulateur est un interprteur interactif de scripts, deux possibilits
soffrent lutilisateur : soit lancer le simulateur et taper les scripts dans linterface du
simulateur, soit crire le script dans un fichier .tcl . La premire solution peut tre
apprcie au dpart pour se familiariser avec les commandes. La seconde vaut pour des
simulations de plus grande ampleur et doivent ensuite tre excutes par la commande :
ns <fichier>
Comme il a t dit plus haut, avant toute action, il faut instancier un objet Simulator
qui permettra de crer et grer tout autre objet. Sa cration est assure par :
set ns_ [new Simulator]
Ensuite, il faut dfinir la topologie, cest--dire les nuds et les liens. Voici la
description de deux nuds et dun lien les reliant :
set n0 [$ns node]
set n1 [$ns node]
$ns duplex-link $n0 $n1 1Mb 10ms DropTail
Le lien ainsi cre est un lien duplex (communication en double sens), avec une
bande passante de 10Mb, un dlai de 10ms et une file dattente DropTail (limination
de la queue). Pour crer une plus grande topologie, on peut crer les nuds avec une
boucle itrative. Chaque nud sera alors stock dans un tableau accessible par un indice.
Le code correspondant la cration dun tableau n de sept nuds est le suivant :
for {set i 0} {$i < 7} {incr i} {
set n($i) [$ns node]
}
Ensuite il faut dfinir les transferts possibles entre chaque nud. Pour cela, il faut
attacher des agents aux diffrents nuds et les connecter ensemble. Voici la cration dun
agent CBR :
set cbr0 [new Agent/CBR]
$ns_ attach-agent $n0 $cbr0
On peut galement rgler les paramtres des paquets envoys (taille et priode) :
48
$cbr0 set packetSize_ 500

$cbr0 set interval_ 0.005
De lautre ct, il faut crer un agent rcepteur sur lautre nud et enfin les connecter :
set null0 [new Agent/Null]
$ns_ attach-agent $n1 $null0
$ns_ connect $cbr0 $null0
Pour voir les effets des tests sur les protocoles de transport, on peut attacher un agent
UDP ou TCP un nud gnrateur de trafic. Voici la mise en place dun trafic CBR par
un agent UDP :
set udp0 [new Agent/UDP]
$ns_ attach-agent $n0 $udp0
set cbr0 [new Agent/Traffic/CBR
$cbr0 attach-agent $udp0
$udp0 set packetSize_ 536
Puis en admettant quun agent Null null0 a dj t attach au nud 1, on peut

connecter les agents :
set null0 [new Agent/Null]
$ns_ attach-agent $n1 $null0
$ns_ connect $udp0 $null0
Ensuite on dfinit les vnements du scnario, cest--dire quand le trafic commence,

se termine :
$ns_ at 0.5 $cbr0 start
$ns_ at 4.5 $cbr0 stop
Enfin il faut lancer la simulation par la commande :

$ns_ run
Bien entendu toutes ces commandes constituent la base des simulations. Pour simuler
des ruptures de liens pour voir comment les protocoles ragissent une panne, on peut
indiquer au simulateur quand dtruire une liaison et quand la remettre en place. On
peut alors mettre un protocole de routage dynamique en place :
$ns_ rtmodel-at 1.0 down $(n1) $n(2)
$ns_ rtmodel-at 2.0 up $(n1) $n(2)
$ns_ rtproto DV
Ces quelques lignes indiquent que le lien entre les nuds 1 et 2 ne seront pas
utilisables du temps 1.0 au temps 2.0. Le protocole de routage qui se chargera de trouver
une nouvelle route est celui Vecteur de Distance.
La simulation de la mobilit dans NS-2 passe par la dclaration de nuds mobiles.
Celle-ci se passe comme pour les autres nuds en prcisant toutefois la configuration des
paramtres dcrits dans la section 3.2.1.6. Lattache des agents pour simuler un protocole
de transport ou une application est identique. Cependant, on peut dfinir la position
initiale des nuds mobiles ainsi que leur mouvement de manire trs prcise :
49
set topo [new Topography]

$topo load_flatgrid 500 500
pour dfinir la grille, frontire de la simulation, puis :

$node_(0) set X_ 5.0
$node_(0) set Y_ 2.0
$ns_ at 10.0 $node_(0) setdest 20.0 18.0 13.0
Les deux premires lignes indiquent la position initiale du mobile dans la grille. La
dernire ligne signifie que le nud 0 au temps 10.0 va se dplacer en direction de la
position (x=20, y=18) sur la grille une vitesse de 13 mtres par seconde.
Dans un souci de clart des scripts, surtout pour les grandes simulations, les
spcifications de mouvement ou les dfinitions des agents de trafic peuvent se faire dans
des fichiers spars.
Bien entendu, tant fait pour valuer des protocoles, NS-2 permet de conserver une
trace de lchange de paquets. Les possibilits offertes sont dcrites dans la section
suivante. La gnration de fichier de sortie fait partie du code NS-2 par des appels de
procdures durant diffrentes actions dans les simulations. Cest pourquoi, pour visualiser
une animation ou simplement enregistrer tous les vnements dans un fichier il faut le
spcifier au dbut du script. Les commandes utilises pour crer un fichier de sortie sont :
set tracefd [open sortie.tr w]
$ns_ trace-all $tracefd
et pour envoyer les vnements NAM :

set tracenam [open out.nam w]
$ns_ namtrace-all $tracenam
Le dtail des sorties gnres par ces lignes est donn dans la section suivante.
3.5
Statistiques et visualisation
NS-2 fournit plusieurs types de support pour analyser les rsultats dune simulation.
Dune part, NS-2 inclus des classes pour suivre la trace les fluctuations des paquets,
pour calculer et enregistrer diverses statistiques sur lensemble des paquets ou
uniquement pour un certain flux. Lutilisateur a le choix de mettre en place ce systme de
suivi pour chaque simulation. Ce systme de suivi est prsent dans la sous-section
suivante. Dautre part, NS-2 travaille de paire avec loutil de visualisation NAM qui
permet de visualiser lensemble de la topologie dans une fentre graphique. Cet outil est
brivement dcrit dans la sous-section 3.5.2.
3.5.1 Systme de suivi

NS-2 propose deux types de monitoring :
Traceur (Trace) : enregistre chaque paquet (arrive, dpart ou suppression)

sur un lien ou dans une file dattente. Ces objets sont configurs dans la
simulation comme des nuds dans la topologie de rseau. Ils sont dfinis
50
dans plusieurs sous-classes pour des vnements prcis.
Moniteur (Monitor) : enregistre le dcompte de diffrentes quantits comme

le nombre darrive de paquets , nombre de bit Il traque ainsi la dynamique
des paquets dans une file dattente en faisant des moyennes. Quand un paquet
arrive ou quitte un lien, il est pass un objet spcial qui contient une
rfrence sur lobjet QueueMonitor. Le contrle bas sur un certain flux de
paquets et non sur lensemble, fonctionne avec des classes spcialises.
Linspection et le mapping du flux est ralis par un objet classificateur. Le
paquet passe ensuite par le moniteur de flux qui enregistre les tats pour
chaque flux.
Pour illustrer le suivi des paquets, nous allons voir un fichier de sortie dune
simulation. Lutilisateur peut demander au simulateur denregistrer chaque dplacement
des paquets dans un fichier de sortie. Ce fichier sera format de la manire suivante :
Action
Temps
Nuds
Paquet
Source
Dest.
Taille
Flag
ID
flux
Adresses
uid
Source
N=
de
sq.
Dest.
1.84375
cbr
210
---
0.0
3.1
225
610
1.84375
cbr
210
---
0.0
3.1
225
610
1.84471
cbr
210
---
3.0
1.0
195
600
1.84566
ack
40
---
3.2
0.1
82
602
1.84566
tcp
1000
---
0.1
3.2
102
611
1.84566
tcp
1000
---
0.0
3.2
102
611
1.84609
cbr
210
---
0.0
3.1
225
610
1.84609
cbr
210
---
0.0
3.1
225
610
1.84609
cbr
210
---
0.0
3.1
225
610
1.8461
cbr
210
---
3.0
3.1
192
511
1.84612
cbr
210
---
3.0
1.0
196
603
1.84612
cbr
210
---
3.0
1.0
196
603
1.84612
cbr
210
---
3.0
1.0
196
603
1.84625
cbr
210
---
3.0
1.0
199
612
Tableau 1 : : format du fichier de sortie .tr

Le Tableau 1 ci-dessus prsente 14 entres de trace de paquets, dont cinq oprations
de mise en file (indiqu par "+" dans la premire colonne), quatre oprations de
dfilement (indiqu par "-"), quatre vnements de rception (indiqu par "r") et un
vnement de suppression ("d"). Le temps simul (en secondes) auquel chaque
vnement est arriv est inscrit dans la deuxime colonne. Les deux champs suivants
indiquent les deux nuds entre lesquels le paquet circule. Vient ensuite un nom descriptif
51
pour le type de paquet, suivi de sa taille, code dans son en-tte IP. Le champ flag
contient des flags qui ne sont pas utiliss ici.
Le champ daprs donne l'identificateur de flux IP. Les deux champs suivants
indiquent les adresses source et destination du paquet, respectivement, comme utilises
dans NS-2. Puis il y a le numro de squence et un identificateur de paquet unique.
Chaque nouveau paquet cr dans la simulation est assign un nouvel identificateur
unique.
Ce type de fichier de sortie peut bien entendu tre utilis pour tracer des courbes. Il est
possible de demander au simulateur de ne rpertorier que les paquets dun certain type,
par exemple que les paquets de contrle appartenant au protocole pour une meilleure
lisibilit.
Le support des traces pour la mobilit utilisait dans un premier temps les objets cmutrace. Ce format de fichier est trs proche de celui que nous venons de voir, bien quil
prsente quelques champs supplmentaires. Ces champs supplmentaires concernent
surtout des informations MAC (identifiant MAC des nuds, temps attendu avant
dmettre sur le mdium) et les protocoles utiliss pour la mobilit.
Dans un effort de regrouper tous les formats de trace de simulation sans fil qui ont
mergs et pour tre le plus complet possible, un nouveau format de fichier de sortie a t
mis en place. Ce nouveau format nest valide que pour les simulations sans fil, il sera
tendu par la suite lensemble des simulations. Il est toutefois compatible avec lancien
format. Le nouveau format est dcrit dans le tableau suivant :
s -t 0.267662078 -Hs 0 -Hd -1 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne
-1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.255 -Id -1.255 -It
message -Il 32 -If 0 -Ii 0 -Iv 32
-1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 1.255 -Id -1.255 -It
message -Il 32 -If 0 -Ii 1 -Iv 32
-1.000000 -Nl AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It tcp Il 1000 -If
2 -Ii 2 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0
r -t 10.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne
-1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It tcp Il 1000 -If
2 -Ii 2 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0
r -t 100.004776054 -Hs 1 -Hd 1 -Ni 1 -Nx 25.05 -Ny 20.05 -Nz 0.00 -Ne
-1.000000 -Nl AGT -Nw --- -Ma a2 -Md 1 -Ms 0 -Mt 800 -Is 0.0 -Id 1.0 -It
tcp -Il 1020 -If 2 -Ii 21 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 1 -Po 0
-1.000000 -Nl AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 1.0 -Id 0.0 -It ack Il 40
-If 2 -Ii 22 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0
Tableau 2 : format du fichier de sortie dans la mobilit .tr
52
Ce format de fichier semble plus complexe, mais en fait il est beaucoup plus facile
lire que le prcdent. Effectivement, chaque valeur note dans le fichier est prcde de
sa signification. En plus des informations contenues dans lancien format (type
dvnement, temps, source, rcepteur) il contient des informations sur :
Sur la position des nuds (Nx, -Ny, -Nz)
Sur lnergie des nuds (-Ne)
Sur le prochain saut (-Hs, -Hd)
Au niveau MAC : type thernet, adresses thernet
An niveau applicatif : type de lapplication,

caractristiques particulires suivant ces types
type
du
protocole,
Ce nouveau format est donc beaucoup plus complet que lancien.
3.5.2 NAM
La conception de protocole demande une comprhension de plusieurs dtails, dont le
suivi des tats dun grand nombre de nuds, une analyse de lchange de messages et
doit caractriser les interactions dynamiques pour des trafics concurrents.
Habituellement, des traces de paquets sont utilises pour accomplir ces tches.
Cependant, ces traces ont deux inconvnients majeurs : elles prsentent un nombre
important de dtails, ce qui peut compliquer la comprhension des donnes, et elles sont
statiques, ce qui cache une dimension importante du comportement des protocoles. Les
outils de visualisation adressent ce problme en permettant lutilisateur de prendre en
considration plusieurs informations trs rapidement, didentifier visuellement les
modles de communication et de mieux comprendre les interactions et les causalits.
NAM [45] est un outil d'animation bas sur Tcl/TK pour l'observation des traces de
paquet. Il peut tre install sur un systme de type unix ou sur Windows 95/98/NT ayant
Microsoft Visual C++ dinstall. Les donnes utilises par NAM peuvent provenir dun
simulateur ou de tests sur des rseaux rels (par exemple : utilisation de tcpdump). Il
supporte laffichage de la topologie, l'animation des changes de paquets et des outils
d'inspection de donnes divers. NAM a t cre par le laboratoire LBL et s'est
considrablement dvelopp durant les dernires annes. Le dveloppement de NAM est
en collaboration avec le projet VINT. Actuellement, il est dvelopp ISI dans les projets
CONSER29 et SAMAN30.
NAM interprte un fichier de trace contenant des vnements rseau indexs par le
temps de diffrentes manires, comme prsent dans la Figure 3-9. Ces vnements sont
principalement les arrives, dparts et suppression de paquets, rupture de lien. Pour les
simulations de rseau sans fil, la localisation et les mouvements des nuds sajoutent aux
vnements interprts.
29
30
Projet CONCER : http://www.isi.edu/conser/index.html

Projet SAMAN : http://www.isi.edu/saman/index.html
53
Simulation NS
NAM
Filtrage
Donnes rseau
Animation des paquets :

- Disposition automatique
- Disposition relative
- Disposition sans fil
Pr-traitement
Autres sources
Graphe des protocoles :

- TCP
- SRM
Figure 3-9 : diagramme de NAM

NAM est excut avec comme paramtre le fichier enregistr. Lorsquon excute
NAM, une fentre de travail NAM est cre. Il est possible de faire tourner plusieurs
animations avec une seule instance, ce qui permet de mieux comparer certain protocole.
La Figure 3-10 reprsente une fentre danimation NAM avec le dtail de la fonction de
chaque bouton. On peut entre autre rgler le pas de la simulation (de 8s 800ms),
zoomer sur des zones de la simulation, et manipuler la lecture : on peut mettre pause
tout moment ce qui donne un arrt sur image , revenir, avancer sur les tapes de la
simulation ce qui permet dexaminer des occurrences particulires.
La taille des objets dpend de leurs caractristiques : lpaisseur des liens dpend du
dbit d lien et la taille des paquets dpend de leur longueur en bits et de la bande passante
sur le lien. La couleur des paquets peut tre utilise pour plusieurs raisons ; dans ce cas,
elle diffrencie deux flux de donnes diffrents (celui du nud 0 et celui du nud 1). Les
paquets se dplacent de nuds en nuds le long des liens et sont mis en file dattente
quand un lien est satur (la file dattente ct du nud 2 correspond la saturation du
lien entre les nuds 2 et 3). Les points bleus et rouges que lon voit dans la partie
infrieure de la fentre reprsentent les paquets dtruits. Ces paquets sont dtruits car la
file dattente est remplie et le lien entre 2 et 3 na pas assez de dbit pour couler tous les
paquets mis par les nuds 0 et 1.
54
Figure 3-10 : fentre danimation NAM

Lanimation de paquets est reprsente Figure 3-11.
Figure 3-11 : animation de paquets dans NAM
55
Visualisation de la mobilit
De la mme manire que sest introduite la mobilit dans NS-2, la visualisation de la

mobilit dans NAM sest faite par lajout dextensions. Les nuds mobiles apparaissent
comme les autres nuds la diffrence prs quils ne sont pas relis entre eux. Dans un
premier temps laffichage des paquets circulant entre eux ntait pas support, seuls
laffichage de leurs mouvements ltait. A lheure actuelle, les paquets changs entre
nuds mobiles sont reprsents par des petits points lorsque les mobiles sont porte
lun de lautre. Les points daccs reprsentant la frontire entre le rseau filaire et le
rseau sans fil sont rattachs au rseau filaire par un lien et communiquent avec les
nuds mobiles. Lmission des beacons sur linterface radio est simule par lapparition
priodique de cercle autour du point daccs, indiquant dans le mme temps leur porte.
Cependant, laffichage nest pas encore parfait et est en cours damlioration.
Effectivement, dans chaque script il faut prciser les positions initiales des nuds
mobiles dans la fentre NAM, alors que cette information pourrait tre dduite de la
dclaration des positions initiales des nuds dans la simulation. De plus, le dernier nud
mobile affich est systmatiquement au mme endroit dans la fentre, quelque soit la
position quon indique. Par contre, sil vient se dplacer, il part du bon endroit. Un autre
dfaut relativement gnant concerne toujours la disposition des nuds dans la fentre
NAM. Maintenant quil est possible de faire des simulations avec la fois des nuds
mobiles et fixes, laffichage ne peut pas tre contrl totalement : on ne peut actuellement
pas donner explicitement la position des nuds filaires dans la fentre danimation.
Mme les points daccs, pour lesquels la position joue un rle important puisquelle
dfinit une zone daccessibilit, ne peuvent pas tre affichs au bon endroit.
Afin de mieux situer ce problme, prenons en considration lexemple suivant : soit un
nud mobile qui se dplace entre deux points daccs situs sur la mme ligne
horizontale mais suffisamment espace pour que leurs cellules se recouvrent peine (voir
Figure 3-12). Dans ce scnario, on dsire tester comment sopre le passage du nud
mobile entre ces deux points daccs lorsquil va et vient de lun lautre. La
visualisation apporte par NAM est compltement inefficace comme le montre la Figure
3-13.
Les deux points daccs

Le nud mobile
Figure 3-13 : Simulation observe
Figure 3-12 : simulation souhaite
56
3.6
Extension pour la mobilit
De nombreux laboratoires de recherche emploient NS-2 pour tester la raction de

nouveaux protocoles dans divers cas de figure. Dans cette section, trois extensions
introduites par luniversit de Manheim, luniversit de Colombie et lINRIA
respectivement seront prsents. Il sagit gnralement de fichier modifi ou de nouveaux
fichiers introduits dans une version de NS-2. Le code est gratuit et disponible sur les sites
respectifs. Malheureusement, le temps ma manqu pour faire des tests concluants sur la
mobilit dans NS-2 travers ces modles dans le cadre du stage de DEA. Ces tests seront
effectus durant les prochains mois.
3.6.1 NOAH
Cette premire extension prsente joue un rle important dans la gestion de la
mobilit dans NS-2. Effectivement, on verra que lextension CIMS prsente ci-dessous
utilise lagent Noah. Cette extension a t implmente par Jrg Widmer du laboratoire
AT&T31 ACIRI32 Berkeley pour NS-2 version 6 (ns-2.1b6) ou 7 (ns-2.1b7).
Lextension est disponible lurl http://www.icsi.berkeley.edu/%7Ewidmer/mnav/nsextension/.
Noah est un nouvel agent de routage sans fil qui supporte uniquement la
communication entre les points daccs et les nuds mobiles (en contraste avec les
agents DSDV, DSR tudis dans la section 3.2.1.6). Cet agent permet de faire des
simulations dans lesquelles le routage multi-sauts entre les nuds mobiles nest pas
dsir. En plus, lagent Noah nenvoie pas de paquets de routage. Cette extension
consiste donc en lamlioration de limplmentation de Mobile IP existante dans NS-2
(voir section 3.2.1.6) par le chevauchement des aires de couverture des points daccs, la
slection intelligente des agents visits, lamlioration du processus de handoff. Cette
extension inclus en plus un modle simple de propagation de distance : quand les
paramtres du modle de propagation radio CMU ne sont pas disponibles (qualit de
rception), le modle simple de propagation de distance permet de spcifier la porte
des points daccs comme une distance (pas dattnuation du signal). Par contre, quand
linformation est disponible, le modle exact sera utilis.
Bien que cet agent soit trs utilis, la documentation sur cette extension nest pas trs
explicite. Daprs une brve tude du code, quelques fichiers ont t modifis
(sdist.{cc,h}, wireless-phy.{cc,h}, cmu-trace.cc, mip.h, mip-reg.cc).
3.6.2 CIMS
CIMS33 est une extension de NS-2 base sur les versions 6 (ns-2.1b6) ou 7 (ns-2.1b7)
disponibles lurl http://www.comet.columbia.edu/micromobility. Lextension est
disponible en deux versions, selon que lagent NOAH dcrit ci-dessus est dj install ou
non. Elle a t dveloppe par le groupe COMET de luniversit de Colombie, en
31
AT&T : http://www.att.com
ACIRI : http://www.aciri.org
33
CIMS : Columbia IP Micro-Mobility Suite
32
57
collaboration avec, laboratoires et entreprises.

CIMS v1.0 inclus les implmentations NS-2 de Cellular IP, Hawaii et Mobile IP
Hirarchique qui ont t prsents dans la deuxime partie de ce rapport.
Limplmentation de Cellular IP supporte le semi-soft handoff et la pagination IP.
Limplmentation de Hawaii supporte les modles de non-propagation unicast et de
propagation de flux multiples. Pour linstant, le pagination IP de Hawaii nest pas
supporter dans cette version de CIMS. De mme, limplmentation de MIP Hirarchique
ne supporte pas la pagination IP non plus. Le tableau 3.3 prsente les supports de chacune
des implmentations de manire dtaille.
Cellular IP
Hawaii
MIP Hirarchique
Couche OSI
Couche 3
Couche 3
Couche 3.5
Nuds impliqus
Nuds IP cellulaires
Tous les routeurs
Agents visits
Id. du nud mobile
Adresse principale
Adresse temporaire
Adresse principale
Nuds
intermdiaires
Commutateur niveau
2
Commutateur niveau
2
Routeurs niveau 3
Mise jour
Paquets de donnes
Pagination
Non
Non
Explicite
Tunneling
non
Non
oui
Handoff dclench
par la couche 2
optionnel
optionnel
Non
Messages MIP
non
oui
oui
Messages de
signalisation
Message de
signalisation
Tableau 3 : fonctionnalit de limplmentation CIMS

Luniversit de Colombie fourni un scnario type pour effectuer des tests. Lexemple
dcrit ci-dessous concerne une topologie constitu de nuds Hawaii. Ils proposent
dutiliser cette mme topologie en changeant simplement le type des points daccs en
nuds cellulaire IP puis en point daccs hirarchique pour implmenter MIP
hirarchique. Cependant lextension a encore des bugs et son installation requiert
beaucoup de retouches, cest pourquoi les tests comparatifs nont pas t fait. On verra
tout de mme dans la partie qui suit, le scnario quils proposent. Ensuite, on dtaillera
des tests que lquipe COMET a raliss sur le protocole Cellular IP.
3.6.2.1 Scnario
Le script du scnario suivant est disponible sur le site Internet de CIMS. la fin de la
simulation, une fentre de NAM apparat (Figure 3-14) qui donne la topologie du rseau.
58
Figure 3-14 : topologie des tests

Cette simulation cre un rseau d'accs sans fil o un unique nud mobile se dplace
entre les point daccs Hawaii 10 et 11 en bas droite dans la Figure 3-14.
Dans ce scnario, le premier handoff arrive peu prs 1.53 secondes dans la
simulation. En ralentissant le minuteur d'affichage on peut observer le flux de message de
contrle (paquets rouges reprsentant la messagerie de contrle, indique par "0" dans la
Figure 3-14) et son impact sur la propagation des paquets de donnes.
3.6.2.2 Tests sur Cellular IP
Dans cette section, des tests sur les performances du handoff dans des rseaux d'accs
Cellular IP sont tudis. Ces tests portent sur les impacts quantitatifs du modle du
handoff dans les rseaux cellular IP (perte de paquets, retard dans la livraison des
paquets).
59
Environnement de Simulation
L'environnement de simulation IP Cellulaire employ pour les rsultats annoncs est

montr dans la Figure 3-15. il sagit dun nud mobile qui se dplace dun point daccs
( gauche dans la figure) une autre ( droite dans la figure). Ces points daccs ont des
zones de couverture qui se recouvrent. Le routeur passerelle de Cellular IP peut atteindre
les deux points daccs et est connect un LAN. Un autre nud fixe est aussi connect
au LAN qui va intragir avec le nud mobile.
Figure 3-15 : plate-forme de test Cellular IP

Les hypothses de l'environnement de simulation NS-2 sont les suivantes : tout
d'abord, on considre que les nuds mobiles utilisent "une interface sans fil idale", c'est-dire que les paquets sont transmis sur l'interface sans fil sans retard, sans erreur et sans
perte. La congestion sur l'interface radio n'est pas modlise non plus, ni les beacons
transmis par le routeur passerelle cellulaire IP. Le rseau est configur quand la session
de simulation est initialise et la topologie reste constante pendant toute la dure de la
simulation. Finalement, la disposition des points daccs cellulaire IP est telle que les
cellules de recouvrement se chevauchent pour que le mouvement des nuds mobiles
d'une cellule une autre soit immdiat. Cela ne limite pas la capacit du simulateur
tudier la perte de paquet pendant le handoff puisque la perte est principalement du des
erreurs de routage.
Performance du handoff
Latence du handoff
L'impact du handoff sur des sessions en cours est gnralement caractris par la
latence du handoff (voir dfinition partie 2 section 2.1). Bien que la latence du handoff ne
dtermine pas entirement les performances du point de vue des applications, c'est une
bonne indication des performances du handoff. On peut dcomposer ce temps de latence
en deux : le temps de rendez-vous et le temps pour le protocole. Le temps de rendez-vous
est le temps pris par le nud mobile pour sattacher au nouveau point daccs aprs avoir
quitt lancien. Ce temps est li la couche physique et au protocole daccs au mdium.
Le temps pris pour le protocole est le temps pris pour restaurer le trafic des sessions du
60
nuds mobiles au nouveau point daccs une fois quil a reu un beacon du nouveau
point daccs. Les tests porteront essentiellement sur le temps pris pour le protocole, le
temps de rendez-vous tant gnralement trs faible.
On considrera donc dans le cadre de ces tests que la latence du handoff est la
diffrence entre le moment o le nud mobile quitte lancien point daccs et le moment
o il reoit le premier paquet au nouveau (en considrant le temps de dplacement nul).
Perte de Paquet
En plus de la latence du handoff, la qualit de service au niveau applicatif est aussi

affecte par la perte de paquet pendant le handoff. Pour dterminer la perte de paquet
pendant un handoff, un nud quelconque de lInternet transmet un flot de paquets
priodiquement au nud mobile. Avant qu'un handoff ne soit amorc, les paquets sont
achemins le long de lancienne route. Dans la simulation, on suppose que le nud de
croisement (B1 dans la Figure 3-15) connat d'avance lequel des paquets du flot sera le
dernier pour atteindre le nud mobile son ancienne localisation. On suppose que le
noeud de croisement marque ce paquet. En recevant le paquet marqu, le noeud mobile
excute un handoff et transmet immdiatement un paquet de mise jour travers le
nouveau point daccs. Les paquets achemins par le noeud de croisement aprs le paquet
marqu, mais avant l'arrive du paquet de mise jour, sont envoys lancien point
daccs et sont donc perdus. Cet intervalle de temps est gal la somme du temps pris par
le paquet marqu pour atteindre le noeud mobile et le temps pris pour le paquet de mise
jour pour atteindre le noeud de croisement. La perte de paquets d au handoff est donc li
au temps daller-retour entre les anciennes et nouvelles localisation et le nud de
croisement.
La perte de paquet occasionne lorsquune source met un dbit constant de bits
(CBR) dans cet environnement de simulation est montr dans la Figure 3-16.
La courbe reprsente en ordonne le nombre moyen de paquets perdus pendant le
handoff et en abscisse le temps entre les arrives de paquet en secondes. Ces rsultats
sont raliss avec des nuds mobiles et des points daccs implmentant le handoff de
base dcrit dans Cellular IP (ce quon a appel hard handoff dans la partie 2 section
2.5.1.2).
61
Figure 3-16 : paquets perdus pour un flux CBR

Les performances de handoff sont dpendantes des conditions de trafic. Dans un
rseau fortement charg, la latence du handoff et la perte de paquet seront plus
importants. Les applications en temps rel (voix sur IP par exemple) sont sensibles au
retard dans la livraison des paquets et ne peuvent typiquement pas tolrer le retard associ
la retransmission des paquets perdus. Pour ces applications, le nombre de paquets
perdus caractrise les performances du handoff. D'autres applications, cependant, utilisent
le contrle de flux de bout en bout pour rpondre aux conditions rseau et retransmettent
des paquets et/ou rduisent le taux de transmission si des erreurs ont lieu. Dans ce qui
suit, on analyse limpact dun handoff sur un trafic TCP. TCP reprsente aujourd'hui le
type de trafic le plus typique dans l'Internet puisquil supporte le World Wide Web, le
transfert de fichier, ltablissement de connexion distance
Comportement TCP
Tout dabord, on va observer le comportement d'une session TCP pendant un handoff

dans la simulation prcdente. Le premier exemple TCP est le tlchargement de donnes
par un nud mobile. La taille des paquets TCP est de 1000 octets et lutilisateur mobile a
jusqu' 5 Mbps de la largeur de bande en sortie, c'est--dire que le taux de paquet partant
est de 625 paquets/seconde. Le temps de transmission de paquets entre des nuds dans la
configuration simule est 2 ms, ce qui abouti une latence du handoff de 4 ms. La
Figure 3-17 expose les numros de squence des paquets de donnes arrivs et des
acquittements observs au routeur passerelle pendant le handoff. Elle prsente en
ordonne les numros de squence TCP ct client (paquets de donnes et acquittements)
et le temps en secondes en abscisse.
62
Figure 3-17 : numro de squence TCP pendant un handoff (mobile rcepteur)

Daprs la Figure 3-17, le handoff est initialis par le nud mobile 4 secondes dans
la simulation. Trois paquets conscutifs sont perdus comme indiqu par les trois
acquittements manquants conscutifs. Une fois que le processus de handoff est achev,
les paquets continuent parvenir au nud mobile. Ces paquets sont, cependant, reus
dans le mauvais ordre et impliquent la duplication des acquittements par le rcepteur.
Cette duplication est indique par la ligne horizontale des numros de squence des
acquittements. Les acquittements dupliqus informent l'metteur TCP des pertes et
causent la retransmission des paquets perdus. Le premier paquet retransmis arrive environ
20 ms aprs le handoff. Le taux TCP maximum est nouveau atteint 4.07 secondes.
Le handoff est interprt par lmetteur dans le rseau IP filaire comme une
congestion qui cause la rduction du taux de transmission. Le contrle du flux TCP dans
NS-2 permet laugmentation ou la rduction progressive de la fentre dmission selon
les erreurs produites. Si jamais une perte ou une congestion est observe, lmetteur
rduit immdiatement la fentre. La simulation montre que la fentre de transmission
maximum est remise en place environ 70 ms aprs que le handoff ai t initialis.
Dans l'exprience suivante, le nud mobile est la source du trafic TCP, tout le reste de
la simulation est exactement identique au cas prcdent. Dans ce cas, le handoff
provoque la perte des acquittements et non la perte des paquets de donne. Les rsultats
de la simulation sont montrs dans la Figure 3-18.
63
Figure 3-18 : numro de squence TCP pendant un handoff (mobile metteur)

Avant que le handoff ne soit initialis, l'expditeur TCP au niveau du nud mobile
utilise une fentre dmission maximale de 20 paquets, ce qui se remarque par la
diffrence des numros de squence entre les paquets de donnes et les acquittements.
4 seconde (temps simul) le noeud mobile excute un handoff et arrte de recevoir les
acquittements pendant environ 4 ms, ce qui reprsente la latence du handoff. Pendant le
handoff, l'expditeur nenvoie pas de paquets puisque sa taille de fentre est entirement
utilise et il a besoin dacquittements pour continuer lmission. Dans cette exprience, le
handoff est initialis quand la session TCP est stabilise et les acquittements parviennent
au noeud mobile continment. Daprs les caractristiques TCP, le premier acquittement
que le nud mobile reoit acquitte non seulement le paquet de donnes dont le numro
de squence correspond, mais aussi tous les paquets de donnes de numro de squence
infrieur qui navaient pas t acquitts. Lmission reprend donc trs vite, et les
rpercutions sur la session TCP sont trs faibles dans le cas prsent.
Nous observons donc un impact diffrent du handoff selon que celui-ci arrive dans une
phase de dbut (petite fentre dmission, acquittement reu irrgulirement) ou dans une
phase avance stable et selon que les nuds mobile est la source ou le rcepteur du flux
TCP.
3.6.3 Mobiwan
Le projet de recherche Mobiwan34 a pour but dintgrer la mobilit des nuds dans
des grandes aires de rseaux IPv6 dans les simulations NS-2. Lobjectif principal est de
simuler une mobilit locale (dans un domaine administratif ou sur un site) et une mobilit
34
Mobiwan : Mobility in Wide-Area Network : mobilit dans des grandes aires de rseaux
64
globale ( travers les frontires de domaines ou de sites) dans des grandes topologies
Internet. En particulier, ce projet a lambition de simuler Mobile IPv6, Mobile IPv6
hirarchique, et divers protocoles de micro-mobilit pour des topologies allant jusqu
des centaines de nuds. Pour cela, il est ncessaire de pouvoir simuler une grande
topologie Internet reprsentative de la ralit et un modle de mobilit qui permettra la
mobilit d'un nud dans n'importe quelle partie de cette topologie. Cette mobilit est
montre dans la Figure 3-19 o les flches bleues montrent une mobilit dans un site et
la flche rouge une mobilit globale entre sites ou domaines.
Mobilit globale : entre les

domaines et les sites
Figure 3. :
Les modules de NS-2 simulant la mobilit (introduits par SUN et CMU) n'accomplissent pas nos besoins
puisquils simulent une mobilit limite une grille gographique. Il n'y a dailleurs aucun moyen de
configurmanipuler une grande topologie.
Mobilit locale :
lintrieur
dun site
Figure 3-19 : aires de mobilit locale et de mobilit globale

Lextension Mobiwan a t implmente pour la version 6 de NS-2 (NS-2.1b6) par
Thierry Ernst de lINRIA Rhne Alpes35 dans le cadre du projet PLANETE36, en
collaboration avec le laboratoire Motorola37 de Paris. Il est prvu dtendre le code pour
quil tourne sous la version 8 de NS-2 (NS-2.1b8).
Le projet se dcoupe en deux parties : une premire partie concerne la gnration et la
35
INRIA : http://www.inrialpes.fr
projet PLANETE : http://www.inrialpes.fr/planete
37
Motorola Paris : http://www.motorola.fr
36
65
manipulation de grandes topologies. Ces topologies doivent pouvoir tre cres et

contrles le plus simplement possible. Le code fourni pour simuler des grandes
topologies peut servir pour simuler dautres protocoles qui nimpliquent pas forcment
des nuds mobiles. Une deuxime partie consiste en limplmentation du protocole
MIPv6 dans NS-2. Comme on la vu dans la prsentation de Mobile IPv6 dans la partie 1
section 1.4, MIPv6 ncessite que les nuds non mobiles implmentent certaines
fonctionnalits spcifiques. Il a donc fallu rajouter cette implmentation lensemble des
nuds dans NS-2. Cependant, lensemble du protocole IPv6 na pas t mis en uvre.
Limplmentation de MIPv6 hirarchique est prvu pour dans quelques mois. Puis, le but
final du projet est de pouvoir utiliser simultanment lapport de ces deux parties pour
simuler la mobilit v6 dans des grandes aires de rseaux.
3.6.3.1 Gnration et manipulation de grandes topologies
Comme il a t dit plus haut, la gnration de grande topologie peut tre utilise pour
toutes sortes de topologie. Des tests ont t raliss avec plus de 3000 nuds, ce qui
devient intressant pour ltude de la mise lchelle de protocoles. Pour conduire des
grandes simulations, il faut :
Une gnration automatique dune grande topologie hirarchique qui est une
reprsentation relle de ce quon peut trouver dans lInternet.
Une topologie hirarchique qui expose la notion de domaines, de sites et de

sous-rseaux.
Une configuration et une manipulation simple de la topologie pour identifier la

position et les fonctions dun nud dans la hirarchie, pour configurer un
nud avec les caractristiques appropries ses fonctions. Par exemple, on
peut configurer tous les routeurs frontires avec MIPV6 hirarchique et tous
les points daccs avec une fonction d'agent mre.
Une configuration de scnario de simulation facile, par exemple choisir tous

les routeurs dun site particulier comme correspondants dun noeud mobile.
La configuration et la manipulation de grandes topologies rseau sont automatique

dans NS-2 de base. Les topologies gnres sont de bonnes reprsentations de ce quon
trouve dans lInternet et permettent de dfinir des fonctionnalits diffrentes aux nuds
selon leur position dans la topologie.
Le module de NS-2 qui cre la topologie est GT-ITM [47]. GT-ITM est un gnrateur
de topologie hirarchique au format SGB. Il cre des topologies constitus de deux sortes
de domaines : dune part les domaines terminaux (stub domain) qui supporte uniquement
le trafic gnr ou destination dun nud dans ce domaine. Dautre part, la topologie
est constitu de domaine de transit (transit domain) qui supporte en plus la propagation
de trafic. Ce sont des domaines qui relient dautres domaines. Un domaine terminal
correspond un campus ou un rseau local (LAN) alors quun domaine de transit
correspond plutt une grande aire de rseau (WAN38). La Figure 3-20 illustre ces
notions de domaine et explicite lgrement la notion de fonction de nuds qui sera
38
WAN : Wide Area Network : grande aire de rseau
66
dvelopp plus tard.
Figure 3-20 : topologie attendue

Cependant, le traducteur du format SGB de la topologie cre par GT-ITM au format
NS-2 perd la plupart des informations, en particulier la hirarchie des nuds. Bien que le
traducteur produise des adresses hirarchiques, lutilisateur nest pas capable de
dterminer si un nud est un nud de transit ou un nud terminal.
La topologie gnre par GT-ITM est tout de-mme un bon squelette pour les besoins
de cette extension. Il manque la notion de site, quil faudra ajouter. On peut dfinir un
site dans une topologie GT-ITM comme tant un domaine terminal avec des points
daccs en plus.
Les outils ajouts par lextension pour raliser ces tches sont le traducteur
TOPOGEN et la librairie TOPOMAN qui sont dcrits ci-dessous. La forte hirarchie
mise en place implique aussi un changement dans ladressage, que nous allons tudier par
la suite.
TOPOGEN
TOPOGEN traduit la production GT-ITM (format SGB) en un format NS-2 appropri

pour TOPOMAN. La topologie GT-ITM nest pas modifie. TOPOGEN classe les nuds
selon leur position dans la topologie (quel domaine de transit dans la topologie, quel site
dans le domaine de transit et quel sous-rseau dans le site) et leur fonction. La sortie de
TOPOGEN donne le nombre de domaines administratifs dans la topologie, ajoute des
67
nuds de transit au domaine indiqu et pour chaque noeud de transit, il dtermine le

nombre de sites. Pour chaque site, il ajoute un noeud frontire et dautres nuds. Bien
sr, il produit aussi la liste des liaisons entre les nuds
TOPOMAN
TOPOMAN est une bibliothque de procdures Tcl/OTcl pour manipuler et configurer

une topologie produite. TOPOMAN construit automatiquement la topologie NS. Il charge
la topologie TOPOGEN dcrite ci-dessus, dfinit l'adressage NS-2 automatiquement et
cre des nuds et des liaisons. TOPOMAN permet non seulement de crer et de
configurer la topologie automatiquement, mais il permet aussi dafficher et de jouer avec
la topologie avant qu'elle ne soit effectivement cre. Ceci est trs utile : pour ajuster la
topologie, l'utilisateur n'a pas besoin de lancer NS-2, ce qui impliquerait la cration de
tous les objets et de la table de routage.
Le chargement de la topologie NS-2 peut tre excute la main avec des instructions
TOPOMAN, ou par l'utilisation du traducteur TOPOGEN. TOPOMAN permet de
classifier les nuds selon leur fonction dans la topologie. ce jour, les fonctions sont :
Nud de Transit : nuds qui peuvent gnrer et recevoir des paquets, mais
aussi uniquement en propager.
Routeur frontire : nuds connectant un site un domaine de transit.
Routeur de Site : routeur autre que le routeur de frontire dans un site.
Point daccs : routeur connectant les nuds mobiles un noeud filaire.
Nud mobile : fonction identique celle dfinie dans la section 3.2.1.6
L'utilisateur peut ajouter des nouveaux types de nuds, toujours en utilisant les appels
TOPOMAN. TOPOMAN tient une information dtaille sur la topologie (nombre de
domaines, de sites, de nuds dans un site, etc.). TOPOMAN peut tre tendu pour
retourner n'importe quelle sorte d'information ncessaire l'utilisateur. Pour le moment,
TOPOMAN peut rendre la liste des nuds frontire dans la topologie, le prfixe
d'adresse pour des nuds dans le topologie, etc.
Outil pour les scnario : SCEN TOOL
SCEN TOOL est un outil de configuration et de gnration de scnario de mobilit qui

utilise TOPOMAN.
Adressage
Chaque noeud de transit correspond un sous-domaine. Un domaine administratif est

donc une accumulation d'un ou plusieurs nuds de transit. Chaque noeud de frontire est
la porte entre un site et un sous-domaine. Tous les routeurs dans le mme site (routeurs
frontire, routeurs de site, points daccs) ont le mme prfixe, c'est--dire quils ont tous
le prfixe du site. Chaque routeur dans le site a aussi son propre prfixe de sous-rseau.
TOPOMAN organise les adresses NS-2 selon cette information, sans quon ait se
soucier de quoique ce soit. Des procdures TOPOMAN permettent de connatre quel
site un noeud appartient.
68
L'adresse de NS-2 de base est divise en 3 niveaux par dfaut. Il tait techniquement
impossible de faire apparatre le domaine et le sous-domaine dans une adresse de NS-2 de
base, cest pourquoi cette information est tenue par TOPOMAN de manire interne.
Lutilisation des nuds mobiles dans NS-2 de base passe par le systme dadressage
suivant:
Le premier niveau identifie le site ; un nud de transit a son propre site (raison
technique). Tous les nuds avec le mme site ont le mme identifiant de site.
Le deuxime niveau identifie le sous-rseau dans le site ; on obtient ainsi le

prfixe sous-rseau. Tous les routeurs frontires, les routeurs de site et les
points daccs ont le mme identifiant de sous-rseau (unique).
Le troisime niveau identifie l'hte dans sous-rseau, c'est--dire le systme

terminal. Les routeurs ont hostid = 0, les nuds mobiles ont hostid 0.
Lutilisateur peut dsirer conserver ce niveau hirarchique dadressage, notamment

lorsquil effectue des simulations sans nuds mobiles. Cependant, lutilisation dun
niveau supplmentaire dadressage peut tre prfr pour rduire la consommation de
mmoire de NS-2 et rduire le temps de calcul des tables de routage (par une information
plus explicite). Par exemple, une simulation avec une topologie de 500 nuds et les
mmes paramtres prendra 37 minutes au lieu de 70 et consommera 100 MO de mmoire
au lieu de 150.
Les 4 niveaux dadressage dans NS-2 signifient :
Le premier niveau identifie le sous-domaine dans la topologie (c'est--dire les

nuds de transit). Cela donne le prfixe de sous-domaine (le prfixe de
domaine est enregistr intrieurement)
Le deuxime niveau identifie le site dans le sous-domaine (i.e. stub). Les

nuds de transit sont dans le stubid 0. Cela donne le prfixe de site.
Le troisime niveau identifie le sous-rseau dans le site. Cela donne le prfixe

du sous-rseau. Tous les routeurs frontires ont stubid 0.
Le quatrime niveau identifie l'hte dans le sous rseau, c'est--dire le systme

terminal. Les routeurs ont hostid = 0 et les nuds mobiles ont hostid 0.
Pour effectuer ce niveau hirarchique dadressage, il faut aussi compiler NS-2 avec les
fichiers route.cc et route.h modifis. Il est impossible dutiliser la fois ladressage 3
niveaux et 4 niveaux dans le mme fichier binaire (cela auraient exig de changer plus
de code dans Tcl, alors que l il ne sagit que dune modification de fichiers). Pour les
simulations sans nuds mobiles, ladressage 4 niveaux de hirarchie nest pas
ncessaire.
3.6.3.2 Mobile IPv6 et IPv6
Limplmentation des protocoles Mobile IPv6 et IPv6 est mise en oeuvre par un jeu de
nouveaux agents et de nouveaux classificateurs NS-2. Ce modle sera prochainement
tendu pour soutenir Mobile IPv6 hirarchique. Toutes les particularits d'IPV6 nont pas
t mises en uvre, seules celles ncessaires Mobile IPv6 ont t implmentes (par
69
exemple DHCPv6, dcouverte des voisins, etc.).

Les nuds qui ont besoin dimplmenter Mobile IPv6 sont les nuds mobiles, les
points daccs et les correspondants des nuds mobiles. Les correspondants doivent
implmenter MIPv6 pour raliser entre autre l'encapsulation, la dcapsulation, le
traitement des en-ttes de routage. Ces changements ont t apports dans la
configuration des nuds NS-2 (classe Node).
Quant au nud mobile et au point daccs (ou lagent mre), lextension sappuie sur
la classe MobileNode cre par CMU (voir section 3.2.1.6). Lagent de routage ad hoc est
remplac par l'agent Rseau (Network Agent). La structure des nuds Mobile IPv6 est
montre dans la Figure 3-21 et la Figure 3-22.
Figure 3-21 : nouvelle structure dun nud filaire
70
Figure 3-22 : nouvelle structure dun nud mobile ou dun point daccs
Limplmentation du protocole respecte les spcifications qui ont t dcrites dans la
partie 1, cest pourquoi lalgorithme de MIPv6 nest plus dcrit ici.
Agent Rseau
Cet agent est utilis par les points daccs et les nuds mobiles. Il remplace l'agent de
routage ad hoc dans la classe MobileNode. Cet agent instantie principalement la variable
de prochain saut dans len-tte de paquet NS-2, vrifie le TTL39 et transmet en les Router
Advertisement et Router Solicitation broadcast aux agents MIPv6.
Quant au nud mobile, l'agent Rseau-MN (NetworkMN) permet aux paquets envoys
l'adresse temporaire d'tre expdis au port dmultiplexeur. Il contrle aussi les paquets
39
TTL : Time To Live : dure de vie du paquet
71
entrants et informe lagent du nud mobile de la source du paquet en faisant appel au

MNAGENT (ce qui aboutit une nouvelle entre dans la liste de correspondance).
Agents Mobile IPv6
Le protocole Mobile IPv6 lui-mme est mis en oeuvre par un ensemble d'agents NS-2.
La classe de base est la classe MIPv6Agent, et les classes drives sont la classe
MNAgent, la classe CNAgent et la classe BSAgent. Les agents MIPV6 se servent des
particularits existantes :
Router Advertisement et Router Solicitation : Actuellement traits

directement par les agents MIPV6 (MNAgent et BSAGENT).
La liste des points daccs : Cette liste est maintenue par les nuds
mobiles grce aux Router Advertisement envoyes par les points daccs.
Les entres sont supprimes quand la dure de vie expire. Le nud mobile
coute les Router Advertisement envoys par les points daccs. Quand il
reoit un Router Advertisement dun point daccs inconnu, il lenregistre
dans la liste des points daccs avec une certaine dure de vie. Le nud
mobile obtient alors une nouvelle adresse temporaire et utilise ce nouveau
point daccs comme point daccs par dfaut.
Obtention dune nouvelle adresse temporaire : Les adresses ont deux

composants : lidentifiant rseau (network_id) qui identifie le sous-rseau
et l'emplacement dans la topologie et lidentifiant de nud (node_id) qui
identifie le noeud. Lidentifiant rseau de ladresse temporaire est donc le
prfixe de l'adresse du point daccs et identifie le sous-rseau visit ;
Tandis que lidentifiant du nud est lidentifiant de l'adresse mre du
nud mobile modulo 128. Le modulo 128 permet davoir 128 mobiles
simultanment dans une simulation. L'objet ARP du nud mobile est
modifi pour rpondre des demandes pour l'adresse temporaire
principale du nud mobile.
Liste de mise jour des associations : Cette liste maintenue par les nuds
mobiles a deux buts : le maintien de la liste des correspondants actifs du
nud mobile et le maintien de l'information sur lmission des Binding
Update. Ne maintenir quune seule liste vite davoir grer deux listes
distinctes et complmentaires dont le but commun est de savoir qui
envoyer un Binding Update.
Une entre indique l'adresse de destination, un flag spcifiant sil faut

envoyer un Binding Update ce noeud ou non (non utilis dans la mise en
oeuvre actuelle), ladresse temporaire, le temps, le numro de squence et
la dure de vie du dernier Binding Update envoy, plus des informations
complmentaires (type de noeud pour distinguer entre point daccs, agent
mre et correspondant).
La liste des correspondants inscrit les nuds potentiels auxquels un

Binding Update peut tre envoy. Ces nuds sont automatiquement insr
par l'agent Rseau, ou explicitement par l'utilisateur partir de
72
l'interprteur OTcl, ou automatiquement par le MNAGENT lui-mme.
La liste des mises jour des associations indique aux nuds quel Binding
Update a rellement t envoy. Les entres dans la liste peuvent tre
actives ou non.
Optimisation de routage : il est possible de mettre en place la

communication directe entre le nud mobile et un correspondant, cest-dire indiquer au correspondant la position courante du nud mobile.
Propagation par lancien point daccs : il est possible de mettre en place

la propagation du trafic destin au nud mobile au nouveau point daccs.
Par dfaut, le nud mobile envoie un Binding Update lancien router
daccs. Par contre, aucune mcanisme de d-enregistrement na t mis
en place (car non spcifier pour le moment), donc les paquets peuvent
tourner en boucle si le nud mobile se dplace rapidement entre deux
mmes points daccs.
Emission des Binding Update : le noeud mobile envoie un Binding Update

chaque fois quil obtient une nouvelle adresse temporaire ou que les
entres dans son cache sont sur le point dexpirer. Il envoie ce message
toutes les entres actives dans sa liste de de mise jour en mme temps.
Cache dassociation : quand un nud reoit un Binding Update, il met

jour son cache dassociation. La table de routage doit alors tre mise jour
pour rediriger les paquets dans la bonne direction. Dans NS-2, la table de
routage est implment par un ensemble de classificateurs. Comme le
montre la Figure 3-21, des nouveaux classificateurs ont t ajouts pour
dterminer si un paquet doit tre redirig ou pas.
Collecte des statistiques : lutilisateur peut charger lhistorique des

vnements (attache aux points daccs, entre/sortie dans les listes,
mission/rception des Binding Update) pour effectuer des statistiques
sur les simulations.
3.6.3.3 Mobilit dans un WAN

Pour tester la mobilit dans des grandes aires de rseaux (WAN), il faut diffrencier la
mobilit locale de la mobilit globale. Un site est un rseau rgit par une politique
administrative commune. Tous les nuds dans un site sont identifis par le mme prfixe
IP. La longueur du prfixe dtermine la taille maximale du site. Le site peut aussi tre
dfini par un secteur gographique limit. Les nuds mobile se dplacent librement dans
la frontire gographique du site et sont rattachs aux diffrents routeurs du site. Un
exemple d'un site peut tre une cit universitaire.
Pour la mobilit WAN, nous avons besoin de :
Moyens pour dfinir la notion de sites dans une topologie de rseau NS-2.
Moyens pour quun noeud mobile puisse rester dans un site limit un certain
secteur gographique et ensuite se dplacer dans un autre site.
73
Un modle de mobilit qui distingue la mobilit locale dune mobilit global
Mobilit intra et inter site
La mobilit intra-site est la mobilit dans un seul domaine d'administration ou la

mobilit dans un seul site (un campus, une organisation). La mobilit intra-site est traite
par limplmentation de NS-2 existante (celle du CMU expose section 3.2.1.6). La
mobilit inter-site signifie le dplacement travers les frontires de domaines, c'est--dire
une mobilit entre deux domaines d'administration ou entre deux sites.
La mobilit inter-site est assure par des nouvelles particularits qui permettent aux
nuds mobiles de se dplacer d'un site un autre. Tous les sites sont associs la mme
grille gographique, mais un canal radio distinct. Tous les points daccs dans le mme
site coutent le mme canal radio et sont associes la mme grille gographique. Le
noeud mobile change son emplacement gographique dans la grille. Un mobile
franchissant la frontire dun site change donc le canal radio qu'il coute. Pour conserver
une certaine simplicit, le nud mobile ne change pas ses coordonnes gographiques
quand il passe d'un site un autre. Ceci permet de continuer employer le modle de
mobilit CMU existant, notamment pour les mouvements alatoires. En effet, le canal sur
lequel le noeud mobile coute est transparent au modle de mobilit.
Mouvements
Un nud mobile peut se dplacer par deux moyens : gographiquement et

topologiquement. Des mouvements gographiques correspondent la mobilit locale,
c'est--dire la mobilit dans un site couvert par un secteur gographique. Le nud mobile
se dplace alors dans une grille comme le montre la Figure 3-23. Ces mouvements
peuvent tre gnrs alatoirement ou par l'utilisation de la commande setdest.
Zone de couverture des points

daccs
Zone de couverture du site
Frontires de la grille
Figure 3-23 : mouvement lintrieur dune grille

Les mouvements topologiques correspondent la mobilit globale, c'est--dire d'un
74
site un autre. Suite un tel mouvement, le nud mobile coute un nouveau canal, celui
correspondant au site auquel il entre. Le nud mobile ne change pas en ralit ses
coordonnes gographiques suite un tel mouvement, mais il change son emplacement
dans le topologie. Il entend donc les Router Advertisement envoys par les points daccs
situ dans le nouveau site, c'est--dire les points daccs ayant un prfixe d'adresse
diffrent.
Tests et commentaires
La mobilit globale n'a pas t value avec plus qu'un nud mobile. En ralit, au
moins un changement est ncessaire pour raliser des tests avec plus quun nud mobile :
pour limiter le nombre d'vnements manipuler, les points daccs dans le site venant
dtre quitt arrtent dmettre des Router Advertisement. Il faut donc changer la
procdure proc enter-site pour effectuer des simulations avec plus dun nud mobile.
Par ailleurs une petite partie du code concerne le support du multicast pour les nuds
mobiles et les points daccs (NS-2 existant ne permet pas ces nuds d'envoyer ou de
recevoir du multicast). Limplmentation ajoute permet uniquement un nud mobile
dmettre un groupe mais pas de recevoir en tant que membre de groupe.
3.7
Conclusion
Cette partie ne constitue quune brve prsentation de loutil de simulation de rseau

NS-2. dautres fonctionnalits offertes comme les liaisons satellites, des techniques
dmulation pour utiliser un rseau rel, nont pas t exposes. NS-2 est un produit
universitaire en cours de dveloppement et non un produit commercial ; Cest pourquoi il
comporte quelques erreurs aussi bien la compilation que lors des tests spcifiques. Il
existe une mailing liste ou les problmes des utilisateurs et souvent les solutions leurs
sont donnes.
La rapide volution des versions savre tre la fois un inconvnient et une qualit.
Un inconvnient car toutes ces extensions ajoutes par des groupes de chercheurs
tournent pas forcement sur les mmes versions. Lutilisation de ces extensions demande
donc beaucoup de patience puisque chaque version a ces problmes dinstallation. Une
qualit car NS-2 devient rapidement de plus en plus robuste, complet et son domaine
dapplication augmente.
75
PARTIE 4
GESTION DINTERFACES MULTIPLES
76
Partie 4 : Gestion dinterfaces multiples
4 Gestion dinterfaces multiples
4.1
Description du projet de gestion dinterfaces multiples

sans fil
4.1.1 Les objectifs

Lobjectif principal de ce projet que nous appellerons MIMP est de mettre en place
des solutions technologiques permettant aux terminaux mobiles IPv6 d'avoir un accs
simultan ou successif plusieurs technologies sans fil. Les nouvelles fonctionnalits
dveloppes permettront une gestion intelligente de la mobilit des quipements IPv6.
Une interface gnrique interne au terminal permettra l'accs aux informations
spcifiques de chaque technologie d'accs sans fil ce qui facilitera la gestion des handoffs
et le choix d'une interface radio. Lorsque plusieurs interfaces permettront simultanment
une connexion au rseau, l'quipement choisira le support en fonction de diffrents
critres comme la qualit de services et le cot d'accs au support. Les applications
adapteront galement leur comportement en fonction de ces critres.
Ces solutions technologiques permettront terme de s'intgrer dans des solutions de
mobilit globale dpassant le cadre de ce projet. Ainsi, la mobilit du point de vue de
l'utilisateur peut se rsumer en trois points: un service de tlcommunication omniprsent
( la maison, dans la rue, dans la voiture, au bureau, dans le train, l'aroport, au caf) ;
un objet communicant simple pour toutes les applications (voix, donnes, images) ainsi
quun service continu, efficace et bon march (la communication doit rester ouverte quels
que soient l'endroit, le rseau support, le fournisseur de service, l'application utilise).
Ces trois exigences peuvent se traduire par la mise en place dun service de mobilit
globale (universelle) avec les contraintes suivantes :
Des rseaux supports prsents partout et tous diffrents : courte et moyenne porte
(Bluetooth), moyenne porte et trs haut dbit (IEEE 802.11 [38] et HiperLAN/2 [40]),
longue porte et bas moyens dbits (GSM [20], GPRS [20], UMTS [21][22][23][24]).
Ces normes seront dcrites dans la section 4.2. Tous ces supports sont fournis en gnral
par des oprateurs diffrents (global, local, public, priv).
Un terminal mobile unique avec le support de divers service de communication
(tlphonie, messagerie, web) et diffrents services daccs (priv, public,
abonnement).
Une gestion de la mobilit tous les niveaux : lors du changement du point dattache,
lors du changement de sous-rseaux, lors du changement du sous-rseau support ou lors
du changement du service daccs.
Afin de permettre l'mergence d'un tel service de mobilit globale, le projet se focalise
sur la fdration de diffrents supports de communication sans fil au sein d'un terminal.
Cela permettra une meilleure prise en compte de la mobilit des quipements et des
utilisateurs. Les mcanismes dvelopps porteront sur la dtection d'une nouvelle
77
ressource de transmission sans fil, la dcision de basculement sur cette nouvelle ressource
de transmission, la mise en place et l'optimisation des procdures de basculement, le
basculement du trafic sur la ou les ressources de transmission disponibles et l'adaptation
du trafic aux niveaux de la qualit et de la scurit en fonction des caractristiques de la
nouvelle ressource de transmission sans fil. Ces mcanismes, limits au terminal, doivent
permettre terme de grer la mobilit dans les rseaux IPv6 de manire globale, efficace
et transparente pour le client et ce sur les plans de la technique, du service, de la qualit
de service et de la scurit.
4.1.2 Etat de lart

Initialement, le monde de lInternet travers son organisme de
standardisation, lIETF, sest principalement pench sur la gestion des dplacements dun
ordinateur mobile sur lInternet, c'est--dire du passage dun rseau local un autre
rseau local. Ce travail a permis de dfinir le protocole Mobile IP [1][2] qui a t
prsent dans la partie 1. Les travaux rcents qui tudient lutilisation des rseaux
cellulaires (Cellular IP [14][15][16][17], Hawaii [18]) montrent les diffrents
problmes poss pour la gestion des diffrentes mobilits des terminaux et la prise en
compte rapide des dplacements. La plupart de ces travaux sont proposes par des
universits amricaines et ne sont qu leur dbut : ils ntudient lheure actuelle que les
problmes de handoffs lintrieur dune seule technologie daccs (voir partie 2).
LInternet du futur aura plusieurs objectifs :
Utiliser les nouveaux protocoles afin de supporter de plus en plus de rseaux et

dutilisateurs : cela passera par ladoption dIPv6 et des protocoles associs.
Exprimenter de nouvelles solutions et des nouvelles fonctionnalits. La

mobilit des utilisateurs est lun des points forts de cet aspect. LInternet
mobile nouvelle gnration nexiste pas encore et il convient de dfinir
rapidement les protocoles qui permettront sa dmocratisation au sein des
communauts dutilisateurs mais galement son adoption par les diffrents
oprateurs.
Il existe ce jour plusieurs projets qui tudient lInternet nouvelle gnration, mais
notre connaissance il nen existe pas (ou trs peu) qui proposent, tudient et dveloppent
des solutions pour lInternet Mobile nouvelle gnration. Il est donc essentiel de pouvoir
proposer une vision globale de la prise en compte sur les terminaux mobiles de la
mobilit aussi bien au niveau IPv6 quau niveau de la gestion des interfaces multiples
sans fil.
Dans le domaine applicatif, l'adaptation dynamique aux conditions d'excution en
gnral et aux variations de la qualit de connexion en particulier a t considre dans le
cadre des applications multimdia grant la qualit de service. Nanmoins, ces travaux
proposent des mcanismes d'adaptation dynamique adapts une application ou un type
d'applications particulier. Dvelopper des nouvelles applications adaptatives requiert
donc la conception rpte de ces mcanismes. En outre, les systmes existant
actuellement manquent d'une approche intgre l'adaptation des couches de plus bas
niveau ce qui permettrait d'effectuer de meilleurs choix lors des adaptations.
78
4.1.3 Cadre du projet et partenaires

Le projet MIMP reprsente lobjet de ma thse qui dbutera en septembre 2001. La
thse seffectue dans le cadre dun contrat de recherche financ par France Tlcom40.
Elle fait partie dun projet plus vaste intitul projet CYBERT41. Le projet CYBERT
est financ par le RNRT [42]. Il est orient vers des thmes de recherche et
dveloppement prcomptitifs. Les partenaires du projet regroupent les centres de
Recherche et Dveloppement France Tlcom pour les rseaux cellulaires, Cisco42 pour
les rseaux locaux sans fil, lIRISA43 pour le dvelopement dapplications sadaptant aux
environnements mobiles et lENST44 Bretagne pour la gestion de la qualit de service. Le
projet CYBERT intgre 4 sous-projets qui sont :
4.2
Sous-projet 1 : description dune architecture multi-interfaces (architecture

MIMP). Cette architecture est dcrite dans la section suivante.
Sous-projet 2 : gestion des profils de qualit de service multiples ; lobjectif est

de dfinir les profils de qualit de service utiliss pour mesurer les capacits de
transmission et les mcanismes dadaptation pour diffrentes interfaces dun
systme.
Sous-projet 3 : dfinition dune architecture gnrique facilitant le

dveloppement d'applications adaptant leurs besoins en qualit de service aux
conditions d'accs au rseau. Lobjectif est de propos des mcanismes
permettant aux applications, d'une part de ragir aux variations de
l'environnement indiques par les mcanismes d'alerte fournis par l'interface
dveloppe dans le sous-projet 1 et, d'autre part, d'informer la couche rseau de
leurs besoins l'aide des profils dfinis dans le sous-projet 2.
Sous-projet 4 : maquette et dmonstrations
Prsentation de larchitecture MIMP
Lobjectif principal du projet est de doter les terminaux mobiles IPv6 dune nouvelle
architecture de communication capable daccder plusieurs technologies de
transmission sans fil. Les terminaux mobiles bnficiant de cette nouvelle architecture
pourront sadapter dynamiquement aux contraintes de qualit de services en remontant
aux applications des informations sur les diffrentes interfaces de communication sans fil
disponibles.
Larchitecture permettra de mettre en uvre des solutions pour :
Offrir une meilleure gestion de la bande passante. Ce mcanisme doit

permettre certaines applications de choisir l'interface qui leur convient le
mieux. Ce choix peut tre effectu suivant diffrents critres (dbit, cot).
Offrir les fonctionnalits de slection de ladresse source. En effet, l'heure
40
France Tlcom : http://www.francetelecom.fr

Projet CYBERTE : projet RNRT dcrit lurl http://www.telecom.gouv.fr/rnrt/suivi/res_01_9.htm
42
Cisco : http://www.cisco.com
43
IRISA : http://www.irisa.fr
44
ENST Bretagne : http://www.enst-bretagne.fr/
41
79
actuelle une application ne choisit pas l'adresse avec laquelle elle met des
paquets. Ce choix se fait simplement en fonction de l'interface d'mission.
Dans le cas de la mobilit IPv6, le choix de l'adresse source est
particulirement important. En effet, un mobile peut changer rapidement de
point d'attachement sur l'Internet. Ce changement impose galement un
changement d'adresse rseau, dans de nombreux cas, il peut tre utile de
pouvoir prendre en compte ce changement sans que pour autant les
applications en soient averties, notamment dans le cadre des communications
multicast.
Disposer d'outils de gestion des interfaces. Il est galement trs important de

pouvoir piloter correctement les interfaces rseau dont dispose un quipement.
Aussi, l'architecture offrira un mcanisme de gestion et de pilotage du
comportement associer une interface.
Prendre en compte les interfaces de "backup" afin de ne pas interrompre des

communications en cours suite la panne de l'un des rseaux utiliss par
l'quipement mais galement d'automatiser le basculement des
communications de manire transparente pour les applications vers un rseau
( travers une interface de backup) de secours.
Optimiser les handoffs. La nature mme des supports sans fil ncessite un
traitement particulier. Or l'heure actuelle, la majorit des drivers de carte
rseau sans fil cherche masquer ces particularits. Il est important de
dvelopper des changes de contrle avec les drivers des interfaces (mise en
uvre de linteraction entre les couches 2 et 3 dont on a parl dans la partie 2).
En effet un mobile IPv6 est amen se dplacer. Ce dplacement peut-tre
plus ou moins rapide. Jusqu' prsent la prise en compte du dplacement d'un
mobile est relativement lente. Elle dpend gnralement de la prise en compte
de la diffusion des prfixes rseau annoncs par les routeurs. Cette diffusion
peut prendre plusieurs secondes. Afin de mieux grer cette mobilit, une prise
en compte des informations reues et mises par les drivers des interfaces
permettra de rduire ces temps. De plus un mobile peut se dplacer laide
dune mme technologie sans fil. Mais nous souhaitons galement lui offrir la
possibilit de se dplacer de manire transparente laide de plusieurs
technologies. Il est donc ncessaire dtudier des mcanismes de handoffs
diffrents niveaux.
Larchitecture MIMP qui doit raliser toutes ces fonctionnalits est prsente dans la
Figure 4-1.
80
Courrier
lectronique
Navigateur
Web
Visioconfrence
Gestionnaire
dinterfaces
TCP/UDP
Mobile IP
Cellular IP
IPv6
Couche de gestion des interfaces multiples

Ethernet
802.11
HiperLAN
Bluetooth
GPRS/UMTS
Figure 4-1 : vue gnrale de larchitecture intgrant MIMP

Comme le montre la Figure 4-1, une gestion globale de la mobilit est propose
travers la dfinition dune couche dabstraction qui permettra dune part de dfinir une
API45 utilisable la fois par les applications mais galement par la couche Rseau IPv6,
et dautre part de tirer au mieux parti des spcificits de chacun des supports de
communication sans-fil sous-jacents.
Grce des mcanismes de gestion unifis et gnriques, cette architecture permettra
d'intgrer tout type d'interface radio existante ou venir. Dans un premier temps, on a
prvu dtudier quelques-unes unes de ces normes radio pour identifier les informations
pertinentes ncessaires aux couches suprieures. Dans la section 4.3 quelques-unes de ces
normes sont brivement prsentes. Cependant il ne faut pas perdre de vue que beaucoup
de normes sont encore en cours de standardisation (UMTS, HiperLAN/2). Cest
pourquoi larchitecture de communication MIMP doit tre modulaire et paramtrable
pour intgrer efficacement les normes et les technologies qui verront le jour
ultrieurement.
Le dveloppement durant ma thse se droulera en deux tapes ; tout dabord
lintgration de cette architecture se fera dans le simulateur rseau NS-2 qui a t
prsent dans la partie 3. Une premire ide de la ralisation de lintgration de
larchitecture MIMP dans NS-2 sera prsente dans la quatrime section. Cette
implmentation fera lobjet de premiers tests. Ensuite, limplmentation relle sera
effectue sur le systme dexploitation FreeBSD avec la pile IPv6 livre en standard.
4.3
Normes prises en considrations
Dans cette section seront dcrites brivement les principales normes de

45
API : Application Programmable Interface interface programmable dapplication
81
communication qui serviront de points de repre pour la conception de larchitecture

gnrique. Il sagit de la norme IEEE46 802.11 dveloppe principalement aux EtatsUnis, de la norme HiperLan/2 qui est en cours de dveloppement et de Bluetooth, produit
europen qui sintgre de plus en plus dans les appareils grand public. Suivant leurs
spcificits, ces normes reprsentent une alternative au rseau filaire ou simplement
labstraction de cblage. Elles proposent des technologies de communication sans fil
associe des protocoles daccs au canal radio. Elles peuvent dfinir une mthode de
communication soit entre un nud mobile et un point daccs, soit entre deux nuds
mobiles. Dans le projet, on sintresse uniquement la communication entre un nud
mobile et un point daccs.
4.3.1 IEEE 802.11

La norme 802.11 [38] est la plus utilise dans les rseaux sans fil ce jour. Elle joue le
mme rle que 802.3 [39] pour Ethernet. La norme dfinit trois fonctions de base pour
tablir la communication :
Une interface de propagation radio pour quil y ait une interoprabilit entre
les fournisseurs.
Une mthode de codage et de modulation : Frequency Hopping Spread

Spectrum ou Direct Sequence Spread Spectrum.
Une couche MAC qui gre laccs au canal : CSMA47 ou Virtual Carrier
Sense.
La bande de frquence utilise est dans les 2,4 GHz et se divise en quatre canaux. Un
point daccs dispose donc de quatre canaux diffrents pour communiquer avec les
stations. Une station utilisera toujours le point daccs qui offre le meilleur signal. Le
dbit maximal est de 11 Mbps.
Au niveau topologique, on parle densemble de service basique (BSS48) quand deux
nuds mobiles (communication ad hoc) ou un nud mobile et un point daccs se sont
authentifis et ont tabli une communication (voir Figure 4-2). Un ensemble de service
tendu (ESS49) est une srie de BSS contenant chacun un point daccs, connects
ensemble par un rseau filaire (voir Figure 4-2).
46
IEEE : http://www.ieee.org
CSMA : Carrier Sense Multiple Access
48
BSS : Basic Service Set
49
ESS : Extended Service Set
47
82
Figure 4-2 : topologie utilise dans IEEE 802.11

Gnralement, les points daccs sont placs de manire ce que leurs cellules de
couvrement se recouvrent. Ce recouvrement permet les dplacements sans coupure des
nuds mobiles entre les points daccs. La norme 802.11 ne dfini que les principes de
base du dplacement (active et passive scanning, processus de r association).
4.3.2 HiperLAN/2
Pour le moment la norme HiperLAN/2 [40] offre uniquement la communication entre
les nuds mobiles et les points daccs. La communication directe entre nuds mobiles
est encore en dveloppement. La topologie propose est plus ou moins la mme que celle
pour IEEE 802.11, savoir des points accs relis par un rseau filaire, fournissant une
connexion sans fils aux htes mobiles. Cette norme fournit un haut dbit, 54 Mbps au
niveau de la couche physique et jusqu 25 Mbps au niveau de la couche IP. Le protocole
MAC daccs au canal radio utilise une forme de division temporelle dynamique.
Lallocation de frquence (dans la bande des 5GHz) est dynamique, comme on peut le
trouver dans les rseaux GSM ; au dmarrage, les points daccs sondent les diffrents
canaux et choisissent le plus appropri en fonction de ceux utiliss par les points daccs
voisins.
HiperLAN/2 inclus une gestion de qualit de service. Toute communication est en
mode orient connexion, cest--dire que deux quipements communicants doivent
dabord schanger des informations de scurit ou au moins dauthentification avant
toute transmission de donnes. Chaque connexion peut tre affecte dune qualit de
service spcifique (largeur de bande passante, taux derreur par bit). HiperLAN/2
fourni aussi des mcanismes dauthentification et de cryptage pour rgler les problmes
de scurit.
La pile du protocole HiperLAN/2 possde une architecture flexible pour permettre une
adaptation facile et une intgration dans diverses varits de rseaux fixes, comme
83
Ethernet ou un rseau cellulaire troisime gnration. Le modle de rfrence du

protocole HiperLAN/2 est dcrit dans la Figure 4-3.
Figure 4-3 : modle de rfrence de HiperLAN/2

Le dplacement des nuds mobiles entre les points daccs peut se faire de deux
manires dans HiperLAN/2 : soit par r association, soit par une signalisation dans le
rseau fixe. Le processus de r association est assez coteux puisquil ncessite que le
nud mobile recommence tout le processus dassociation (authentification,
autorisation). Dans la deuxime solution, le nouveau point daccs reoit les
informations ncessaires sur le nud mobile par le rseau filaire qui interconnecte les
points daccs.
4.3.3 Bluetooth
Bluetooth [41] ne sinscrit pas dans la mme gamme que les deux normes prsentes
ci-dessus. Bluetooth dfini une liaison courte distance, conomique mais faible dbit,
pour remplacer le cblage. Les points forts de cette norme sont sa robustesse, sa faible
complexit, sa faible consommation de courant et son prix.
Bluetooth opre dans la bande de frquence de 2,4 GHz. Le dbit symbolique est de 1
Mbps sur un canal division temporelle. Le systme se dcompose en une unit radio,
une unit de contrle de liaison et une unit de gestion de liaison et de primitives.
Plusieurs quipements partageant le mme canal sont appels piconet. Chaque piconet
est hirarchis en un matre et un ou plusieurs esclaves. Le mode de communication peut
84
tre orient connexion ou non. Lorsquil sagit dune communication point point, la
liaison est synchrone oriente connexion. Lorsquil sagit dune communication point
multipoint entre un matre et des esclaves, la liaison est asynchrone en mode non
connect.
4.3.4 Comparatif des trois normes et porte des solutions

technologiques
Le Tableau 4 dcrit les caractristiques principales des trois normes.
Caractristique
802.11
HiperLAN
Bluetooth
Spectre de
frquence
2,4 GHz
5 GHz
2,4 GHz
54 Mbps
1 Mbps
CSMA/CA
TDMA/TDD
TDMA/TDD
Connexion
Sans
Avec
Avec ou sans
Multicast
Oui
Oui
Oui
Mode
conomique
Oui
Oui
Oui
Qualit de
service
PCF
ATM/802.1p/RSVP/DiffServ
Gestionnaire
de liaison
Rseau fixe
sous-jacent
Ethernet
Ethrnet, IP, ATM, UMTS
Multiple
Dbit maximal
Contrle
daccs au mdia
11 Mbps
(version b)
Tableau 4 : comparatif des trois normes

La Figure 4-4 qui suit montre grossirement les solutions actuelles pour
linterconnexion dquipements en terme de dbit, ainsi que la porte ou plutt les lieux
dutilisation. Sont reprsents les LAN qui offrent le dbit le plus lev, mais est limit
des postes fixes en intrieur. Bluetooth offre une mobilit locale de faible porte avec un
dbit moindre. Les LAN sans fil actuel (IEEE 802.11 gnralement) offrent un dbit
allant jusqu 10 Mbps mais aucun protocole ne gre actuellement les dplacements de
manire assez efficace pour que les quipements puissent se dplacer dans nimporte
quelle partie de lespace. Par contre les rseaux cellulaires offrent une totale libert de
mouvement (dans la limitation des zones couvertes) mais avec un dbit trop faible pour
du trafic IP.
85
Mobility
Intrieur
Extrieur
Vhicule
Marche
Fixe
Marche
Fixe/
bureau
G
S
M Wideband
, Cellular
IS
95
Bluetooth
0,
W-LAN
LAN
10
100
Figure 4-4 : dbit et porte de diffrentes modes de connexion
4.4
Introduction de larchitecture MIMP dans NS-2
4.4.1 Planification
La premire tape dans la ralisation de larchitecture MIMP sera de limplmenter
dans le simulateur rseau NS-2 qui a t prsent dans la partie 3. On pourra ainsi
sapercevoir des performances quelle pourra procurer au sein des quipements mobiles.
Actuellement, la norme 802.11 est implment en standard dans NS-2 et Bluetooth est
une extension base sur la version 6 de NS-2. Un premier travail pourrait donc concerner
la gestion de ces deux interfaces sans fil et de linterface utilise par les nuds fixes.
Dans NS-2 les protocoles daccs au mdium sont implments dans la classe MAC.
La couche MAC est la couche intermdiaire entre le canal physique et la couche liaison.
Les fichiers mac.{h,cc} contiennent les tats et mthodes de configuration gnrales
applicables tout type de protocole MAC. La classe MAC est ensuite drive pour des
implmentations plus spcifiques comme pour le protocole CSMA (classe CsmaMac) ou
802.11 (classe mac-802_11).
Lobjectif est de prendre la meilleure interface disponible un moment donn. Mais
pour cela, il faut pouvoir comparer la qualit des interfaces radio. La meilleure interface
est celle qui offre le meilleur dbit par rapport son cot et lapplication en cours. Il
faudra donc ajouter aux implmentations des technologies un attribut cot qui entrera en
compte lors de la dcision. De mme, il faudra pouvoir distinguer quelle application
86
Mbps
ncessite un plus grand dbit que telle autre. Ceci peut tre fait dans NS-2 par la mesure
du taux de trafic gnr.
4.4.2 Implmentation dun nouvel objet

La gestion de ces interfaces passe par lajout dun nouvel objet. Cest cet objet qui
devra dtecter quelles interfaces sont disponibles, quel est leur cot et quels sont les
besoins de la communication. Cet objet devra intgrer la structure interne dun nud
mobile, se situant au mme niveau que linterface de file dattente. Lobjet gestionnaire et
ses interactions avec les autres objets sont reprsents dans la Figure 4-5.
Agent
metteur/
receveur
Table ARP
mac
LL
ARP
Interface
de la file
Gestion des
interfaces
multiples
Cible montante
MAC
Cible descendante
Cible montante
Modle de
propogation
radio
propagation
Interface
rseau
canal
Cible montante
canal
Figure 4-5 : gestion dinterfaces multiples dans NS-2
87
Le modle de propagation radio enregistre lintensit du signal chaque paquet reu.

Effectivement les paquets voyageant sur les interfaces radio contiennent un indicateur
dintensit du signal. Si celui-ci est en dessous dun certain seuil, il est marqu avec un
flag derreur et le protocole de la couche MAC le dtruira. Il serait trs intressant
dutiliser cette mesure dintensit du signal au niveau du gestionnaire dinterfaces
multiples. Cest pourquoi il faut tablir un change dinformation entre ces deux objets.
Dautre part, le gestionnaire dinterface multiple devra communiquer avec lobjet
MAC pour lui donner linterface utiliser. Lobjet MAC devra donc utiliser tel ou tel
protocole selon les dcisions prises au niveau du gestionnaire.
Lanalyse des besoins de lapplication peut passer par lagent metteur/receveur selon
le cas du nud en question. Le traitement sera videmment diffrent selon que cet agent
est un metteur ou un rcepteur puisque les ncessits ne sont pas les mmes (cf. agent
TCP dans Cellular IP partie 3 section 3.6.2.2). Ceci ncessite cependant une petite
intervention dans les fichiers correspondants afin de pouvoir extraire des informations
comme le dbit minimum et de pouvoir les communiquer au gestionnaire.
Lobjet gestionnaire sera implment par une classe drive de la classe Connector.
Elle contiendra donc les mthodes de communication avec les objets MAC, modle de
propagation radio et agent rcepteur/metteur ainsi que des mthodes de mesure et de
dcision. La classe MAC devra devenir une sous-classe dune classe au-dessus delle qui
permettra de changer de protocole daprs les donnes fournies par le gestionnaire. Cette
nouvelle classe sera celle qui instanciera tel ou tel protocole MAC.
Il suffira dajouter quelques mthodes au modle de propagation radio pour quil
puisse communiquer les informations pertinentes la classe gestionnaire. Par contre, il
faudra dfinir une chelle de graduation pour que les agents puissent exprimer les besoins
des applications. La classe Application se verra alors augmente dun nouvel attribut que
lagent du nud devra communiquer au gestionnaire.
4.4.3 Conclusion
La courte dure de mon stage ne ma malheureusement pas suffit pour commencer
limplmentation. Cest pourquoi les explications ci-dessus ne sont quune premire
vision de limplmentation de larchitecture dans NS-2 et viendra probablement tre
modifie.
Un autre problme se pose pour limplmentation de cette architecture ; pour pouvoir
utiliser Bluetooth ou mme les extensions Noah, Mobiwan ou CIMS (prsentes partie 3
section 3.6) il est ncessaire dutiliser la version 6 de NS-2. Or aujourdhui la version 8
est dj disponible. Cette nouvelle version comporte non seulement des outils
supplmentaires mais est beaucoup moins bugger. Il sera donc probable quil faille
travailler sur plusieurs versions au dpart de manire gnrique pour pouvoir utiliser le
plus dextensions possibles.
88
Conclusion
CONCLUSION
Dans ce rapport ont t dvelopps les problmes et les solutions lis la mobilit
dans lInternet daujourdhui travers divers organismes de recherche. Un ensemble de
ces propositions a t tudi dans les deux premires parties. Les solutions proposes ne
sont en gnral qu leur phase de spcification et sont donc en constante volution. Afin
dvaluer de tels protocoles, le simulateur rseau NS-2 est frquemment utilis. La
prsentation de ce simulateur a t faite dans la partie 3. Cette prsentation sest focalise
sur limplmentation existante et venir de la mobilit. La dernire partie du rapport
concerne plutt nos travaux venir, savoir limplmentation dune nouvelle
architecture pour grer plusieurs interfaces radio dans un mme quipement.
La gestion de la mobilit
Le protocole Mobile IP est la solution actuelle pour rsoudre les problmes de rupture
de communication durant les dplacements des nuds mobiles dans des rseaux IP. Ce
protocole permet donc aux nuds mobiles de se dplacer de rseaux en rseaux sans
rompre leurs sessions en cours. Le nud mobile obtient une nouvelle adresse temporaire
chaque entre dans un rseau visit. Cette adresse indique la position courante du nud
mobile dans lInternet. Il devra la communiquer son agent mre, agent qui se charge
dintercepter les paquets dans le rseau principal du nud mobile et de les lui transmettre
sa position courante dans lInternet.
Mobile IP existe en deux versions, MIPv4 et MIPv6, selon la version du protocole IP

utilis. La version 6 nest encore quun draft de lIETF (en cours de normalisation) alors
que la version 4 est un RFC de lIETF (normalise). MIPv6 offre beaucoup plus de
fonctionnalits que MIPv4, comme loptimisation de route ou la suppression dun agent
pour la mobilit (lagent visit). Par contre, la mise en uvre des optimisations offertes
par MIPv6 ncessite que tous les nuds qui communiquent avec un nud mobile
supportent des fonctionnalits comme la gestion de cache dassociation ou la gestion
den-tte de routage.
Bien que MIP permette des nuds mobiles de se dplacer tout en continuant leur
communication, des pertes de paquets ou des dsquencements peuvent avoir lieu. Ces
pertes peuvent se faire ressentir au niveau des applications temps rel comme de la vido
ou la voix sur IP. Pour rsoudre ces problmes, les groupes de travail Seamoby et
MobileIP de lIETF proposent des amliorations de la gestion de la mobilit et
particulirement du traitement du handoff (procdure de dplacement). Ces solutions sont
soit des amliorations directes MIP, soit lajout de nouveaux protocoles de gestion
dune mobilit locale (limit un domaine). Les amliorations apportes MIP
consistent en un change dinformations entre les anciens et nouveaux routeurs daccs
lors dun handoff. Cet change dinformation permet au nouveau routeur daccs
didentifier le nud mobile et de lui fournir un service plus rapidement. Lchange peut
avoir lieu avant mme que le nud mobile ne se dtache de son ancien routeur daccs,
par une anticipation du dplacement. Cette anticipation permet de raliser des fast
89
Conclusion
handoffs. Le bi casting est une autre solution qui a t prsente. Le bi casting est la
duplication du trafic destin un nud mobile son ancienne sa nouvelle localisation.
MIP hirarchique met en place une hirarchie des rseaux. LInternet est divis en
domaines. La mobilit lintrieur dun domaine est appele mobilit locale et la
mobilit entre domaines mobilit globale. MIP hirarchique cache les mouvements des
nuds mobiles lintrieur dun domaine. Le nud mobile doit juste communiquer son
entre dans un domaine son agent mre (et ventuellement ses correspondants), et
ensuite ses mouvements sont grs par le domaine.
Cellular IP est un autre protocole de gestion de la micro mobilit (mobilit locale un
domaine). Il gre aussi les mouvements lintrieur dun domaine et les cachent au reste
de lInternet. Cellular IP sinspire des systmes cellulaires en utilisant la pagination
(localisation des mobiles) et en faisant la distinction entre mobiles actifs et inactifs.
Linformation de routage est totalement distribue dans tous les nuds IP cellulaires.
Cellular IP est prvu pour fonctionner avec un grand nombre de mobile et grer les
handoffs de manire optimise. Cellular IP interagit avec MIP pour ce qui est de la
mobilit entre domaines.
Simulateur rseau NS-2
NS-2 est le simulateur rseau le plus utilis dans la communaut de recherche en
rseau. Il implmente en C++ et OTcl tout un ensemble de classes pour dfinir les
concepts de nuds, liaisons et agents. La structure dun nud est fortement inspire par
le modle en couche OSI. La mobilit a t introduite dans NS-2 dans sa version 2 par le
CMU. Au dpart, il sagissait uniquement de simuler des LAN ad hoc, cest--dire tous
les nuds de la simulation devaient tre mobiles. Plus tard est venue limplmentation de
MIPv4 qui a permis de faire des simulations sur des topologies avec la fois des nuds
mobiles et des nuds fixes. Plusieurs extensions sont notamment disponibles sur
diffrents sites de recherche qui implmente des protocoles particuliers, comme Cellular
IP ou MIPv6.
Perspectives
Ce stage de DEA avait pour objectif de faire ltat de lart sur la gestion actuelle de la
mobilit des htes. Ctait le premier pas dans un projet plus vaste sinscrivant dans un
projet RNRT [42]. Etant donn lmergence de diverses et nombreuses technologies de
communication, il est probable que dans un proche futur un hte ait plusieurs interfaces
de communication. Il devient alors impratif quun tel quipement puisse grer de
manire intelligente ses interfaces de communication. Pour une gestion efficace des
interfaces, on se propose de rajouter une couche dans larchitecture de la pile rseau dun
hte. Cette couche gestionnaire dinterfaces devra prendre en compte les besoins des
applications, dterminer quelles interfaces sont utilisables, quels sont leurs cots (en
terme de dbit, dabonnement) et slectionner linterface la plus approprie.
Limplmentation de cette nouvelle couche se fera dans un premier temps dans le

simulateur rseau NS-2. Elle sera intgre dans la structure dun nud et utiliser les
modle de propagation disponible dans NS-2. Ensuite elle intgrera la pile rseau dun
terminal.
90
Rfrences bibliographiques
REFERENCE BIBLIOGRAPHIQUES
[1] C. Perkins, Mobile IP, Internet Engineering Task Force Request For Comment 2002, octobre 1996.
[2] D. Johnson, C. Perkins, Mobility support in IPv6, Internet Engineering Task Force draft-ietfmobileip-ipv6-13.txt, Novembre 2000.
[3] J. Manner, M. Kojo, T. Suihko, P. Eardley, D. Wisely, R. Hancock, N. Georganopoulos, Mobility
Related Terminology, Internet Engineering Task Force draft-manner-seamoby-terms-01.txt, Mai
2001.
[4] K. El-Malki, P. Calhoun, T. Hiller, J. Kempf, P.J. McCann, A. Singh, H. Soliman, S. Thalanany, Low
latency Handoffs in Mobile IPv4, Internet Engineering Task Force draft-ietf-mobileiplowlatencyhandoffs-v4-00.txt, Fvrier 2001.
[5] G. Tsirtsis, A. Yegin, C. Perkins, G. Dommety, K. El-Malki, M. Khalil, Fast Handovers for Mobile
IPv6, Internet Engineering Task Force draft-ietf-mobileip-fast-mipv6-00.txt, Fvrier 2001.
[6] O. Levkowetz, P. Calhoun, G. Kenward, H. Syed, J. Manner, M. Nakhjiri, G. Krishnamurthi, R.
Koodli, K. Atwald, M. Thomas, M. Horan, P. Neumiller, Problem Description: Reasons For Doing
Context Transfers Between Nodes in an IP Access Network, Internet Engineering Task Force draftietf-seamoby-context-transfer-problem-stat-00.txt, Fvrier 2001.
[7] R. Koodli, C. Perkins, A Context Transfer Framework for Seamless Mobility, Internet Engineering
Task Force draft-koodli-seamoby-ctv6-00.txt, Fvrier 2001.
[8] G. Krishnamurthi, R. Chalmers, C. Perkins, Buffer Management for Smooth Handovers in IPv6,
Internet Engineering Task Force draft-govind-seamoby-buffer6-00.txt, Fvrier 2001.
[9] Y. Ezaki, Y. Imai, Mobile IP6 handoff by Explicit Multicast, Internet Engineering Task Force draftezaki-handoff-xcast-00.txt, Novembre 2000.
[10] Small Group Multicast (sgm) BOF agenda, http://www.ietf.org/ietf/00jul/sgm-agenda.txt.
[11] E. Gustafsson, A. Jonsson, E. Perkins, Mobile IP Regional Registration, Internet Engineering Task
Force draft-ietf-mobileip-reg-tunnel-04.txt, Mai 2001.
[12] H. Soliman, C. Castelluccia, K. El-Malki, L. Bellier, Hierarchical MIPv6 mobility management,
Internet Engineering Task Force draft-ietf-mobileip-hmipv6-03.txt, Fvrier 2001.
[13] C. Perkins, P. Calhoun, AAA Registration Keys for Mobile IP, Internet Engineering Task Force
draft-ietf-mobileip-aaa-key-04.txt, March 2001.
[14] A. Campbell, J. Gomez, C-Y. Wan, S. Kim, Z. Turanyi, A. Valko, Cellular IP, Internet Engineering
Task Force draft-ietf-mobileip-cellularip-00.txt, Dcembre 1999.
[15] A. Valko, Cellular IP: A New Approach to Internet Host Mobility
[16] A. Campbell, J. Gomez, S. Kim, A. Valko, C-Y. Wan, Z. Turanyi, Design, Implementation, and
Evaluation of Cellular IP, IEEE Personal Communications, Aot 2000.
[17] Z. Shelby, D. Gatzounas, A. Campbell, C-Y. Wan, Cellular IPv6, Internet Engineering Task Force
draft-shelby-seamoby-cellularipv6-00.txt, Novembre 2000.
[18] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, L. Salgarelli, IP Micro-mobility support using
HAWAII, Internet Engineering Task Force draft-ietf-mobileip-hawaii-00, Juin 1999.
[19] S. Tabbane, Rseaux mobiles, rseaux et tlcommunications, dition Hermes, 1997.
[20] X. Lagrange, Rseaux GSM, cinquime dition, dition Hermes, Septembre 2000.
[21] F. Muratore, UMTS Mobile Communications for the Future, Janvier 2001.
[22] H. Kaaranen, S. Naghia, L. Laitinen, A. Ahtiainen, UMTS Networks: Architecture, Mobility and
Services, 2001.
91
Rfrences bibliographiques
[23] J.P. Castro, The UMTS Network and Radio Access Technology: Air Interface Techniques for Future
Mobile Systems, Avril 2001.
[24] UMTS, http://www.umts-forum.org.
[25] N. Montavont, T. Noel, Survey of IP Handoffs in Wireless Network, article en cours de soumission,
Juin 2001.
[26] Data processing Open System Interconnexion Basic Reference Model, ISO IS 7498, 1984.
[27] D.C. Plummer, An Ethernet Address Resolution Protocol, Internet Engineering Task Force Request
For Comment 826, Novembre 1982.
[28] Finlayson, Mann, Mogul, Theimer, A Reverse Address Resolution Protocol, Internet Engineering
Task Force Request For Comment 903, Juin 1984.
[29] Universit de Californe du Sud, Internet Protocol, Internet Engineering Task Force Request For
Comment 760, Janvier 1980.
[30] Univesit de Californe du Sud, Transmission Control Protocol, Internet Engineering Task Force
Request For Comment 761, Janvier 1980.
[31] J. Postel, User Datagram Protocol, Internet Engineering Task Force Request For Comment 768,
Aot 1980.
[32] R. Droms, Dynamic Host Configuration Protocol, Internet Engineering Task Force Request For
Comment 2131, Mars 1997.
[33] T. Narten, E. Nordmark, W. Simpson, Neighbor Discovery for IP Version 6, Internet Engineering
Task Force Request For Comment 2461, Dcembre 1998.
[34] S. Thomson, T. Narten, IPv6 Stateless Address Autoconfiguration, Internet Engineering Task Force
Request for Comments 2462, Dcembre 1998.
[35] P. Mockapetris, Domain Names -- Concepts and Facilities, Internet Engineering Task Force Request
for Comment 1034, Novembre 1987.
[36] P. Mockapetris, Domain Names -- Implementation and Specification, Internet Engineering Task
Force Request for Comment 1035, Novembre 1987.
[37] P. Furguson, D. Senie, Network Ingress Filtering: Defeating Denial of Service Attacks which employ
IP Source Address Spoofing, Internet Engineering Task Force Request for Comment 2827, Mai 2000.
[38] Norme IEEE 802.11 : IEEE Std 802.11-1999.
[39] Norme IEEE 802.3 : IEEE Std 802.3ad-2000.
[40] Norme HiperLan2 : ETSI TR 101 031 v2.2.1, Janvier 1999.
[41] Norme Bluetooth : Specification of the Blutetooth System, v1.1, Fvrier 2001.
[42] RNRT, Rseau National de Recherche en Tlcommunication, http://www.telecom.gouv.fr/rnrt
[43] M. Gondran, M. Minoux, Graphes et algorithmes, dition Eyrolles, 1979.
[44] D. Comer, TCP/IP : Architecture, Protocoles Applications, dition InterEditions, 1992.
[45] D. Estrin, M. Handley, J. Heidemann, S. McCanne, Y. Xu, H. Yu, Network Visualization with the
VINT Network Animator NAM, Mars 1999.
[46] Universit de Californie du Sud ISI, Virtual InterNetwork Testbed (VINT): methods ans system, 1996.
[47] K. Calvert, E.W. Zegura, GT-ITM : Georgia Tech Internetwork Topologie Models, Technical report,
Georgia Institute of Technology, College of computing, 1996.
92
Rfrences Internet
REFERENCES INTERNET
IPv6
IP Version 6 (IPv6) : http://playground.sun.com/ipv6/

Recherche G6 : http://www.urec.fr/IPng/G6.html
Projet6 rseau Ipv6 sous linux : http://project6.ferrara.linux.it/
IPv6 : la nouvelle gnration internet : http://www.ipv6.org/
Home page du 6bone : http://www-cnr.lbl.gov/6bone/
Projet Kame : implmentation de la pile IPv6 pour FreeBSD :
http://www.kame.net/
Prsentation dIPv6 : http://www.data.com/issue/991021/ipv6.html
Documentation IPv6
Aperu dIPv6 : http://playground.sun.com/pub/ipng/html/INET-IPng-Paper.html
Tout sur IPv6 : http://www.networkmagazine.com/issue/991021/ipv6.html
Linux et IPv6 : http://www.bieringer.de/linux/
Equipes de recherche
IETF Mobile IP : http://www.ietf.org/html.charters/mobileip-charter.html
Cellular IP luniversit de Columbie : http://comet.ctr.columbia.edu/cellularip/
Projet CMU Monarch : http://www.monarch.cs.cmu.edu/
micro-mobilit HAWAII IP (Lucent Bell Labs) : http://www.belllabs.com/user/ramjee/
SUN : Mobile IP pour Solaris / Linux : http://playground.sun.com/pub/mobile-ip/
Groupe de recherche rseau du LBNL : http://www-nrg.ee.lbl.gov/
Groupe de recherche rseau de lULP Strasbourg : http://www-r2.u-strasbg.fr/
Groupe de recherche rseau de lENST : http://www.enst-bretagne.fr
At&t lab : http://www.att.com
ACIRI : http://www.aciri.org
Implmentations Mobile IP
LancasterIPv6 Mobilit (Linux) : http://www.cs-ipv6.lancs.ac.uk/MobileIP/
HUT Mobile IP (Linux) : http://www.cs.hut.fi/Research/Dynamics/
Mobile-IP par lunivesit de ltat du Portland (sous BSD) :
http://www.cs.pdx.edu/research/SMN/index.html
CMU Mobile-IP (sous BSD) : http://www.monarch.cs.cmu.edu/software.html
SUN Mobiule-IP (sous Solaris) : http://playground.sun.com/pub/mobileip/index.html
Mobile-IP de luniversit de Bucharest (NT) : http://mip-nt.aii.pub.ro/
Evnements dans la mobilit
Workshop de MANET :
93
Rfrences Internet
http://www.isr.umd.edu/Courses/Workshops/MANET/program.html
IFIP Broadland Communications 99 : http://www.ee.ust.hk/~bc99/
Bibliothque WWW : Mobile and Wireless Computing :
http://gunpowder.stanford.edu/mobile/
Tutorials et rsum
Tutorial : Mobile IP : http://www.computer.org/internet/v2n1/perkins.htm
Rsum de Mobile IP standard :
http://www.neda.com/mobileIpSurvey/html/mobileIP.html
Integration dUMTS et de B-ISDN :
http://www.ee.surrey.ac.uk/Personal/L.Wood/UMTS/
Tutorial: Mobile IP : http://computer.org/internet/v2n1/perkins.htm
G6 IPv6 - Prsentations Recherche Mobilit : http://www.ipv6.ustrasbg.fr/G6Recherche/
Sans fil
Communications sans fil et mobilit :
http://http.cs.berkeley.edu/~randy/Courses/CS294.S96/CS294-7.S96.html
IEEE P802.11, groupe de travail pour des LAN sans fil :
http://grouper.ieee.org/groups/802/11/
FranceNet - intgrateur Internet franais : http://www.fluxus.net/HomePage/
IEEE P802.15 groupe de travail pour des aires de rseaux personnels sans fil :
http://grouper.ieee.org/groups/802/15/
IEEE EUI64 Standard : http://grouper.ieee.org/groups/802/15/
ETSI: TIPHON Homepage : http://www.etsi.org/tiphon/tiphon.htm
Qos dans IP: George Fankhauser : http://www.tik.ee.ethz.ch/~gfa/
Organisations
Programmes de R&D europen : http://www.cordis.lu/en/home.html
Commission europenne : http://www.cordis.lu/en/home.html
Home Page de lIETF: http://www.ietf.org/
IPv6 Forum : http://www.ipv6forum.com/
W3C : http://www.w3.org/
Forum WAP : http://www.wapforum.org/
Homepage de 3GPP : http://www.wapforum.org/
Forum de linternet sans fil mobile : http://www.mwif.org/
EUROCONTROL : http://www.eurocontrol.fr/
TAROT : http://www.eurocontrol.fr/
Renater : http://www.renater.fr/
IEE: Institution of Electrical Engineers : http://www.iee.org.uk/
AFNIC: Association Franaise pour le Nommage Internet en Coopration :
http://g6.nic.fr/
ETSI : http://www.etsi.org/
EIA: Electronic Industries Alliance : http://www.eia.org/
IMT-2000 : http://www.itu.int/imt/
IEEE Communications Society : http://www.comsoc.org/index.html
94
Rfrences Internet
IEEE Standards : http://standards.ieee.org/

IEEE Computer Society : http://www.computer.org/
ITU : http://www.itu.int/home/index.html
SIGCOMM : http://www.acm.org/sigcomm/
ACM : http://www.acm.org/
ACTS Information Window : http://www.uk.infowin.org/ACTS/
CaberNet : http://www.laas.research.ec.org/cabernet/
Simulateur rseau
NS
HomePage de NS : http://www.isi.edu/nsnam/ns/index.html
NAM: Network Animator : http://www.isi.edu/nsnam/nam/index.html
OTcl- MIT Object Tcl : http://www.isi.edu/nsnam/otcl/index.html
NS : Implementation dOSPF : http://networks.ecse.rpi.edu/~sunmin/rtProtoLS/
WirelessNetwork Simulator (WiNS) : http://http.cs.berkeley.edu/~gnguyen/ns/
MetricomNetwork Simulation avec NS :
http://http.cs.berkeley.edu/~rfromm/Courses/SP96/cs294-7/
LBNL Network Simulator, ns version 1 : http://www-nrg.ee.lbl.gov/ns/
Topologie rseau
Gnrateur de topologie pour des simulateurs rseau :
http://www.cs.uoregon.edu/~zappala/topology/
GT-ITM: modlisation de topologie inter rseau :
http://www.cc.gatech.edu/projects/gtitm/
Autres Simulateurs
Simulation pour des mcanismes de routage : http://wwwnrg.ee.lbl.gov/collapse.html
Simulator rseau cnet (v1.4) : http://www.cs.uwa.edu.au/pls/cnet/
STCP: ATM et IP : http://lrcwww.epfl.ch/~manthorp/stcp/
Simulation de qualit de service IP : http://bacon.gmu.edu/qosip/
Software de simulation : http://www.topology.org/soft/sim.html
Simulateur REAL : http://www.cs.cornell.edu/skeshav/real/overviaw.html
Tcl/Tk
Programmation en Tcl et Tk : http://www.beedub.com/book/2nd/

Tcl/Tk Consortium : http://www.tclconsortium.org/index.html
Manuel Tcl8.0/Tk8.0 : http://www.elf.org/tcltk-man-html/contents.htm
C++
Stroustrup: The C++ Programming Language (Third Edition) :

http://www.research.att.com/~bs/3rd.html
The ISO/ANSI C++ Draft : http://www.cygnus.com/misc/wp/
95
Rfrences Internet
Entreprise
Motorola : http://www.motorola.fr
Motorola Bluetooth : http://www.mot.com/bluetooth/index.html
Ericsson : http://www.ericsson.de/
France Telecom : http://www.francetelecom.fr
Cisco : http://www.cisco.com
Sun Microsystem : http://www.sun.com
96
Glossaire
GLOSSAIRE
Agent visit
passerelle
Domaine
Agent Visit rgional
Cl de registration
Registration
rgionale
Registration-mre
Handoff soft
Handoff hard
Interface RP
Nud servant des
paquets de
donnes (PDSN)
Nud dun rseau
radio (RNN)
Gateway FA (GFA)
Agent Visit qui a une adresse IP routable publique
Collection de rseaux qui partagent une administration

rseau commune
Regional Foreign
Agent Visit qui peut tre la cible dune demande de
Agent
registration rgionale
Cl utilise par les nuds mobiles et les agents de
Registration key
mobilit pour scuriser certains messages de contrle
relatifs MIP
Un nud mobile fait une registration locale dans un
domaine visit en envoyant un Regional Registration
Regional registration
Request au GFA et reoit un Regional Registration Reply
en retour
Registration, excute par lagent mre et lagent visit
Home registration
passerelle utilis les spcifications du RFC 2002 (MIPv4)
Processus par lequel un terminal mobile CDMA est
transfr entre une ou un ensemble de point daccs
un(e) autre dans un rseau daccs. Un handoff soft est an
Soft handoff
gnral trs rapide (de lordre de 20ms) et une faible
probabilit de rduire la connexion temps rel
Processus par lequel un terminal mobile est transfr entre
un fournisseur de service cellulaire et un autre, ou entre
deux routeurs daccs qui ne partagent pas directement
Hard handoff
une connexion de fournisseur de rseau. Un handoff hard
a une grande probabilit de rduction de connexion et est
assez lent (100ms ou plus)
Interface entre un nud dune rseau radio et un nud
RP interface
servant des paquets de donnes
Nud responsable de ltablissement, du maintient et de
Packet Data Serving
la terminaison de la couche liaison au nud mobile
Node
Domain
Radio Network Node
Tunnel GRE
GRE tunnel
Data-connected
Data-connected
Nud responsable du relais du protocole de la couche

liaison entre le nud mobile et le PDSN correspondant
Norme de tunnel (voir suns SKIP Firewall Traversal
for Mobile IP , RFC 2356, 1998)
Connexion oriente donnes
97
Glossaire
Agent de mobilit
Anchor Agent Visit
Roaming
Handover ou
handoff
Handoff de la couche
2
Handoff entre
routeur daccs
Handoff lintrieur
dun rseau daccs
Handoff entre rseau
daccs
Handoff intratechnologie
Handoff intertechnologie
Handoff horizontal
Handoff vertical
Handoff proactif
Mode veille
Mode veille de semicoute
Mobility agent
Point daccs sans fil au rseau

FA avec une adresse IP publique qui joue le rle de point
dancrage quand un mobile se dplace un nouvel agent
visit. Jusqu ce que la registration soit complte,
Anchor Foreign Agent
lAnchor FA supporte une registration locale quand le
nud mobile change son point dattache lagent visit
voisin
Terme bas sur les oprateurs qui implique les accords
Roaming
entre diffrents oprateurs pour permettre mobile
davoir une connexion dans le rseau tranger
Processus enclench quand un mobile actif change son
Handover or handoff point dattache au rseau sans quune reconfiguration de
la part de lutilisateur nait lieu
Opration effectue par un mobile qui change de point
daccs sans changer de routeur daccs. Ce type de
Layer 2 handoff
handoff est transparent au routage de la couche IP
Handoff qui change linterface rseau du routeur daccs
Intra-AR handover par laquelle il communique avec le mobile. Ladresse IP
du mobile ne change pas
Opration effectue quand le mobile change de routeur
daccs en restant dans le mme rseau daccs. Ce
Intra-AN handover handoff est invisible pour un point extrieur au sousrseau. Ladresse du mobile ne change toujours pas, mais
le chemin pour latteindre est modifi
Dplacement du mobile hors du rseau daccs
Inter-AN handover
obtention dune nouvelle adresse IP pour le mobile
Intra-technology
Handoff entre des quipements de mme technologies
handover
Inter-technology
Handoff entre quipements de technologies diffrentes
handover
Handoff ralis par le mobile sur une mme interface
cest--dire que le mobile communique avec le rseau
Horizontal handover
daccs avec la mme interface avant et aprs le handoff
(gnralement cest un handoff intra-technologie)
Handoff ralis par le mobile entre deux de ses interfaces
Vertical handover
(gnralement handoff inter-technologie)
Proactive handover = fast handoff ?
Etat du mobile dans lequel il restreint sa capacit
recevoir un trafic IP normal en rduisant le monitoring du
Dormant mode
canal radio. Cet tat permet au mobile dconomiser son
nergie et dallger la charge de signalisation sur le rseau
Implmentation du mode de veille dans lequel le mobile
Time-slotted dormant alterne des priodes dcoute et de non-coute du trafic.
Cette implmentation est gnralement synchronise
mode
avec le rseau
98
Glossaire
Pagination
Paging
Aire de pagination
Paging area
Canal de pagination
Paging channel
Canal du trafic
Channel traffic
Mise jour de
localisation
Location updating
Registrations daire
de pagination
Paging area
registrations
Diff-serv
Diff-serv
Int-serv
Int-serv
Handoff contrl par

le mobile
Handoff contrl par
le rseau
Handoff assist par
le mobile
Mobile-controlled
handover
Network-controlled
handover
Mobile assisted
handover
Handoff assist par

le rseau
Network-assisted
handover
Handoff backward
Backward handover
Signalisation utilise pour localiser un mobile en mode

veille et tablir la connexion du dernier saut lorsquun
trafic arrive pour le mobile. Un mobile peut entrer dans ce
mode quand il ne gnre pas de trafic IP pour ses donnes
(aucunes donnes mettre et aucunes donnes
recevoir). Le protocole de localisation est dpendant du
type de liaison radio utilis.
OU : procdure pour mettre un mobile idle dans un mode
actif
Ensemble de points daccs radio qui effectuent une
signalisation pour localiser le mobile. Le mobile
ninforme de sa localisation que quand il change daire.
Une aire de pagination ne correspond pas forcment un
sous-rseau
Canal radio ddi la signalisation des mobiles en mode
veille dans le but du pagination. Actuellement, le
protocole utilis est dpendant de la technologie radio
Canal utilis pour le trafic IP li un mobile actif. Pour
certains protocoles radio, cest le seul canal disponible
Procdure ralise par le mobile par laquelle il informe le
rseau daccs quil sest dplac dans une nouvelle aire
de pagination
Signalisation dun nud mobile en mode veille au rseau
quand le nud mobile traverse une aire de pagination
pour informer sa prsence dans la nouvelle aire
Procure des services un mobile inscrit et un traitement
diffrents des paquets dans les routeurs. Diff-serv place la
responsabilit sur le rseau qui gre la politique, les
comptes
Utilise la signalisation RSVP pour installer des dtails sur
le chemin de routage dun trafic destination dun
utilisateur
Cest le mobile qui a le plus important contrle sur le
processus de handoff
Cest le rseau qui a le plus important contrle sur le
processus de handoff
Les informations et les mesures effectues au mobile sont
utilises pour dcider de lexcution du handoff
Handoff pour lequel le rseau daccs collecte des
informations qui peuvent tre utilises dans la dcision de
handoff
Handoff initialis par lancien router daccs, ou alors par
le mobile travers lancien routeur daccs
99
Glossaire
Handoff forward
Handoff plannifi
Handoff non
plannifi
Handoff initialis
par le rseau
Handoff initialis
par le mobile
Handoff makebefore-break
Handoff breakbefore-make
Smooth handoff
Fast handoff
Seamless handoff
Latence du handoff
Handoff initialis par le nouveau routeur daccs ou par le

mobile travers le nouveau routeur daccs
Handoff proactif (prvu) dans lequel une partie de la
signalisation peut tre faite avant la connexion du mobile
Planned handover
au nouveau routeur daccs (construction dun tunnel
entre lancien et le nouveau routeur daccs)
Handoff ractif (non prvu) o aucune signalisation nest
Unplanned handover faite avant que le mobile ne se soit dplac de lancien au
nouveau routeur
Le rseau est le seul qui prend la dcision que le mobile
Network-initiated
doit faire un handoff en grant une liste de routeurs
handover
daccs candidats
Le mobile est le seul qui prend la premire dcision de
faire un handoff - Dcision de handoff prise sur rception
Mobile-initiated
dun Neighbor Advertisement ou sur des informations de
handover
plus bas niveau comme le SIR
Pendant un handoff make-before-break, le mobile peut
Make-before-break
communiquer simultanment avec lancien et le nouveau
handover
routeur daccs
Durant un handoff break-before-make, le mobile ne peut
Break-before-make
pas communiquer simultanment avec les deux routeurs
handover
daccs
Handoff qui a pour but principal de minimiser la perte de
Smooth handoff
paquets, sans condition sur le dlai de propagation des
paquets
Handoff qui a pour but principal de minimiser les dlais,
Fast handoff
sans conditions sur le nombre de paquets perdus
La dfinition absolue est un handoff o il ny a pas de
changement dans la capacit, la scurit ou la qualit du
service. En pratique, une dgradation est tout de mme
Seamless handoff
observe la dfinition pratique est que dautres
protocoles, applications ou utilisateurs ne remarquent pas
ces dgradations
Le temps de latence du handoff est la diffrence de temps
entre le dernier moment o le mobile peut recevoir et
mettre des paquets IP travers lancien routeur daccs
et le premier moment o il peut recevoir et mettre des
Handover latency
paquets au nouveau routeur daccs cest le temps
pendant lequel il ne peut pas recevoir et mettre un trafic
IP
Forward handover
100
Glossaire
Micro diversit (ref

L1/L2)
Micro diversity
Macro diversit (ref

L1/L2)
Macro diversity
Diversit IP (ref L3)
IP diversity
Mode actif
Active mode
Mode idle
Idle mode
Etat dtach
Detached state
Mobilit utilisateur
User mobility
Mobilit personnelle
Personal mobility
Mobilit dhost
Host mobility
Macro mobilit
Macro mobility
Micro mobilit
Micro mobility
Adresse temporaire
Care-of Address
Agent mre
Home Agent
Terme employ pour le cas o par exemple deux antennes

sur le mme transmetteur mettraient le mme signal
prenant deux chemins diffrents pour parer aux pertes
Cette diversit a lieue quand la duplication est mise en
place sur plusieurs points daccs pas forcment sur le
mme routeur daccs. Ceci procure un support pour la
couche rseau pour dplacer des frames radio entre points
daccs et un point central combin
Dcoupage et recombinage des paquets la couche IP
Un mobile est en mode actif quand le rseau daccs
connat le routeur daccs du mobile et quand le mobile
met et reoit un trafic IP. Le lien daccs peut ne pas tre
actif, mais la couche radio peut tablir un liaison sans
utiliser la couche rseau. Le mobile a une adresse IP
assigne
Mode dans lequel le rseau daccs connat laire de
pagination du mobile, mais o le mobile na pas de lien
daccs et donc les paquets ne peuvent pas tre dlivrs au
mobile sans un pagination du rseau daccs
Etat dans lequel le mobile nest ni en mode actif, ni en
mode idle. Le nud mobile na pas dadresse IP dans le
rseau daccs
Rfre la capacit dun utilisateur daccder des
services partir de diffrents host physiques
Complte la mobilit utilisateur avec la capacit de suivre
les positions de lutilisateur et fournir l'emplacement
actuel d'utilisateurs pour permettre des sessions d'tre
lances par l'utilisateur par n'importe qui sur n'importe
quel autre rseau
Rfre aux fonctions pour permettre au host mobile de
changer leur point dattache au rseau sans interrompre
les communications de ce host
Rfre une mobilit dans une vaste aire. Ceci inclut le
support de la mobilit et les procdures de registration
dadresse IP lorsque le host mobile se dplace entre
diffrents domaines IP
Rfre un mobilit dans une petite aire. Habituellement
cest une mobilit dans un domaine IP
adresse temporaire du mobile attribue dans le rseau
visit
routeur Ipv4 avec une interface sur le mme lien que le
mobile (dans le rseau mre)
101
Glossaire
Ancien routeur
daccs
Cellule radio
Domaine
administratif
passerelle daccs
rseau
Hte mobile
Lien daccs
Micro flot
Nud mobile
Nouveau routeur
daccs
Point daccs
Rseau daccs
Routeur daccs
Routeur daccs
candidat
Routeur daccs qui offrait une connectivit au host

mobile avant un handoff
Aire gographique dans laquelle un point daccs procure
Radio Cell
une couverture radio
Administrative
Collection de rseaux sous le mme control administratif
Domain
et regroup ensemble pour des buts administratifs
Routeur de rseau daccs qui spare un rseau daccs
dautres rseaux IP. Un routeur daccs et une passerelle
Access Network
de rseau daccs peuvent tre situ physiquement sur le
Gateway
mme nud
Mobile Host
Nud mobile qui est un host terminal
Lien du dernier saut entre un hte mobile et un routeur
daccs. Cest le mdium travers lequel un point daccs
Access Link
et un quipement de la couche 2 attach au mobile
peuvent communiquer au niveau de la couche de liaison
Unit fondamentale dun service IP = plus petite partie
Microflow
dun trafic dune mobile ayant un contexte distinct
Nud Ipv4 qui peut changer de points dattachement sur
lInternet tout en maintenant les communications en cours
Mobile Node (MN)
(et en utilisant uniquement son adresse principale). Un
MN peut avoie des fonctionnalits de routage
New access router
Routeur daccs qui offrait une connectivit au host
(nAR)
mobile aprs un handoff
Equipement de niveau 2 connect un ou plusieurs
routeurs daccs et qui offre une connexion sans fil au
Access Point (AP) host mobile. Quelques fois on utilise les termes de point
daccs ou point daccs transceiver. Il peut tre une
partie dun routeur ou sur un quipement spar
Rseau IP qui inclue au moins un routeur de rseau
Access Network (AN)
daccs
Un routeur de rseau daccs est situ sur une branche
dun rseau daccs et est connect un ou plusieurs
Access Router (AR) points daccs. Un routeur daccs offre une connexion IP
aux host mobiles, fonctionnant comme un routeur par
dfaut pour le(s) mobile(s) quil dsert
Routeur daccs candidat sur lequel le host mobile
Candidate Access
pourrait se dplacer. Un schma de handoff peut supporter
Router
plusieurs candidats
Old access router
102
Glossaire
Routeur daccs offrant actuellement une connexion au

host mobile. Cest habituellement le point de dpart dun
Routeur daccs de
Serving Access Router host mobile quand il se dirige vers un nouveau routeur
service
daccs. Un mobile peut avoir plusieurs routeurs daccs
de service un moment donn
Routeur IP dans un rseau daccs. Peut inclure des
Access Network
Routeur de rseau
fonctionnalits spcifiques un rseau daccs comme la
Router (ANR)
daccs
mobilit, QoS
Un seamless handoff est thoriquement un handoff pour
lequel il ny a aucun changement dans la capacit de
service , scurit ou qualit. Pratiquement, cest un
Seamless handoff
Seamless handoff
handoff pour lequel un utilisateur ne remarque aucun
changement
Mcanisme pour tablir les conditions suffisantes un ou
plusieurs routeurs daccs pour entirement supporter le
microflot dun mobile. Aprs ce transfert, un routeur
Context transfer
Transfert de contexte
daccs est capable de grer le trafic dun mobile sans
interruption
103

Mobilité

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mobilité

Transféré par

Droits d'auteur :

Formats disponibles

Nicolas Montavont

LA MOBILITE DANS LES RESEAUX IP

Matre de stage : Thomas Nol Matre de confrences

Table des matires

TABLES DES MATIERES

Table des matires

Liste des illustrations

LISTE DES ILLUSTRATIONS

Liste des illustrations

Figure 4-4 : dbit et porte de diffrentes modes de connexion ....................................... 86

Liste des tableaux

LISTE DES TABLEAUX

Utiliser les nouveaux protocoles afin de supporter de plus en plus de rseaux et

Exprimenter de nouvelles solutions et des nouvelles fonctionnalits. La

IETF : Internet Engeenering Task Force, http://www.ietf.org

MIMP : Multiple Interfaces Management Protocol, protocole de gestion dinterfaces multiples.

Le terme de mobilit dfini la situation intermdiaire entre le nomadisme et les

1.2.1 Modle OSI

Couche n7 : comprend les programmes dapplication qui utilisent

Couche n6 : est destine supporter les fonctions dont beaucoup

Couche n5 : dfinit la manire dont les protocoles peuvent tre

Couche n4 : assure un contrle de bout en bout, en permettant

Couche n2 : soccupe de lacheminement de trames de donnes

Couche n1 : soccupe de la connexion physique dune machine

Figure 1-1 : modle des couches OSI

1.2.2 Nouveaux quipements

Dans Mobile IP, quatre nouveaux acteurs sont dfinis :

Noeud mobile : quipement IP qui est capable de se dplacer sur Internet et

Point daccs : quipement intermdiaire entre le rseau filaire et le noeud

Figure 1-2 : architecture de base

1.3.1 Dcouverte des agents de mobilit

1.3.2 Enregistrement auprs de lagent mre

TCP : Transmission Control Protocol

Ton adresse IP est

Figure 1-3 : configuration DHCP

Figure 1-4 : enregistrement v4

UDP : User Data Protocol

Figure 1-5 : ds-enregistrement auprs de lagent mre

Figure 1-6 : routage triangulaire : du correspondant au mobile

Figure 1-7 : routage triangulaire : du mobile au correspondant

Une nouvelle version du protocole IP est en train dmerger depuis quelques

1.4.1 Fonctionnalits requises

1.4.2 Dcouverte des routeurs daccs

Figure 1-8 : communication v6

HANDOFF ET MICRO MOBILITE

Partie 2 : Handoff et Micro Mobilit

2 HANDOFF ET MICRO MOBILITE

IETF : Internet Engeenering Task Force, http://www.ietf.org

Partie 2 : Handoff et Micro Mobilit

Handoff intra-routeur daccs : handoff gnr par le changement

Handoff lintrieur dun rseau daccs : Opration effectue quand le

Handoff entre rseaux daccs : Dplacement du mobile hors du rseau

Les travaux de recherche concerne surtout lamlioration du dernier type de handoff,

Partie 2 : Handoff et Micro Mobilit

Handoff intra-routeur daccs

Figure 2-1 : niveaux du handoff

Smooth handoff : handoff qui a pour but principal de minimiser la perte de

Seamless handoff : la dfinition absolue est un handoff o il ny a pas de

Partie 2 : Handoff et Micro Mobilit

changement dans la capacit, la scurit ou la qualit du service. En pratique,

Partie 2 : Handoff et Micro Mobilit

des procdures de synchronisation. La dtection de mouvement au niveau 3 joue un rle

Proxy Router Advertisement : envoy par lancien AV/RA un nud mobile