Vous êtes sur la page 1sur 132

UNIVERSITE LIBANAISE

(Facult de Gnie)

UNIVERSITE SAINT-JOSEPH
(Facult d'Ingnierie)

Sous l'gide de l'Agence Universitaire de la Francophonie


AUF
Diplme d'Etudes Approfondies
Rseaux de tlcommunications

Services de Mobile IP au dessus de MPLS


Par

Lina El-Mekkaoui

Encadr par : M. Mahmoud Doughan

Soutenance le Lundi 22/12/2003 devant le jury compos de


MM. Samir Tohm
Mohamad Zoater
Wajdi Najem
Imad Mougharbel
Nicolas Rouhana
Mahmoud Doughan
Maroun Chamoun

Prsident
Membre
Membre
Membre
Membre
Membre
Membre

Table des matires

LISTE DES FIGURES

........................................................................................... V

LISTE DES ABBREVIATIONS ................................................................................. VII


INTRODUCTION GENERALE................................................................................. XII

Chapitre I : Mobililit IP, transition de IPv4 IPv6

PROBLEMES DE LA MOBILITE IP..................................................................... 1

II

MOBILE IP VERSION 4 ......................................................................................... 2


II.1
II.2

Infrastructure ........................................................................................................................ 3
Fonctionnement du protocole.......................................................................................... 3
II.2.1 Principe de base ..................................................................................................... 3
II.2.2 Adresse temporaire ............................................................................................... 4
II.2.3 Encapsulation IP dans IP..................................................................................... 4
II.2.4 Dcouverte des FAs et procdure denregistrement ................................... 5
II.2.5 Extensions ............................................................................................................... 7
II.2.6 Routage .................................................................................................................... 7

III

PROBLEMES PRINCIPAUX DES MECANISMES DE MOBILE IPV4......... 9

IV

MOBILE IP VERSION 6 ....................................................................................... 9


IV.1
IV.2
IV.3
IV.4

Infrastructure ...................................................................................................................... 10
Diffrences avec Mobile IPv4........................................................................................ 10
Messages utiliss ............................................................................................................... 11
Fonctionnement de Mobile IPv6 .................................................................................. 11
IV.4.1 Enregistrement auprs du HA.......................................................................... 11
IV.4.2 Routage triangulaire ........................................................................................... 12
IV.4.3 Optimisation de routage .................................................................................... 12
IV.4.4 Dtection du HA .................................................................................................. 12

CONCLUSION

.......................................................................................... 13

Chapitre II :MPLS, Multi Protocol Label Switching

14

ORIGINES DE MPLS .......................................................................................... 15

II

OBJECTIFS DE MPLS .......................................................................................... 15

III PRESENTATION DE LA TECHNIQUE MPLS ................................................ 16


III.1 Modle architectural.......................................................................................................... 16

II

III.2
III.3
III.4
III.5

Codage et hirarchie dtiquettes, agrgation ........................................................... 18


Distribution dtiquettes .................................................................................................. 20
Route explicite.................................................................................................................... 21
Route base contrainte ..................................................................................................... 22
III.5.1 Le protocole CR-LDP ....................................................................................... 22
III.5.2 Le protocole RSVP ............................................................................................ 24
III.5.3 Comparaison entre CR-LDP et RSVP ......................................................... 26
III.6 Ingnierie de trafic et qualit de service ...................................................................... 27
III.7 Avantages de MPLS .......................................................................................................... 28
III.7.1 Protocoles de routage ou de dcouverte du rseau ................................... 28
III.7.2 Scurit ................................................................................................................. 28
III.7.3 Les applications .................................................................................................. 29
III.7.4 Virtual Private Network.................................................................................... 30
IV

CONCLUSION

.......................................................................................... 30

Chapitre III: Intgration de Mobile IPv4 avec MPLS

31

PROBLEMES DE PASSAGE A LECHELLE DANS MOBILE IPV4 ............. 31

II

INTEGRATION DE MOBILE IPV4 AVEC MPLS.......................................... 32


II.1

II.2

II.3

Cas d'un simple domaine MPLS ................................................................................... 32


II.1.1 Procdure d'enregistrement............................................................................... 33
II.1.2 Livraison des paquets ......................................................................................... 35
II.1.3 Handoff ........................................................................................................... 36
II.1.4 Retour au rseau mre........................................................................................ 38
II.1.5 Plusieurs noeuds correspondants .................................................................... 38
Plusieurs domaines de rseaux ...................................................................................... 40
II.2.1 Plusieurs domaines MPLS ................................................................................ 40
II.2.2 Un nuage IP entre les domaines MPLS ........................................................ 40
II.2.3 Sommaire .............................................................................................................. 41
Routage Optimis .............................................................................................................. 41
II.3.1 Routage optimis standard ............................................................................... 42
II.3.2 Routage optimis avec le message Path Change ................................ 45

III CONCLUSION

.......................................................................................... 51

Chapitre IV : Intgration de Mobile IPv6 avec MPLS


I

DISPOSITIFS D'INTEGRATION DE MOBILE IPV6 AVEC MPLS ............. 52


I.1
I.2
I.3
I.4
I.5
I.6

II

52

Etablissement d'un LSP garantissant une QoS .......................................................... 52


Considration des mobiles inactifs................................................................................ 53
Support du doux dplacement ( Smooth Handoff ) ............................................. 53
Etablissement d'un LSP bidirectionnel ........................................................................ 53
Aucun engagement dune signalisation MPLS au mobile ..................................... 53
Aucun message MPLS additionnel de signalisation ................................................ 54

INTEGRATION DE MOBILE IPV6 AVEC MPLS........................................... 54

III

II.1
II.2
II.3
II.4

Cas o le mobile lance la transmission de donnes ................................................. 54


Cas o le correspondant lance la transmission de donnes ................................... 55
Smooth Handoff .......................................................................................................... 56
Support de la QoS par un LSP ....................................................................................... 57

III CONCLUSION

.......................................................................................... 58

Chapitre V: Intgration de HMIPv4 avec MPLS

59

PRESENTATION DE MOBILE IPV4 HIERARCHIQUE OU HMIPV4 ..... 59

II

RESEAU MPLS HIERARCHIQUE POUR MOBILE IPV4........................... 61


II.1
II.2
II.3

III

Procdure denregistrement ............................................................................................ 62


Livraison de paquets ......................................................................................................... 63
Re-routage lors du handoff ..................................................................................... 65
II.3.1 Rtablissement du LSP ...................................................................................... 65
II.3.2 Re-routage du LSP .............................................................................................. 65
II.3.3 Re-routage multicast.......................................................................................... 67

CONCLUSION

.......................................................................................... 68

Chapitre VI: Intgration de HMIPv6 avec MPLS

69

PRESENTATION DE MOBILE IPV6 HIERARCHIQUE OU HMIPV6 ....... 69

II

RESEAU MPLS HIERARCHIQUE POUR MOBILE IPV6............................. 70


II.1
II.2

II.3

III

Architecture du rseau..................................................................................................... 70
Livraison de paquets ........................................................................................................ 71
II.2.1 Cas o le correspondant initie la communication .................................... 71
II.2.2 Cas o le mobile lance la communication ................................................. 73
Types de Handoffs dans HMIPv6 ....................................................................... 74
II.3.1 Handoff inta-RAN .................................................................................... 74
II.3.2 Handoff inter-RAN .................................................................................. 75

CONCLUSION

.......................................................................................... 75

Chapitre VII: Etude de performance


I

NETWORK SIMULATOR OU NS ............................................................... 76


I.1

II

76

Implmentation de MPLS dans NS.............................................................................. 77


I.1.1 Modle conceptuel de mns-v2.0.................................................................... 77
I.1.2 Implmentation de mns-v2.0......................................................................... 78
I.1.3 Limites de mns-v2.0 ........................................................................................ 80
I.1.4 Propositions et solutions................................................................................. 81
I.1.5 Expriences selon NS...................................................................................... 84

EXPERIENCES SELON OPNET ....................................................................... 88


II.1

Srie 1

...................................................................................................................... 89

IV

II.2

III

II.1.1
II.1.2
II.1.3
II.1.4
Srie 2
II.2.1
II.2.2
II.2.3
II.2.4
II.2.5

Modle architectural ..................................................................................... 89


Dlai de bout en bout .................................................................................... 89
Variation de dbit .......................................................................................... 91
Sommaire......................................................................................................... 92
...................................................................................................................... 92

Modle architectural...................................................................................... 93
Dlai du Handover ................................................................................ 93
Rupture de communication ......................................................................... 94
Besoin de tampon .......................................................................................... 94
Sommaire ......................................................................................................... 95

CONCLUSION

.......................................................................................... 95

CONCLUSION GENERALE....................................................................................... 96
ANNEXE A :Distribution des tiquettes selon des extensions de Mobile IP
ANNEXE B :Adresses prives pour lintgration de Mobile IPv4 avec MPLS
ANNEXE C: Distribution du profil du mobile
ANNEXE D: Micro Cell Mobile MPLS, MMPLS
ANNEXE E: Intgration des fonctions de MPLS avec celles de HMIPv6
ANNEXE F : Deux stages de handoff
REFERENCES

97
100
104
107
110
114

........................................................................................ 116

Liste des Figures

Figure I.1 : Encapsulation IP dans IP


Figure I.2 : Procdure denregistrement
Figure I.3 : Modes de routage dans Mobile IPv4 (sens montant)
Figure I.4 : Routage optimis
Figure I.5 : Fonctionnement de Mobile IPv6
Figure II.1 : Exemple dun rseau MPLS
Figure II.2 : Exemple du fonctionnement dun rseau MPLS
Figure II.3 : Trame Ethernet de base
Figure II.4 : Trame Ethernet marque MPLS
Figure II.5: Encapsulation dtiquettes dans un VPI/VCI ATM
Figure II.6: Architecture des tiquettes hirarchiques MPLS
Figure II.7: Cas de deux LSPs dans un rseau MPLS
Figure II.8: Champs ajouts dans CR-LDP
Figure II.9: Procdure dtablissement des LSPs avec CR-LDP
Figure II.10: Procdure dtablissement des LSPs avec RSVP
Figure III.1 : Exemple dune topologie dun rseau
Figure III.2 : Procdure denregistrement de Mobile IPv4
Figure III.3 : Procdure de livraison de paquets
Figure III.4 : Exemple dun handoff dun mobile
Figure III.5 : Exemple dune topologie dun rseau avec plusieurs correspondants
Figure III.6 : Plusieurs domaines MPLS
Figure III.7 : Nuage IP entre les domaines MPLS
Figure III.8 : Routage optimis standard
Figure III.9 : Extension du LSP
Figure III.10 : Optimisation du LSP
Figure III.11 : Format du message PATH CHANGE
Figure III.12 : Procdure doptimisation de routage
Figure III.13 : Nud Correspondant Muli-Homed
Figure III.14: Nuage IP entre un correspondant et un nud dentre MPLS
Figure IV.1 : Rseau MPLS supportant Mobile IPv6
Figure IV.2 : Le mobile initiateur de communication
Figure IV.3 : Le correspondant initiateur de communication
Figure IV.4 : Smooth Handover
Figure V.1 : Mobile IPv4 Hirarchique
Figure V.2 : Rseau MPLS hirarchique pour Mobile IPv4
Figure V.3 : Procdures denregistrement et dtablissement de LSP
Figure V.4 : Livraison de paquets et distribution des tiquettes
Figure V.5 : Rtablissement dun LSP
Figure V.6 : Enregistrement rgional et distribution des tiquettes
Figure V.7 : Re-routage multicast
Figure VI.1 : Architecture du rseau RAN
Figure VI.2 : Dcouverte du HA et procdure denregistrement
Figure VI.3 : Etablissement du LSP quand un correspondant initie la communication
Figure VI.4 : Etablissement du LSP quand le mobile lance la communication
Figure VII.1 : Modle conceptuel de MPLS dans NS-2

5
6
7
8
13
17
17
18
18
19
19
20
23
23
25
32
34
36
36
39

40
41
42
44
45
45
47
48
50
54
55
56
57
60
61
63
64
65
66
67
70
71
73
74
77

VI

Figure VII.2: Architecture de MPLS Node


Figure VII.3 : Hirarchie de classifiers
Figure VII.4:Architecture dun noeud BaseStation
Figure VII.5 : Recouvrement des paquets selon le niveau MAC
Figure VII.6 : Modle architectural
Figure VII.7 : Performance dUDP sans recouvrement de paquets selon MAC
Figure VII.8 : Performance dUDP avec recouvrement de paquets selon MAC
Figure VII.9 : Performance de TCP sans et avec recouvrement des paquets
Figure VII.10 : Modle architectural
Figure VII.11 : Dlai de bout en bout
Figure VII.12 : Dlai de bout en bout pour HMIPv4 et son cas optimal avec MPLS
Figure VII.13 : Variation de dbit
Figure VII.14 : Variation du dbit pour HMIPv4 et son cas optimal avec MPLS
Figure VII.15 : Architecture du rseau
Figure VII.16: Handover Delay
Figure VII.17 : Rupture de communication
Figure VII.18: Besoin en tampons
Figure A.1: Format de lextension de ltiquette
Figure B.1 : Rseau MPLS bas sur Mobile IPv4 utilisant des adresses prives
FigureB.2: Cas dun mobile initiant la communication
FigureB.3: Cas dun correspondant initiant la communication
Figure C.1 : Bases de donnes distribues
Figure C.2 : Base de donnes centralise
Figure D.1:Architecture dun rseau MM-MPLS
Figure D.2: Procdure de handoff dans MM-MPLS
Figure E.1 : Bases des donnes et mthodes de relation
Figure E.2 : Etablissement dun LSP dans le cas dintgration des protocoles

79
81
83
85
86
87
87
88
89
90
90
91
92
93
94
94
95
95
99
100
101
103
104
106
108
109
111

Liste des Abbrviations

A
ACK
AF
AODV
ARP
ATM

Acknowledgment
Assured Forwarding
AD-hoc On-demand Distance Vector
Address Resolution Protocol
Asynchronous Transfer Mode

B
BAck
BGP
BU

Binding Acknowledgement
Border Gateway Protocol
Binding Update

C
CBR
CBR
CCOA
CDR
CIDR
CIMS
CLP
CN
COA
CoS
CR-LDP
CR-LSP
CTS

Constraint Based Routes


Commited Burst Size
Co-located COA
Commited Data Rate
Classeless Interdomain Routing
Columbia IP Micro-Mobility Software
Cell Loss Priority
Correspondent Node
Care-Of- Address
Class of Service
Constrained Routing-LDP
Constrained RouteLSP
Clear To Send

D
DHCP

Dynamic Host Control Protocol

VIII

DiffServ
DLCI
DNS
DSDV
DSR
DWDM

Differentiated Services
Data Link Channel Identifier
Domain Name Server
Destination Sequence Distance Vector
Dynamic Souce Routing
Dense Wavelength Division Multiplexing

E
EBR
EF
EGW
ERO

Excess Burst Size


Expedited Forwarding
Edge Gateway
Explicit_Route Object

F
FA
FEC
FN
FQDN

Foreign Agent
Forwarding Equivalent Class
Foreign Network
Fully Qualified Domain Name

G
GFA
GMPLS
GPRS

Gateway Foreign Agent


Genralized MPLS
General Packect Radio Systems

H
HA
HEC
HMIP
HN

Home Agent
Header Error Control
Hierarchical Mobile IP
Home Network

IX

I
ICMP
IETF
IGP
IntServ
ISP

Internet Control Message Protocol


Internet Engineering Task Force
Interior Gateway Protocol
Integrated Services
Internet Service Providers

L
LCOA
LER
LIB
LL
LSR
LSP

Local COA
Label Edge Router
Label Information Base
Link Layer
Label Switch Router
Label Switch Path

M
MAC
MAP
MM-MPLS
MN
MPLS

Multiple Access Control


Mobility Anchor Point
Micro Cell Mobile MPLS
Mobile Node
Multi-Protocol-Label-Switching

N
NAM
NAT
NS

Network Animator
Network address Translator
Network Simulator

O
OPNET
OPSF
OSI

Optimized Network Engineering Tools


Open Path Shortest Forwarding
Open Systems Interconnection

OTcl

Object Tool Language Command

P
PA
PDR
PHB
PPP
PPTP
PT
PVC

Paging Areas
Peak Data Rate
Per Hop Behavior
Point-to-Point Protocol
Point-to-Point Tunneling Protocol
Payload Type
Private Virtual Circuit

Q
QoS

Quality of Service

R
RAN
RAR
RCOA
RFA
RSVP
RTS
RTT

Radio Access Network


Radio Access Router
Regional COA
Regional Foreign Agent
Resource Reservation Protocol
Request To Send
Round Trip Time

S
SLA
SPT

Service Level Agreements


Shortest Path Tree

T
TE
TLV
TORA

Traffic Engineering
Type Length Value
Temporally ordered Routing Algorithm

XI

TTL

Time-To-Live

U
UDP
UMTS

User Datagram Protocol


Universal Mobile Telecommunications System

V
VCI
VPI
VPL
VPN

Virtual Channel Identifier


Virtual Path Identifier
Virtual Private Lines
Virtual Private Network

W
WAP
WLAN

Wireless Application Protocols


Wireless Local Area Network

Introduction gnrale

Actuellement, beaucoup de propositions sont mises en oeuvre pour incorporer des


technologies bases sur IP dans les noyaux des rseaux des futurs systmes cellulaires
sans fil tels que le systme mobile universel de tlcommunications (Universal Mobile
Telecommunications System, UMTS) et les systmes au del de la troisime
gnration.
Mobile IP peut potentiellement fournir une solution de mobilit dans les rseaux curs
de ces futurs rseaux. Comme le nombre d'utilisateurs attachs ne cesse de crotre, le
problme de passage l'chelle, l'efficacit et l'excution de lIP mobile forment un
grand dfi.
D'autre part, la technologie MPLS (Multi-Protocol-Label-Switching) constitue un
mcanisme principal dexpdition de paquets. Un domaine MPLS n'examine que
l'tiquette durant la transmission d'un paquet. Par consquent, l'en-tte du paquet IP n'est
analyse qu' l'entre du rseau. C'est la raison principale pour laquelle la commutation
dans MPLS est clairement plus rapide que le routage IP conventionnel. Puisque les
tiquettes n'ont q'une signification locale entre les routeurs MPLS adjacents, le
problme de passage l'chelle ne peut tre frquent car il est impossible pratiquement
de manquer d'tiquettes.
Ce sujet de stage consiste tudier le support des services de Mobile IP sur MPLS.
L'intgration de ces deux protocoles permet ces deux technologies de fonctionner
mutuellement dans les noyaux des futures rseaux et fournir galement le support de
mobilit.
En effet, les fournisseurs de services imaginent le futur rseau Internet comme un rseau
capable de crer une plus grande fonctionnalit, une gnralit, une adaptabilit et une
robustesse afin de soutenir l'opration et l'entretien du rseau tout en garantissant des
niveaux acceptables de qualit de service (Quality of Service, QoS) et en satisfaisant
les divers accords de niveau de service (Service Level Agreements, SLA). Pour
soutenir les modles des rseaux sans fil, lInternet original sera amlior pour satisfaire
les demandes exiges par les applications de temps rel et de multimdia. Les fonctions
de tolrance de fautes, de priorit et des classes de QoS seront alors supportes offrant la
capacit de concevoir en fonction du service du rseau les besoins spcifiques des
diverses applications selon les classes variables de service.
En combinant des fonctions de perage d'un tunnel entre l'Agent Mre (Home Agent,
HA) et l'Agent visit (Foreign Agent, FA) dans le paradigme d'expdition de MPLS, le
nud MPLS peut tre capable de s'occuper du noeud mobile en assignant des tiquettes
pour un tunnel entre le HA et le FA. Dans ce cas-ci, les deux agents peuvent tre situs
ou attachs au noeud MPLS. Il en rsulte que le tunnel s'effectue au niveau de la couche
de MPLS. Pour viter le problme de routage triangulaire, les noeuds MPLS peuvent
permettre une communication directe, qui est une optimisation de routage, entre
n'importe quel noeud correspondant et n'importe quel noeud mobile.

XIII

Ce rapport tudiera galement l'intgration de Mobile IPv4 avec MPLS ainsi que
l'intgration de Mobile IPv6 avec MPLS.
Comme le protocole Mobile IP ne supporte que la mobilit globale ( macro-mobility),
le protocole Mobile IP hirarchique (Hierarchical Mobile IP, HMIP) sera introduit
pour supporter la mobilit locale ( micro-mobility ). L'intgration de HMIPv4 ainsi
que HMIPv6 seront aussi dtaills dans ce rapport.
Chapitre I tudie en dtail le protocole Mobile IP ainsi que tous les mcanismes de son
fonctionnement. Le passage de Mobile IPv4 Mobile IPv6 est aussi illustr tout en
dmontrant les diffrences entre ces deux versions.
Chapitre II explique le principe de MPLS. Les mthodes de distribution des tiquettes
ainsi que son intrt dans le support de la qualit de service et de l'ingnierie de trafic est
exploit.
Chapitre III propose l'intgration de Mobile IPv4 avec MPLS. Cette intgration limine
le tunnel IPv4-IPv4 observ dans Mobile IPv4 entre le HA et le FA.
Chapitre IV exploite l'intgration de Mobile IP sous sa version IPv6 avec MPLS. Les
diffrentes phases de fonctionnement sont tablies et les avantages de cette intgration
sont aussi prsents.
Comme Mobile IP, dans ses deux versions, est suppos tre un protocole grant la
macro-mobilit, Chapitre V propose HMIPv4 comme une solution de la micro-mobilit
et tudie les moyens de son intgration avec MPLS.
Chapitre VI prsente la version IPv6 de HMIP et les mcanismes de son intgration avec
MPLS.
Chapitre VII expose une tude de performance pour montrer les avantages dintgration
de Mobile IP et de HMIP avec MPLS. Cette tude prsente limplmentation de MPLS
dans le simulateur Network Simulator ou NS et expose ses limites de fonctionnement
et dapplicabilit ainsi que les rsultats obtenus. Les expriences dveloppes selon le
puissant simulateur OPNET (Optimized Network) sont aussi prsentes.
Enfin, je ne me permettrai point de finir cette prface sans remercier Monsieur Mahmoud
Doughan, lencadreur de mon projet, qui ma guid tout au long de ce stage avec rigueur
et patience. Je lui suis particulirement reconnaissante pour son aide prcieuse et sa
disponibilit.
Remerciements tous les enseignants des cours de DEA, Rseaux de
Tlcommunications, qui ont contribu largir nos connaissances.
Merci enfin, tous mes proches pour leurs encouragements et leur soutien

Chapitre I :
Mobilit IPTransition de IPv4 IPv6

Le support de la mobilit dans lInternet devient de plus en plus crucial surtout


que de nombreux quipements mobiles offrant des services daccs aux rseaux IP font
leur apparition ( General Packet Radio Systems/Wireless Application Protocols
ou GPRS/WAP). Lapparition de lUMTS dans le futur proche et son offre de services
multimdia implique que les rseaux IP devront supporter la mobilit.
Lobjectif de ce chapitre est de prsenter l'une des solutions proposes par l'IETF
(Internet Engineering Task Force) conue pour rsoudre le problme de la mobilit
dans les environnements IP : Mobile IP.
Une brve introduction aux problmes lis la mobilit dans les environnements IP est
mentionne dans la Section I .Une description du protocole Mobile IP sous IPv4 [1] est
illustre dans la Section II. Section III explique les problmes de Mobile IPv4 dont lun,
la limite despace dadressages a conduit au dveloppement de Mobile IPv6. Par la suite,
la Section IV dtaillera la mobilit sous IPv6 [2], la version des rseaux IP futurs.

I Problmes de la mobilit IP
Le protocole IP identifie le point d'accs d'un nud sur l'Internet dune manire
unique grce son adresse IP. Celle-ci se dcompose en deux parties :
le prfixe qui dtermine le sous rseau sur lequel la machine se trouve, et ;
lidentifiant de la machine sur son sous rseau.
LInternet est un rseau de trop grande taille pour que chaque routeur puisse mmoriser
une route vers toutes les machines qui y sont attaches. En fait, les routeurs ne stockent
que des entres correspondant des sous rseaux en considrant que des paquets
destins des machines ayant le mme prfixe seront tous routs d'une manire
identique.

La mobilit introduit un nouveau problme de routage : les mobiles se dplacent dun


sous rseau IP vers un autre sous rseau IP, mais ont un mauvais prfixe sur le rseau
destination. Par consquent, un nud doit tre situ sur le rseau indiqu par son adresse
IP afin de pouvoir recevoir les paquets qui lui sont destins. Pour qu'un nud puisse
changer de point d'accs sans perdre la possibilit de communiquer, deux mcanismes
peuvent tre employs :
le nud doit changer d'adresse IP chaque fois qu'il change de point
d'accs,
des chemins spcifiques l'hte doivent tre propags dans presque toute
la structure de routage de l'Internet.
Ces deux alternatives sont souvent inacceptables. La premire ne permet pas un nud
de conserver des connexions au niveau de la couche transport ou des couches suprieures
lorsqu'il change de position. La seconde pose des problmes de passage l'chelle.
Un nouveau mcanisme flexible est ncessaire afin de s'adapter la mobilit des nuds
sur Internet. Le protocole Mobile IP permet aux nuds de changer de point d'accs
l'Internet sans changer d'adresse IP. Les spcifications minimales de la solution
recherche sont les suivantes :
le dplacement d'un mobile ne doit pas provoquer de coupure des
connexions ouvertes ;
lopration doit tre simple mettre en uvre et d'un cot raisonnable;
laccs aux ressources doit tre transparent, et ;
la solution doit tre compatible avec le protocole IP et en particulier avec
les algorithmes de routage. Le support de la mobilit ne doit pas
ncessiter la modification de tous les routeurs.
De nombreux protocoles et architectures ont t proposs pour grer la mobilit. Un des
ces protocoles est Mobile IPv4 de lIETF qui sera dcrit le dans la suite.

II Mobile IP version 4
LIETF est lorganisme charg de dvelopper et de publier les protocoles
reconnus comme les protocoles de lInternet standard. Cet organisme est compos de
groupes de travail qui soccupent chacun dun domaine bien prcis. Lun dentre eux
(Mobile IP) est charg de proposer un protocole pour le support des mobiles sur
lInternet.

II.1

Infrastructure

Nud mobile ( Mobile Node , MN)


Cest un hte ou un routeur qui change de point d'accs d'un rseau (ou sous
rseau) un autre. Comme toute machine fixe, un mobile appartient initialement un
rseau sur Internet. Ce rseau, appel rseau mre ( Home Network , HN), affecte son
adresse IP au mobile. Un nud mobile peut changer de position sans changer d'adresse
IP.
Agent Mre ( Home Agent , HA)
Cest un routeur sur le rseau mre d'un mobile, qui envoie les paquets dans un
tunnel pour les remettre au mobile lorsqu'il visite un autre rseau. Cet agent met jour
les informations concernant la position du mobile.
Agent visit ( Foreign Agent , FA)
Cest un routeur sur un rseau visit ( Foreign Network , FN) par le nud
mobile, qui fournit des services de routage au mobile lorsqu'il est enregistr auprs de
lui.
Adresse permanente / temporaire ( Care-Of- Address , COA)
Un nud mobile possde une adresse IP permanente sur son rseau mre.
Lorsqu'il visite un autre rseau, une adresse temporaire est affecte au mobile. Cette
adresse reflte le point d'accs du mobile. En gnral, le mobile utilise son adresse mre
comme adresse source dans tous les paquets IP qu'il envoie.
Nud Correspondant ( Correspondent Node , CN)
Cest une machine (mobile ou non) qui dialogue avec un mobile.

II.2

Fonctionnement du protocole

Le HA peut rediriger les paquets vers le nud car il connat son emplacement
actuel reprsent par une adresse IP intitule COA. En effet le nud informe par un
message spcial son HA quil a chang demplacement en lui fournissant cette nouvelle
adresse.
II.2.1

Principe de base

Mobile IPv4 permet un nud de changer de rseau tout en gardant dune faon
transparente ses connections dj tablies.
Ce noeud s'attache une station de base qui implmente des fonctionnalits de niveau 2
du modle OSI (Open Systems Interconnection). Elle assure une connectivit de
niveau liaison de donnes et permet lchange dinformations avec un mobile par un
canal sans fil.
Quand un correspondant veut envoyer des donnes un mobile, il cre un paquet IP
ordinaire dont ladresse IP source est celle du correspondant et ladresse IP destination

est celle du mobile sur son rseau mre. Chaque nud est en ralit toujours identifi par
son adresse IP dorigine. Un nud spcial sur le rseau dorigine appel le HA intercepte
ainsi les paquets destins au nud mobile et les lui renvoie.
Ce mcanisme est compltement transparent aux couches suprieures.
II.2.2

Adresse temporaire

Lorsqu'un mobile quitte son rseau mre, Mobile IPv4 utilise le tunnel
(tunneling) pour cacher l'adresse mre du mobile aux routeurs situs entre le rseau
mre et le mobile. La fin du tunnel correspond l'adresse temporaire du mobile. Cette
adresse temporaire doit tre une adresse laquelle les paquets peuvent tre remis par des
mcanismes de routage IP classiques. A l'adresse temporaire, le paquet d'origine est
enlev du tunnel et remis au nud mobile.
L'adresse temporaire peut tre obtenue de deux manires diffrentes :
Une COA est une adresse temporaire fournie par un FA grce aux
messages Agent Advertisement . Dans ce cas, l'adresse temporaire est
l'adresse IP du FA. C'est donc cet agent qui est l'extrmit du tunnel ;
lorsqu'il reoit les paquets tunnels, il les dcapsule
et remet le paquet
d'origine au mobile. Ce mode d'acquisition d'adresse temporaire est
prfrable car il permet de nombreux nuds mobiles de partager une
mme adresse temporaire.
Une Co-located COA (CCOA) est une adresse IP locale, acquise par
des moyens externes, que le mobile associe l'une des ses interfaces de
rseau. Cette adresse peut tre acquise dynamiquement par des
mcanismes tels que DHCP (Dynamic Host Control Protocol), ou peut
tre possde par le mobile comme adresse utiliser dans certains rseaux
visits. Lorsque le nud mobile utilise une CCOA, il se trouve lui-mme
l'extrmit du tunnel et dcapsule les paquets tunnels jusqu' lui. Ce
mode permet un mobile de fonctionner sans le FA, mais il pose un
problme au niveau de l'espace d'adressage d'IPv4.

II.2.3

Encapsulation IP dans IP

Le HA ne fait quencapsuler les paquets, cest dire quil ne les modifie pas de
telle faon quil na pas besoin de recalculer les sommes de contrle (checksum) des
couches suprieures. Il se contente donc dajouter une nouvelle en-tte IP devant lentte du paquet reu.

Figure I.1 illustre lencapsulation IP dans IP.


En-t t e a j ou t e p ar l e HA

Ad r es s e I P Ad re s s e I P
d u HA
du F A
Adr e s s e
s ou r ce

I P- I P

Adr e s s e Pr o c h a i n e
De s t i n a t i o n En- t t e

Paquet envoy par l e CN a u MN

Ad r es s e I P Ad r es s e I P
TCP En- t t eTCP +d o nn es
d u CN
du MN
Adr e s s e
s ou r ce

Adr e s s e
P r o c ha i n e
De s t i n a t i o n
En- t t e

Figure I.1 : Encapsulation IP dans IP


Le HA envoie un message Neighbor Advertisement lui permettant dassocier son
adresse MAC (Multiple Access Control) avec ladresse IP dorigine du nud mobile.
Ainsi les paquets sont facilement redirigs et routs dans lInternet. Ladresse IP vers
laquelle le HA fait suivre les paquets destins au mobile est la COA.
Mobile IP dfinit un ensemble de messages de contrle, envoys avec UDP ( User
Datagram Protocol ) tels que les messages de demande d'enregistrement (Registration
Request) et rponse d'enregistrement (Registration Reply).
Pour la dcouverte des agents, Mobile IP utilise les messages existants Router
Advertisement et Router Solicitation dfinis pour la dcouverte de routeurs ICMP
(Internet Control Message Protocol).
II.2.4

Dcouverte des FAs et procdure denregistrement

Des mcanismes de communication entre les mobiles et leurs FAs sont


ncessaires. En particulier, il faut quun mobile puisse apprendre ladresse IP des FAs.
Le mobile doit ensuite senregistrer auprs dun FA et obtenir son accord pour quil
relaye les paquets. Puis, le HA doit tre inform de ladresse IP du nouvel FA, qui
devient l'adresse temporaire du mobile ou son COA. On peut galement transmettre cette
adresse lancien FA (sur le rseau que le mobile a quitt) pour que les paquets en
transit au moment du dplacement du mobile arrivent bien destination. En effet, il se
peut que le HA continue envoyer des paquets lors de la procdure de changement de
FA.
La gestion des FAs peut par exemple tre effectue en utilisant le protocole ICMP. Si le
mobile dsire savoir l'agent auquel il est attach, il envoie un message Agent
Solicitation .
Les FAs signalent priodiquement leur prsence avec des ICMP Agent
Advertisements sur les liens o ils se trouvent. Le mobile reoit ce message et en
dduit sil est dans son rseau mre ou bien sil est dans un rseau visit.
Une fois le mobile reoit les Agent Advertisement , il dmarre ensuite la procdure
denregistrement.

Cette procdure comporte quatre messages :


demande denregistrement au FA,
traitement de la demande par le FA, puis transmission de la demande au
HA,
notification dacceptation ou de refus de prise en charge du mobile du HA
au FA ( Registration Reply ), puis ;
traitement de la notification par le FA et transmission de linformation au
mobile.
Figure I.2 illustre la procdure denregistrement.

Re gi s t r at i o n Re pl y

Registration Reques t

FN
HN

Agent Adv ert i s ement s

Rs eau I nt er net

MN

FA

HA

Agent
Sol i ci t a t i ons

CN
Figure I.2 : Procdure denregistrement
La procdure denregistrement est accompagne dune authentification afin
dassurer que les paquets destins au mobile ne sont pas dtourns par une autre
machine. Les messages sont authentifis par le HA grce lassociation de scurit quil
partage avec son mobile. Le FA fait confiance au HA pour authentifier le mobile. En
gnral, il possde une association de scurit avec le HA et se situe dans le mme
domaine administratif.
Lorsque le mobile est situ sur son rseau mre, il n'utilise pas les services de mobilit et
se comporte comme un terminal fixe.
Lune des extensions des messages ICMP Router Discovery , appele Mobility
Agent Advertisement Extension , permet dutiliser un champ dure de vie (TTL,
Time-To-Live ), prsent dans les messages ICMP Router Advertisement envoys
rgulirement par un FA. Quand un mobile se connecte sur un rseau, il enregistre la
dure de vie associe son FA. Lorsque cette valeur expire, le mobile suppose quil nest
plus gr par cet agent. Par contre, si le mobile reoit un Router Advertisement dun
autre FA, il senregistre auprs de celui-ci.

II.2.5

Extensions

Mobile IP dfinit un mcanisme d'extension gnral pour permettre aux messages


de contrle Mobile IP et aux messages de dcouverte de routeurs ICMP de transporter
des informations supplmentaires. Ces extensions sont codes avec le format Type
Longueur Valeur TLV ( Type Length Value ), une exception prs.
Certaines extensions n'apparaissent que dans les messages de contrle Mobile IP :
Authentification mobile / HA,
Authentification mobile / FA, et ;
Authentification FA / HA.
Les extensions prsentes uniquement dans les messages de recherche de routeur ICMP
sont :
Bourrage d'un octet,
Annonce d'agent de mobilit (Mobility Agent Advertisement), et ;
Longueurs des prfixes.
II.2.6

Routage

Lorsquun correspondant veut dialoguer avec un mobile (sens descendant), il ne


connat pas la position courante de ce dernier et envoie les paquets l'adresse mre du
mobile. Ceux-ci sont intercepts par le HA puis envoys dans un tunnel du HA vers
l'adresse temporaire du mobile. A la sortie du tunnel (au niveau soit du FA, soit du
mobile lui-mme), les paquets sont transmis au mobile. Si le correspondant est mobile, il
doit galement passer par son propre FA. Dans l'autre sens (sens montant), les paquets
envoys par le nud mobile sont gnralement remis aux destinataires en utilisant des
mcanismes de routage IP standard, en passant par le HA (mode bidirectionnel) ou non
(mode standard). Ces 2 modes sont illustrs dans la Figure I.3.
HA

1 -Pa que t s i nt e rc e pt s
pa r l e HA

2 - Tunne l
FA

HA

2 - Tunne l
FA

1 -Pa que t s i nt e r c e pt s
pa r l e HA

3 - Pa que t s e nv o y s
pa r l e mo bi l e

CN
a- Mo de s t a nda r d

3 - Pa que t s e nv o y s
pa r l e mo bi l e

CN
b- Mo de bi di re c t i o nne l

Figure I.3 : Modes de routage dans Mobile IPv4 (sens montant)

Routage triangulaire

De point de vue routage, la principale faiblesse de Mobile IPv4 est le


routage triangulaire, cest dire un routage via le HA dans la direction du mobile. En
effet, lorsquun mobile, hors de son sous rseau mre, cherche joindre une machine sur
le mme rseau visit, les paquets doivent nanmoins transiter par le sous-rseau mre
du mobile.
Ce problme n'apparat pas dans le sens descendant (du mobile au correspondant) car
Mobile IP dfinit un routage direct.
En effet, le routage triangulaire est le routage utilis par dfaut. Il devient
particulirement peu performant lorsque le mobile en dplacement et son correspondant
sont sur le mme rseau IP.
b

Routage optimis

Afin d'obtenir un routage performant dans la direction du mobile, un


correspondant doit savoir s'il dialogue avec une machine fixe ou mobile. Dans cette
proposition, seul le premier paquet envoy un mobile passe par son HA ; aprs
rception de ce paquet, le HA indique au correspondant que la machine quil cherche
joindre est un mobile et fournit ladresse par laquelle il peut tre joint (son adresse
temporaire COA).
Un mobile peut avoir plusieurs correspondants susceptibles d'utiliser des routes non
optimales (cest dire qui passent par le HA). Le HA mmorise donc la liste des
correspondants de chacun des mobiles quil gre pour informer les correspondants des
mouvements des mobiles.
Figure I.4 illustre le routage optimis.
HN
HA

Pr e mie r pa que t
de s ti n a u m o bi l e

R s e au I nte rn et
CN
FN

MN

FA

Figure I.4 : Routage optimis

III Problmes principaux des mcanismes de Mobile IPv4


Les problmes principaux [3] de Mobile IPv4 peuvent tre rsums dans les cinq
points suivants :
Routage triangulaire,
Garantie de QoS difficile (le flux change chaque changement de
position du mobile),
Division de la gestion de la mobilit en deux parties: la macromobility , entre domaines (Mobile IP) et la micro-mobility
lintrieur des domaines (protocoles ddis),
Limitations de lespace dadressage dans IPv4, et ;
Latence dans la gestion du handover (atteindre le HA).
En effet, la principale faiblesse d'IPv4 [4] rside dans son espace dadressage puisqu'une
adresse est dfinie sur 32 bits seulement.
Le succs rapide d'Internet et l'acclration de la consommation d'adresses IP, fait
craindre une pnurie dadresses IP. Pour linstant, IPv4 a russi repousser les limites de
son systme d'adressage grce des procds tels que la translation d'adresses
( Network address Translator ou NAT) ou le schma de routage CIDR (Classeless
Interdomain Routing) qui permet d'agrger des adresses IP.
IPv6, labor par l'IETF au milieu des annes 90, est la prochaine version du protocole
IP. En premier lieu, IPv6 amliore les capacits d'adressage d'IPv4 en allouant 128 bits
au lieu de 32 aux adresses IP. Il peut tre alors considr comme un protocole adapt la
diffusion massive d'Internet.
Ceci permettra de faire face aux besoins engendrs par le dveloppement des nouvelles
applications always on et de rtablir lusage du mode end-to-end qui est le
principal apport dIPv6 au niveau des applicatifs. Les autres avantages techniques d'IPv6
sont:
Adressage hirarchique pour optimiser le routage,
Autoconfiguration,
IPSec natif,
Multicast, et ;
Mobile IPv6.
La section suivante dfinit le principe de fonctionnement de Mobile IPv6 tout en
s'appuyant sur les avantages apports par IPv6.

IV Mobile IP version 6
LInternet mobile sera un moteur de croissance dIP et IPv6 sera ncessaire pour
dvelopper des services attrayants. Lhorizon de la 3me Gnration est clairement voqu
par ces derniers comme une relle opportunit pour IPv6.

10

Le march des WLAN (Wireless Local Area Network) connat un dveloppement


sensible la fois dans le domaine des rseaux dentreprises et, plus rcemment, dans le
domaine des rseaux daccs public.
Les systmes mobiles GPRS et UMTS exploitent IPv4 ; la version IPv6 apparat comme
un enjeu important pour les oprateurs de rseau mobile, car il permettra dallouer une
adresse IP permanente chaque terminal mobile connect. En effet, le GPRS introduit le
concept de always-on , cest--dire de connexion permanente au rseau de donnes en
IP, mme lorsque lutilisateur est inactif. A terme, IPv6 est considr par les acteurs du
secteur comme une volution incontournable des rseaux mobiles.
Aujourdhui, de plus en plus de demandes se font sentir quant lutilisation des
technologies WLAN sur des rseaux publics. Si une telle utilisation tend se gnraliser,
larrive de Mobile IPv6 pourrait sacclrer de manire notable.
La gestion native de la mobilit par IPv6 et ses solutions simples permettant une
simplification de la gestion de la mobilit dun terminal dans un rseau (autoconfiguration, renumrotation automatique) constituent des avantages vidents pour ce
type de technologie et font dIPv6 une solution particulirement sduisante pour la
gestion de la mobilit dans des rseaux htrognes. On pense notamment aux terminaux
mobiles au travers dun WLAN, puis sur les rseaux 3G : mobilit totale et transparente
pour lutilisateur.

IV.1 Infrastructure
Linfrastructure permettant la mobilit avec IPv6 est semblable celle de
Mobile IPv4 si ce nest quil nexiste pas dagent dans le domaine visit ou de FA. Les
paquets IPv6 sont donc toujours directement adresss au mobile. En effet, tant donn
quil nexiste pas de FA, le mobile possde toujours une adresse locale qui lui est
assigne de faon unique (et temporaire) afin de rester joignable.

IV.2 Diffrences avec Mobile IPv4


La dfinition de Mobile IPv6 a profit des expriences acquises lors de la
dfinition de Mobile IPv4 et des nouvelles caractristiques dIPv6. De nombreuses
diffrences assez techniques existent entre Mobile IPv4 et Mobile IPv6.
Les diffrences essentielles sont :
Loptimisation du routage fait intgralement partie du protocole
linverse de Mobile IPv4 pour qui cest une extension. Un mobile peut
donc senregistrer auprs de ses correspondants. En effet, la fonction
d'enregistrement et la fonction d'optimisation de routage sont excutes
par un seul protocole plutt que deux protocoles comme dans Mobile
IPv4. Quand un mobile revient son rseau mre, le HA est prt lui
envoyer tous les paquets destins lui selon le mcanisme de dcouverte
des agents Neighbor Discovery. Ceci amliore la robustesse du
protocole Mobile IP et le dcouple de n'importe quelle type particulier de
couche liaison contrairement au mcanisme de ARP (Address
Resolution Protocol) utilis dans Mobile IPv4.

11

Le FA nexiste pas dans Mobile IPv6. Le mobile possde toujours une


adresse locale. Celle-ci est attribue de faon unique au mobile (par
exemple via DHCPv6 ou par lautoconfiguration sans tat).
Les messages Registration Request sappellent Binding Update .
Tous les messages et les mcanismes mis en jeu dans Mobile IPv6 seront brivement
mentionns dans la suite.

IV.3 Messages utiliss


Tous les nouveaux messages utiliss dans Mobile IPv6 sont dfinis comme des
options de destination IPv6 ( IPv6 Destination Options ). Ces options contiennent
des informations supplmentaires que la destination devra traiter.
Binding Update (BU) :
Cette option est utilise par tout nud mobile afin dinformer son
HA ou tout autre nud avec lequel une communication est tablie de sa
nouvelle adresse IP ou sa COA.
Binding Acknowledgement (BAck) :
Cette option est utilise par le destinataire dun BU pour acquitter
sa rception.
Binding Request :
Cette option est utilise par tout nud afin de demander au nud
mobile de lui envoyer un BU avec sa COA actuelle.
Home Address :
Cette option est incluse dans un paquet envoy par un nud
mobile lorsquil est hors de son rseau dorigine afin dinformer la
destination de son adresse dorigine. En fait un nud mobile utilise
comme adresse source des paquets une de ses adresses de COA.
Ainsi le nud destinataire est capable de substituer ladresse COA par
ladresse dorigine et rendre ainsi la mobilit transparente aux couches
suprieures.

IV.4 Fonctionnement de Mobile IPv6


Cette sous-section explique le fonctionnement de Mobile IPv6 en s'appuyant
sur les points qui le diffre de celui de Mobile IPv4.
Enregistrement auprs du HA
Ds quun nud dtecte quil est dsormais dans un nouveau rseau, il procde
lautoconfiguration dune nouvelle adresse IP. Cette nouvelle adresse est ladresse COA
du nud.
Il envoie alors son HA un BU contenant cette nouvelle adresse pour lui permettre de
faire lassociation avec ladresse dorigine du nud. Le HA rpond par un BAck.

12

Routage triangulaire
L'anomalie du routage triangulaire existe toujours dans Mobile IPv6.
Quand le nud correspondant n'a pas un BU du noeud mobile, tout paquet destin au
nud est ainsi reu par le HA qui se charge denvoyer ce paquet au nud mobile en
utilisant le mcanisme dencapsulation IPv6. Le nud mobile envoie ses paquets
directement au correspondant en utilisant comme adresse source sa COA.
Optimisation de routage
Pour viter ce routage triangulaire, un nud mobile peut envoyer un BU tout
nud correspondant quil soit mobile ou stationnaire.
Ainsi le nud correspondant effectue un appariement entre ladresse dorigine du nud
mobile et sa COA. Dans ce cas, le nud correspondant nutilise pas lencapsulation mais
consulte sa cachette pour trouver un appariement avant l'envoi d'un paquet. Sil existe
un appariement, il envoie le paquet en y incluant loption Routing Header. La route
spcifie dans cette option est constitue de deux sauts. Le premier est ladresse COA du
nud, le second est ladresse origine du nud. Ainsi lorsque le nud reoit le paquet, il
lenvoie vers le saut suivant qui nest autre que son adresse dorigine. Ainsi le paquet
fera un bouclage lintrieur de sa pile protocolaire garantissant ainsi la transparence
aux couches suprieures.
Dtection du HA
Il se peut que durant que le mobile est loin de son rseau mre, des modifications
affectent son lien du rseau mre tel que le remplacement de son propre HA par un autre
agent jouant le mme rle. Dans ce cas, le mobile doit savoir l'adresse IP de son
nouveau HA.
Mobile IPv6 fournit au mobile le mcanisme de dcouvrir dynamiquement son HA. Le
nud mobile se contente denvoyer un message ICMPv6 intitul Home Agent Address
Discovery Request ayant ladresse de destination ladresse Anycast ddie aux
HAs de son rseau dorigine. Ce message sera reu par un des agents prsents sur le
rseau. Cet agent envoie au nud un message ICMPv6 de retour intitul Agent
Address Discovery Reply en y incluant la liste de tous les agents prsents sur le rseau
et leur ordre de priorit. Ainsi le nud mobile envoie son BU un de ces agents.

13

Figure I.5 rsume le fonctionnement de Mobile IPv6.


HN

1- S i l e c o r r e s p o n d a n t n e
c onn a t pas la pos it ion
co ura nte du mobi le

HA

R s e a u I n te r n e t
2- L e H A i n t e r c e p t e l e s p a q u e t s
e t l es env oi e au mobi le le l on g
d 'un tunnel IP v6- IP v6

FN

MN

3- L e m o b i l e r e o i t l e s p a q u e t s
e t env oi e un B U au CN

4- C o m m u n i c a t i o n d i r e c t e

CN

Figure I.5 : Fonctionnement de Mobile IPv6

V Conclusion
Dans ce chapitre, une exposition dtaille du protocole Mobile IP a t tablie. Le
principe de fonctionnement de Mobile IPv4 a t expliqu ainsi que ses problmes dont
l'un a abouti la dfinition d'une nouvelle version de ce protocole, Mobile IPv6. Le
fonctionnement de Mobile IPv6 a t aussi prsent.
Comme le but essentiel de ce sujet de stage est l'tude d'intgration de Mobile IP avec
MPLS, une explication du fonctionnement du protocole MPLS est l'objet du chapitre
suivant.

Chapitre II
MPLS :
Multi Protocol Label Switching

Au dbut de l'Internet, la proccupation majeure tait de transmettre les paquets


leur destination. Mais depuis le dbut des annes 90, la communaut des fournisseurs de
service (Internet Service Providers ou ISPs) qui administrent l'Internet est confronte
non seulement au problme de croissance explosive mais aussi des aspects de politique,
globalisation et stabilit du rseau. Par ailleurs, outre ces diffrents aspects, apparat une
trs forte diversification des services offerts. Ainsi de nouvelles applications se
dveloppent sur le rseau: tlphonie, vidoconfrence, diffusion audio et vido, jeux en
rseau, radio et tlvision en direct Lmergence des rseaux privs virtuels (Virtual
Private Network ou VPN), ncessite galement une diffrentiation de services. La
qualit de service de bout-en -bout apparat, dans ce contexte, essentielle au succs de
ces applications.
La mthode utilise jusque-l, consistant fournir des rseaux surdimensionns, ne peut
plus s'appliquer indfiniment. De plus, la nature intrinsque de l'Internet (mode sans
connexion, niveau de service Best-Effort ) ne permet pas d'offrir une QoS constante,
ni de donner des priorits certains types de trafic. C'est pourquoi, les architectes des
rseaux, les constructeurs et les ISPs concentrent depuis quelques annes leurs efforts sur
la dfinition et l'implmentation de ce concept dans les rseaux IP [5].
Cest pourquoi, ce chapitre tiendra compte de la prsentation du protocole MPLS qui est
suppos comme une solution d'implmentation de la QoS.
Ce chapitre s'intresse aux origines de MPLS dans la Section I, ses objectifs dans la
Section II. Dans la Section III, une explication de la mthode utilisant MPLS pour offrir
des services diffrencis est tablie. La mthode selon laquelle chaque routeur classe les
paquets IP par type dacheminement dans des FECs (Forwarding Equivalent Class), la
QoS offerte tant corrle au chemin suivi, sera ensuite envisage. Enfin, la mthode de
rservation de liens selon Traffic Engineering (TE) avec les protocoles RSVP
(Resource Reservation Protocol) et CR-LDP (Constrained Routing-Label
Distribution Protocol) sera explique.

15

Origines de MPLS

Pour aborder MPLS, il est important d'tudier les fonctionnalits existant dans l'IP
classique qui ont conduit l'laboration de ce protocole.
Avec lIP classique, la fonction de routage offre au routeur une vision de la topologie du
rseau en excutant un algorithme (par exemple, Link State Routing) et construit les
tables de routage et dacheminement. La fonction dacheminement analyse len-tte du
paquet IP et dtermine le prochain routeur vers lequel sera transmis le paquet. Il existe
deux types de routage :
Saut-par-saut ( Hop-by-hop routing ) ;
A la source ( Source routing ).
Dans le routage saut-par-saut , chaque routeur choisit le prochain routeur (ou saut) en
se basant sur sa propre table de routage. Une dcision de routage est effectue chaque
nud du rseau qui na pas besoin de connatre lintgralit de la topologie du rseau.
Dans le routage la source , le premier routeur rencontr par le paquet calcule un
chemin et spcifie lensemble des routes suivre. Un algorithme de routage de type tat
des liens est alors ncessaire.
Il est devenu alors intressant de trouver une technologie pouvant associer la puissance
de la commutation de la couche 2 avec la flexibilit du routage de la couche3.
En effet, MPLS [6] n'est pas proprement parler une technologie de niveau couche
rseau, mais plutt intermdiaire entre la couche liaison et la couche rseau.
Paradoxalement pour une couche tant situe sensiblement au niveau infrieur IP,
MPLS a besoin d'IP et des protocoles de routage associs pour exister. MPLS est une
technologie permettant d'offrir IP un mode circuit, la mode X25 ou ATM
(Asynchronous Transfer Mode).
MPLS permet de construire dans un rseau un chemin balis d'une source une
destination, ou d'un groupe de sources un groupe de destinations. Chaque chemin
labor est slectionn ds la source par l'adjonction en tte du paquet IP d'un label ou
tiquette qui entranera automatiquement un traitement particulier au niveau de
l'quipement suivant sur le rseau, en aiguillant ce paquet sur la bonne voie en lui
associant son tour un label adquat en remplacement du prcdent.

II Objectifs de MPLS
Les objectifs de MPLS sont doffrir de la QoS, cest--dire dautoriser de
nouvelles routes certains paquets IP par rapport la route par dfaut. Avec lIP
classique, le calcul dune route optimale est assur par lalgorithme de larbre de plus
court chemin SPT (Shortest Path Tree), si bien que certains chemins entre routeurs IP
ne sont jamais emprunts. Ce sont ces chemins que MPLS utilisera pour offrir de la QoS.

16

Les objectifs de MPLS peuvent se rsumer :


Augmenter les performances et la scalability (conomie dchelle) des
rseaux,
Simplifier limplmentation dun acheminement des paquets IP base sur
la QoS,
Augmenter la flexibilit au niveau du routage,
Diminuer la taille des tables de routage,
Simplifier la gestion ( management ),
Etre indpendant des couches 2 et 3 (aspect multi protocolaire), et ;
Supporter le multicast et la QoS.

III Prsentation de la technique MPLS


III.1 Modle architectural
Dans un rseau mettant en oeuvre MPLS [7], tout paquet entrant se voit attribuer
un label par un routeur de frontire ou Label Edge Router (LER). Le premier
routeur d'entre MPLS intitul MPLS Ingress Node est celui qui gre le trafic qui entre
dans un rseau MPLS. Il possde la fois des interfaces IP traditionnelles et des
interfaces connectes au rseau MPLS.
Pour un routeur donn, les routeurs situs vers la destination sont dits en aval
(downstream) alors que les routeurs situs vers la source sont dits en amont
(upstream). En dautres termes, la source dinformation est considre comme le plus
haut point.
Le routeur Ingress et lui seul, classe les paquets en amont dans des classes de service
(Class of Service , CoS) appeles FECs associes des prfixes dadresse IP et le
protocole transport, leur ajoute les labels . Chaque FEC reprsente une QoS donne.
Les paquets sont routs le long d'un tunnel dit Label Switch Path (LSP) o chaque
routeur supportant MPLS, Label Switch Router (LSR) prend les dcisions de routage
en s'appuyant seulement sur la valeur des labels. A chaque saut, le LSR remplace
l'ancien label par un autre nouveau qui indique comment router le paquet au prochain
saut. Donc les labels sont changs selon le mcanisme de Label Swapping et ne
sont donc pas routs.
A la sortie du rseau MPLS, le routeur de sortie MPLS intitul MPLS Egress Node
retire le label aux paquets sortants. Or lorsque le paquet arrive sur le LER, il n'est pas
ncessaire pour lui d'avoir toujours le label inclus dans le paquet. En effet, il va devoir
le dpiler et utiliser les mcanismes de routage qui vont lui permettre de router le paquet
vers sa prochaine destination hors du rseau MPLS. Comme les oprations de routage
sont complexes et coteuses, il est recommand d'effectuer l'opration de dpilement sur
le dernier LSR du LSP (avant-dernier nud du LSP avant le LER) pour viter de
surcharger le LER inutilement. Le routeur immdiat prcdant le routeur LER de sortie
jouant ce rle d'optimisation est dit Penultimate Node et cette option de MPLS est
dite Penultimate Hop Mapping.

17

Figure II.1 illustre un exemple dun rseau MPLS.


Ech an ge d u " lab el"
s elon F E C
et tr an sm ission

In clu sion d u " lab el"


s elon F E C
et transm ission

LSR

L E R d ' en tre

R etrait d u " label"


et rou tage

LSR

L E R d e sortie
LS R
L E R d 'en tre

Figure II.1 : Exemple dun rseau MPLS

Le routage des paquets classifis dans des FECs peut tre dtermin par diffrents
protocoles comme l'IGP (Interior Gateway Protocol), lOPSF(Open Path Shortest
Forwarding) et le BGP (Border Gateway Protocol). Chaque nouveau paquet pour
lequel il n'existe pas de FEC est associ par un label. Ensuite, tous les paquets
appartenant une FEC dj existante sur un LSR sont routs de la mme faon en
utilisant le label associ la FEC et ceci sans recalculer chaque saut une route
partir de l'adresse IP. Chaque routeur LSR construit une table LIB (Label Information
Base) pour spcifier comment un paquet doit tre achemin, cest--dire comment une
FEC est lie au label.
Figure II.2 montre un exemple dun rseau MPLS.
In
Label

Address
Prefix

Out
Label

Out
Port

In
Label

In
Port

Address
Prefix

Out
Label

Out
Port

128.89

128.89

131.69

10

128.89

LER d'entre

LER de sortie
LSR

In
Label

In
Port

Address
Prefix

Out
Label

Out
Port

128.89

128.89

10

131.69

Figure II.2 : Exemple du fonctionnement dun rseau MPLS

18

Le routeur dentre analyse ladresse IP de destination du paquet, la classe dans la FEC


de prfixe 128.89, lui adjoint ltiquette 4 et lenvoie vers linterface de sortie numro 1.
Quand le routeur intermdiaire suivant reoit ce paquet sur son interface dentre numro
2, il commute ltiquette avec une tiquette 9 et lachemine vers son interface de sortie
numro 9. Enfin le paquet IP arrive sur linterface dentre numro 1 du routeur de sortie
, se voit enlever ltiquette, analyser ladresse de destination et est transmis sur
linterface de sortie numro 0 pour tre envoy vers un routeur IP classique sans gestion
dtiquettes.
La sous-section suivante explique comment sont codes les tiquettes et comment
MPLS introduit une hirarchie dtiquettes (labels stack , pour pile dtiquettes).

III.2 Codage et hirarchie dtiquettes, agrgation


Une tiquette identifie le chemin quun paquet doit suivre et cest pourquoi il est
encapsul dans une en-tte de niveau 2, immdiatement suivi par le paquet de niveau 3
comme le montrent Figure II.3 et Figure II.4 [8] .

Figure II.3 : Trame Ethernet de base

Figure II.4 : Trame Ethernet marque MPLS

Ensuite, ltiquette est analyse par le routeur en aval pour dterminer le prochain
routeur vers lequel il sera achemin. Une fois un paquet tiquet, seule ltiquette est
utilise pour assurer la commutation (label switching). Les valeurs dtiquettes nont
quune signification locale entre deux LSR successifs.
Len-tte de ltiquette, ajoute entre len-tte de niveau 2 et len-tte de niveau 3
possde 32 bits, soit 4 octets prsents par Figure II.3.
Cette en-tte comporte 4 champs :
20 bits pour coder la valeur de ltiquette et permettant 220 - 1 = 1048575
combinaisons,
3 bits exprimentaux,
1 bit pour savoir si le paquet se trouve en bas de la pile dtiquettes, et ;
8 bits pour le TTL (Time To Live ).
Le format exact dune tiquette, et la manire avec laquelle cette tiquette est
ajoute au paquet, dpend de la technologie utilise au niveau de la couche liaison des
donnes dans le rseau MPLS considr. Par exemple, une tiquette peut correspondre
un VPI/VCI ATM (Virtual Path Identifier / Virtual Channel Identifier), un DLCI

19

Frame Relay (Data Link Channel Identifier) ou une longueur donde DWDM
(Dense Wavelength Division Multiplexing) dans les rseaux optiques. Pour dautres
types de couches de niveau 2, comme par exemple Ethernet ou PPP (Point-to-Point
Protocol), ltiquette est directement ajoute au paquet de donnes dans une en-tte
MPLS shim, qui est place entre les en-ttes des couches 2 et 3.
Dans le cas dun rseau MPLS sur ATM, ltiquette correspond un VPI/VCI ATM dont
le format est donn par Figure II.5.

Figure II.5: Encapsulation dtiquettes dans un VPI/VCI ATM

Seul le champ Label sur 20 bits, contenant la valeur de ltiquette, est conserv. Le
champ VPI/VCI peut contenir une ou deux tiquettes. Les champs PT (Payload Type),
CLP (Cell Loss Priority), et HEC (Header Error Control) restent inchangs.
La commutation MPLS est hirarchique, cest--dire quen plus de commuter des
tiquettes, il est possible den ajouter ou den enlever. Le jeu des tiquettes attach un
mme paquet IP reprsente une pile dtiquettes appele label stack. Un routeur
nanalyse que ltiquette situe au sommet de la pile. Comme une tiquette reprsente un
tunnel, avec une pile dtiquettes, il est possible de raliser des tunnels de tunnels.
Un LER dentre ralise un ajout dtiquette (push) alors quun LER de sortie ralise
une suppression dtiquette (pop) chaque niveau. Le routeur de plus bas niveau
ralise lchange dtiquettes (swap) tout comme les routeurs des niveaux
hirarchiques suprieurs (quils soient Ingress , Egress ou intermdiaires).
Une tiquette tant ajoute quand le paquet passe un niveau hirarchique plus lev, la
pile dtiquettes sallonge et le TTL est systmatiquement positionn 0. Seul le TTL
correspondant au plus bas niveau de la hirarchie (level N) est positionn 1 pour dire
que la pile dtiquettes ne possde plus quune tiquette.
Ceci est montr dans Figure II.6.

Figure II.6: Architecture des tiquettes hirarchiques MPLS

20

III.3 Distribution dtiquettes


Afin de pouvoir utiliser les LSPs, les tables dacheminement de chaque LSR
doivent effectuer un lien du couple {interface dentre, valeur dtiquette} vers le couple
{interface de sortie, valeur dtiquette}. Ce processus est appel la distribution
dtiquettes, ou la configuration des LSPs.
LIETF ne spcifie pas un protocole unique de distribution des tiquettes entre les LSRs,
mais au contraire recommande le recours des protocoles multiples, pour une utilisation
adapte aux diffrents scnarios possibles.
De ce fait, plusieurs approches peuvent tre envisages pour la distribution dtiquettes,
et ceci indpendamment des besoins matriels intrinsques du rseau MPLS, et des
politiques de gestion utilises sur le rseau.
Le principe est quun LSP est configur soit en rponse une requte du LER dentre ,
ce qui correspond au mode downstream-on-demand, soit dune manire premptive
par les LSRs du rseau ou le LER de sortie , ce qui correspond au mode downstream
unsolicited.
Le cas o les deux types de configurations se ralisent en mme temps est une situation
envisageable. Le LSP rsultant sera alors compltement configur vers le milieu du
rseau MPLS, au point de rencontre des deux types de configuration.
Dans tous les cas, les tiquettes sont alloues dans le sens montant (le sens montant tant
pris comme celui contraire au flux de donnes), ce qui signifie que linformation relative
lallocation se propage en direction de la source des donnes.
Figure II.7 permet dillustrer ces propos.
21

LSR B

L E R d 'e n t r e
LSR A

17

47

11

L E R d e s or t ie
LSR D

L E R d e s or t ie
LSR C

Figure II.7: Cas de deux LSPs dans un rseau MPLS

Le LSR D informe le LSR B que ce mme LSR doit utiliser ltiquette (47) pour tous
les paquets destins lutilisateur Z. Le LSR B alloue alors une nouvelle tiquette (21),
introduit la correspondance dans sa table dacheminement, et informe enfin le LSR A
que ce mme LSR doit utiliser ltiquette (21) pour tous les paquets destins
lutilisateur Z.
Plusieurs options sont possibles pour contrler la configuration des LSPs, cest--dire la
distribution dtiquettes selon les protocoles utiliss est dcrite ci-aprs :
Le processus dallocation des tiquettes saut par saut route les
demandes de distribution dtiquettes en direction du destinataire, LSR
aprs LSR. La distribution dtiquettes peut tre initie lors de la mise

21

jour des tables de routage ou en rponse un nouveau flux de trafic.


LIETF a recommand le protocole LDP (Label Distribution Protocol)
pour lallocation dtiquettes saut par saut. Ce dernier ne tient pas
compte de notion de la QoS ou de TE. Dautres protocoles comme RSVP
et CR - LDP peuvent galement tre utiliss.
Dans le mode de distribution dtiquettes downstream unsolicited, le
LER de sortie distribue ltiquette utiliser vers lutilisateur. Ce
processus est gnralement dclench par la rception de nouvelles
informations de routage au niveau du nud de sortie. De plus, si la
mthode de distribution des labels est contrle ordonn (Ordered
Control), chaque LSR amont distribue une tiquette encore plus en
amont. Ce procd conduit rapidement la cration dun arbre de LSPs
dont les racines sont les LERs de sortie. LDP est actuellement le seul
protocole pouvant raliser ce mode de distribution des tiquettes.
Une fois que des LSPs ont t tablis travers le rseau MPLS, ils
peuvent tre utiliss pour fournir de nouvelles routes ds quils seront
disponibles. Comme les protocoles de routage, par exemple BGP,
distribuent les nouvelles informations de routage vers lamont, ils peuvent
aussi indiquer quelle tiquette, cest dire quel LSP, doit tre utilis pour
atteindre les destinations joignables par ces routes.
Si un LER de sortie veut configurer un LSP qui ne suit pas le chemin de
routage prvu, il doit alors utiliser un protocole de distribution
dtiquettes qui permet de spcifier une route explicite. Cela demande une
distribution dtiquettes de type downstream-on-demand. CR-LDP et
RSVP permettent cette fonctionnalit.
Un LER dentre peut aussi vouloir configurer un LSP fournissant un
niveau de service particulier, comme par exemple la rservation de
ressources chaque LSR intermdiaire, sur toute la longueur du chemin.
Dans ce cas, la route correspondant ce LSP peut tre compromise par la
disponibilit des ressources et la capacit des nuds garantir la QoS
requise. L encore, CR-LDP et RSVP sont les deux protocoles autorisant
la distribution dtiquettes de type downstream-on-demand, et ils
permettent galement les demandes de besoins spcifiques de garanties de
services.
Les protocoles CR-LDP et RSVP seront tudis en dtail et compars dans les
paragraphes suivants.

III.4 Route explicite


Une route explicite est un enchanement prcis dtapes entre lentre et la sortie
dun rseau MPLS. Un LSP peut tre configur pour suivre un chemin explicite, cest-dire une liste dadresses IP. Cependant, il nest pas ncessaire que ce chemin soit dcrit
entirement. Par exemple, la route peut se limiter spcifier uniquement les deux
premiers sauts effectuer. Aprs que le dernier saut faisant partie de la spcification ait

22

t atteint, le routage des LSPs seffectue suivant le routage dit de saut par saut.De
plus, une partie de route explicite nest pas ncessairement spcifie autant en dtail.
Un ensemble de nuds peut tre considr comme une tape dans la route, par exemple
en utilisant un prfixe IP plutt quune adresse prcise. Le LSP doit alors tre rout
jusqu un ou certains des nuds faisant partie de cet ensemble de nuds. La route peut
contenir plusieurs sauts faisant partie de lensemble de nuds avant dmerger jusquau
prochain saut spcifi par la route explicite.
Dautre part, une route explicite peut tre qualifie de stricte (strict) ou de non stricte
(loose). Une route stricte doit contenir seulement les nuds spcifis par la route
explicite, et doit les utiliser dans lordre prtabli. Une route non stricte doit inclure tous
les sauts spcifis, et doit conserver lordre, mais peut galement inclure des sauts
supplmentaires et ncessaires pour joindre les nuds spcifis.
Les routes explicites sont particulirement utiles pour contraindre un LSP utiliser un
chemin diffrent de celui prconis par le protocole de routage. Elles peuvent galement
tre utilises pour rpartir le trafic dans un rseau charg, pour tablir des routes
contournant les points de congestion ou les points dfaillants, ou pour fournir des LSPs
de secours pr-allous en cas de panne du rseau.

III.5 Route base contrainte


Lappellation route base contrainte provient de la traduction directe du terme
anglais Constraint Based Routes (CBR). La route quemprunte un LSP peut tre force
partir du LER dentre du rseau selon certains critres, dont le nombre est assez
important. Une route explicite est un exemple de route base contrainte, o la contrainte
est lordre dans lequel les LSRs intermdiaires doivent tre joints. Dautres types de
contraintes peuvent tre imposes par une description prcise du trafic devant tre assur.
Dans ce cas sont dfinis la bande passante, le dlai, les classes et priorits des diffrentes
ressources.
Une approche consiste ce que le LER dentre calcule entirement la route base
contrainte en se fondant sur les contraintes et les informations de ltat actuel du rseau.
Ceci conduit ltablissement dune route explicite satisfaisant les contraintes nonces.
Une autre approche possible consiste faire varier le routage saut par saut, o chaque
LSR, le saut suivant est calcul en utilisant les informations dtenues par ce LSR et
concernant la disponibilit des ressources locales.
Ces deux approches peuvent tre combines, notamment lorsque linformation des
segments de route est indisponible, par exemple, lors de la traverse dun systme
autonome. Dans ce cas, la route peut tre spcifie en partie, et ce non strictement, puis
route explicitement en utilisant les contraintes l o elles sont requises.
III.5.1 Le protocole CR-LDP
CR-LDP est une version tendue de LDP spcialement destine faciliter le
routage bas sur la contrainte des LSPs. Certains champs sont ajouts au protocole LDP
dcrivant les caractristiques de la connexion : Peak , Comitted , Excess .

23

Figure II.8 illustre les champs ajouts dans CR-LDP.

Figure II.8: Champs ajouts dans CR-LDP

Ce protocole est dit hard state car la liaison est tablie pendant toute la dure spcifie
du transfert jusqu' ce qu'elle soit explicitement ferme.
Tout comme, LDP, CR-LDP utilise des sessions TCP entre les LSRs, au cours desquelles
il envoie les messages de distribution des tiquettes. Ceci permet en particulier CRLDP dassurer une distribution fiable des messages de contrle.
Les changes dinformations ncessaires ltablissement des LSPs utilisant CR-LDP
sont dcrits dans Figure II.9.
L abel R equest (C )
L abel R equest (B ,C )
L SR B
L E R d' entre
LE R de sortie
Label M apping (17)
Label M apping (32)
LSR A
LSR C
Figure II.9: Procdure dtablissement des LSPs avec CR-LDP

Le LER dentre (LSR A) dtermine quil est ncessaire dtablir un


nouveau LSP jusquau LSR C. Les paramtres et critres de trafic requis
pour la session permettent au LSR A de dterminer que la route pour le
nouveau LSP doit passer par le LSR B, puis aller vers le LSR C. Cette
route nest dailleurs vraisemblablement pas la mme que la route saut par
saut pour aller du LSR A jusquau LSR C. Le LSR A construit alors un
message Label Request contenant une route explicite (B, C) et les
dtails des paramtres de trafic demands pour la nouvelle route. Le LSR
A rserve les ressources dont il a besoin pour le nouveau LSP, et envoie le
message Label Request constitu vers le LSR B en utilisant une session
TCP.

24

Le LSR B reoit le message Label Request, dtermine quil ne doit pas


tre considr comme le LER de sortie vis--vis de ce LSP, et quil doit
donc envoyer le message sur la route spcifie. Le LSR B rserve alors
les ressources ncessaires pour le nouveau LSP, modifie la route explicite
dans le message Label Request, et envoie le message au LSR C. Il faut
noter que si les paramtres de trafic taient marqus comme tant
ngociables dans le message Label Request ou message de demande
dtiquettes, le LSR B pourrait alors rduire la rservation des ressources
alloues au nouveau LSP.
Le LSR C reoit son tour le message Label Request, et dtermine
quil est bien le LER de sortie pour ce nouveau LSP. Il effectue alors les
dernires ngociations de ressources puis les alloue au LSP. Le LSR C
attribue ensuite une tiquette au nouveau LSP et distribue cette tiquette
au LSR B dans un message Label Mapping ou message dassociation
dtiquettes, qui contient les dtails des paramtres finaux du trafic
rserv pour le LSP.
Le LSR B reoit le message Label Mapping et le fait correspondre la
demande originale en utilisant lidentit du LSP contenue la fois dans
les messages Label Request et Label Mapping . Le LSR B finalise
les rservations de ressources, attribue une tiquette au LSP, configure sa
table de routage, et envoie la nouvelle tiquette au LSR A dans un
message Label Mapping.
Le processus est le mme au niveau du LSR A, mais celui-ci na pas
attribuer une nouvelle tiquette et la propager vers les LSRs amonts,
puisquil est le LER dentre pour ce nouveau LSP.
Un LSP, appel CR-LSP (Constrained RouteLabel Switched Path) est
alors tabli entre le LER dentre et celui de sortie.
III.5.2 Le protocole RSVP
Le protocole RSVP utilisait initialement un change de messages pour rserver
les ressources des flux IP travers un rseau. A l'origine, ce protocole tait prvu pour
rclamer la bande passante requise et des conditions de trafic sur un certain chemin, et le
lien n'tait tabli que si la bande passante ncessaire tait disponible. Il dfinissait trois
types de trafic sur les liens via des paramtres IntServ (Integrated Services) :
guaranteed load, controlled load et best-effort load.
Une version tendue de ce protocole, en particulier pour permettre les tunnels de LSP,
autorise actuellement RSVP tre utilis pour distribuer des tiquettes MPLS.
RSVP est un protocole compltement spar de la couche IP, qui utilise des paquets IP
(ou UDP aux limites du rseau) pour communiquer entre les LSRs. RSVP ne requiert pas
la maintenance ncessaire aux connexions TCP, mais doit nanmoins tre capable de
faire face la perte de messages de contrle.

25

Les changes dinformations ncessaires ltablissement de LSP permettant les tunnels


de LSP et utilisant RSVP sont dcrits dans Figure II.10.
P at h (C )

P a th (B ,C )
LS R B

L E R d 'entre
LS R A

RE S V - L a b el (1 7 )

R E SV -L ab el (3 2 )

LE R d e sortie
LS R C

Figure II.10: Procdure dtablissement des LSPs avec RSVP

Le LER dentre (LSR A) dtermine quil est ncessaire dtablir un


nouveau LSP jusquau LSR C. Les paramtres et critres de trafic requis
pour la session permettent au LSR A de dterminer que la route pour le
nouveau LSP doit passer par LSR B, puis aller vers LSR C. Cette route
nest dailleurs vraisemblablement pas la mme que la route saut par saut
pour aller du LSR A jusquau LSR C. Le LSR A construit alors un
message de chemin (Path message) contenant une route explicite (B, C)
et les dtails des paramtres de trafic demands pour la nouvelle route. Le
LSR A envoie le message Path comme paquet IP vers le LSR B.
Le LSR B reoit le message Path , dtermine quil ne doit pas tre
considr comme le LER de sortie vis--vis de ce LSP, et quil doit donc
envoyer le message sur la route spcifie. Le LSR B modifie alors la route
explicite dans le message Path , et envoie le message au LSR C.
Le LSR C reoit son tour le message Path , et dtermine quil est
bien le LER de sortie pour ce nouveau LSP. En fonction des paramtres
de trafic demands, le LSR C dtermine la bande passante ncessaire pour
rserver et allouer les ressources. Le LSR C attribue ensuite une tiquette
au nouveau LSP et distribue cette tiquette au LSR B dans un message de
rservation (RESV message ), qui contient les dtails de la rservation
des ressources pour le LSP.
Le LSR B reoit le message de rservation et le fait correspondre la
demande originale en utilisant lidentit du LSP contenue la fois dans
les messages Path et RESV . A partir des dtails du message
RESV , le LSR B dtermine quelles ressources doivent tre rserves,
attribue une tiquette au LSP, configure sa table de routage, et envoie la
nouvelle tiquette au LSR A dans un message RESV.
Le processus est le mme au niveau du LSR A, mais celui-ci na pas
attribuer une nouvelle tiquette et la propager vers les LSRs amonts,
puisquil est le LER dentre pour ce nouveau LSP.
Un CR-LSP est alors tabli entre le LER dentre et celui de sortie.
Ce protocole est dit soft state car la liaison n'est tablie que pendant la dure spcifie
par des temporisateurs envoye dans les messages RESV. Il faut alors rtablir la
liaison une fois ce temps coul en recommenant la demande rservation pour continuer
couler le trafic.

26

III.5.3 Comparaison entre CR-LDP et RSVP


Les principales diffrences entre CR-LDP et RSVP sont essentiellement la
fiabilit des protocoles de transport utiliss (IP dans le cas de RSVP et TCP dans le cas
de CR-LDP), et le sens dans lequel seffectue les rservations de ressources (sens
montant pour RSVP et sens descendant pour CR-LDP).
Ces diffrences, ainsi que dautres, sont rsumes dans Tableau II.1.
Comparaison

CR-LDP

RSVP

Transport

TCP

Couche IP

Scurit

Oui

Oui

Mutlipoint-to-point

Oui

Oui

Support de multicast

Non

Non

Support de plusieurs
LSPs

Oui

Oui

Hard

Soft

Etat de LSP

Strict avec portions


approximatives

Re-routage

Strict avec portions


approximatives
Oui, par chemin
enregistr

Assignation de routes

Oui

Premption de LSP

Oui, avec priorit

Oui, avec priorit

Protection LSP

Oui

Oui

Maintient des LSPs

Non ncessaire

Priodique,
saut par saut

Haute disponibilit

Non

Oui

Rservations partages

Non

Oui

Contrle de trafic

En descendant

En montant

Policy Control

Implicite

Explicite

Non

Oui

Oui

Non

Type de QoS

ATM

IntServ

Temps dtablissement

Un peu plus lent

Rapide

A faire avant cassure

A faire avant cassure

Protocole de niveau 3
indiqu
Contrainte de classe de
ressources

Modifications des
chemins

Tableau II.1: Comparaison de CR-LDP % RSVP


RSVP et CR-LDP savrent tre tous les deux de bonnes solutions techniques pour la
configuration et la gestion de LSPs utilisant lingnierie de trafic.

27

Les diffrences, tant dans la structure de ces protocoles que dans les protocoles de
transport associs, permettent de conclure que lapport inhrent RSVP et CR-LDP ne
pourra jamais converger compltement. De plus, les diffrences du Tableau II.1, ainsi
que celles de vitesse et de possibilit de dploiement seront les principaux facteurs
permettant de faire un choix entre ces deux protocoles.

III.6 Ingnierie de trafic et qualit de service


Des protocoles comme LDP ou BGP permettent de router des paquets au sein
d'un rseau MPLS, mais ne peuvent viter les congestions s'ils redirigent les paquets vers
un LSP de priorit haute.
Lingnierie de trafic, ou TE, permet aux administrateurs rseaux d'optimiser l'emploi
des liaisons en tablissant des tunnels LSPs dans un rseau MPLS, indpendamment de
l'IGP. Ceci peut tre combin avec la rservation de bande passante.
Les LSPs peuvent servir mettre en oeuvre la notion de la rpartition de charge (load
balancing) et de la haute disponibilit (high availability) via l'utilisation de plusieurs
LSPs.
La qualit de service, ou QoS, rajoute des contraintes telles que la garantie de bande
passante, la priorit, la dure de vie d'un paquet, la classe de service associe. Des
propositions sont faites pour rajouter ses informations dans le champ appel Exp.
Des propositions ont t faites pour intgrer DiffServ (Differentiated Services) [9] au
sein de MPLS via des extensions [10].
Un certain nombre de protocoles existent qui permettent de prendre en compte des
notions de QoS tels CR-LDP, RSVP-TE ou OSPF-TE. Ce sont des extensions pour
respectivement les protocoles LDP, RSVP et OSPF.
Le principe du TE dans MPLS est d'utiliser des tunnels unidirectionnels pour dcaler le
trafic d'un chemin sur un autre. Les tunnels peuvent tre dtermins statiquement ou
automatiquement par les LSRs. Plusieurs tunnels peuvent tre utiliss pour rpartir le
trafic si celui-ci est trop important pour tre vhicul par un seul chemin.
Le TE consiste router les donnes travers le rseau suivant une vision de gestion de la
disponibilit des ressources, et du trafic courant et attendu. La CoS et la QoS requises
pour les donnes peuvent aussi tre prises en compte.
Le TE peut tre sous le contrle doprateurs manuels. Ils surveillent ltat du rseau et
routent le trafic ou rservent des ressources supplmentaires pour pouvoir faire face
dventuels problmes naissant. D'une manire alternative, le TE peut aussi tre men
par des processus automatiss, ragissant aux informations relatives ltat du rseau qui
sont envoyes entre autres par les protocoles de routage.
Le TE aide le fournisseur de rseau optimiser au mieux les ressources disponibles,
rpartissant la charge des liaisons de niveau 2, et autorisant quelques liaisons tre
rserves pour certaines classes de trafic, ou pour des clients particuliers.
Ainsi, pour assurer le service demand, il ne suffit pas de slectionner une route pouvant
fournir suffisamment de ressources. Ces ressources doivent tre rserves pour assurer
quelles ne seront pas partages ou voles par dautres LSPs plus tard. Les critres
ncessaires ltablissement dun trafic adapt peuvent tre achemins lors de la
configuration des LSPs, ou avec le routage bas contrainte. Ces critres sont utiliss

28

chaque LSR pour rserver les ressources ncessaires, ou pour signaler un chec
dtablissement de LSP dans le cas de ressources insuffisantes.
Une des principales utilisations du MPLS est de fournir du TE amlior sur les rseaux
fdrateurs des fournisseurs de services Internet. En particulier, pour lutilisation de
services ncessitant diffrents niveaux de priorits, tels que le transport de voix ou de
vido sur Internet, MPLS permet dviter le recours une politique de
surdimensionnement des rseaux physiques pratique jusqualors, en allouant les
ressources du rseau des LSPs utilisant le routage bas contrainte.

III.7 Avantages de MPLS


MPLS permet de simplifier ladministration du rseau de cur en ajoutant des
fonctionnalits pour grer la QoS. Tout comme DiffServ, MPLS permet de rduire le
cot des traitements associs lacheminement des paquets en les reportant la
priphrie du rseau et en rduisant la frquence.
MPLS apporte un routage hirarchique efficace grce aux tunnels qui permettent de grer
les rseaux privs virtuels ou VPN.
MPLS est un outil puissant dagrgation. En effet, les tables dacheminement interroges
pour chaque paquet dans chaque routeur peuvent avoir une taille rduite car le nombre
des tiquettes ne dpend plus du nombre de prfixes annoncs par les oprateurs mais du
nombre de routeurs en sortie du rseau.
Avec MPLS, le routeur suivant (en aval) peut ne pas tre le routeur par dfaut, ce qui
permet la QoS. MPLS remet en cause la notion de routage traditionnel. En effet, les
protocoles de routage internes empchent les oprateurs de grer leurs ressources car ils
privilgient certaines routes. Cela pose un problme pour offrir des services de VPN.
Avec MPLS, il devient possible de configurer les FECs dans les routeurs Ingress et les
tables dacheminement dans les quipements de cur afin dimposer un chemin diffrent
du chemin par dfaut et de rserver des ressources sur ce nouveau chemin. Pour cela, les
protocoles RSVP et CR-LDP dcrits dans les paragraphes prcdents sont utiliss.
III.7.1 Protocoles de routage ou de dcouverte du rseau
En vue de dterminer et de maintenir la connaissance des noeuds dentre et de
sortie, il faut utiliser un protocole permettant la dcouverte du rseau. MPLS peut
s'appuyer sur un ensemble de protocoles dj disponibles. Un ensemble de rseaux
MPLS peuvent tre interconnects chacun utilisant leur propre protocole de dcouverte
tel que BGP, IGP, OPSF etc ...
III.7.2 Scurit
La sparation des flux entre clients sur des routeurs mutualiss supportant MPLS
est assure par le fait que seule la dcouverte du rseau se fait au niveau de la couche 3 et
qu'ensuite le routage des paquets est effectu en s'appuyant uniquement sur le mcanisme
des tiquettes (intermdiaire entre la couche 2 et la couche 3).Le niveau de scurit est
le mme que celui de Frame Relay avec les DLCI au niveau 2.

29

Le dni de service est en gnral effectu au niveau 3. Ici, les paquets seront quand
mme routs jusqu'au destinataire au travers du rseau MPLS en s'appuyant sur les LSPs.
III.7.3 Les applications
Le choix de MPLS par les oprateurs est motiv par diffrents aspects :
L'acclration du temps de transit des paquets,
La mise en oeuvre de la QoS,
Les possibilits de gestion du trafic ou TE pour viter les congestions des
rseaux ou encore amener de la redondance,
L'tablissement de tunnels IP permettant la mise en oeuvre des VPNs,
L'utilisation de MPLS sur un ensemble de rseaux htrognes permet de
remonter certains contrle de la couche 2 la couche 3 et amne ainsi une
simplification de la gestion des rseaux pour les oprateurs et par l mme
une simplification de gestion de service sur des rseaux tels ATM ou
Frame Relay,
La possibilit de cohabitation de MPLS orient connexion avec IP orient
non connexion,
Mise en place de circuit-switched paths travers des LSPs en tant
indpendant de la technologie employe la couche de niveau 2,
Problmatique de migration vers un coeur de rseau base sur une
technologie autre qu'ATM,
Routage explicite ou via un protocole de routage, et ;
Diminution des cots.
Les applications pour les clients peuvent se rsumer en ces points :
Mise en place de la QoS,
Scurit : cration de VPNs au niveau 2 ou 3,
Mise en oeuvre d'Intranet /Extranet ou niveau de la couche 2 ou 3,
Connectivit Any-to-Any ,
Mise en place de Communauts d'intrts via des Open VPNs,
Possibilit d'utiliser des solutions de cryptage par-dessus des MPLSVPNs,
Scurit, QoS, TE,
Voix et Vido avec dbit garanti en fonction des contraintes temps rel,
Tlphonie et plus gnralement tout service avec des contraintes au
niveau temporel,
Solutions de redondance pour le back up du trafic en cas de rupture,
Mise en place de rseaux compltement maills au niveau de la couche3,
Mise en place de Virtual Private Lines, VPLs directement au niveau de
la couche 2,
Mise en place de rseaux partiellement maills au niveau de la couche 2
avec une indpendance de la solution utilise ( Frame Relay ou ATM),
et ;

30

Transport au niveau de la couche 2 de n'importe quel protocole de la


couche 3, permettant la convergence des applications.
III.7.4 Virtual Private Network
Les VPNs [11] s'appuyant sur le protocole MPLS, sont diffrents de l'image
classique du VPN, savoir un tunnel crypt tabli la couche 3. Par dfaut les tunnels
VPN btis sur MLPS ne sont pas crypts et s 'apparentent plutt des PVCs (Private
Virtual Circuit) comme avec ATM ou Frame Relay plutt qu' des PVCs tablis
avec IpSec ou PPTP ( Point-to-Point Tunneling Protocol ). Ils s'appuient sur la
sparation des paquets sur la valeur de leurs tiquettes et n'utilisent pas de mthode de
cryptage ou d'encapsulation. La valeur de cette tiquette n'est lue que par les LSRs qui
appartiennent un LSP prcis.
MPLS-VPN permet d'isoler le trafic entres sites n'appartenant pas au mme VPN, et en
tant totalement transparent pour ces sites entre eux. Il permet d'utiliser un adressage
priv sans utilisation de fonctionnalit de NAT et d'avoir un recouvrement d'adresses
entre diffrents VPNs.

IV Conclusion
Ce chapitre a mis en vidence la technologie de MPLS. Les origines de MPLS ont
t discutes ainsi que ses objectifs. Le modle architectural de la technique MPLS a t
prsent expliquant linfrastructure utilise. Le codage et la distribution dtiquettes entre
les routeurs ont t envisags. Les protocoles RSVP et CR-LDP ont t dcrits et une
comparaison entre eux a t tablie. La contribution de MPLS dans lingnierie de trafic
ainsi que dans ltablissement dune qualit de service a t mentionne. Puis une
analyse des avantages de MPLS a t dtaille.
Aprs avoir tudi en dtail le fonctionnement de Mobile IPv4 et sa transition vers IPv6
et avoir dcrit lopration de MPLS, le chapitre suivant abordera le but essentiel de ce
projet qui est lintgration de Mobile IP et MPLS.

Chapitre III:
Intgration de
Mobile IPv4 avec MPLS

Comme est indiqu au Chapitre I, Mobile IP est un protocole qui permet des
utilisateurs de se dplacer d'un rseau un autre tout en conservant leurs adresses IP et
en maintenant leurs connectivits avec l'Internet.
Chapitre II a mis en uvre le protocole MPLS qui combine la simplicit d'acheminement
d'IP ainsi que la commutation rapide d'ATM.
Ce chapitre propose une mthode d'intgration des protocoles Mobile IPv4 avec MPLS.
Section I rappelle les problmes de Mobile IPv4 tels que le problme de passage
lchelle et les problmes de performance. Section II prsente le principe d'intgration de
Mobile IPv4 avec MPLS. Les mcanismes de signalisation et de contrle sont dtaills
dans plusieurs scnarios. Section III dcrit l'amlioration ajoute par le routage optimis
qui se traduit par un routage de donnes plus efficace.
Enfin, une conclusion est tablie.

I Problmes de passage lchelle dans Mobile IPv4


Comme mentionn au Chapitre I, Mobile IPv4 repose sur trois activits: le
procd de dcouverte des agents, le procd d'enregistrement et le processus
d'expdition des donnes. Il est important que ces trois activits fonctionnent
conformment quand le nombre des noeuds mobiles s'accrot normment.
Or le processus d'expdition des donnes un nud mobile se trouvant dans un rseau
tranger ncessite plusieurs tapes de signalisation : le HA doit examiner si l'adresse
destination du paquet correspond un nud dj inscrit chez lui. Si oui, un tunnel IPv4IPv4 doit tre tabli avant de passer au processus d'acheminement.
Dans le cas o le mobile est toujours dans son rseau mre, le HA lui fournit directement
les paquets.
Il est souvent notable que la quantit de traitement exige par le HA dans l'expdition des
donnes dpend du nombre de noeuds mobiles actifs appartenant au rseau mre et ceux
prsents dans les rseaux trangers visits et qui sont dj inscrits avec le HA. Si le

32

nombre de ces nuds est considrable, les processus d'encapsulation et d'expdition


seront de plus en plus ralentis et une consommation des ressources disponibles au HA est
considrablement remarquable.
En outre, le processus de consultation des tables de routage introduit galement un
retard significatif quand il y a un grand nombre dentres.
Ces problmes de passage l'chelle peuvent essentiellement nuire au fonctionnement de
Mobile IPv4 lors de son introduction dans les rseaux cellulaires donc il est important
dexposer dans la section suivante la solution dintgration avec MPLS [12].

II Intgration de Mobile IPv4 avec MPLS


La stratgie d'intgration de Mobile IPv4 avec MPLS est explique dans cette
section. Les mcanismes de signalisation et de contrle seront tudis selon plusieurs
cas:
Cas d'un simple domaine MPLS,
Cas de plusieurs domaines MPLS, et ;
Cas de routage optimis.
Dans chaque cas, les procdures d'enregistrement et d'acheminement des donnes
seront expliques. A noter que la mthode de distribution des tiquettes utilise est le
LDP standard.
Annexe A propose une mthode de distribution des tiquettes base sur une extension de
Mobile IP [13].

II.1

Cas d'un simple domaine MPLS

MN
LSR3
LSR1

FA / LER

LSR2

CN
Dom aine M PLS

LSR4

H A / LER

MN

Figure III.1 : Exemple dune topologie dun rseau

Figure III.1 illustre un exemple d'une topologie d'un rseau dans le cas o le HA
et le FA sont des LSRs de sortie et appartiennent un mme domaine MPLS. Ils
supportent alors les fonctionnalits de Mobile IPv4 et de MPLS.
L'adresse mre du mobile est "a.b.c.d" et celle du HA est "a.b.c.e". L'adresse du FA donc
la COA est "w.x.y.z".

33

II.1.1

Procdure denregistrement

Les tapes dtablissement de la procdure denregistrement sont les suivants :


(1) Le mobile dtermine s'il se trouve dans son rseau mre ou dans un rseau
tranger selon les messages Agent Advertisment reus.
(2) Sil est dans un rseau tranger, le mobile acquiert une COA du FA
et
envoie un message de demande d'enregistrement Registration Request au HA
travers le FA.
(3) Comme le FA est un LER, il analysera le message entrant de la demande
d'enregistrement et obtiendra l'adresse du HA contenue dans le message.
(4) La table de routage du FA sera mise jour et une range correspondant
l'adresse permanente du mobile sera ajoute. En outre, la valeur du port de sortie de
cette entre sera celle du port entrant d'o la demande d'enregistrement a t reue.
(5) Le message de demande d'enregistrement sera achemin vers le HA selon la
table de routage du FA.
(6) Le paquet est achemin saut-par-saut au HA utilisant l'acheminement
normal d'IP.
(7) Quand le HA reoit le message de demande d'enregistrement et apprend la
COA, il recherche dans sa table d'expdition (Table of Labels) une range dont la FEC
correspond l'adresse du mobile. Ceci est montr par la deuxime range du Tableau
III.1, mais on remarque que le port sortant et l'tiquette sortante sont vides du fait que le
mobile tait prcdemment dans son rseau mre.
(8) Le HA envoie la suite un message de demande d'tiquettes de LDP [14]
(Label Request) au FA avec la FEC correspondant la COA. Le FA rpond avec un
message d'association d'tiquettes (Label Mapping). Quand cette tiquette arrive au
HA, un LSP sera tabli entre le HA et le FA. L'entre de ce LSP dans la table
d'expdition est montre dans la premire range du Tableau III.1.
(9) Ensuite, le HA change la range de sa table d'expdition qui pointait
l'adresse du mobile comme FEC et ajuste les valeurs de l'tiquette sortante et du port
sortant aux valeurs de l'tiquette sortante et du port sortant du LSP du HA au FA. De
cette faon, le HA peut transmettre les paquets destins au mobile quelle que soit sa
position courante dans le rseau tranger.
(10) Le HA envoie ensuite une rponse d'enregistrement (Registration Reply)
au FA le long du LSP dj tabli.

34

(11) Quand le FA reoit la rponse d'enregistrement, la valeur du port entrant et


la valeur de l'tiquette entrante du message de rponse seront enregistres. Une nouvelle
range est alors ajoute dans sa table d'expdition avec la COA comme FEC et le port
sortant et l'tiquette sortante vides.
Tableau III.1 montre la table d'expdition du HA aprs l'enregistrement.
In Port

In Label

FEC

Out Label

Out Port

w.x.y.z

a.b.c.d

Tableau III.1 : Exemple de la table dexpdition du HA aprs lenregistrement


Le port sortant et la valeur d'tiquette sortante du LSP tabli sont 1 et 5 respectivement
comme le montre la premire range du Tableau III.1. Puisque le HA est un LER
d'entre pour ce LSP, l'entre d'tiquette entrante est vide.
La deuxime range correspond au LSP tabli entre un correspondant et le mobile.
Puisque le HA est un LER de sortie pour ce LSP, le port sortant et l'tiquette sortante
sont toutes les deux vides l'origine mais aprs la rception de la demande
d'enregistrement, ces deux valeurs correspondront aux valeurs du port sortant et de
l'tiquette sortante du LSP tabli entre le HA et le FA.
Figure III.2 illustre le procd d'enregistrement dans Mobile IPv4.

MN

FA / LER

HA / LER

Annonce des agents


Demande
d'enregistrement

Demande
d'enregistrement
Demande
d'tiquettes
Association
d'tiquettes

Rponse
d'enregistrement

Rponse
d'enregistrement

Figure III.2 : Procdure denregistrement de Mobile IPv4

Tableau III.2 illustre la table d'expdition du FA aprs la rception de la rponse


d'enregistrement. La valeur du port entrant est celle du port entrant do est parvenue la

35

rponse d'enregistrement. La valeur d'tiquette entrante contient celle d'tiquette de la


rponse d'enregistrement. La valeur du FEC est la COA du FA. Le port sortant et
l'tiquette sortante sont vides puisque le LSP se termine au niveau du FA.
In Port

In Label

FEC

Out Label

Out Port

w.x.y.z

Tableau III.2 : Table dexpdition du FA aprs la rception de la rponse denregistrement

II.1.2

Livraison des paquets

La livraison de paquets seffectue selon les tapes suivantes:


(1) Un correspondant envoie un paquet de donnes au mobile selon son adresse
mre. Si le mobile se trouve dans un rseau tranger, le paquet sera expdi au HA.
(2) Le HA cherche la valeur de l'tiquette entrante correspondant l'adresse du
mobile dans sa table d'expdition. En rfrence au Tableau III.1, les valeurs de
l'tiquette sortante et du port sortant seront celles trouves dans la deuxime range de la
table d'expdition.
A noter que dans le cas o le mobile se trouve dans son rseau mre, le port sortant et
l'tiquette sortante auront des valeurs vides. Le paquet serait alors envoy la couche IP
et serait achemin au mobile selon le port indiqu dans la table de routage.
(3) Si le mobile est dans un rseau tranger, le paquet est livr le long du LSP
dj tabli entre le HA et le FA.
(4) Le FA reoit le paquet et recherche dans sa table d'expdition l'entre
correspondante. Comme il est le LER de sortie, le port sortant et l'tiquette sortante ont
des valeurs vides. Le FA envoie alors le paquet la couche IP.
(5) Enfin, le FA envoie le paquet au mobile selon l'information prsente dans la
range spcifique de la table de routage qui a t ajoute lors de la procdure
d'enregistrement dj dcrite.

36

Figure III.3 illustre le procd de livraison de paquets.

CN

FA / LER

MN

H A / LER

Paquet
de donnes

Paquet
de donnes

C onsultation de
la table d'expdition

LSP

Consultation de
la table de routage
Paquet
de donnes
Figure III.3 : Procdure de livraison de paquets

II.1.3

Handoff

Dans cette section, la procdure d'enregistrement et la procdure de la livraison


de donnes au mobile se dplaant d'un rseau tranger un autre sont tudies. Ce
dplacement est dit Handoff.
Figure III.4 illustre l'autre rseau tranger manipul par un autre FA dont la COA est
a.s.d.f .

MN
Nouveau FA / LER

MN
LSR3 Ancien FA / LER

LSR1

LSR2

CN
Domaine M PLS

LSR4

HA / LER

MN

Figure III.4 : Exemple dun handoff dun mobile

Une fois que le mobile se dplace un nouveau FA:


(1) le procd d'enregistrement dcrit dans la section prcdente est rpt encore
une fois entre le HA et le nouveau FA.

37

(2) Aprs l'enregistrement, une nouvelle range sera insre dans la table
d'expdition du HA, comme le montre le Tableau III.3. La troisime range contient
l'tiquette pour le nouveau LSP tabli entre le HA et le nouveau FA. Les valeurs du port
sortant et de l'tiquette sortante dans la deuxime et la troisime range sont identiques
pour que les paquets destins au mobile puissent lui tre transmis aprs son dplacement.
In Port

In Label

FEC

Out Label

Out Port

w.x.y.z

a.b.c.d

a.s.d.f

Tableau III.3 : Table dexpdition du HA lors du handover du mobile


Le nouveau FA doit ajouter une range dans sa table de routage pour la nouvelle entre
du mobile.
(3) Un paquet de donnes noy d'un correspondant un mobile est intercept par
le HA. Ce dernier cherche dans sa table d'expdition la valeur d'tiquette entrante et
insre la valeur d'tiquette sortante prsente dans la deuxime range pour envoyer le
paquet par le port sortant indiqu dans la mme range.
L'ancienne range peut tre supprime grce un temporisateur qui une fois expir,
indique que le mobile ne reviendra pas l'ancien rseau visit.
(5) Le nouveau FA reoit le paquet et recherche dans sa table d'tiquettes.
Encore une fois, puisqu'il est le LER de sortie, l'tiquette sera enleve et le paquet
envoy la couche IP.
(6) Finalement, le paquet est livr au mobile selon la table de routage.
Si durant son dplacement, un mobile reoit des paquets, le cas dj prsent va
introduire un problme de perte de paquets.
Cependant ce type de gestion savre efficace lors dune dgradation du niveau de QoS
un LSP tabli. Une fois le LSP rtabli , la route entre le HA et le FA peut tre optimise.
Cette gestion est intitule LSP Optimization.
Dans la procdure prcdente, le mobile n'est pas suppos se dplacer
frquemment d'un rseau tranger un autre car il est clair que, pour chaque
changement, la procdure d'enregistrement ainsi que la procdure dtablissement dun
nouvel LSP doivent tre rptes conduisant ainsi un dlai au niveau du HA
(Handover delay) surtout dans le cas o la distance entre le HA et le nouveau FA
dpasse trois sauts. De mme, le trafic de signalisation sera norme et des paquets
peuvent se perdre.

38

Une solution sera propose au Chapitre V o sera trait un mcanisme qui diminuera le
besoin d'intervention du HA et qui est bas sur des enregistrements rgionaux et des FAs
hirarchiques.
II.1.4

Retour au rseau mre

Dans ce paragraphe, la procdure d'enregistrement et celle de livraison des


donnes seront tudies dans le cas o le mobile retourne son rseau mre.
(1) Le mobile est inform qu'il est en retour son rseau mre aprs la rception
des messages de publicit d'agents diffuss par son HA.
(2) Le mobile envoie un message de demande de terminer le dernier
enregistrement (Deregistration message) en ajustant le TTL zro dans le message
d'enregistrement. La COA dans ce message est donc la COA du HA.
(3) Le HA efface les valeurs du port sortant et de l'tiquette sortante de la
deuxime range de sa table d'expdition qui ont t ajoutes pendant le dernier
enregistrement avec le FA. Comme illustr dans le Tableau III.4, ces deux entres sont
laisses vides. La premire range dfinit le LSP entre le HA et le FA et la deuxime
range dfinit le LSP entre le HA et le nud correspondant.
(4) Quand des paquets sont destins l'adresse mre du mobile arrivent au HA,
ce dernier enlve l'tiquette et envoie les paquets la couche IP.
(5) Le HA recherche l'entre correspondante au mobile dans sa table de routage
et la valeur du port sortant do seront envoys les paquets au mobile.
In Port

In Label

FEC

Out Label

Out Port

w.x.y.z

a.b.c.d

Tableau III.4 : Table dexpdition du HA lors du retour du mobile son rseau mre
II.1.5

Plusieurs noeuds correspondants

Sil y a plusieurs nuds communiquant avec le mobile, une fois que le mobile se
dplace de son rseau mre un rseau tranger, tout le trafic de ces correspondants doit
tre redirig la position courante du mobile.

39

Figure III.5 illustre le cas de trois correspondants communiquant avec le mobile.

CN2

LSR 5
MN
LSR 3 A ncien F A / LE R
L SR1

L SR 2

CN 1
L SR 6 D om aine M P L S

LSR 4

H A / L ER

MN

CN3

Figure III.5 : Exemple dune topologie dun rseau avec plusieurs correspondants

Le procd d'enregistrement est identique au procd dans le cas d'un seul noeud
correspondant.
La table d'expdition du HA aprs l'enregistrement est illustre dans Tableau III.5.
In Port

In Label

FEC

Out Label

Out Port

w.x.y.z

a.b.c.d

a.b.c.d

a.b.c.d

Tableau III.5 : Table dexpdition du HA cas de plusieurs correspondants


La premire range dfinit le LSP entre le HA et le FA. La seconde, la troisime
et la quatrime ranges sont celles qui dfinissent les tiquettes des LSPs entre le HA
et chaque correspondant. Le port sortant et l'tiquette sortante de ces trois ranges
prennent les valeurs du port sortant et de l'tiquette sortante de la premire range. Par
consquent, les paquets arrivant le long de ces trois LSPs seront envoys en utilisant le
mme port sortant avec la mme valeur d'tiquette sur le LSP vers le FA du rseau
tranger.
Si le trafic des diffrents correspondants a des besoins de QoS diffrentes, le HA devrait
tablir un LSP pour chaque classe de service. Ceci traduit la ncessit du HA de
distinguer les diffrentes classes de service du trafic destin l'adresse mre du mobile.
Quand les paquets arrivent au HA, il doit classifier les paquets et identifier la classe de
service et la destination. Puis, il doit affecter les paquets au LSP appropri bas sur la
combinaison de la classe du service et de l'adresse de destination. Dans un rseau MPLS,
DiffServ[15] peut tre soutenu pour des agrgats des flots.

40

II.2

Plusieurs domaines de rseaux

Il est ncessaire de considrer la connectivit des multiples domaines de rseaux


car il y a une possibilit que les noeuds mobiles se dplacent entre des domaines
diffrents.Dpendant de la nature des raccordements entre les domaines, quelques
conditions doivent tre spcifies au niveau des routeurs de bordure entre ces domaines,
comme sera dcrit dans les sous-sections suivantes.
II.2.1

Plusieurs domaines MPLS

Domaine M PLS
LSR6
LSR5
FA / LER

MN

LSR3
LSR2
LSR1
CN

Dom aine M PLS

LSR4

HA / LER

MN

Figure III.6 : Plusieurs domaines MPLS

Dans la topologie de rseau reprsente dans la Figure III.6, le HA et le FA sont


des LERs mais appartiennent deux domaines MPLS diffrents directement relis. Ils
soutiennent les deux fonctionnalits de Mobile IPv4 et de MPLS.
LS3 et LSR5 sont deux LSRs de bordure et supportent le protocole LDP-BGP [16][17].
Ces deux LSRs changent entre eux les informations lies aux tiquettes en les ajoutant
( piggy-backing ) aux messages de commande de BGP.
Par consquent, un LSP du HA au FA peut tre tabli travers le lien reliant les deux
diffrents domaines MPLS. Les procdures d'enregistrement et de livraison des donnes
dcrites dans les sections prcdentes peuvent tre employes sans aucune modification.
II.2.2

Un nuage IP entre les domaines MPLS

Si le FA se trouve dans un nuage IP, un tunnel d'IP [18] est ncessaire pour
transporter les paquets des donnes au FA. Dans ce cas, LSR3 effectue l'change entre le
LSP et le tunnel IP et agit comme tant un FA du point de vue du HA. Des paquets sont
commuts du HA au LSR3 puis suivent le tunnel de LSR3 au FA.

41

Une petite modification doit tre faite si le FA se trouve dans un domaine MPLS comme
reprsent dans la Figure III.7, o un nuage IP spare le domaine du HA du domaine du
FA.

Domaine MPLS
LSR6
LSR5
FA / LER
MN
Nuage IP

Routeur IP
FA

MN

LSR3
LSR1

LSR2

CN

LSR4
Domaine M PLS

HA / LER

MN

Figure III.7 : Nuage IP entre les domaines MPLS

Le tunnel IP se termine au niveau de LSR5 et un LSP est tabli entre LSR5 et le FA.
II.2.3

Sommaire

Les cas dj tudis ont trait le cas o le rseau entier est un domaine simple
MPLS, le cas o il y a plusieurs domaines MPLS et le cas o il y a un nuage IP non
MPLS. Le point essentiel est de savoir si on a besoin de se recourir la couche IP pour
faire acheminer le paquet entre le HA et les routeurs de frontire. Ceci s'avre ncessaire
dans le cas d'un nuage IP entre le HA et le FA. Mais dans les autres cas, l'acheminement
des paquets se rvle plus rapide et plus efficace pour confronter au problme de passage
l'chelle. Pour confronter aussi au problme de manque dadresses globales IPv4,
Annexe B propose lutilisation des adresses prives dans lintgration de Mobile IPv4
avec MPLS [19].

II.3

Routage Optimis

Le problme de routage triangulaire dtaill au Chapitre I est habituellement


indsirable. Cette section tudiera la solution doptimisation de routage dans lintgration

42

de MPLS avec Mobile IPv4. Une deuxime mthode sera aussi expose qui consiste
introduire un nouvel message de signalisation.
II.3.1

Routage optimis standard


a

Etablissement de LSP

En se basant sur la mthode de loptimisation telle quelle tait dj dfinie, le


chemin de livraison de paquets doit tre recalcul aprs la procdure de dcouverte des
agents. Quand le HA reoit les paquets du mobile, il envoie un message Binding
Update (BU) au routeur LER dentre connect au nud correspondant lui informant de
ladresse du mobile. Le routeur dentre rafrachit sa cachette aprs la rception de ce
message authentifi et associe un temporisateur cette nouvelle entre. Quand le FA
reoit des paquets destins un correspondant, il cherche une entre associe au mobile.
Sil nen trouve pas, il envoie un message Binding Update Warning au HA pour lui
envoyer un message BU au routeur dentre attach au correspondant. Ceci est illustr
dans Figure III.8

MN

FA / LER

H A / L ER

L E R d 'en tre

A n no n ce des a g en ts
D em a n d e
d 'en reg istrem en t

D em a nd e
d 'en registrem en t

R p on se
d 'en registrem en t

Rp o n se
d'en registrem en t

P a qu et
d e d o n nes

P a q uet
d e d o n n es

P a s un e tiq uette
d 'en tre p o ur le m ob ile
P a q u et
d e do n n es

P a q u et
de d o nn es

BU
D em a n d e
d 'tiq u ettes
A sso cia tio n
d 'tiq u ettes
P a qu et
d e d o n nes

P a qu et
d e d o n nes

P a q u et
de d o nn es
LS P

Figure III.8 : Routage optimis standard

CN

43

Extension du LSP (lors du handoff)

Dans le cas o le mobile effectue un handoff, un LSP sera tendu entre


lancien FA et le nouveau FA.
Les tapes suivantes sont suivre :
(1)
Quand le mobile se dplace un rseau tranger, il envoie un message de
demande denregistrement et un BU au nouveau FA.
(2)
Le nouveau FA envoie le message de demande denregistrement au HA et
le message BU lancien FA.
(3)
Lancien FA rpond par un message Binding Update Request au
mobile travers le nouveau FA. Lancien FA envoie ensuite un message de demande
dtiquettes au nouveau FA.
(4)
Une fois lancien FA reoit lassociation dtiquettes, un LSP est alors
tabli entre lancien FA et le nouveau FA.
(5)

Ensuite, le HA envoie un message de rponse denregistrement au mobile.

En effet, quand lancien FA est inform de la nouvelle position du mobile, il cherche


ltiquette correspondant au mobile dans sa table dexpdition. Sil en trouve, il tablit
un LSP avec le nouveau FA. Donc lancien LSP dj tabli entre le HA et lancien FA
sera tendu au nouveau FA aprs lchange de messages de signalisation entre lancien
FA et le nouveau FA.
Durant ce temps, lancien FA garde les paquets destins au mobile ou dlivrs par le
mobile. Quand le LSP est rtabli, les paquets sont destins au mobile. Si lancien FA
reoit des paquets destins au mobile, il les redirige vers le nouveau FA selon le LSP
tendu.
Si ltiquette nest pas trouve dans la table dexpdition de lancien FA, les paquets
destins au mobile seront routs au mobile selon le routage IP conventionnel.

44

Figure III.9 rsume le mcanisme du LSP tendu.

MN

Ancien FA / LER

Nouveau FA / LER
Annonce des agents
Demande
d'enregistrement
et BU

HA / LER

Demande
d'enregistrement
BU
BAck

BAck

Demande
d'tiquettes
Association
d'tiquettes
Rponse
d'enregistrement

Rponse
d'enregistrement

Figure III.9 : Extension du LSP

Optimisation du LSP

Comme a t expliqu dans la section 0, quand un mobile ncessite de garantir un


certain niveau de QoS, lancien LSP ne sera pas tendu mais un nouveau LSP sera tabli
entre le nouveau FA et le LER dentre attach au nud correspondant.

45

Figure III.10 rsume cette opration.

MN

Nouveau F A / LER

Ancien FA / LER

LER d'entre

Paquet
de donnes

CN

P aquet
de donnes

Ancien LSP
BU avec besoin
de QoS

BU avec besoin
de QoS
Demande
d'tiquettes
Association
d'tiquettes

Paquet
de donnes

Paquet
de donnes

Paquet
de donnes

LSP garantissant
une QoS

Figure III.10 : Optimisation du LSP

En effet, la mthode doptimisation de routage ordinaire consiste ce que le HA


envoie le message de BU tous les correspondants et tous les FAs.
Une nouvelle technique consistant ce que loptimisation de routage se fait directement
entre le FA et le nud correspondant sera dcrite dans la suite.
II.3.2

Routage optimis avec le message Path Change

Dans ce cas, le LER d'entre jouera le rle d'un routeur d'optimisation (route
optimization proxy). Le noeud correspondant fonctionnera sans tenir compte du
processus d'optimisation. Afin de mettre en application l'optimisation de routage, un
message de signalisation spcial appel Path Change est ajout.
Le format de ce message est illustr dans la Figure III.11.

Figure III.11 : Format du message PATH CHANGE

46

Le champ FEC TLV a deux lments. Le premier lment traduit l'adresse mre du
mobile et le deuxime lment la COA du FA.
a

Un seul domaine MPLS

En se rfrant la Figure III.1, le procd d'optimisation de routage s'effectue


comme suit:
(1) Quand le mobile se dplace un rseau tranger pour une dure qui dpasse
un certain temps de seuil, le FA envoie un message Path Change au nud
correspondant.
(2) Ce message est achemin saut par saut selon la table de routage en direction
du correspondant.
(3) Quand le message atteint le LER d'entre (LSR1 selon la Figure III.1), il
enregistre l'adresse mre du mobile prsent dans le premier lment du champ FEC TLV
et la COA du FA prsente dans le deuxime lment de ce mme champ dans une table
de hachage stocke dans le LER d'entre.
(4) Ce LER d'entre envoie un message de demande d'tiquettes vers le FA avec
la COA comme FEC.
(5) Le message de demande d'tiquettes est envoy au FA saut par saut.
(6) Quand le FA reoit la demande, il ajoute une nouvelle range dans sa table
d'expdition, insre la COA comme FEC et la lie avec la nouvelle valeur d'tiquette.
Puis, il envoie en retour un message d'association d'tiquettes qui contient la COA
comme FEC et la nouvelle valeur d'tiquette associe ce FEC.
Tableau III.6 montre la table d'expdition du FA dans laquelle la premire range
contient l'tiquette pour le LSP du HA au FA. La deuxime range est ajoute pour le
nouveau LSP tabli entre le LER d'entre et le FA.
In Port

In Label

FEC

Out Label

Out Port

w.x.y.z

w.x.y.z

Tableau III.6 : Table dexpdition du FA


(7) Le message d'association d'tiquettes est envoy en retour saut par saut au
LER d'entre.
(8) Une fois le message arriv au LSR, un LSP entre cet LSR et le FA sera tabli
et l'optimisation de routage est termine.

47

(9) Quand un paquet non tiquet arrive au LER d'entre, il vrifiera si son
adresse de destination possde une entre dans sa table de hachage.
Sil en trouve une entre, le LER d'entre commutera ce paquet le long du nouveau LSP
tabli entre lui et le FA au lieu de celui tabli entre lui et le HA. De cette faon, le
routage triangulaire est limin et le paquet est envoy directement au FA puis au
mobile. Le procd de signalisation pour le routage optimis est montr dans la Figure
III.12.

L E R d 'en tre

FA / LER
E x p ira tio n
d u tem p o risa teu r
" P a th C h a n g e"

C o n n ai ssan ce
d e l'a d resse m re
et la CO A d u m o b ile
D em a n d e
d 'tiq uettes
Asso cia tio n
d 'tiq u ettes
Asso cia tio n
d 'u n e tiq u ette
la C O A d u m o b ile

Figure III.12 : Procdure doptimisation de routage

Si la distribution des tiquettes est selon le type Unsolicited downstream, le FA peut


envoyer l'association d'tiquettes pour la COA directement au correspondant. Dans ce
cas, le FA n'a plus besoin d'envoyer le message Path Change ou dattendre
l'association d'tiquettes. Ceci conduira une dure d'optimisation rduite.

48

b
Nud correspondant appartenant plusieurs rseaux ( MultiHomed )

LSR5

MN
LSR3

FA / LER

LSR2
CN

LSR1
Domaine MPLS

LSR4

HA / LER

MN

Figure III.13 : Nud Correspondant Muli-Homed

Il peut arriver des cas o le noeud correspondant appartient plusieurs rseaux.


Comme indique la Figure III.13, le correspondant est reli deux LERs d'entre (LSR1
et LSR5). Dans ce cas, le LER d'entre identifi par le message Path Change peut ne
pas tre celui correspondant au chemin dj tabli au HA.
Selon Figure III.10, le message Path Change trouvera LSR5 en se basant sur
l'algorithme du chemin le plus court (Shortest Path First). Cependant, LSR1 peut tre
le vrai LER d'entre. Pour cela, une signalisation renverse est ncessaire pour trouver le
LER d'entre correct.
D'abord, le FA envoie le message Path Change au HA, puis le HA l'envoie au LER
d'entre (LSR1) selon le chemin dj tabli entre ce LSR et le HA lors de la demande
d'tiquettes du HA mais dans la direction oppose. Ceci signifie que le port entrant
duquel le message de demande d'tiquettes envoy par le LER d'entre qui apparat dans
les routeurs intermdiaires (LSR1, LSR2 et LSR4) le long du chemin au HA doit tre
enregistr pour quil soit utilis comme le port sortant pour le message Path Change.
Quand le correct LER d'entre est trouv, un LSP est tabli directement avec le FA.
Mais la complexit de cette signalisation renverse ne peut tre justifie malgr
l'avantage introduit par le routage optimis.
c

Plusieurs domaines MPLS

Si l'opration de routage optimis est effectue travers des domaines MPLS


diffrents, les LSRs de bordure supportent le protocole BGP (voir la section II.2.1).
Dans ce cas, le processus est identique celui du simple domaine MPLS dans la soussection (a). Le message Path Change est envoy au LER d'entre et le paquet destin
l'adresse mre du mobile est commut directement au FA le long du LSP tabli entre le
LER d'entre et le FA travers les domaines diffrents.

49

Nuage IP entre les domaines MPLS

Si un nuage IP spare les domaines MPLS comme reprsent dans la Figure


III.7, une modification doit tre faite au processus de routage optimis. En effet, les
routeurs de frontire doivent se rendre compte du message Path Change pour pouvoir
le traiter en consquence.
En rfrence la Figure III.7, le procd d'optimisation s'effectue comme suit :
(1) Quand le mobile se dplace un rseau tranger pour une dure dpassant le
temps de seuil, le FA envoie le message Path Change au correspondant.
(2) Ce message est expdi saut par saut selon la table de routage de chaque
routeur intermdiaire.
(3) Quand le message Path Change arrive au LER de sortie du domaine MPLS
(LSR3), ce LSR doit retenir l'adresse mre du mobile et sa COA. Il prcise alors une
interface pour tablir le tunnel IP pour l'adresse mre du mobile ayant la COA comme
destination.
(4) En conclusion, le message Path Change arrive au LER d'entre (LSR1). Ce
LSR traite le message de la faon dcrite dans la sous-section (a).
(5) Quand un paquet non tiquet IP est destin au mobile arrive au LER d'entre,
il sera commut le long du LSP entre lui et le LER de sortie (LSR3).
(6) Quand le paquet marqu arrive au LER de sortie (LSR3), il enlvera
l'tiquette de MPLS et enverra le paquet la couche IP. Comme l'interface de tunnel IP
pour l'adresse mre du mobile a t dj prcise, le paquet sera envoy comme un
paquet IP aprs avoir lui appos une nouvelle en-tte IP avec la COA comme adresse de
destination.
(7) Le paquet est tunnel alors vers le LER dentre (LSR5). Au niveau de ce
routeur, une tiquette MPLS est ajoute, base sur la COA de l'en-tte IP, et le paquet
est ensuite commut au FA.
(8) Le FA dpouille l'tiquette MPLS et fournit le paquet la couche IP. La
couche d'IP dpouille l'en-tte appose avec la COA comme adresse de destination
et expdie le paquet IP original au mobile.

50

Si un nuage IP se trouve entre le correspondant et le LER d'entre, comme


reprsente la Figure III.14, le routeur 1 enregistrera l'adresse mre du mobile et sa COA.

Domaine MPLS
LSR6
LSR5
FA / LER
MN
Nuage IP
Routeur 2
FA

Nuage IP

CN

Routeur 1

MN

LSR3

LSR1

LSR2
LSR4

Domaine MPLS

HA / LER

MN

Figure III.14: Nuage IP entre un correspondant et un nud dentre MPLS

Puis, le routeur1 tablira une interface du tunnel IP tel que le paquet destin au mobile
sera tunnel du routeur 1 au FA avec la COA comme adresse de destination. Quand le
paquet tunnel arrive au LER d'entre (LSR1), il peut lui ajouter une tiquette MPLS et
le commuter vers le FA. Sil y a un raccordement entre le routeur 1 et le routeur 2, le
routeur 1 peut tunneler le paquet au routeur 2 directement en se basant sur sa table de
routage.
e

Sommaire

Le routage optimis n'exige pas que le nud correspondant s'en rend compte et
aucune modification n'est alors ncessaire au niveau du correspondant. En outre, cette
optimisation est applique au niveau du LER d'entre du domaine MPLS. Puisqu'il y a
seulement un nombre limit de LERs la frontire, un chemin optimis issu du LER
d'entre apporte plusieurs bnfices tous les correspondants communiquant avec le
mobile.
Les cas traits sont ceux d'un domaine MPLS simple, cas o il y a plusieurs domaines
MPLS et le cas o nuage IP spare les domaines. Une fois qu'il y a un nuage IP, un
tunnel est tabli pour prolonger le LSP au FA. Dans le plus mauvais cas, le tunnel IP sera
utilis le long du chemin au FA.

51

Naturellement, l'optimisation de routage fonctionne mieux quand le rseau entier est


MPLS.
Une autre proposition dchange de profiles du mobile directement avec les
correspondants sans avoir recourir au HA est dtaille dans Annexe C [20].

III Conclusion
Ce chapitre a examin le problme de passage l'chelle dont souffre Mobile
IPv4. L'intgration de Mobile IPv4 avec MPLS a t propose. Cette intgration rend le
tunnel IPv4-IPv4 inutile pour la livraison de paquets dans des rseaux MPLS. Les
mcanismes de signalisation et de commande et d'optimisation de routage ont t dcrits.
L'intgration emploie MPLS pour commuter les paquets de donnes du HA au FA du
rseau visit. Dans le cas dun domaine compltement MPLS, le processus entier
d'expdition est totalement fait au niveau de la couche MPLS et le HA n'a plus besoin
d'envoyer les paquets la couche IP et d'encourir des consultations de la table de routage
et par suite de former des tunnels IPv4-IPv4.
Par consquent, le problme de passage l'chelle dans Mobile IPv4 est
considrablement rduit. En outre, puisque l'en-tte d'tiquette est plus petite que l'entte IP, le trafic circulant entre le HA et le FA est galement rduit.
Le chapitre suivant examinera lintgration de Mobile IPv6 avec MPLS.

Chapitre IV:
Intgration de
Mobile IPv6 avec MPLS

Ce chapitre discute la faon d'tablir un rseau grande chelle supportant


Mobile IPv6 et bas sur une infrastructure MPLS.
Les mcanismes CR-LDP/RSVP-TE peuvent en fait tre appliqus pour installer des
LSPs supportant une QoS garantie entre les routeurs LSRs attachs au mobile et au
correspondant. Les tunnels IPv6-IPv6 peuvent tre ainsi remplacs par un ou plusieurs
LSPs.
Ce chapitre prendra en considration les mobiles inactifs et les mcanismes de garanti de
QoS ainsi que la gestion du dplacement du mobile.
Section I dfinit les dispositifs d'intgration de Mobile IPv6 avec MPLS. Section II
explique les mcanismes de droulement de cette intgration selon que l'initiateur de
communication est le mobile ou le correspondant.

I Dispositifs d'intgration de Mobile IPv6 avec MPLS


Lintgration de Mobile IPv6 avec MPLS [21] doit tenir compte de plusieurs
dispositifs qui seront discuts dans les sous-sections suivantes.

I.1

Etablissement d'un LSP garantissant une QoS

Il est exigent de pouvoir soutenir un niveau appropri de QoS pour les paquets
envoys d'un mobile traversant les domaines intermdiaires dun rseau, pour que
l'excution des applications sensibles la QoS fonctionnant sur le mobile soit maintenue
au niveau dsir. Pour raliser ceci, l'objet de QoS [22] est incorpor avec CRLDP/RSVP-TE.

53

I.2

Considration des mobiles inactifs

Actuellement, on peut imaginer que l'accs l'Internet doit tre possible vingtquatre heures sur vingt-quatre. Mais en fait, la grande majorit d'abonns ne
communiquent pas pour la majorit du temps. Plutt, ils restent connects au rseau,
prts dclencher des services et toujours accessibles par les nuds correspondants.
Essentiellement, le mobile se trouvant dans un tat inactif sera passivement reli au
rseau. Pour cela, on a conu que l'tablissement d'un LSP pouvant garantir une certaine
QoS ne doit s'effectuer que pour les donnes actives. Ceci empchera alors
l'tablissement des LSPs pouvant provoquer un grand nombre de paquets de commande
et de signalisation. Ainsi un LSP est seulement tabli entre le routeur du mobile et le
routeur du correspondant diffrent de celui tabli travers le HA. Cette conception est
efficace pour la sauvegarde de la largeur de bande du rseau et pour la rduction du
retard de la connexion de bout en bout.

I.3

Support du doux dplacement ( Smooth Handoff )

Le dplacement d'un mobile ncessite deux besoins: la rduction du temps de


latence d l'interruption rsultant du changement de position et la rduction de la
charge de signalisation.
Mobile IPv6 peut tre considr comme une solution optimale de ces deux besoins. Un
mobile peut utiliser une ou plusieurs COAs ainsi, dpendant de ce nombre de COAs,
plusieurs LSPs garantissant chacun une QoS peuvent tre tablis. Cette opration est
nomme "Smooth Handoff.

I.4

Etablissement d'un LSP bidirectionnel

Le MPLS gnralis (Generalized MPLS , GMPLS) [23] soutient


l'tablissement de LSP bidirectionnel.
Le LSP bidirectionnel a l'avantage de rduire le temps de latence et le nombre de
messages ncessaires pour accomplir l'installation. Cela exige seulement un initiateur
ou suppresseur du temps aller-retour de transit (Round Trip Time, RTT).
L'intgration de Mobile IPv6 avec MPLS peut tre extensible au GMPLS.

I.5

Aucun engagement dune signalisation MPLS au mobile

Mobile IPv6 n'exige pas que le mobile ou le noeud correspondant supporte des
fonctionnalits MPLS telles que le CR-LDP et le RSVP-TE. CR-LDP et RSVP-TE
peuvent fonctionner seulement sur des routeurs lis au mobile et au correspondant.
Par consquence, ceci rduira le cot de mmoire et la complexit du dispositif install
au mobile et au correspondant.

54

I.6

Aucun message MPLS additionnel de signalisation

Intgrer Mobile IPv6 avec MPLS ne ncessite aucun message ou un


TLV/Object additionnel sur le CR-LDP/RSVP-TE existant pour installer un LSP
garantissant une QoS entre les routeurs attachs au mobile et au correspondant.

II Intgration de Mobile IPv6 avec MPLS


Pour tudier lintgration de Mobile IPv6 avec MPLS, on distinguera quatre cas :
Cas o le mobile est linitiateur de la communication,
Cas o le correspondant est linitiateur de la communication,
Cas de Smooth Handover, et ;
Cas dun LSP supportant une QoS.
A noter que le protocole de distribution des tiquettes utilis est le RSVP-TE.

II.1

Cas o le mobile lance la transmission de donnes

Les procdures de Mobile IPv6 telles que new default router finding [24],
Address auto-configuration [25], Registration et Binding Acknowledgement
reception sont supposes dj effectues par le mobile.
Figure IV.1 illustre un exemple d'un rseau Mobile IPv6 intgr avec MPLS.

Domaine MPLS
/ Ancien FN
MN

LER 2

LER 4

MN

LSR 2
Domaine MPLS
/ Nouveau FN

LER 3

CN

LSR1
HA / LSR
Domaine MPLS
/ HN

LER 1
MN

Figure IV.1 : Rseau MPLS supportant Mobile IPv6

Un noeud IPv6 mobile emploie la COA comme l'adresse source dans l'en-tte IP des
paquets qu'il envoie. Ceci simplifie lacheminement des paquets afin d'tablir des LSPs
vers le mobile.

55

Pour viter le routage triangulaire, le mobile envoie un message de BU et un objet de


QoS au noeud correspondant.
Le LER du mobile recevant ce message doit dcider le lancement ou pas du message
Request/Path . Si le message de BU a le bit H positionn zro, le routeur initie un
message Request/Path pour une adresse de destination qui constitue la FEC. A noter
que le LER joue un rle quivalent d'un routeur ayant une fonction de filtrage dentre
ou Ingress Filtering.
Le noeud correspondant recevant le message de BU peut directement envoyer les paquets
au mobile. Une fois le LSP garantissant une QoS, les paquets poursuivront ce tunnel
pour arriver la destination.
Figure IV.2 traduit le mcanisme de livraison de paquets.

MN

LER2

HA / LSR

LER 3

CN

Paquet
de donnes
Paquet
de donnes

Tunnel IPv6-IPv6

BU avec
objet de QoS

BU avec
objet de QoS
Request
/ Path
M apping
/ RESV

Paquet
de donnes

P aquet
de donnes

Paquet
de donnes

LSP garantissant
une QoS
Figure IV.2 : Le mobile initiateur de communication

II.2

Cas o le correspondant lance la transmission de donnes

De mme, dans cette section, on suppose que le mobile a dj effectu les


procdures de new default router finding, Address autoconfiguration,
Registration et Binding Acknowledgement reception.
Avant que le correspondant lance la transmission des paquets au mobile, il doit examiner
sa cachette d'associations (Binding Cache) pour chercher une entre ayant comme

56

adresse de destination l'adresse mre du mobile. Si le correspondant en trouve une entre,


les paquets sont alors destins au mobile.
Dans le cas o cette entre n'existe pas, les paquets seront intercepts par le HA du
mobile puis encapsuls dans un tunnel IPv6-IPv6 avant d'tre offerts la COA du
mobile.
De mme, pour viter le routage triangulaire, le mobile envoie un message de BU
et un objet de QoS au noeud correspondant.
Le LER du mobile recevant ce message doit dcider le lancement ou pas du message
Request/Path. Si le message de BU a le bit H positionn zro, le routeur initie un
Request/Path ayant la FEC comme adresse de destination. Le noeud correspondant
recevant le message de BU peut directement envoyer les paquets au mobile.
Figure IV.3 schmatise cette opration.

MN

LE R 2

CN

Paquet
de donnes

T unnel IPv6-IPv6

B U avec
objet de QoS

L ER 3

H A / L SR

B U avec
objet de QoS

Request
/ Path
M apping
/ R ESV
Paquet
de donnes

Paquet
de donnes

Paquet
de donnes

L SP garantissant
une QoS

Figure IV.3 : Le correspondant initiateur de communication

II.3

Smooth Handoff

Un mobile peut avoir plusieurs COAs, ce qui facilite lchange des donnes
durant son dplacement d'un rseau un autre. Si un mobile se trouve dans le secteur de
chevauchement de deux zones de couverture de deux stations de base adjacentes, il
pourra rester reli aux deux stations simultanment. Le mobile acquiert une nouvelle
COA avant de se dplacer hors de la gamme de transmission de l'ancienne station de
base. Ainsi, il pourra encore intercepter les paquets de l'ancienne base durant qu'il met
jour son HA et ses correspondants en les informant de sa nouvelle COA.

57

Quand un mobile acquiert la nouvelle COA tout en communiquant avec un


correspondant le long d'un ancien LSP dj tabli, il envoie le message de BU avec
l'objet de QoS ce correspondant pour l'optimisation de routage. Le LER attach au
mobile recevant ce message lance un message Request/Path. Une fois le correspondant
reoit le message de BU, il envoie les paquets directement au mobile le long du nouveau
LSP tabli. L'ancien LSP sera libr automatiquement aprs l'expiration d'un certain
temporisateur.
L'change des messages et des donnes est montr dans la Figure IV.4.

MN avec
une nouvelle COA

LER 4
Nouveau LER

LER 2
Ancien LER

LER 3

CN

Ancien LSP
BU avec
objet de QoS

BU avec
objet de QoS

Request
/ Path
M apping
/ RESV
Paquet
de donnes

Paquet
de donnes

Paquet
de donnes

Nouveau LSP garantissant


une QoS

Figure IV.4 : Smooth Handover

II.4

Support de la QoS par un LSP

Lintroduction de loption de lobjet de QoS ou QoS Object a permis un LSP


de supporter un certain niveau de QoS.
Ce champ est une extension de loption RSVP QoS et de loption Filter_Spec. Il se
compose dun champ intitul QoS Requirement qui dcrit les besoins en QoS des
paquets du mobile tout en sappuyant sur leurs classes de service.
Par exemple, les classes seront Expedited Forwarding (EF) et Assured Forwarding
(AF) dans les cas de DiffServ Per Hop Behavior ou PHB.
Dans le cas dIntServ, la classification se fait selon les services de types guaranteed
services ou controlled load services.

58

Pour les classes de QoS de lUMTS [26], on peut distinguer les applications de
diffrents types tels que delay sensitives, interactive-delay sensitive, noninteractive delay sensitive ou delay insensitive.
Aprs certaines procdures dauthentification, le routeur LER attach au mobile peut
envoyer un message Label Request/Pathavec un DiffServ TLV/DiffServ Object
pour tablir des LSPs de types E-LSP ou L-LSP (non abords dans ce projet).

III Conclusion
L'intgration de Mobile IPv6 avec MPLS a t expose dans ce chapitre. Le tunnel
IPv6-IPv6 est pratiquement limin durant l'expdition de donnes.
On a pu concevoir q'aucun changement n'est ncessaire dans Mobile Ipv6 et que les
mobiles inactifs sont allous un LSP diffrent de celui des mobiles actifs. Le Smooth
Handoff , le LSP bidirectionnel et le LSP garantissant une QoS ont t aussi introduits.
Jusqu maintenant, on a considr la mobilit seffectuant entre des domaines diffrents
et une vitesse du mobile relativement lente. Cette mobilit est dite macro-mobility.
Mais il est souvent ncessaire dtudier le cas des mobiles qui se dplacent frquemment
dans un mme domaine ou mme zone gographique. Cette mobilit est dite micromobility .
Le chapitre suivant expose une mthode de grer la micro-mobility avec le protocole
Hierarchical Mobile IP ou HMIP qui repose sur Mobile IP mais avec une
disposition hirarchique des FAs et des mcanismes denregistrement rgionaux.

Chapitre V:
Intgration de
HMIPv4 avec MPLS

Dans la version du Mobile IP standard, la nouvelle position dun mobile est


toujours signale son HA. Ce dernier est ainsi averti de tous les dplacements des
mobiles quil gre. Ces oprations gnrent une grande quantit de signalisation. De
plus, les pertes de paquets pendant les handoffs peuvent tre importantes puisque la
procdure denregistrement est longue, en particulier si le HA se trouve lautre bout du
rseau. La dure dun handoff peut atteindre plusieurs secondes dans lInternet actuel.
La micro-mobilit reprsente donc la gestion de la mobilit locale. La gestion de la
micro- mobilit permet des mobiles de senregistrer localement lintrieur du rseau
quils visitent. Cet enregistrement local rduit le dlai de signalisation, ce qui peut
amliorer les performances des handoffs.
Dautre part, pour des mobiles bnficiant dune certaine QoS, lacquisition dune
nouvelle COA pour chaque handoff implique de remettre en place des rservations
entre le HA et le nouveau FA. Cependant, une grande partie du chemin entre le
correspondant et le mobile risque dtre identique avant et aprs le handoff (si le
mobile ne change pas de domaine).
Plusieurs solutions pour grer la micro-mobilit ont t proposes. Ce chapitre prsente
le Mobile IPv4 hirarchique (HMIPv4) dans Section I. Section II illustre larchitecture
dintgration de HMIPv4 avec MPLS. Les procdures denregistrement et de livraison de
paquets sont expliques et les diffrents mcanismes de handoff proposs sont aussi
dtaills.

Prsentation de Mobile IPv4 hirarchique ou HMIPv4

Mobile IPv4 hirarchique ou HMIPv4 [27] est une solution pour effectuer des
enregistrements rgionaux lintrieur du domaine visit. Les enregistrements rgionaux
rduisent le nombre de messages de signalisation qui sont envoys jusquau rseau mre.
Ils rduisent aussi le dlai de signalisation lorsquun mobile se dplace dun FA un
autre, tout en restant dans le mme domaine.

60

Figure V.1 illustre larchitecture de base de HMIPv4.

HN

H A sa it se u le m e n t
q u e l e m o b il e s e t r o u v e
d e r ri r e u n G F A
HA

G F A s a i t l a p o s i ti o n
e x a c t e d u m o b il e
GFA

R FA

R FA

FA

FA

FA

FN

FA

M N

M N
L e m o b i le c h a n g e
d e F A sa n s in fo r m e r so n H A

Figure V.1 : Mobile IPv4 Hirarchique

Les nuds mobiles ne sont pas obligs de prvenir leur HA de tous leurs dplacements
lintrieur du rseau visit, car un lment de rseau gre tous les enregistrements du
mobile.
Lorsquun mobile arrive pour la premire fois dans un rseau visit, il senregistre
normalement auprs de son HA. Ensuite, le mobile senregistre d'une manire rgionale
lintrieur du rseau visit.
Si le rseau visit supporte la gestion de tunnels rgionaux, il existe un FA particulier
appel Gateway Foreign Agent (GFA). Le mobile utilise ladresse IP du GFA comme
une adresse temporaire lorsquil senregistre auprs de son HA. Cette adresse temporaire
ne change pas lorsque le mobile se dplace entre des FAs situs sous le mme GFA.
Aprs le premier enregistrement, le mobile senregistre auprs du GFA. Les
enregistrements ne sont plus faits auprs du HA tant que le mobile se dplace sous le
mme GFA.
Les FAs de niveau infrieur sont appels Regional Foreign Agents (RFAs)
et acceptent les requtes denregistrement des FAs relais servant les mobiles et les

61

acheminent au GFA de niveau suprieur. Si le nud mobile change de GFA, il doit


nouveau senregistrer auprs de son HA.
Une fois le mobile enregistr, il acquiert deux nouvelles adresses IP temporaires. La
premire adresse est ladresse temporelle virtuelle (Regional COA , RCOA) qui est
valide au niveau de gestionnaire de mobilit ; elle est dtermine en concatnant
lidentifiant de linterface physique du mobile avec le prfixe rseau du gestionnaire de
mobilit recueilli dans lannonce des routeurs. La deuxime adresses dite adresse
temporaire locale (Local COA , LCOA) identifie la liaison locale ; elle est obtenue en
concatnant lidentifiant de linterface physique du mobile avec le prfixe rseau du
routeur daccs courant. Quand le mobile se trouve dans un rseau tranger, il sera
identifi par sa RCOA.
Des enregistrements normaux [28] auprs du HA sont galement ncessaires pour que
lassociation nexpire pas.
Aprs cette brve introduction de HMIPv4, la suite de ce chapitre tudiera lintgration
de HMIPv4 avec MPLS.

II Rseau MPLS hirarchique pour Mobile Ipv4


Figure V.2 illustre un exemple dun rseau MPLS pour HMIPv4.

L SR

L ER 2
CN
L ER 1

H A / L ER

L SR

G FA
/ LER
R FA
/ LS R

RF A
/ LSR

FA / LER
F A / L ER
F A / LE R

MN

MN

Figure V.2 : Rseau MPLS hirarchique pour Mobile IPv4

62

Dans cette architecture, le HA , le GFA et les FAs sont considrs comme tant des
LERs tandis que chaque RFA joue le rle dun LSR. Tous ces agents supportent les
fonctionnalits de HMIPv4 de MPLS [29].

II.1

Procdure denregistrement

Si un mobile se trouve dans un rseau tranger, il envoie un message de demande


denregistrement ayant la COA ladresse du GFA signal dans le message dannonce des
agents. En effet, chaque FA avertit les adresses des agents hirarchiques dbutant par sa
propre adresse et terminant par ladresse du GFA. Le FA le plus proche du mobile reoit
le message denregistrement rgional selon la procdure denregistrement base sur la
mthode Mobile IP Regional Registration[28]. Il analyse ce message puis le transmet
au prochain RFA dans la direction du GFA .Quand le RFA reoit le message, il rserve
une entre correspondant au mobile dans sa table dacheminement puis inclut sa propre
adresse dans le message denregistrement.
Cette procdure se rpte jusqu larrive au GFA. Le GFA collecte linformation
propos du RFA de niveau infrieur puis transmet le message au HA. Chaque FA
maintient une entre correspondant au mobile dans sa liste des visiteurs.
Quand le HA reoit le message de demande denregistrement, il apprend la COA du
GFA et lui envoie un message de demande dtiquettes en utilisant la COA du GFA
comme FEC1 .
Le GFA lui rpond par un message dassociation dtiquettes. Tout en associant les
tiquettes, le GFA conserve ladresse mre du mobile et la table dassociation
dtiquettes correspondant aux mobiles enregistrs. Quand le message dassociation
acquiert le HA, un LSP est alors tabli.
Ensuite, le HA change la range dans sa table dexpdition ayant ladresse mre du
mobile comme FEC. Les valeurs vides du port sortant et de ltiquette sortante sont
remplaces par les nouvelles valeurs ngocies avec le GFA. De cette faon, le HA peut
livrer les paquets destins au mobile en les dirigeant au GFA. A la fin, un message de
rponse denregistrement sera envoy au GFA travers le LSP tabli.
De la mme faon, le GFA tablit un LSP avec le RFA infrieur en utilisant la COA du
RFA infrieur comme FEC et en changeant les messages de demande et dassociation
dtiquettes. Le GFA doit ensuite changer la range de sa table dexpdition
correspondant ladresse mre du mobile et le message de rponse denregistrement est
achemin au RFA infrieur le long du LSP tabli. Cette opration est rpte jusqu
arriver au FA servant le mobile.

.
[1] Annexe D propose un protocole de micro-mobilit trs semblable HMIPv4 mais qui associe une FEC
ladresse mre du mobile et non pas ladresse du GFA ou la COA.

63

Figure V.3 illustre la procdure denregistrement.

MN

FA / LER

RFA / LSR

GFA / LER

HA / LER

Annonce des agents


Demande
Demande
Demande
Demande
d'enregistrement d'enregistrement d'enregistrement d'enregistrement
Dem ande
d'tiquettes
Association
d'tiquettes
Demande
d'tiquettes

Rponse
d'enregistrement

Association
d'tiquettes
Demande
d'tiquettes

Rponse
d'enregistrement

Association
d'tiquettes
Demande
d'tiquettes

Rponse
d'enregistrement

Association
d'tiquettes
Rponse
d'enregistrement

Figure V.3 : Procdures denregistrement et dtablissement de LSP

II.2

Livraison de paquets

Un paquet issu dun correspondant arrive au LER dentre. Ce routeur vrifie si


sa table dexpdition contient une tiquette correspondant ladresse destination du
paquet. Sil len trouve, ltiquette est attache et le paquet est dirig au routeur en aval.
Sinon, un LSP est tablir avec le HA du mobile. Le LER dentre attach au
correspondant envoie une requte dtiquettes pour la FEC du mobile. Le HA reoit ce
message et envoie le message dassociation dtiquettes non pas au mobile mais un
LSR en amont. Le HA doit connatre ladresse mre du mobile en sappuyant sur la

64

valeur de ltiquette reue du LSR en amont tout en consultant la table dexpdition. Le


HA enregistre ensuite ltiquette correspondant au GFA.
Figure V.4 prsente la procdure de transmission des paquets un mobile.

In Label

FEC

MN

In Label

FEC

12

MN

Out Label
vers LSR1

FEC

19

MN

Vers LSR

GFA

Vers LSR

Out Label

Out Label

Out Port

Out Port

Vers HA

19

Out Port
12

HA / LER

LSR 1

LER 2

CN

In Label

In Label

FEC

GFA

Out Label
Vers GFA

Out Port
2

LSR
GFA / LER

RFA / LSR

FA /LER 2

MN

In Label

In Label

FEC

22

MN

FEC
MN

Vers RFA

RFA

Vers RFA

FEC

MN

Vers FA

22

FA

Vers FA

22

Vers MN

Out Port

In Label

Out Label

Out Label

Out Label

Out Port

Out Port
-

Figure V.4 : Livraison de paquets et distribution des tiquettes

Le paquet destin au mobile arrive au HA avec une tiquette de valeur 19. Ltiquette de
sortie a une valeur 5 correspondant au GFA. Le GFA reoit le paquet travers le LSP
tabli entre lui et le HA. Selon ltiquette attache au paquet, il peut vrifier si le mobile
est enregistr chez lui ou pas et identifier le RFA infrieur.
Selon Figure V.4, ltiquette entrante a une valeur 2 pour le mobile dans la table
dexpdition du GFA. Ltiquette sortante a une valeur 7 qui pointe vers le RFA de
niveau infrieur. Pareillement, le RFA reoit le paquet travers le LSP tabli et change
la valeur dtiquette entrante par celle sortante correspondant au mobile. Le dernier FA
enlve la fin ltiquette et livre le paquet la couche IP et le transmet au mobile.

65

II.3

Re-routage lors du handoff

Dans une architecture hirarchique de MPLS, on distingue trois propositions[30]


de livraison de paquets lors dun handoff dun mobile :
Rtablissement du LSP,
re-routage du LSP, et ;
re-routage multicast.
II.3.1

Rtablissement du LSP

Cette approche est simple du fait quelle consiste ce que chaque fois quun
mobile change de position, tout le LSP soit tre rtabli. Dans ce cas, la route optimale
sera choisie. Cependant, cette approche ne profite pas de larchitecture hirarchique
prsente dans ce chapitre.
Figure V.5 illustre cette approche.

LER
Ancien LSP

CN

GFA
/ LER

HA / LER
Nouveau LSP

RFA
/ LSR

RF A / LSR
RFA / LSR
FA / LER

FA / LER
FA / LER

MN

MN

Figure V.5 : Rtablissement dun LSP

II.3.2

Re-routage du LSP

Dans lenregistrement rgional du Mobile IP, quand un handoff est mis en


place, le mobile compare le nouveau vecteur des COAs avec lancien vecteur. Il choisit

66

le niveau commun le plus bas entre les deux vecteurs. Ceci reprsente le FA anchor,
ou FA racine, qui le mobile envoie le message denregistrement rgional. Tout autre
agent de niveau suprieur ne prend pas conscience du mouvement du mobile car le LSP
dj tabli pointe toujours la position locale du mobile[31] .
Le message de demande denregistrement est envoy au GFA travers un
ou plusieurs RFAs. Chaque agent intermdiaire vrifie si le mobile est dj enregistr
chez lui en consultant sa liste des visiteurs. Sinon, il vrifie avec le RFA de niveau
suprieur et lui envoie le message. Cette opration est rpte par chaque agent prsent
dans la hirarchie dans la direction du GFA jusqu ce quun agent reconnaisse le
mobile. Ce dernier agent transmet le message de rponse denregistrement vers lagent
de niveau infrieur qui pointera alors la position du mobile pour lui livrer les paquets. Le
message de rponse denregistrement sera ainsi chang entre les RFAs conscutifs
jusqu aboutir au nouveau FA servant le mobile. Si un LSP existe entre le mobile et le
RFA anchor, un message de demande dtiquettes sera envoy au RFA infrieur. Ce
dernier rpond le RFA suprieur par un message dassociation dtiquettes et un LSP est
ensuite tabli. Les entres des tiquettes dans la table dexpdition doivent tre
modifies. La valeur de ltiquette entrante reste celle de ltiquette reue du RFA
suprieur. La valeur de ltiquette sortante sera celle issue du RFA infrieur durant
lenregistrement rgional. Ensuite, chaque RFA envoie le message de demande
dtiquettes au RFA suivant avec la COA comme FEC et le LSP est tabli aprs lenvoi
du message de rponse denregistrement en retour. A la fin, un nouvel LSP est tabli
entre le FA anchor et le nouveau FA. On remarque alors que le LSP est partiellement
rtabli du fait que le LSP entre le HA et le FA anchor reste le mme.
Figure V.6 reprsente la procdure denregistrement rgional et le processus de
distribution des tiquettes.

MN

Nouveau FA / LER

RFA / LSR
"anchor"

GFA / LER

Dem ande
Dem ande
d'enregistrem ent d'enregistrem ent

LSP com m un

Rponse
Rponse
d'enregistrem ent d'enregistrem ent
Dem ande
d'tiquettes
Association
d'tiquettes

HA / LER

LSP partiel

Figure V.6 : Enregistrement rgional et distribution des tiquettes.

67

Il sera ensuite ncessaire de se dbarrasser de lancienne information denregistrement


avec lancien FA et le RFA suprieur et de relcher le LSP. Si les anciennes
localisations ne sont pas effaces, on risque que les LSPs ne soient pas correctement
redirigs une fois que le mobile retourne lancien FA. Pour cela, le RFA anchor
envoie un message de BU ayant le champ TTL ajust zro et un message de
relchement dtiquettes lancien FA. Ainsi, tout agent en direction de lancien FA,
recevant ce message, enlve lentre correspondante au mobile dans sa liste des visiteurs
et le LSP avec lagent suprieur sera libr.
II.3.3

Re-routage multicast

Dans ce cas, le FA anchor tablit des LSPs avec la station de base servant le
mobile et toutes les autres attaches aux agents voisins.
Au dbut, le mobile envoie une requte de dplacement au RFA anchor qui informe le
mobile de la station de base qui le servira. Ce groupe de stations de base est le groupe
mulicast de LSPs. Une fois que les paquets arrivent au routeur anchor, il diffusera
les paquets tous les membres du groupe multicast. Quand un dplacement seffectue,
les donnes destines au mobile sont tout de suite prsentes sa disposition.
La mthode de re-routage multicast permet dallger le RFA anchor de la
responsabilit de poursuivre la position exacte du mobile. Tant que le mobile reste fixe
dans son domaine, le RFA anchor est toujours sr que le mobile recevra les paquets
qui lui sont destins.
Figure V.7 illustre le cas de re-routage multicast o RFA-C est le RA anchor.

LER
CN
HA / LER
GFA / LER
RFA/ LSR
RFA / LSR
FA / LER

RFA C
/ RFA anchor
FA / LER

FA / LER

MN

MN

Figure V.7 : Re-routage multicast

68

III Conclusion
Larchitecture dun rseau MPLS bas sur Mobile IPv4 hirarchique a t prsente
dans ce chapitre . Les procdures denregistrement, dtablissement du LSP et la
livraison de paquets ont t aussi dtailles. Quand un mobile se trouve dans un rseau
tranger, des enregistrements rgionaux sont effectus et un rtablissement partiel du
LSP est ncessaire. Donc le retard dtablissement du LSP est rduit par rapport au retard
lors dintgration de Mobile IPv4 avec MPLS. Diffrentes mthodes de re-routage ont
t expliques.
La transition de HMIP de la version IPv4 la version IPv6 introduit des changements
dans larchitecture et les oprations de livraison de paquets. Le chapitre suivant prend
compte de ces changements lors dintgration de HMIPv6 avec MPLS.

Chapitre VI:
Intgration de
HMIPv6 avec MPLS

Pour rpondre aux demandes de services multimdia dans les futurs systmes
cellulaires, les zones cellulaires auront des rayons plus petits pour pouvoir supporter des
dbits levs tout en assurant des taux derreurs acceptables. Avoir de petites cellules
implique que le mobile pourra traverser les frontires plus frquemment et la capacit de
signalisation saccrotra rapidement.
Ce chapitre prsente lintgration de MPLS avec Mobile IPv6 hirarchique
HMIPv6[32] . Section I introduit HMIPv6 et larchitecture utilise. Section II prsente
le schma du rseau bas sur MPLS et HMIPv6. Ltablissement des LSPs, la livraison
de paquets et les mthodes de handoff seront aussi voques.

Prsentation de Mobile IPv6 hirarchique ou HMIPv6

Ce protocole est propos comme un protocole pouvant grer la micro-mobilit pour


IPv6. Il conserve, comme son ancienne version, le but de rduire la charge de
signalisation dune part , entre le mobile et les nuds correspondants et dautre part,
entre le mobile et le HA. HMIPv6 [33] est bas sur Mobile IPv6 [34] et introduit une
nouvelle entit dite Mobility Anchor Point, MAP et des extensions mineurs au mobile
et aux oprations du HA.
Lide essentielle est que le mobile enregistre la COA du MAP avec son HA. Cependant,
quand un mobile se dplace localement (sans changer de MAP), la nouvelle position ne
sera informe quau MAP et rien nest chang avec le HA ou avec les correspondants se
trouvant hors du rseau daccs radio (Radio Access Network, RAN). La signalisation
sera alors concentre dans une petite zone et ne perturbe pas le rseau coeur et le temps
de mise jour de la position courante du mobile est ensuite rduit.

70

II Rseau MPLS hirarchique pour Mobile Ipv6


II.1

Architecture du rseau

On considre une architecture compose de plusieurs domaines comme le montre


Figure VI.1 o chaque domaine forme un RAN. Un RAN est constitu de deux ou
plusieurs niveaux de LSRs. Les routeurs de frontire ou LERs assurent une connectivit
entre le mobile et une ou plusieurs stations de base. Ces routeurs sont intituls Radio
Access Routers ou RARs. Plusieurs RARs sont connects aux LSRs intermdiaires qui
leurs tours, sont lis un ou plusieurs passerelles dextrmit ou Edge Gateways ,
EGW (ou un Remote Access Server selon [35]). Un EGW relie le rseau local au
rseau extrieur contenant dautres RANs[36].

MA10
HA

CN

MA9
/ LSR

MA12
MA1

MA 11
/ LSR

HN

RAR

RAR
MA2

LSR

LSR
RAR
Nuage MPLS
RAN
MA0 / MAP / EGW
FN
MA4

MA3

MA8
/ RAR
MA5
/RAR

MA6
/ RAR

MA7
/ RAR

MN

Figure VI.1 : Architecture du rseau RAN.

71

II.2

Livraison de paquets
La livraison de paquets sera tudie dans deux cas :
Cas o le correspondant initie la communication, et ;
Cas o le mobile lance la communication.

Dans les deux cas, quand le mobile se dplace vers un rseau tranger, il effectue
la procdure denregistrement avec le MAP.
Par dfaut, le MAP est choisi comme tant lagent le plus loin du mobile. Il se peut quil
arrive parfois que le mobile ncessite de dcouvrir son HA avant de performer la
procdure denregistrement comme le montre Figure VI.2.

MN

RAR

D c ou v er te d e
R C O A et L C O A

M AP / LER

HA

S ollic ita tion


d es a ge n ts
A n n on c e
d e s a g en t s

D e m an d e
d 'en r eg istr em e nt e t B U
R p on s e d 'en r eg ist r em e nt
e t B A ck
D em ande
d 'e n re g is tr e m e n t e t B U
R p on s e d 'en r e gistr em e nt
e t B A ck
M N e nr e gis tr
av e c le M A P e t le H A
Figure VI.2 : Dcouverte du HA et procdure denregistrement

II.2.1

Cas o le correspondant initie la communication

Aprs avoir examin sa cachette et avoir cherch une entre de la nouvelle COA
du mobile, le correspondant dcide sil doit livrer les paquets directement au mobile si
cette entre existe ou les faire passer au HA dans le cas contraire.
Si le RAR attach au correspondant (MA10 dans Figure VI.1) possde un LSP dj
tabli pour la FEC du mobile, les paquets seront achemins selon ce LSP.
Sinon, ce RAR initie ltablissement dun LSP. Le RAR attach au mobile va rpondre
par une association des tiquettes et le LSP sera tabli.

72

Semblablement la mthode dintgration de Mobile IPv6 avec MPLS, quand le mobile


se trouve dans son rseau mre, les paquets qui lui sont destins sont intercepts par son
HA. Le dernier RAR cherche dans sa table dexpdition lentre correspondante
ltiquette dentre et comme il est un LER, il fait passer les paquets au niveau IP et le
HA les achemine au mobile.
Si le mobile se trouve dans un rseau tranger, le HA doit possder une entre du mobile
dans sa cachette des associations. La COA du mobile sera utilise comme une FEC dans
la table dexpdition. Dans le cas o lentre correspondante a les valeurs du port sortant
et dtiquette sortante vides, un LSP entre MA11 et EGW/MAP (MAP0) doit tre tabli
(voir Figure VI.1). Le MAP possde une entre correspondant la FEC du mobile dans
sa cachette mais non pas une association dtiquettes. Il a besoin donc dobtenir une
tiquette du RAR servant le mobile (MA5).
Ensuite, le HA aura donc deux entres dans sa table dexpdition : une pour le LSP entre
le correspondant et lui (entre MA10 et MA11), et une pour le LSP entre lui et le MAP
(entre MA11 et MA0). Le MAP possde aussi dans sa table dexpdition, une entre
pour le LSP entre lui et le mobile (entre MA0 et MA5).
Les paquets seront ainsi achemins selon les LSPs tablis tout en inter-changeant les
tiquettes au niveau des routeurs intermdiaires.
Dans la cachette du MAP, une relation existe entre la RCOA et la LCOA du mobile. Le
MAP cre une en-tte encapsule ayant la LCOA comme ladresse de destination.
Le paquet sera de nouveau trait par la couche MPLS et une tiquette lui sera associe en
considrant la LCOA comme FEC. Les routeurs auront donc mettre jour leurs entres
dans leurs tables dexpdition.
Quand le mobile reoit un paquet encapsul, il se rend compte que le correspondant na
pas une mise jour de sa position courante. Le mobile lui envoie directement un
message de BU. Le RAR attach au correspondant (MA10) dcide sil est ncessaire
dtablir un LSP avec le MAP du mobile qui est MA0.

73

Figure VI.3 illustre les tapes suivies pour tablir un LSP lorsquun correspondant lance
la communication.

MN

MA5

M A P / L ER

H A / M A11

M A10

D em ande
d'tiquettes

CN

Paquet
de donnes

A ssociation
d'tiquettes
D em ande
d' tiquettes

D em ande
d'tiquettes
A ssociation
d'tiquettes
Paquet
de donnes
C ouche IP
P aquet
de donnes

Association
d'tiquettes
Paquet
de donnes

Paquet
de donnes

LSP ent re
M A 10 et M A11

L SP entre
M AP et M A 11

LSP entre
M A P et M A5

BU
B Ack
D em ande
d'tiquettes
Association
d'tiquettes

LSP entre
M AP et M A10

Figure VI.3 : Etablissement du LSP quand un correspondant initie la communication

II.2.2

Cas o le mobile lance la communication

Le mobile envoie les paquets destins au correspondant directement sans


lintervention du HA.

74

Au dbut de la communication, un LSP doit tre tabli entre MA5 et MA10 comme le
montre Figure VI.4.

MA5

MN
Paquet
de donnes

MAP / LER

Demande
d'tiquettes

Association
d'tiquettes

HA / MA11

Demande
d'tiquettes

Association
d'tiquettes

MA10

CN

Demande
d'tiquettes
Association
d'tiquettes

Paquet
de donnes

LSP entre
MA5 et MA10

Figure VI.4 : Etablissement du LSP quand le mobile lance la communication

Le LSP comprend les routeurs {MA5, MA3, MA0, --, MA2, MA9, MA10} selon la
Figure VI.1. Les routeurs intermdiaires entre MA5 et MA10 consultent uniquement
leurs tables dexpdition pour faire passer les paquets MA10 tandis que dans le cas o
le correspondant lance la communication, ces routeurs examinent leurs tables de routage
et leurs tables dexpdition ensemble cause des mcanismes dencapsulation.

II.3

Types de Handoffs dans HMIPv6

On distingue deux types de Handoff dans HMIPv6 [37]:


Handoff intra-RAN : entre lesRARs dun mme RAN, et ;
Handoff inter-RAN : entre des RANs diffrents.
II.3.1 Handoff inta-RAN
Si on suppose que le mobile se dplace de MA5 MA6,selon la Figure VI.1, il va
obtenir une nouvelle LCOA. Il envoie ensuite un message de BU local son MAP
(MA0) et tous les correspondants se trouvant lintrieur du RAN. En mme temps, le
mobile envoie un message de BU MA5 pour que les paquets soient redirigs de MA5
MA6.

75

Un LSP sera tabli entre MA5 et MA6 selon la mthode dextension des LSPs explique
ultrieurement et les deux routeurs remettent jour par consquence leurs tables
dexpdition.
Le MAP ayant une entre dans sa cachette reliant la RCOA et lancienne LCOA et un
LSP le connectant lancien RAR servant le mobile doit rassocier la nouvelle LCOA
avec sa RCOA fixe et rtablir un nouvel LSP.
II.3.2 Handoff inter-RAN
Ce type de handoff reprend les mmes tapes du handoff intra-RAN
et ajoute le besoin dtablissement des LSPs dune part, entre le HA du mobile et le
nouveau MAP et dautre part, entre le nouveau MAP et les correspondants se trouvant
en dehors du RAN.
Si on considre que le mobile se dplace de RAN1 RAN2 servi par MA2. Le HA reoit
un message de BU avec MA2 contenant une nouvelle adresse RCOA (RCOA2). Si le
mobile est actif, un nouveau LSP est tabli vers la nouvelle RCOA. Les correspondants
se trouvant hors RAN2 doivent effectuer la mme opration.
Enfin, lentre correspondante RCOA1 sera garde jusqu tre relche par le routeur
dentre ou rejete par le routeur de sortie.
Jusqu ce point, MPLS et HMIPv6 oprent sparment. Plusieurs LSPs sont
ncessaires pour connecter le mobile son correspondant. Le HA le MAP ne peuvent pas
interchanger directement les tiquettes pour aboutir au mobile. Pour cette raison,
chaque LER, ltiquette est ajoute au paquet puis une association est ajoute dans la
cachette puis ltiquette est rejete.
Le changement de niveaux dans une mme hirarchie et la dcomposition du chemin en
plusieurs LSPs expliquent pourquoi Annexe E propose une intgration optimise pour la
micro-mobilit pour MPLS o un seul LSP est suffisant.
Dun autre ct, lorsquun handoff est mis en place, les deux protocoles
assistent dans la gestion de livraison de paquets. Annexe F propose une sparation des
niveaux de handoff. Ainsi, on distingue le handoff au niveau MPLS qui assure une
livraison rapide de paquets au mobile et le handoff au niveau Mobile IP qui joue
uniquement un rle de scurisation et dauthentification.

III Conclusion
Ce chapitre a propos un modle dintgration de MPLS avec la version IPv6 du
protocole de micro-mobilit HMIP bas sur le rseau daccs radio.
Le mcanisme de livraison de paquets a t expliqu dans deux cas diffrents et les deux
types de handoff ont t dtaills.
Aprs avoir thoriquement tudi le dploiement des services de Mobile IP sous
ses deux versions IPv4 et IPv6 au dessus dune infrastructure MPLS, ltude de
performance de cette intgration sera exploite dans le chapitre suivant.

Chapitre VII:
Etude de performance

Aprs avoir tudi dans les chapitres prcdents les rseaux MPLS mobiles, ce
chapitre ralise une tude de performance des mcanismes dintgration de Mobile IPv4
et de HMIPv4 avec MPLS. Cette tude est base sur des expriences de simulation qui
permettent de tester ces nouveaux mcanismes afin de pouvoir anticiper les problmes
qui pourront se poser dans le futur.
Section I prsente le Network Simulator (NS) comme un outil de simulation.
Limplmentation de MPLS dans NS est dtaille et les problmes nuisant la
simulation de MPLS avec Mobile IPv4 ou HMIPv4 sont expliqus et quelques solutions
sont proposes. Section II illustre les expriences effectues avec NS pour tudier
lintgration de Mobile IPv4 et de HMIPv4 avec MPLS.
Section III montre une autre srie dexpriences qui a t dveloppe selon OPNET
( Optimized Network Engineering Tools), un trs puissant simulateur mais
malheureusement commercial.

I Network Simulator ou NS
NS est un simulateur qui a dbut comme une variance du simulateur REAL
implment en 1989 par UC Berkeley. Actuellement, son dveloppement fait partie du
projet VINT et son code est gratuitement distribu.
Les modles de simulations sont raliss l'aide du langage C++, comme tant le
langage de compilation, pour spcifier le fonctionnement interne des composants du
rseau, et laide du langage Otcl ( Object Tool Language Command ), comme tant
le langage dinterprtation, pour dcrire les conditions dune simulation comme la
topologie du rseau, les caractristiques des liens physiques, les protocoles utiliss, les
communications
NS possde un outil NAM (Network Animator) qui visualise les rsultats de
simulation et les traces des paquets de donnes.
La version de NS utilise est ns-2.1b6a [38] qui implmente dj le protocole Mobile
IPv4. Cependant, pour tester le protocole HMIPv4, on a besoin dajouter le module de
micro mobilit CIMS (Columbia IP Micro-Mobility Software)[39] dvelopp par
luniversit Columbia.

77

Pour simuler MPLS, un module mns-v2.0 [40] dvelopp par Gail Ahn, est ncessaire.
Cependant, mns-v2.0 est un module qui a t dvelopp pour raliser uniquement les
fonctions de MPLS tout en crant un nouveau type de nud sans tenir compte du
dveloppement de NS surtout au niveau du support du routage hirarchique et de la
gestion de mobilit.
Les sous-sections suivantes prsentent limplmentation de MPLS dans NS puis
expliquent les limites de son usage.

I.1

Implmentation de MPLS dans NS


I.1.1

Modle conceptuel de mns-v2.0

Mns-v2.0 supporte les fonctions suivantes de MPLS [41] :


Lchange des tiquettes (push, pop et swap), dcrmentation du TTL
et les fonctions du LSR penultimate, et ;
La distribution selon le protocole LDP et les messages CR-LDP.
Figure VII.1 illustre le modle conceptuel de MPLS dans NS-2.

Figure VII.1 : Modle conceptuel de MPLS dans NS-2 [41]

78

Selon la figure prcdente, mns-v2.0 consiste en plusieurs composants :


LDP/ CR-LDP :
Cette entit gnre et gre les messages de LDP ou CR/LDP tels que les
messages Request , Mapping , Release
MPLS classifier :
Cette entit effectue toutes les oprations appliques aux tiquettes telles que
lajout, lenlvement et lchange des tiquettes.
Service Classifier :
Cette entit classifie les services selon que les paquets arrivant par les interfaces
sont tiquets ou non.
Admission Control :
Cette entit vrifie le paramtre de trafic de CR-LDP et dtermine si le nud
MPLS possde suffisamment de ressources pour supporter un certain niveau de
QoS.
Resource Manager :
Cette entit cre ou limine les queues de donnes et gre les informations de
ressources disponibles.
Packet Scheduler :
Cette entit gre les paquets dans les queues ou les files dattente.
Les quatre dernires entits traitent les flux de trafic de type temps rel (pour plus
dinformations, se rfrer [41] ).

I.1.2 Implmentation de mns-v2.0


Un nud, comme dfini dans NS, consiste dagents et de classifiers. Lagent
reoit ou envoie les paquets et le classifier classifie les paquets. Chaque classifier
associe au paquet un certain critre logique pour rfrencier un autre objet de
simulation. Chaque classifier contient donc une table dobjets de simulation indexs
par un numro de slot. Donc le classifier doit dterminer le slot associ au paquet
pour lenvoyer lobjet rfrenci par ce slot.
Dans mns-v2.0, un nouveau type de nud MPLS Node a t cre selon une classe
hrite de la classe Node de base.

79

Figure VII.2 illustre larchitecture de MPLS Node .

Figure VII.2: Architecture de MPLS Node [41]

Quand un MPLS Node reoit un paquet selon node_entry, il effectue les oprations
suivantes :
MPLS classifier dtermine si le paquet est tiquet ou pas. Si oui, un
change dtiquettes est fait. Si le paquet nest pas tiquet, mais un LSP existe
pour la FEC de destination, il sera trait comme un paquet tiquet. Dans les
autres cas, le paquet est envoy lentit Address Classifier.
MPLS classifier ralise lacheminement du niveau 2 et envoie les paquets
directement au prochain saut.
Address Classifier ralise le routage du niveau IP en se basant sur
ladresse IP de destination. Ce type de classifier est utilis pour le routage
unicast .
Si le saut suivant du paquet est le nud lui-mme, le paquet est envoy
lentit Port Classifier qui assure le passage du paquet lagent correspondant.
Lagent livre le paquet la destination.
Lagent LDP est responsable de la rception des paquets, la gestion des
messages LDP, la slection dun nouveau nud et de la cration dun nouveau
message LDP pour tre envoy lagent attach au nouveau nud.
Lagent Null ou Source/Sink gnre les agents qui envoient les
paquets la source, la destination ou qui rejettent les paquets.

80

Deux tables sont implmentes dans mns-v2.0 :


Partial Forwarding Table ou PFT, qui associe un paquet IP un LSP au
niveau du routeur dentre. Elle contient la FEC, le FlowID et un
pointeur LIBptr vers une entre de la table LIB.
Label Information Base ou LIB, qui contient les informations dun LSP
qui sont ltiquette et le port dentre et ltiquette et le port de sortie.

I.1.3 Limites de mns-v2.0


Le code MPLS est actuellement un code trop exprimental et il nest pas
entirement test. Il connat plusieurs points faibles:
Il ne supporte pas le routage multicast pour les raisons suivantes :
Pas de mcanisme de distribution dtiquettes pour les groupes
multicast ,
Pas une entit Replicator1 multicast pour cooprer avec le
classifier MPLS, et
Len-tte MPLS possde des pointeurs qui ne fonctionnent pas
avec le Replicator multicast .
Il ne fonctionne quavec le routage unicast et ladressage de type
flat et ne comprend daucune faon le routage hirarchique.
Dans la version actuelle de mns-v2.0, un nud ne peut pas supporter en
mme temps le routage hirarchique et les fonctions de MPLS pour les
raisons suivantes :
Le classifier MPLS est explicitement coupl avec le
classifier dadresses de type unicast qui ne supporte pas le routage
hirarchique.
MPLS Node a besoin de vrifier si une entre est une entre de
type de mise jour (procdure route-update ), une nouvelle entre
(procdure route-new ) ou une entre de type no change (procdure
route-nochange qui consiste ne rien modifier).
Cette distinction ne peut pas se faire si on dcouple le classifier MPLS du
classifier unicast , car selon la procdure add-route implante dans la
classe Node de base, le nud peut seulement informer MPLS si lentre
est une nouvelle route et non pas si cest une entre de mise jour, une
nouvelle entre ou une entre de type no change.

.
[1] Replicator est un autre type de classifier qui effectue un certain nombre de copies du paquet.
Pour le multicast , il doit effectuer des copies pour tous les liens aux membres du groupe multicast .

81

Quelques interfaces dans MPLS classifier et MPLS Node doivent


tre changes pour fonctionner conformment avec le nouveau modle du
nud (mcanisme du node-config). Or dans mns-v2.0, on a cr un
nouveau nud MPLSnode.
Il est actuellement impossible dinstaller le module mns-v2.0 avec le
module mobiwan [42] qui implmente Mobile IPv6 malgr que les deux
modules sont crits pour la mme version de ns (ns-2.1b6).

I.1.4 Propositions et solutions


Pour pouvoir simuler MPLS avec Mobile IPv4 ou HMIPv4, il faut commencer
par dvelopper un module MPLS pouvant comprendre le routage hirarchique.
Pour ce fait, plusieurs propositions sont mises en uvre :
Il faut dfinir ladressage hirarchique pour chaque nud.
Dans MPLS, chaque nud est identifi par son id_ donc la FEC est
distribue selon cet id_ et non pas selon ladresse. Donc, on a
introduire linstruction set-address-format hierarchical.
Pour le routage hirarchique, un nud est form de plusieurs niveaux de
classifiers dont chacun tudie une partie du paquet et lenvoie au
classifier suivant. Un classifier hirarchique fonctionne conformment
au classifier dadresses de type flat mais la seule diffrence est que le
nud aura n niveaux de classifiers nots pas clsfr[n].
Lentre est au clsfr[0] qui pointe vers le niveau suprieur clsfr [1] jusqu
aboutir au clsfr[n].
Figure VII.3 illustre une hirarchie de trois niveaux de classifiers .

Figure VII.3 : Hirarchie de classifiers [43]

MPLS classifier doit tre ainsi modifi. Le nud ne doit pas avoir
des informations sur tous les nuds de la topologie mais doit
uniquement maintenir des informations sur les nuds appartenant au

82

mme cluster, sur le nombre de clusters dans son domaine et le


nombre de domaines (dcomposition hirarchique du rseau selon la
classe AddParams).
Il faut que le nud puisse intercepter la fonction add-route pour
savoir quand mettre jour sa table de routage.
Donc, il sera plus dsirable que les fonctions de MPLS deviennent
une partie du nud de base et que MPLS sera un module attach au
nud et non pas un nouveau type de nud. Il faut que le nud
reoive add-route puis passe au module MPLS qui le transforme
en route-new selon ltat du slot de MPLS classifier (plus
prcisment la fonction add-hroute qui lie les classifiers de
diffrents niveaux de la hirarchie).
En effet, le nud ne doit mettre jour sa table de routage rtable_
que lorsque la destination nest pas de type agentnull_.
On pourra ainsi liminer la mauvaise mthode de mns-v2.0 qui
vrifie si la table de routage est dj construite (selon la fonction
rtable-ready ) durant la phase dinitialisation (avant de lancer $ns
run ) puis commence calculer les routes si cette table est prte.
Pour appliquer ces propositions, on peut penser soit reprendre lcriture du code MPLS
tout en crant une nouvelle classe hrite de la classe HierNode , soit interconnecter
les classes dj existantes dans NS entre eux.
En partant de la dernire mthode, il faut tudier linterconnexion du code MPLS avec le
code de Mobile IPv4 et de HMIPv4 et essayer de lier leurs composants.
Cependant dans Mobile IPv4, ainsi que dans HMIPv4, on distingue le mobile
appartenant la classe MobileNode et les agents FA et HA appartenant la classe
BaseSation.
La classe BaseStation est une classe hybride entre la classe MobileNode
et la classe HierNode.
Chaque domaine contient un seul nud de type BaseStation. Ce noeud permet
lchange de paquets entre le rseau fixe et le rseau sans fils.
Or MPLS doit tre implant au niveau du HA, du FA et des nuds fixes interconnectant
les deux agents.
En se rfrant la Figure VII.4 illustrant larchitecture dun nud BaseStation , on
remarque lexistence dun agent de routage RTAgent qui prend la dcision du routage
des paquets.
Plusieurs protocoles ont t dfinis pour illustrer le routage hirarchique dans les rseaux
mixtes ( wired-cum-wireless scenarios ). On peut citer DSDV ( Destination Sequence
Distance Vector ), DSR ( Dynamic Source Routing ), TORA ( Temporally ordered
Routing Algorithm ), AODV (AD-hoc On-demand Distance Vector)
La variable defaulttarget_ indique que les paquets sont destins un nud mobile.
Ces paquets seront ensuite redirigs au protocole de routage appropri.
Larchitecture dun nud BaseStation est illustre dans Figure VII.4.

83

Figure VII.4:Architecture dun noeud BaseStation [43]

Il sera alors ncessaire dinterconnecter lagent LDP de MPLS avec les agents de routage
au niveau du nud hirarchique.
Les tapes suivantes sont alors respecter :
Le MPLS Classifier doit extraire les paquets selon quils soient
tiquets ou pas. Les paquets tiquets subiront les oprations de MPLS
selon L2 Switching et seront ensuite envoys lentit Link Layer ou
LL (entit de BaseStation ).
La variable defaulttarget_ doit tre ajoute pour le cas des paquets
traits par Address Classifier et routs selon le niveau IP.
Un agent de routage doit tre ajout pour traiter les paquets issus de
Address Classifier de MPLS et de defaultarget_ .
Donc, lintgration de MPLS avec Mobile IPv4 et HMIPv4 ncessite encore de travail
dcriture de codes et de changement de procdures dOTcl de NS.

84

I.1.5 Expriences selon NS


Un groupe de recherche canadien [44] a dj implment dans NS les fonctions
de MPLS avec Mobile IPv4 et HMIPv4 mais son travail na pas t publi.
Ce groupe de chercheurs a propos une mthode pour prvenir la perte de paquets durant
le handoff lors dintgration de MPLS avec HMIPv4. Cette mthode se base sur le
niveau MAC et consiste ce que lancienne station de base possde un tampon
( buffer ) pour mmoriser les paquets perdus au niveau MAC afin de les retransmettre
la nouvelle station de base.
Cette mthode repose sur les propositions suivantes :
Temporisateur Ta
Comme expliqu au Chapitre V, quand un mobile se dplace vers un
nouveau FA, ce dernier envoie un message handoff notification lancien FA
qui dclenche un temporisateur Ta. Durant Ta, tout paquet destin au mobile
sera intercept par lancien FA et redirig vers le nouveau FA selon le LSP tabli
entre les deux FAs (mthode dextension de LSP).
Dans cette nouvelle proposition, Ta indique si le mobile est actif ou non selon
quil reoit ou envoie des paquets. Chaque paquet issu du mobile ou arriv au
mobile rafrachit Ta. Si Ta expire, on suppose que le mobile est en tat passif
et le LSP correspondant est enlev des tables dexpdition.
Paging
Cette nouvelle proposition utilise le processus de paging dans le but de
rduire la consommation en nergie des quipements du rseau et diminuer la
charge de signalisation rsultant de la rptition de la procdure denregistrement.
Chaque domaine sans fil sera divis en des Paging Areas ou PAs. Un mobile
en tat passif, changeant de cellules mais se trouvant toujours dans la mme PA,
na pas besoin de rpter la procdure denregistrement. Le mobile ne
senregistre auprs de son GFA quaprs changement de PA.
Chaque PA contient un paging server et le GFA ne doit connatre la position
du mobile actif ou passif quau niveau de PA.
Le mobile actif, changeant de cellules, envoie le message de demande
denregistrement au paging server qui constitue donc un autre niveau de
hirarchie. Les paquets intercepts par le GFA sont envoys au serveur puis au
mobile. Les paquets issus du mobile arrivent au serveur puis sont livrs leurs
destinations.
Quand le mobile est en tat passif, le serveur mmorise tous les paquets et
envoie en multicast un paging request toutes les stations de base
prsentes dans son PA. Les stations envoient ce message selon lacheminement
du niveau 2. Le mobile recevant ce message, envoie un message de demande
denregistrement sa propre station de base qui le transmet au serveur. Enfin, le
serveur tablit un LSP pour le mobile.
Recouvrement des paquets selon MAC
Dans les rseaux sans fils, les paquets perdus sont automatiquement
retransmis. Pour ce fait, MAC utilise les messages Request To Send (RTS),

85

Clear To Send (CTS), DATA et Acknowledgment (ACK) pour


lchange de paquets. RTS est une trame de contrle tandis que CTS est une
trame de rservation daccs au canal. Aprs la transmission de donnes, ACK
confirme le succs de transmission. Ainsi, le niveau MAC maintient des
informations sur les trames correctement livres.
Le recouvrement des paquets selon MAC et illustr dans Figure VII.5 :

Figure VII.5 : Recouvrement des paquets selon le niveau MAC [44]

Les paquets IP passent au niveau de liaison (LL). A ce niveau, une trame MAC sera
construite du paquet IP tout en ajoutant le header et le trailer appropris du
niveau MAC. La trame MAC est ensuite place dans une queue IFq. Cette trame assure
laccs aux canaux (selon RTS/CTS/DATA/ACK). Si la transmission dune trame
choue aprs plusieurs tentatives, cette trame est place dans le tampon MAC.
Comme illustr dans Figure VII.5.b, quand lancienne station de base reoit le message
de handoff notification de la nouvelle station, elle transmet les paquets mmoriss
dans le tampon la nouvelle station le long du nouveau LSP tabli.
De mme, les paquets prsents dans IFq sont aussi transmis la nouvelle station de base.
A noter que les mobiles se trouvant sous la mme couverture dune station partagent le
mme tampon MAC. La station de base utilise ladresse MAC du mobile prsente dans
le message handoff notification pour identifier les paquets qui lui sont destins.

86

Les rsultats quantitatifs dtude de la performance de cette mthode sur les applications
TCP et UDP ont considr le modle architectural illustr dans Figure VII.6.

Figure VII.6 : Modle architectural [44]

Les stations de base sont considres comme des LSRs/FAs. On suppose une connexion
directe entre chaque deux stations voisines. W1 et W2 sont considrs comme tant des
serveurs de paging . On varie la distance de la couverture commune (ou d overlapping )
entre les stations voisines afin dtudier plusieurs scnarios.
Performance des applications UDP
Dans cette exprience, on considre un trafic UDP issu dun correspondant (CH)
au mobile (MH).
Si on trace la squence des paquets en fonction du temps de simulation pour diffrentes
valeurs de d overlapping , on remarque quune faible distance de couverture commune
induit un nombre plus lev de paquets perdus.

87

Figure VII.7 illustre ces rsultats.

Figure VII.7 : Performance dUDP sans recouvrement de paquets selon MAC [44]

Cependant, ces mmes scnarios appliqus pour la mthode de recouvrement de


paquets selon MAC montre une limination de perte des paquets, comme le montre
Figure VII.8.

Figure VII.8 : Performance dUDP avec recouvrement de paquets selon MAC [44]

On peut remarquer aussi que plus d overlapping augmente, plus le dcalage entre deux
paquets conscutifs est rduit.

88

Performance des applications TCP


Figure VII.9 compare la squence des paquets TCP Reno sans et avec
recouvrement des paquets (a et b).

Figure VII.9 : Performance de TCP sans et avec recouvrement des paquets [44]

On remarque que dans VII.9.b, pas de paquets perdus ou retransmis et les slow-start
ne sont plus observs.
Sommaire
Cette proposition a limin la perte des paquets durant handoff et a amlior
la performance de dbit TCP par comparaison lintgration de MPLS avec HMIPv4.
Cependant, NS est un engin de simulation qui est extensible, configurable
et
programmable. Mais les efforts de rassembler plusieurs codes de simulation
et
tudier linteraction entre les diffrents codes sont encore trs faibles et primitifs.
Un autre exemple de simulateur qui a tudi lintgration des services de Mobile IP avec
MPLS est dcrit dans la partie suivante.

II Expriences selon OPNET


OPNET est un autre type de simulateur. Comme cest un outil commercial, des
dtails techniques ne sont pas disponibles.
Trois sries dexpriences sont prsentes dans les sous-sections suivantes.

89

II.1

Srie 1

Un autre groupe de recherche canadien [37], [49] a ralis plusieurs expriences


pour tudier les avantages de division du rseau MPLS en deux domaines de mobilit.
II.1.1 Modle architectural

Figure VII.10 : Modle architectural

Figure VII.10 illustre une architecture de rseau utilise pour les expriences de
simulation. Dans le cas de Mobile IPv4, FDA (ou GFA) sera considr comme une
normale passerelle.
II.1.2 Dlai de bout en bout
Il est vident que le dlai introduit par Mobile IPv4 dpasse celui de HMIPv4.
Ceci revient au fait que, dans le cas de Mobile IPv4, chaque fois que le mobile change de
position, il doit senregistrer auprs de son HA tandis que dans le cas de HMIPv4,
lenregistrement nest fait quavec le GFA ou le FDA. Autant que la distance entre le HA
et le mobile est grande, autant que le dlai est grand dans Mobile IPv4 avec MPLS.
Dun autre ct, pour le cas optimal de HMIPv4, discut en Annexe D, on remarque que
les dlais sont encore plus faibles du fait que le mobile se dplaant vers un nouveau FA
envoie le message de demande denregistrement au routeur anchor et non pas au
GFA donc le nombre de sauts traverser est plus petit.

90

Figure VII.11 compare la variation du dlai de bout en bout entre le cas de Mobile IPv4
et HMIPv4 avec MPLS.

Figure VII.11 : Dlai de bout en bout [37]

Figure VI.12 compare le dlai de bout en bout entre HMIPv4 et son cas optimal.

Figure VII.12 : Dlai de bout en bout pour HMIPv4 et son cas optimal avec MPLS [49]

91
II.1.3 Variation de dbit
Figure VII.13 illustre la variation du dbit du trafic pour Mobile IPv4 et HMIPv4
avec MPLS.

Figure VII.13 : Variation de dbit [37]

Pour Mobile IPv4, quand un mobile se dplace dun rseau un autre, la variation de dbit
est grande. Le retard introduit pour achever la procdure denregistrement permet certains
paquets dtre envoys par le HA lancien FA et par suite redirigs au nouveau FA. Pour
HMIPv4, le mobile senregistre avec le GFA donc certains paquets sont envoys du GFA
lancien FA.
Par contre, HMIPv4 introduit un dbit plus stable, rsultat optimal pour les applications de
QoS mais ceci au cot dintroduction dun nouveau composant au rseau (le GFA).
Si on considre la cas optimal de HMIPV4, prsent en Annexe D, les messages de mise
jour sont envoys au RFA anchor et non pas au GFA avec un temps plus court. Donc, le
RFA anchor envoie une quantit faible de paquets lancien FA pour tre redirigs au
nouveau FA. Ceci permet donc une variation plus fine du dbit.

92
Figure VII.14 illustre ces rsultats.

Figure VII.14 : Variation du dbit pour HMIPv4 et son cas optimal avec MPLS [49]

II.1.4 Sommaire
En rsum, le cas optimal de HMIPv4 a prsent des rsultats plus performants que
les cas de HMIPv4 et de Mobile IPv4 intgrs avec MPLS. Mais, comme signal en Annexe
D, cette optimisation introduit une complexit au niveau des routeurs.

II.2

Srie 2

Un groupe de recherche koren [29] a analys la performance dintgration de


HMIPv4 avec MPLS en considrant le dlai du handover, la charge de signalisation et
loccupation de ressources pour comparer les diffrents mcanismes de routage.

93
II.2.1

Modle architectural

Figure VII.15 : Architecture du rseau [29]

Selon larchitecture du rseau prsente dans Figure VII.15, N dfinit le nombre de sauts
sparant les FAs du RFA anchor (GFA dans le pire des cas).
II.2.2

Dlai du Handover

Le dlai de handover est un important facteur de QoS li la probabilit de perte


des paquets. Si le dlai est grand, le signal se propageant dans le domaine sans fils sera trs
faible et conduira une perte de paquets.
Figure VII.16 prsente ce dlai pour les trois diffrents mcanismes de re-routage expliqus
au Chapitre V.

Figure VII.16: Handover Delay [29]

94
On remarque que le routage multicast prsente le plus faible dlai.
II.2.3

Rupture de communication

Une autre caractristique dun bon mcanisme de re-routage est une dure courte de
rupture de communication.
Si la rupture est longue, le dlai entre les paquets sera augment ce qui pourra nuire aux
services de type temps rel comme la vidoconfrence.
La rupture de communication est compare pour les trois mcanismes de routage dans la
Figure VII.17.

Figure VII.17 : Rupture de communication [29]

On remarque que la rupture de communication minimale est rencontre pour le re-routage


multicast. Ceci est d, comme expliqu au Chapitre V, au fait que les donnes sont
transmises toutes les stations de base adjacentes celle servant prcdemment le mobile.
II.2.4

Besoin de tampon

Pour dterminer le cot dquipements du rseau, il est important dtudier les


besoins davoir des tampons des paquets au niveau des routeurs. La quantit de paquets
rservs dans un tampon affecte le dlai de livraison de paquets au mobile.
Si le tampon a une taille insuffisante, on risque davoir une perte de paquets.

95
Figure VII.18 compare le besoin total de tampons dans le rseau (somme du besoin de
chaque nud participant dans le handover ).

Figure VII.18: Besoin en tampons [29]

Le re-routage dynamique ncessite une quantit minimale de tampons au niveau du routeurs


du fait quun nombre de routeurs est commun entre le nouveau LSP et lancien LSP.
II.2.5

Sommaire

Le re-routage multicast prsente des rsultats optimaux en ce qui concerne le dlai de


handover et la priode de rupture de communication mais ceci au dtriment dune
mauvaise efficacit de la bande passante du rseau.

III

Conclusion

Ce chapitre a prsent une tude de performance de lintgration des services de


Mobile IP au dessus de MPLS. La simulation de MPLS dans NS a t dcrite et ses checs
ont t signals. Des propositions ont t tablies pour pouvoir effectuer des expriences de
simulation.
Il a t remarquable que les rsultats obtenus par OPNET soient plus varis mais lusage de
ce simulateur nest pas gratuitement disponible.
Enfin, de travaux supplmentaires sont encore ncessaires pour former un simulateur unique
pouvant supporter des natures diffrentes de rseaux de tlcommunications comme MPLS,
Mobile IP et HMIP sous les deux versions IPv4 et IPv6.

Conclusion gnrale

Lvolution croissante des rseaux mobiles ajoute le besoin de fournir aux utilisateurs
des services de transmission de donnes, et vu limportance de lInternet et dIP, cela se fera
dans lUMTS et les technologies ultrieures, par une intgration dIP dans les rseaux
mobiles.
Mobile IP est un srieux candidat pour les rseaux de 3G et 4G. Mais, il a quelques
limitations en termes de scalabilit et de performance de handovers .
Pour sopposer cette limitation, on a essay de se recourir aux avantages de la technologie
MPLS, une technologie de commutation issue de la recherche du meilleur interfonctionnement entre IP et ATM. Cette technologie est devenue aujourdhui un prodigieux
vecteur de marketing pour ses promoteurs et en passe dtre adopte par de trs grands
oprateurs comme une technologie de commutation dans leurs curs de rseau.
Ainsi, ce projet a essay de dgager les avantages dintgration des fonctions de Mobile IP
avec MPLS.
Le tunnel observ dans Mobile IPv4 entre le HA et le FA est limin donc le dlai de
handover est strictement rduit et la charge de signalisation alourdissant le rseau est
diminue.
Pour grer la micro-mobilit des utilisateurs, lintgration de MPLS avec HMIPv4, un
protocole de gestion de mobilit locale, a t aussi tudie et encore une fois, les dlais sont
de plus en plus rduits et la transmission des paquets est de plus en plus fiable.
Cependant, comme IPv6 est la version future de lInternet, il a t important dtudier
lintgration de MPLS avec IPv6 selon les diffrents niveaux de mobilit.
Or, ce sujet est encore en cur de dploiement et il existe actuellement de diffrents groupes
de chercheurs qui essaient de tester lefficacit dintgration des services de Mobile IP avec
MPLS tout en effectuant des expriences de simulation, dont certaines ont t prsentes
dans ce sujet, et en essayant de raliser des implmentations pratiques ou des testbeds
pour avoir des rsultats rels et concrets.
Donc, on sattend dans le future proche ltablissement de nouvelles propositions et
llaboration de nouvelles suggestions dans le but daboutir un rseau mobile de
transmission de donnes rapide, fiable et scuris.

ANNEXE A : Distribution des tiquettes selon des


extensions de Mobile IP

Cette annexe tend proposer une mthode dtendre la faon de distribution des
tiquettes en sappuyant sur le processus denregistrement de Mobile IP. Cette mthode
consiste ce que les informations dtiquettes soient portes par les messages de demande
et de rponse denregistrement de Mobile IP. Dans le cas de routage optimis, ces
informations sont portes par le message de BU.
La mthode de distribution des tiquettes selon le protocole LDP seffectue entre les noeuds
adjacents. Dans le cas o cette distribution, comme dans le cas des VPNs, stablit entre des
noeuds non adjacents, une distribution explicite dtiquettes effectue comme tant une
opration spare aprs la procdure denregistrement. Cette opration spare introduit des
overhead additionnels et une livraison de paquets non compatible.
Pour ce fait, une extension de Mobile IP est ajoute aux messages de demande
denregistrement, de rponse denregistrement et de BU.
Le champ dextension de ltiquette a le format suivant :
Type

Length

Label

LGP

Exp

Reserved

TTL

Figure A.1: Format de lextension de ltiquette

Type: identifie lextension comme une tiquette (la valeur 50 est


tre assign)
Length : longueur en byte de lextension excluant la longueur de
TLV
Le bit L indique si lmetteur de lextension utilise le codage
MPLS des tiquettes. Sil est positionn 1 , ltiquette de 32-bits sera code
en 20bits label , Exp, S et un format TTL .
Le bit G indique si lmetteur de lextension utilise une session
GRE pour le codage ses tiquettes. Sil est positionn 1, ltiquette sera une
cl de session GRE de 32 bits (non discut dans ce projet).
Le bit P indique si lmetteur de lextension utilise une extension de
loption de destination IPv6. Sil est positionn 1, ltiquette sera insre
dans le format de ltiquette MPLS.

98
Les bits Reserved sont mis zro par lmetteur et ignors par le
rcepteur.
Brivement, cette nouvelle mthode de distribution des tiquettes se rpartit entre les
diffrents composants de Mobile IP.
Pour le FA, il doit pouvoir assigner une tiquette unique chaque
mobile et envoyer cette tiquette au HA ou au nud correspondant durant la procdure
denregistrement. En effet, un champ dextension de ltiquette sera plac dans le message de
demande denregistrement envoy au HA.
Si un domaine MPLS spare le mobile du FA, le FA sera un ordinaire LSR permettant de
distribuer explicitement les tiquettes. Sinon, Le FA jouera le rle dun LER de sortie
et passera le paquet au niveau IP.
Pour le HA, il place ltiquette dans un champ dextension de
ltiquette dans le message de rponse denregistrement lors de la rception du message de
demande denregistrement du mobile contenant un champ dextension dtiquette.
De mme si un domaine MPLS spare le nud correspondant du HA, le HA sera un
ordinaire LSR recevant les tiquettes du FA. Sinon, le HA jouera le rle dun LER de sortie
et passera le paquet au niveau IP.
Pour le noeud correspondant , ce scnario ne sapplique que dans le cas
de routage optimis. Le HA peut placer le champ dextension dtiquette (reu par le FA
dans le message de demande denregistrement) dans lentre de lassociation
denregistrement en envoyant le message du BU au nud correspondant. Le correspondant
associe une tiquette au paquet par rapport celle prsente dans lentre et livre les paquets
au mobile.
Les avantages de distribution des tiquettes selon Mobile IP par rapport la mthode
conventionnelle de distribution des tiquettes selon MPLS sont les suivants :
o
Les en-ttes sont plus petites et la commutation est plus rapide car la
distribution des tiquettes fait partie de la procdure denregistrement.
o
Pas de sparation de distribution des tiquettes pour la ngociation explicite
des tiquettes.
o
On na plus besoin dautres protocoles pour la ngociation explicite des
tiquettes car la procdure denregistrement est suffisante.
o
Les informations du mobile et les informations des tiquettes sont
synchronises ensemble.
o

La distribution des tiquettes est implicitement scurise par Mobile IP.

Le relchement de ltiquette se fait lors de lexpiration du message de BU.

99

Si la distribution des tiquettes se fait selon le principe conventionnel de MPLS, les tapes
suivantes sont suivre :
o
o
o
o

Etablir la procdure denregistrement de Mobile IP,


Ngocier explicitement les tiquettes entre le HA et le FA,
Garantir une scurit pour ltape prcdente, puis;
Ngocier les tiquettes entre les noeuds MPLS voisins.

La premire et la deuxime tapes sont ncessaires pour lenregistrement de chaque mobile.


La deuxime et la troisime tapes introduisent beaucoup doverhead lors de la procdure
denregistrement.
Selon la distribution des tiquettes selon Mobile IP, la premire et la deuxime tapes sont
combines en une seule tape .

ANNEXE B : Adresses prives pour lintgration de


Mobile IPv4 avec MPLS

Comme l'espace d'adressage d'IPv4 disponible est devenu


limit du fait
d'augmentation d'quipements connects l'Internet, beaucoup d'organismes ont rduit
l'emploi des adresses globales et ont eu recours l'usage des adresses prives dans leurs
rseaux. En outre, l'utilisation de l'adresse prive rend le systme plus scuris.
L'adresse IP prive[46], a t prsente pour rduire le manque d'espace d'adressage d'IPv4.
Ces adresses peuvent ne pas tre globalement uniques car plusieurs organismes peuvent les
employer dans leurs propres rseaux tout en les coordonnant avec d'autres organismes.
Tous les protocoles mobiles doivent pouvoir soutenir les adresses prives. D'ailleurs, les HAs
qui sont situs la frontire sparant le rseau global du rseau priv, ont besoin d'un
mcanisme pour la communication entre une adresse prive et une adresse globale. Le
mcanisme propos utilise le traducteur d'adresse des rseaux (Network Address
Translator , NAT)[47] qui consiste traduire les adresses prsentes dans les en-ttes des
paquets IP. Un routeur traduit les adresses prives en des adresses globales selon lensemble
d'adresses disponibles.
Cette annexe prsente l'intgration de MPLS avec Mobile IPv4 utilisant l'adresse IP prive
selon le traducteur NAT et le serveur DNS (Domain Name Server).
Figure B.1 illustre une infrastructure dun rseau MPLS connect dune part, un rseau
global et dautre part , des rseaux privs.

DNS
CN

Rseau priv

R seau global
LER 1
L SR 4

HA/ LER 2
MN

L SR 2
L SR 3
D om aine M P L S

L SR 5
FA / L ER 3
MN
R seau priv

Figure B.1 : Rseau MPLS bas sur Mobile IPv4 utilisant des adresses prives

101
Procdure denregistrement
Pour la procdure denregistrement, les requtes denregistrement envoyes le HA
et les rponses denregistrement reues par le FA possdent respectivement comme adresses
source et destination les adresses globales du FA et du HA.
Livraison de paquets lorsquun mobile lance la communication

LSR 5
LSR 4
H A / L ER 2
FA / LER3
P a q uet
d e d o n nes
Dem a n d e d 'tiq u ettes

MN

Asso cia tio n d 'tiq u ettes

L SR 4

L ER 1

CN

LS P entre
F A et H A

Ad d ress A ssig n
Req u est
A d dress Assig n
M a p p in g
P a q u et
d e d o n n es

D em a n d e
d' ti qu ettes
A sso cia tio n
d 'tiq u et tes

LS P en tre
H A et L E R1

Ad d ress A ssig n
R equ est
Ad d ress A ssig n
M a p pi ng
P aq u et de d on n es
P a q u et d e do n n es

P a q u et d e d o n n es

FigureB.2: Cas dun mobile initiant la communication

Figure B.2 prsente la procdure de livraison de paquets dans le cas o un mobile


utilisant une adresse prive veut communiquer avec un correspondant dadresse globale.
En effet, le mobile envoie un paquet au FA. Ce paquet a comme adresse source celle prive
du mobile et comme adresse destination celle globale du correspondant. Le FA vrifie si une
adresse globale est dj associe au mobile. Sinon, le FA demande au HA (possdant la
fonction du NAT) dassigner au mobile une adresse globale en envoyant un message de
requte dassignation dadresse (Address Assign Request) contenant ladresse prive du
mobile. Avant denvoyer ce message, on propose dtablir un LSP entre le HA et le FA.

102
Quand le HA assigne une adresse globale au mobile , il maintient une association entre
ladresse prive du mobile, ladresse globale du mobile , la dure de vie de cette adresse et
ladresse globale du FA [ IPpri(MN), IPglo(MN), TTL, IPglo(FA)]. Puis le HA rpond par
un message dassignation dadresse (Address Assign Reply) contenant ladresse globale du
mobile et la dure de vie y correspondante. Le FA doit ainsi maintenir lassociation entre
ladresse prive du mobile, ladresse globale du mobile et la dure de vie y correspondante
[IPpri(MN), IPglo(MN), TTL].
Livraison de paquets lorsquun correspondant lance la communication
Figure B.3 prsente la procdure de livraison de paquets dans le cas o un correspondant
ayant une adresse globale veut communiquer avec un mobile dadresse prive.

MN

FA / LER3

L SR 5

L SR 4

H A / L ER 2

L SR 4

L ER 1

CN

D em ande
d'tiquettes
Association
d'tiquettes

L SP entre
H A et L E R1

Address A ssign R equest


+ D NS query
A ddress A ssign M apping
+ D N S A nsw er M essage
P aquet
de donnes

P aquet
de donnes

D em ande d'tiquettes
L SP entre
F A et H A

Paquet
de donnes
P aquet
de donnes

Association d'tiquettes

Address A ssign
Inform ation
P aquet
de donnes

Address A ssign
R equest

P aquet
de donnes

FigureB.3: Cas dun correspondant initiant la communication

P aquet
de donnes

103
Le correspondant envoie une question DNS ou DNS query et un message de requte
dassignation dadresse contenant un champ Fully Qualified Domain Name, (FQDN) du
mobile au HA.
Le serveur DNS maintient une association entre le FQDN et ladresse prive du mobile et
envoie ladresse prive au HA. Ce dernier associe alors une adresse globale cette adresse
puis maintient lassociation entre les deux adresses, la dure de vie et ladresse globale du FA
[IPpri(MN), IPglo(MN), TTL, IPglo(FA)]. Ensuite, le FA envoie une rponse dassignation
dadresse au serveur DNS contenant ladresse globale du mobile et la dure de vie y
correspondante.
Le correspondant apprend ainsi ladresse globale du mobile en recevant une rponse du
serveur DNS (DNS Answer message) travers le HA.
Le HA doit informer le FA de lassociation entre ladresse prive du mobile, ainsi que
ladresse globale du mobile en envoyant un message dinformation dassignation dadresses
(Address Assign Information message) aprs avoir tabli un LSP.

Sommaire
Cette annexe a propos lintgration de Mobile IPv4 utilisant ladresse prive avec
MPLS. Cependant plusieurs problmes peuvent avoir lieu. Il se peut que plusieurs mobiles
aient la mme adresse prive assigne de diffrents rseaux mres mais dont le rseau visit
est le mme. Cette collision est dite Private Address Collision et peut tre rsolue si on
oblige le FA de consulter ladresse MAC de chaque paquet quil reoit.
Cependant, lvolution d IP de la version 4 la version 6 a normment rsolu le problme
de manque despace dadressage et a limin lutilisation du traducteur dadresses NAT.

ANNEXE C : Distribution du profil du mobile

Il a t indiqu que pour le routage optimis, quand un correspondant ne possde pas


une association de la position courante du mobile, le premier paquet sera livr au HA puis la
suite de livraison de paquets sera effectue directement entre le correspondant et le mobile.
Une optimisation de cette mthode consiste ce que chaque mobile maintient un profil
groupant toutes les informations concernant son comportement de mobilit et tous ses
besoins de communications Ce profil aide prdire le comportement du mobile avant de
performer une livraison de donnes.
Deux approches existent pour permettre aux correspondants dobtenir le profil du mobile. La
premire approche consiste avoir des bases de donnes distribues au niveau de chaque
mobile. La deuxime approche centralise les informations en une seule base de donnes
maintenue par un serveur de profil.
Bases de donnes distribues
Chaque mobile maintient un profil propre dans sa base de donnes. Si un
correspondant demande dobtenir ce profil, le mobile doit vrifier si le demandeur possde le
droit daccder sa base de donnes. Les correspondants peuvent avoir des classes de
priorit diffrentes.
Si le mobile accepte la requte, il enverra son profil au correspondant. Sinon, il enverra un
message de refus de requte.
Mais cette distribution des bases de donnes introduit un potentiel poids aux quipements des
mobiles qui doivent manipuler les requtes de profils issues des correspondants.
Figure C.1 illustre cette approche.

CN 1
d e m a n d e d e p r ofi l
e t r po n se
CN2

MN

CN3

Figure C.1 : Bases de donnes distribues

105
Base de donnes centralise
Dans cette approche, un serveur maintient tous les profils des mobiles figurant dans
son domaine. En effet, chaque mobile doit au dbut enregistrer son profil de mobilit avec le
serveur.
Le serveur de profils rpond par un message de confirmation si lenregistrement a russi. Le
mobile peut aussi envoyer son nouveau profil pour le mettre jour.
A chaque profil figurant dans la base de donnes du serveur est associ un temporisateur qui,
une fois expir, conduit llimination du profil. Le mobile doit mettre jour son profil
avant lexpiration du temporisateur.
Quand un correspondant demande un profil dun mobile, le serveur vrifie le droit daccs du
correspondant comme dans le cas de bases de donnes distribues. Si la requte est accepte,
le serveur rpond par le profil de mobilit du mobile ; sinon, il rpond par un message de
refus de demande.
Le serveur doit donc soccuper de toutes les requtes de profils des mobiles de son domaine.
Si le serveur tombe en panne, toutes les informations seront perdues. Pour confronter ce
problme, des serveurs de profils back up doivent tre prsents dans le domaine. Ceci
ncessite le besoin dune synchronisation entre les processus de mise jour des profils.
Figure C.2 illustre cette approche.

CN1

M N1
Enregistrem ent de profil
et confirm ation

dem ande de profil


et rponse
CN2

Serveur de profils

M N2
Figure C.2 : Base de donnes centralise

CN3

Une fois, selon lune des deux approches, le correspondant reoit le profil du mobile,
il prend compte de la position exacte du mobile et devient capable de lui envoyer tout le
trafic. Le problme de routage triangulaire est ainsi limin.
Si le correspondant a des paquets envoyer au mobile, il consulte tout dabord sa cachette
pour trouver une entre correspondant au mobile. Si cette association est trouve, un LSP est
directement tabli avec la COA du mobile. Si lassociation nest pas trouve, il consulte sa
base de donnes des profils pour vrifier sil possde le profil du mobile. Si ce profil existe,
le correspondant extrait le format appropri et dtermine la position exacte du mobile ou sa
COA. Puis, il ajoute cette association dans sa cachette et tablit le LSP. Les paquets seront
ensuite livrs au mobile le long de ce LSP.

106
Comparaison avec le routage optimis standard
Dans le routage optimis standard, si le correspondant ne trouve pas dinformations
sur le mobile dans sa cachette, il envoie les paquets au rseau mre du mobile.
Cependant, dans le cas de distribution des profils, le profil prsent dans la base des donnes
du correspondant peut ne pas tre la version la plus rcente. Alors, le FA recevant les paquets
du correspondant, apprend la version de lassociation de mobilit du mobile et transmet les
paquets au mobile puis envoie au correspondant lassociation rcente pour rafrachir sa
cachette. Si le FA ne connat pas lassociation rcente du mobile, les paquets sont de
nouveau transmis au rseau mre du mobile et ladresse mre du mobile est envoye au
correspondant.
Enfin, lapproche de distribution de profils [48] des mobiles nest pas approprie dans le cas
o le mobile se dplace frquemment entre les rseaux daccs car sa position exacte sera
indfinie pour un certain temps. Donc la solution de ce problme revient considrer
lintgration de MPLS avec Mobile IPv4 hirarchique.

ANNEXE D : Micro Cell Mobile MPLS, MMPLS

Une autre approche permettant MPLS de supporter la micro-mobilit est propose


dans cette annexe dite Micro Cell Mobile MPLS ou MM-MMPLS[49]. Cette proposition
sappuie sur lacheminement MPLS, la signalisation localise et la gestion de type soft
state.
Pareillement lintgration de MPLS avec HMIPv4, MM-MPLS cache les mouvements
locaux dun mobile de son HA et emploie deux niveaux de FAs: le GFA et les RFAs.
Le protocole de signalisation utilis est le RSVP-TE qui, comme expliqu au Chapitre II, est
un protocole de type soft-state qui rafrachit priodiquement les tats des LSPs et les
liminent lors dexpiration des temporisateurs associs.
Dans cette proposition, ladresse mre du mobile est utilise comme FEC la place de
ladresse du FA dans HMIPv4. Ceci permet tout LSR intermdiaire entre lancien FA et le
GFA de grer le message de BU du mobile et doffrir les paquets au FA servant le mobile
aprs son dplacement. Cette opration ntait permise quau GFA dans le cas de HMIPv4.
Dans MM-MPLS, mme le GFA ne sera pas oblig de poursuivre la position du mobile.
Donc le dlai sera encore plus rduit durant le dplacement du mobile par comparaison au
cas de HMIPv4 du fait que le message de BU prendra moins de temps pour aboutir un LSR
intermdiaire que darriver au GFA.
Figure D.1 illustre une architecture dun rseau MM-MPLS.

F A -E
R F A -C

R F A -A
F A -B
G F A / LE R

F A -D

MN
MN

Figure D.1:Architecture dun rseau MM-MPLS

108
Procdure denregistrement
La procdure denregistrement est tout fait identique celle de HMIPv4 du fait que
le HA nest inform du dplacement du mobile que lorsque ce dernier change de domaine.
Quand un mobile se dplace vers un domaine visit, le message de requte denregistrement
est envoy au plus proche FA (par exemple, FA-D dans Figure D.1). Le FA envoie ce
message au GFA qui ngocie avec le HA pour tablir un LSP selon la mme procdure
dfinie dans HMIPv4. Puis le GFA tablit un LSP avec le FA en utilisant RSVP-TE. Il
envoie un message Path avec un objet dtiquette ( Label_request Object ). Le FA
rpond par un message de rservation contenant lobjet dtiquette portant lassociation
dtiquettes. Le message de rservation est envoy en aval dans la direction du GFA. Arriv
au GFA, un LSP est tabli entre ce GFA et le FA. A noter que ladresse mre du mobile est
utilise comme FEC. Finalement, le GFA envoie le message de rponse denregistrement
issu du HA au mobile le long du LSP dj tabli.
Livraison de paquets issus dun correspondant
Pareillement HMIPv4, quand un correspondant envoie des paquets un mobile
situ dans un rseau visit, le HA intercepte ces paquets. Dans MM-MPLS, le HA utilise
ltiquette entrante pour associer, selon sa table dexpdition, une tiquette sortante et un
port de sortie. Les paquets sont ensuite envoys au GFA selon le LSP tabli. Le GFA reoit
ces paquets et les fait passer au FA selon le LSP dj tabli entre les deux agents. Le FA,
tant un LER, livre les paquets au mobile selon le niveau IP.
Handoff dun mobile
Quand le mobile se dplace vers un nouveau rseau, il envoie un message de requte
denregistrement au nouveau FA (FA-B selon FigureD.1) qui le transmet au GFA. Chaque
routeur intermdiaire vrifie sil possde une entre correspondant ladresse mre du
mobile comme FEC dans sa table dexpdition.
La requte denregistrement arrive un LSR en aval (RFA-A dans Figure D.1) qui est le
nud dintersection entre la nouvelle route et lancienne route en direction du GFA (donc le
RFA anchor).
Dans M-MPLS, le LSP sera rtabli entre ce LSR et le nouveau FA. Ladresse mre du
mobile est choisie comme FEC.
Aprs ltablissement du LSP, RFA-A redirige les paquets la nouvelle position du mobile.
Il intercepte ensuite le message PATH du GFA lancien FA et gnre un message de
rservation contenant un nouvel objet de route explicite (Explicit_Route Object, ERO)[50]
qui dfinit le nouveau chemin entre le GFA et le nouveau FA. Il envoie en retour au GFA un
nouveau message de rservation. Chaque message Path dans RSVP-TE envoy par le GFA
contient un nouveau ERO qui sera transmis le long du LSP tabli entre le LSR anchor et
le nouveau FA.
Finalement, les noeuds de lancien chemin (RFA-C et FA-D dans Figure D.1) liminent les
entres ayant comme FEC ladresse mre du mobile.

109
Figure D.2 illustre la procdure de handoff dun mobile.

MN

R FA - A
"a n c ho r "

F A -B

F A -D
A n no nc e
d e s a g e nts
D e m a nd e
d 'e n r e g is tr e m e n t
BU

D em a n de
d 'e n re g i st r e m e n t
P a th
RESV

R p o nse
d 'e n re g is t r em e n t

R p o nse
d 'e n r e g is t re m e n t

R po n se
d 'e n r e g is tr e m e n t

Figure D.2: Procdure de handoff dans MM-MPLS

A noter que dans ce cas, le GFA a pris compte du dplacement du mobile. Durant son
dplacement, le mobile informe aussi son ancien FA de sa nouvelle CoA en lui envoyant un
message de BU. Ceci permet lancien FA de livrer les paquets au mobile si le GFA utilise
toujours lancienne entre du mobile en tablissant un LSP entre lancien FA et le nouveau
FA .
Sommaire
Lintgration de MPLS avec HMIPv4 peut tre considre comme le cas le plus
mauvais de MM-MPLS o le LSR anchor est le GFA. Donc MM-MPLS possde
lavantage sur HMIPv4 dun handoff plus rapide. Cette amlioration rside du fait que
ladresse mre du mobile est utilise comme FEC pour tablir le LSP entre le GFA et le FA
servant le mobile. Donc, les LSRs intermdiaires sont capables de chercher dans leurs tables
dexpdition la range ayant ladresse mre du mobile comme FEC et dajuster les valeurs du
port de sortie et de ltiquette sortante en celles du LSP tabli avec le nouveau FA.
Un autre avantage de MM-MPLS est la gestion soft-state de la localisation du mobile qui
permet un changement dynamique de LSP. Cette proprit augmente lefficacit du
protocole.
Dans HMIPv4, le GFA doit grer tous les mobiles dans son domaine ce qui augmente sa
charge quand le nombre des mobiles saccrot normment. MM-MPLS distribue ce travail
entre les routeurs lintrieur du domaine ce qui aide de rsoudre le problme de passage
lchelle.
Cependant, dans MM-MPLS, la complexit des routeurs est leve. Les routeurs doivent tre
capables de changer le LSP vers le nouveau FA tandis que dans HMIPv4, les routeurs
intermdiaires nont qu interchanger les tiquettes. De mme, le rafrachissement
priodique dans RSVP-TE conduit une charge lourde de messages de signalisation.

ANNEXE E : Intgration des fonctions de MPLS avec


celles de HMIPv6

Cette annexe propose une mthode o MPLS et HMIPv6 noprent pas sparment
chacun dans son niveau mais partagent des fonctions communes. Lobjectif de cette
intgration est de rendre les oprations plus rapides et plus efficaces.
Pour cela, deux composants sont optimiser : larchitecture du nud et le re-routage.
Larchitecte du noeud regroupe toutes les notions permettant le support de mobilit par
MPLS. Le re-routage dsigne la mthode dont opre MPLS lors des handoffs.
Un changement primordial consiste une diffrence dans la mthode daccs aux bases de
donnes. Un plan de contrle commun sera utilis entre MPLS et Mobile IP parsuite, MPLS
aura le droit daccder aux cachettes des agents de mobilit.
Cette interaction est prsente dans Figure E.1.

Figure E.1 : Bases des donnes et mthodes de relation

Comme on a dj vu prcdemment, plusieurs oprations sont effectues pour la


livraison de paquets entre un mobile et son correspondant, il est ncessaire que les en-ttes
MPLS soient enlevs et les paquets soient traits au niveau IP. Aprs que les chemins soient

111
correctement dtermins, MPLS est re-introduit et les tiquettes sont de nouveau associes
(Figure E.1.a).
Si MPLS a un accs direct la cachette de Mobile IP, comme indique Figure E.1.b,
ltape de changement de niveau sera limine. La FEC pour le suivant LSP est obtenue en
consultant la cachette. Ltiquette suivante est introduite dans le champ dtiquette et le
champ TTL est mis jour dans la nouvelle en-tte MPLS sans quitter la couche MPLS. Cette
faon rduit le temps dexcution car len-tte MPLS nest pas dtruite. Mais on remarque
que le nombre de tables consulter est le mme.
Une meilleure optimisation consiste ce que le routeur MPLS effectue une relation
entre les entres de la table dexpdition tout en se basant sur linformation prsente dans la
cachette des associations. Pour ce fait un nouveau champ est ajouter contenant un pointeur
vers une autre entre de la mme table. La nouvelle structure de la table dexpdition est
illustre dans Tableau E.1.
#

In Port

In Label

FEC

Out Label

Out Port

LIB ptr

10

MN

--

--

RCOA1

20

--

RCOA2

60

Tableau E.1 : Structure modifie de la table dexpdition au niveau du HA.


Le pointeur de la premire range pointe initialement la premire RCOA (RCOA1) de la
deuxime range. Si le mobile change de RAN, ce pointeur pointe la nouvelle RCOA
(RCOA2) de la troisime range.
Cette mthode daccs aux bases de donnes est illustre dans Figure E.1.c dont les
avantages sont llimination de changement de niveaux et un temps dexcution sauvegard
et un temps de recherche rduit pour une nouvelle FEC.
Cas o le correspondant lance la communication
Le nombre et le type des messages de signalisation pour ltablissement dun LSP
entre un correspondant et un mobile se trouvant dans un rseau tranger est le mme que
dans le cas o MPLS et HMIPv6 oprent sparment. Mais la squence de ces messages est
diffrente.

112
Figure E.2 montre la squence des messages de signalisation.

MN

RAR
du MN

MAP / LER

Demande
d'tiquettes
Association
d'tiquettes

Paquet
de donnes

Demande
d'tiquettes

Association
d'tiquettes

Paquet
de donnes

HA

RAR
du CN

Demande
d'tiquettes

CN

Paquet
de donnes

Association
d'tiquettes
Paquet
de donnes

LSP entre
RAR du MN
et RAR du CN

Couche IP
Paquet
de donnes

Figure E.2 : Etablissement dun LSP dans le cas dintgration des protocoles.

La diffrence avec la mthode expose au Chapitre VI se traduit par le cas o le


correspondant na pas dans sa cachette une entre pour le mobile et doit tablir un LSP.
Quand le RAR attach au mobile reoit la demande dtiquette, comme il connat la CoA
courante du mobile, il envoie la demande vers sa RCOA. LEGW/MAP ayant une entre du
mobile mais pas une association dtiquettes, doit avoir une tiquette du RAR servant le
mobile dans sa nouvelle position. Aprs que le MAP reoit lassociation des adresses pour le
LSP en direction de RAR servant le mobile, il envoie en amont lassociation dtiquettes vers
le HA.
A la fin de cette opration, le RAR attach au correspondant possdera une tiquette de sortie
pour pouvoir envoyer les paquets au mobile et le RAR attach au mobile aura une tiquette
dentre pour pouvoir recevoir les paquets destins au mobile et issus du correspondant.
Donc, les routeurs entre le RAR attach au mobile et le RAR attach au mobile nont qu
consulter leurs tables dexpdition. Il est remarquable ainsi que la consultation des tables
dexpdition repose sur lalternance des tiquettes puisque le chemin se forme dun seul LSP
mme sil y a une transition vers le HA et le MAP.
Dans le cas o le mobile lance la livraison de paquets, le processus dtablissement du LSP et
le processus de livraison de paquets restent les mmes que ceux dtaills au Chapitre VI.

113
Handoff
Dans ce cas dintgration, le handoff nest plus bas sur une extension ou une
optimisation du LSP. Comme le LSP entre le correspondant et le mobile nest pas
interrompu, on peut bnficier de la modification du LSP selon les principes de MPLS. Les
deux mcanismes de modification du LSP, comme expliqu au Chapitre II, sont les
protocoles de signalisation CR-LDP et RSVP-TE.
La modification du LSP sera alors assure par un rtablissement partiel du chemin, initie par
les routeurs dentre en se basant sur le principe make-before-break. Ce principe consiste
ce que les services assurs par le LSP ne sont pas interrompus et les ressources ne sont pas
rserves deux fois. Quand le routeur dentre est inform quun changement de LSP est
ncessaire, il envoie un message de modification de LSP et attend une nouvelle tiquette
pour tablir le LSP modifi. Cette information peut tre un message de mobilit (comme le
message de BU) ou un rsultat dun algorithme dingnierie de trafic.
Dans le cas de handoff intra-RAN, le MAP agit comme un routeur dentre pour
les LSPs dont lorigine se trouve en dehors du RAN. Aprs que le mobile enregistre sa
LCOA avec le MAP, ce dernier labore un message de modification de LSP. Quand un
nouveau LSP est tabli, une nouvelle tiquette sera envoye en amont vers le MAP. Par la
suite, le MAP met jour sa table dexpdition et utilise la nouvelle tiquette pour poursuivre
la communication le long du LSP modifi. Le routeur dentre enlve lancienne tiquette
aprs la rception de la nouvelle tiquette pour le mme LSP.
Le handoff inter-RAN reprend le mme processus du handoff intra-RAN
lexception que le HA et les correspondants se trouvant en dehors du rseau RAN sont
considrs dans ce cas comme des routeurs dentre changeant leurs LSPs en direction du
MAP.
Dans les deux cas de handoff , le RAR attach au mobile doit initier les modifications
pour les LSPs dont le mobile est lmetteur des paquets. Ce RAR est alors un routeur
dentre.
Conclusion
Cette mthode dintgration des protocoles amliore la performance en fusionnant
les processus et les tables ainsi que la signalisation. Le chemin non interrompu utilis dans le
cas des protocoles intgrs apporte une meilleure ingnierie de trafic.

ANNEXE F : Deux stages de handoff

Une proposition de grer la livraison de paquets lors dun handoff consiste diviser
cette opration en deux stages : Handoff au niveau MPLS et Handoff au niveau Mobile
IP[35].
Mobile IP et son extension HMIP,sous les deux versions IPv4 et IPv6, oprent uniquement
aprs laccomplissement du handoff de niveau MPLS dans le seul but doptimiser le
routage et dassurer une meilleure scurit.
Lessentiel point de cette proposition est que le changement dadresse locale de liaison est
limin et les paquets sont temporairement dirigs de lancien RAR au nouveau RAR.
Handoff de niveau MPLS
Une fois que le mobile perd sa connexion avec sa station de base, il cherchera se
connecter une nouvelle station de base au niveau 2 puis attendra la rception dun message
ICMP davertissement de routeur ou enverra un message ICMP de sollicitation pour
distinguer le routeur attach cette nouvelle station.
Pour tre indpendant de Mobile IP, ces oprations doivent tre supprimes du mcanisme de
dcouverte des agents. Cependant, pour gagner de rapidit, ces oprations sont toujours
intgres avec Mobile IP.
En effet, deux cas sont distingus :
Si ladresse IP du RAR est la mme (handoff intra-RAR), le dplacement est alors
effectu entre deux stations de base connectes au mme RAR. Dans ce cas, on na
pas recourir au niveau IP.
Si ladresse IP change (handoff inter-RAR), le mobile a chang de sous rseau.
Dans ce cas, un message de BU est envoy par le mobile au nouveau RAR. Ce
message peut tre nimporte quel message car le nouveau RAR a besoin de connatre
lancienne adresse du RAR servant le mobile. Cette adresse peut tre dduite de
ladresse source du mobile.
Pour ce fait, on a propos dutiliser un message UDP spcial. Ceci ajoute lavantage
que le RAR nas pas besoin de vrifier tout le trafic pour dtecter la nouvelle adresse
mais demande de recevoir les messages de BU que lorsquil en a besoin.
Le nouveau RAR cherche sil possde un LSP dj tabli avec lancien RAR. Sil
nen trouve pas, un tablissement de LSP entre le nouveau RAR et lancien RAR aura
lieu. Puis le nouveau RAR doit envoyer un autre message de BU lancien RAR pour
lui informer que le mobile est devenu sous son service. Lancien RAR ajoute alors
une entre correspondant au mobile pointant au nouveau LSP. Enfin, le nouveau
RAR associe une entre au mobile et son interface de niveau 2.
A ce point, les paquets destins au mobile seront intercepts par lancien RAR puis
redirigs au nouveau RAR le long du LSP.

115
Si le mobile se dplace frquemment, lancien RAR interceptera toujours les paquets
et des longues chanes peuvent tre prvenues.
Handoff de niveau Mobile IP
Le handoff de niveau MPLS, comme dcrit prcdemment, fonctionne
conformment pour un environnement qui ne risque pas davoir de srieux problmes de
scurit. Dans les environnements ncessitant une garantie de scurit, le mobile doit
sauthentifier chaque fois quil change de sous rseau. Mobile IP est ainsi propos pour
garantir lauthentification du mobile aprs avoir accompli le handoff du niveau MPLS.
Le handoff de niveau MPLS conduit un routage triangulaire donc on peut profiter du
routage optimis de Mobile IP.
Quand le mobile termine son handoff de niveau MPLS, il ouvre une seconde interface
logique pour dcouvrir les routeurs selon les mcanismes de Mobile IP. Le RAR doit
possder ainsi les fonctionnalits dun FA pour Mobile IPv4, dun routeur IPv6 pour Mobile
IPv6 ou dun routeur hirarchique pour HMIP (v4 ou v6).
Aprs la fin de mise jour du mobile, ce dernier utilise une nouvelle interface IP pour
recevoir et envoyer les paquets. Lancienne interface lancien RAR est ensuite enleve.
Quand lopration de Mobile IP est termine, le nouveau RAR envoie un message lancien
RAR pour liminer lentre correspondante au mobile dans sa table de routage puis limine
sa propre entre pour rduire le nombre dentres. A ce moment, le nouveau RAR est devenu
le RAR unique servant le mobile.
Sommaire
Cette proposition de diviser le mcanisme de handoff en deux stages acclre le
handoff. Quand le mobile entre un nouveau sous rseau, un LSP est tabli entre lancien et
le nouveau RARs. Les paquets arrivent donc au mobile sans aucune interruption. Mobile IP
intervient ensuite pour optimiser le routage et assurer la scurit.
Cependant, cette proposition est encore en cours en dveloppement et nest pas encore
compltement labore.

Rfrences
[1] Mobile IP -Qualit de service dans des environnements Internet mobile M. Gwendal LE
GRAND-UPMC, Paris VI -11 Juillet 2001
[2]
[3]

[4]
[5]

[6]
[7]

Prsentation de Mobile IPv4/v6 -Toni SOUEID-2002


Une comparaison des protocoles de micro-mobilit sous IP -Pierre Reinbold - Groupe Infonet Facults universitaires de Namur.
La migration vers ipv6- Synthse -Octobre 2002
La QoS IP sur ATM-Partie MPLS et ATM - Projet module Rseaux Large Bande- -Nicolas
MAUGET-ENST-Jrme PONS-Mars 2001
Tout savoir sur le monde IP -wwww.routage.org
MPLS Tutorial , by Trillium, 2000, http://www.iec.org/tutorials/mpls/index.html, site WEB de
lInternational Engineering Consortium

[8]

Quadrillium technologies http://www.quadrillium.com

[9]

RFC : 2475 : Architecture for Differentiated Service

[10] MPLS-Support of Differentiated Services, RFC 3270: http://www.ietf.org/rfc/rfc3270.txt


[11] A
Framework
for
IP
http://www.ietf.org/rfc/rfc2764.txt

Based

Virtual

Private

Networks,

RFC

2764:

[12] Integration of Mobile IP and Multi-Protocol Label Switching -Chen-Khong Tham Zhong RenDepartment of Electrical & Computer Engineering National University of Singapore -Singapore
119260
[13] Mobile IP Generic Label Distribution Extensions-draft-shaji-mobileip-generic-label-ext-00.txtShaji Radharishnan ,Yingchun Xu , Ellis Wong-September, 2001
[14] Label Distribution Protocol (LDP) Specification -IETF Internet Draft-L. Andersson, P. Doolan, N.
Feldman, A. Fredette & B. Thomas-Aug. 2000, work in progress.
[15]

Supporting Differentiated Services in MPLS Networks-I. Andrikopoulos, G. Pavlou - Proc.


IWQoS'99, Seventh International Workshop on QoS, 1999, pgs. 207-215.

[16] Multiprotocol Label Switching Architecture-E. Rosen, A. ViswanatHan, R. Callon -IETF Internet
Draft, July 2000, work in progress.
[17] Carrying Label Information in BGP-4 -Y. Rekhter, E. Rosen - IETF Internet Draft, Jan 2000, work
in progress.
[18] IP Encapsulation within IP-C. Perkins- IETF RFC 2003, May 1996.
[19] Secured MPLS-based Mobile IP using the Private IP Address - Sriborrirux Wiroon, Jeong-Beom
Kim, Rhe yun-jung and Tai-Yun Kim -Computer Science and Engineering, Korea University {wiroon,
qston, genuine, tykim}@netlab.korea.ac.kr

117
[20] Profile-based Mobile MPLS Protocol - Tingzhou Yang, Yixin Dong, Bin Zhou, Dimitrios
Makrakis - Broadband Wireless and Internetworking Research Laboratory- School of Information
Technology & Engineering, University of Ottawa -Colonel By Hall, P.O.Box 450 Stn A, Ottawa, Ont.,
K1N 6N5, Canada
[21] Mobile IPv6 support in MPLS Network - Jun Kyun Choi , Myoung Hun Kim , Yoon Ju Lee
Internet Draft <draft-choi-mobileip-ipv6-mpls-02.txt> -December 2001
[22] Framework for QoS Support in Mobile IPv6 -H. Chaskar-draft-ietf-mobileip-qos-requirements01.txt -August, 2001[23] Generalized MPLS-Signaling Functional Description-draft-ietf-mpls-generalized-signaling-06.txt P. Ashwood-October, 2001.
[24] Neighbor Discovery for IP Version 6 (IPv6) -Thomas Narten, Erik Nordmark- RFC 2461Decembre 1998.
[25] IPv6 Stateless Address Autoconfiguration-S. Thomson and T. Narten- RFC 2462-1998.
[26] Qualit de service dans des environnements Internet mobile -Thse de doctorat de lUniversit
Pierre et Marie Curie - M. Gwendal LE GRAND -Juillet 2001.
[27] Une comparaison des protocoles de micro-mobilit sous IP - Pierre
Pierre.reinbold@info.fundp.ac.be - Groupe Infonet -Facults universitaires de Namur.

Reinbold

[28] Mobile IP Regional Registration- Gustafsson E -draft-ietf-mobileip-reg-tunnel-05.txt,September


2001.
[29] Path Re-routing Algorithm for Mobile IP Service at the ATM-based MPLS Network -Tai Won
Um, Jun Kyun Choi- KOREA

[30] Telecommunication Standardization Sector-Study Period 2001-2004 Group 13 Contribution 28


-Draft new Recommendation Y.MIPoMPLS (Mobile IP Services over MPLS) -(05/2003)-Sophia
Antipolis.
[31] Extension of LDP for Mobile IP Service through the MPLS Network-<draft-choi-mobileip-ldpext03.txt> - Jun Kyun Choi (ICU) , Tai Won Um (ICU) , Yoo Kyoung Lee (ETRI) , Sun Hee Yang
(ETRI) - November 2001.
[32] M-MPLS:Micromobility-enabled Multiprotocol Label Switching -Vasos Vassiliou, L. Owen,
Hans-Peter Huth,Jochen Grimminger.
[33] Hierarchical MIPv6 Mobility Management -H. Soliman - IETF Internet Draft- Nov. 2001.
[34] Mobility Support in IPv6 -D. B. Johnson, C. E. Perkins and J. Arkko - IETF Internet Draft- Nov.
2001.
[35] MMPLS- a MPLS based Micro Mobility Concept - J. Grimminger, H.-P. Huth - Siemens AG,
Corporate Technology, Information & Communication -hans-Peter.Huth@mchp.siemens.deJochen.Grimminger@mchp.siemens.de
[36] A Radio Access Network for Next Generation Wireless Networks Based on MPLS and Hierarchical
Mobile IP-V. Vassiliou et al - Sep 2002.

118
[37] Hierarchical Mobile MPLS: Supporting Delay Sensitive Applications over Wireless Internet -T.
Yang and D. Makrakis-Beijing. 2001.
[38]

The Network Simulator-NS-2 notes, documentation and source codes: www.isi.edu/nsnam/ns/

[39] Columbia IP Micro-Mobility Software -

http://www.comet.columbia.edu/micromobility/

[40] MPLS Network Simulator - http://flower.ce.cnu.ac.kr/~fog1/mns/


[41] Design AND implementation of MPLS Network Simulator (MNS) -Gail Ahn,Woojik ChunDepartment of Computer Engineering , Chungnam National University , Korea.
[42] http://www.inrialpes.fr/planete/pub/mobiwan
[43]

The ns Manual (formerly ns Notes and Documentation)-The VINT Project-Kevin Fall- November
9, 2003

[44] Support of Micro-Mobility in MPLS-based Wireless Access Networks -Kaiduan Xie, Vincent
W.S. Wong, and Victor C.M. Leung - Department of Electrical and Computer Engineering - The
University of British Columbia.
[45] OPtimized Network Engineering tool version - OPNET Technologies: http://www.mil3.com
[46] Address Allocation for Private Internet - Y. Rekhter - RFC 1597- March 1994.
[47] The IP Network Address Translator (NAT)-K. Egevang and P. Francis- RFC 1631- May 1994.
[48] Profile-based Mobile MPLS Protocol- Tingzhou Yang, Yixin Dong, Bin Zhou, Dimitrios
Makrakis - Broadband Wireless and Internetworking Research Laboratory- School of Information
Technology & Engineering, University of Ottawa -Colonel By Hall, P.O.Box 450 Stn A, Ottawa, Ont.,
K1N 6N5, Canada
[49] Practical Approaches for Supporting Micro Mobility with MPLS -Tingzhou Yang, Yixin Dong,
Yihan Zhang, Dimitrios Makrakis -Broadband Wireless and Internetworking Research Laboratory School of Information Technology & Engineering, University of Ottawa Canada
[50] RSVP-TE: Extensions to RSVP for LSP Tunnels - D. O. Awduche, L. Berger, D. Gan, T. Li, V.
Srinivasan, and G. Swallow - Internet Draft - February 2001