Cellular IP avec Qualité de Service

Transcription

UNIVERSITE LIBANAISE
UNIVERSITE SAINT-JOSEPH
(Faculté de Génie)
(Faculté d’ingénierie)
Sous l’égide de l’Agence Universitaire de la Francophonie
AUF
Diplôme d’Etudes Approfondies
Réseaux de télécommunication
Par
Samer Khalil
Encadré par : M Nicolas Rouhana
Soutenance le 18 décembre 2001 devant le jury composé de
MM. Samir Tohmé
Wajdi Najem
Imad Mougharbel
Mahmoud Doughan
Maroun Chamoun
Nicolas Rouhana
Samer Khalil
Mémoire
Président
Membre
Membre
Membre
Membre
Membre
DEA Réseaux 2000-2001
Page 1
REMERCIEMENTS
Je remercie Nicolas Rouhana, mon maître de mémoire, pour m’avoir encadré durant mon
stage de DEA, et m’avoir fait bénéficier de ses conseils et de son expérience.
Un grand merci à tous les membres des équipes de recherche Réseau de l’ENST, de l’ESIB et
de l’UL qui m’ont initié au monde de la recherche.
Enfin, une pensée à l’équipe de l’AUF pour leur soutient.
Samer Khalil
Mémoire
Page 2
----------------------------------------------------------------------------------------------------------------RESUME :
Initialement, les protocoles de l’Internet n’étaient pas désignés pour supporter la mobilité ni
pour gérer les services temps-réel.
La gestion de la Qualité de Service (QoS) permet à l'Internet de fournir d'autres classes de
service que le traditionnel service best effort. L'objectif de la QoS est de répondre aux
exigences qualitatives spécifiques des applications actuelles; ces applications vont du simple
transfert de données à la téléphonie, la vidéo à la demande ou la conférence multimédia.
Parallèlement, l'évolution rapide des systèmes mobiles impose la prise en compte des
utilisateurs mobiles utilisant la même variété d'applications que les utilisateurs fixes.
L'introduction de la QoS dans les réseaux mobiles est encore plus complexe, car leur
topologie et leurs ressources évoluent dynamiquement.
De nouvelles recherches sur Cellular IP d’un coté et sur RSVP d’un autre, assurent
séparément la gestion de mobilité, et de qualité de service pour les applications de temps-réel.
Dans ce travail, nous proposons une solution pour offrir des garanties de bande passante à des
utilisateurs mobiles dans l’Internet. Notre solution, CIRP (Cellular IP Reservatio n Protocol),
est basée sur un algorithme distribué qui répartit la bande passante localement et sur un
contrôle d’admission dans le réseau qui garantit une plus faible probabilité de blocage aux
handoffs qu’aux nouvelles connexions. Nous proposons également des mécanismes pour
optimiser l’utilisation de la bande passante pour cette solution.
Mots-clefs : mobilité, Mobile IP, Cellular IP, Qualité de service, gestion de la bande passante,
RSVP, Réservation de ressources.
Zones d’intérêt : Protocoles Multimédia, Protocoles de réseaux sans fils.
-----------------------------------------------------------------------------------------------------------------
Samer Khalil
Mémoire
Page 3
Table des Matières
RESUME
Table des matières
Chapiter 1 :Introduction
2
3
7
Chapiter 2 : LA Mobilité
9
1 Introduction au chapitre
2 Problème de la mobilité IP
3 Mobile IP
3.1 Communication
3.2 Limites de Mobile IP
4 Solutions de micro mobilité
5 Cellular IP
5.1 Pourquoi ce nouveau protocole ?
5.2 Introduction
5.3 Routage
5.4 Handoff
5.5 Paging
5.6 Détails du protocole
5.6.1 Algorithme du Nœud
5.6.2 les compteurs (timers)
5.6.3 Algorithme du mobile
5.7 Adressage et migration
5.8 messages de contrôle
5.9 Format des Paquets
5.9.1 paquet de données
5.9.2 Paquet de Route-Update
5.9.3 Paquet de paging update
5.9.4 Paquet de paging Teardown
5.10 Securité
9
9
10
10
11
11
12
12
13
14
14
15
16
16
17
19
19
20
21
21
21
21
21
22
Chapiter III QoS et RSVP
23
2 Qualité de service dans l’ Internet
2.1 Principe de l’architecture à Intégration de Services
2.2 L'architecture à différenciation de services
2.2.1 Principe de l’architecture à Différenciation de Services
2.3 Multi-Protocol Label Switching (MPLS)
3 RSVP
3.1 La gestion de la QOS avec RSVP
3.2 Motivation pour la conception de RSVP
3.3 QoS et RSVP
3.4 Fonctionnalités de RSVP
Samer Khalil
Mémoire
23
23
23
24
26
26
28
28
28
29
29
Page 4
3.5 RSVP, comment fonctionne-t- il ?
3.6 RSVP alloue des débits simplex
3.7 RSVP établit des états non-permanents
3.8 RSVP est un protocole orienté récepteur
3.9 Accroissement de l'efficacité par fusion des requêtes communes
3.10 Les communications multipoints: Unicast, Broadcast et Multicas
3.11 Modèle de Reservation sur RSVP(Reservation Style)
3.11.1 Implications des modèles de réservation
3.12 Exemple de réservation RSVP
3.13 Tous les routeurs ne supportent pas RSVP
3.14 Réservation de ressources
3.14.1 scénario
3.15 flux de données
3.16 Mise en place d'une Session Rsvp
3.17 Eléments de Protocole
3.18 Format des messages RSVP
3.19 Réticences au déploiement de RSVP
4 Conclusion du chapitre
Chapitre IV : Mobilité et Qualité de Service
1 Introduc tion au chapitre
1.1 La méthode d’accès de base : CSMA/CA
1.2 Virtual carrier Sense (CTS/RTS)
2 MRSVP ( Mobile IP Reservation Protocol)
2.1 Introduction
2.2 MRSVP overview
2.3 Réticences aux déploiement de MRSVP
3 CLEP (Controlled Load Ethernet Protocol)
3.1 Introduction
3.2 Limites du protocole Ethernet
3.3 Principe de CLEP
3.3.1 Contexte
3.3.2 Différents type de flux
3.4 Fonctionnement du protocole
3.5 Résultats de simulation
4 MIR (Mobile IP Reservation)
4.1 description
4.2 Définitions
4.3 Répartition des ressources entre les différents utilisateurs
4.3.1 Partitionne ment de la bande passante
4.4 Politique d'allocation des ressources
4.4.1 Pour les nouvelles connexions
4.4.2 Pour les handoffs
4.5 Calcul du nombre de jetons
4.6 Algorithme de contrôle d'admission
4.6.1 Nouveau flux privilégié
Chapiter V : CIRP ( Cellular IP Reservation Protocol )
Samer Khalil
Mémoire
30
31
32
32
32
34
34
35
36
39
39
39
40
41
41
41
43
43
45
45
45
46
47
47
47
50
50
50
51
52
52
52
54
56
57
57
59
60
60
60
60
60
61
61
62
64
Page 5
1 Introduction
2 QoS et macro mobilité
3 QoS et Cellular IP
4 Description du protocole
64
65
65
67
Chapitre VI : Conclusion
69
Références Bibliographiques
71
Samer Khalil
Mémoire
Page 6
Chapitre 1
Introduction
Le marché des terminaux portables (téléphones, ordinateurs portables, assistants
personnels, etc.) est en forte croissance. Avec les réseaux sans fil, l’utilisateur peut accéder à
des informations sans devoir rechercher un emplacement de branchement ; les réseaux sans fil
présentent de nombreux avantages sur les réseaux câblés classiques, en termes de
productivité, simplicité et coût. En particulier, les systèmes de réseaux locaux sans fil peuvent
assurer aux utilisateurs d’un réseau un accès aux informations en temps réel. Ce service est
accessible quelle que soit leur localisation à l’intérieur d’une certaine zone de couverture.
Un point d’accès assure la liaison entre les terminaux mobiles et le réseau câblé. Pour
augmenter la couverture du réseau sans fil, les utilisateurs peuvent se déplacer de manière
transparente (sans perte de connectivité) de point d’accès en point d’accès à l’intérieur d’un
même sous-réseau IP.
L’augmentation de la bande passante disponible sur les liens sans fil permet d’envisager
l’utilisation de l’Internet à partir de ces terminaux portables. Aujourd’hui, les réseaux locaux
sans fil IEEE 802.11 offrent des liens partagés à plus de 10 Mbit/s et ce chiffre ne cesse
d’augmenter.
Parallèlement, le développement des technologies UMTS rend possible la mise en oeuvre de
services large bande sur des réseaux nationaux à court ou moyen terme. Les utilisateurs
demandent à présent les mêmes services à l’Internet mobile qu’à l’Internet classique. Ils
souhaitent que la mobilité et la portabilité des terminaux soit complètement transparente afin
de bénéficier de performances comparables dans les deux environnements.
Le protocole Cellular IP, développé au sein du groupe de recherche COMET de l'Université
Columbia aux Etats-Unis, assure une mobilité transparente des utilisateurs à l’intérieur d’un
domaine. Ce protocole garantit le routage correct des paquets d’un nœud mobile ol rsque
celui-ci change de point d’attachement.
L’introduction de la Qualité de Service (QoS) permet à l’Internet de fournir d'autres classes de
service que le traditionnel service best effort. Cette demande d'enrichissement de la gamme
des services de l'Internet augmente au fur et à mesure que l'Internet pénètre dans la société.
L'objectif de la QoS est de supporter des services de communications ayant des exigences
qualitatives spécifiques.
Outre la connectivité globale, les utilisateurs mobiles souhaitent obtenir des garanties de
qualité de service telles qu’une bande passante assurée au cours de leurs déplacements, un
délai et une gigue minimale, un faible taux de pertes, etc. Certaines de ces questions font
l’objet de recherches depuis plusieurs années sur l’Internet classique (filaire et non mobile).
Les environnements mobiles, plus complexes du fait de la mobilité des terminaux et
l’hétérogénéité des ressources disponibles en des localisations différentes, constituent un
nouveau défi. L'introduction de la QoS dans les réseaux mobiles est encore plus complexe, car
leur topologie et leurs ressources évoluent dynamiquement. Le besoin de mécanismes de QoS
dans ces environnements est incontestable du fait de la rareté des ressources, de
l'imprévisibilité de la bande passante et des taux d'erreurs importants.
Dans le cadre de nos travaux, nous nous intéressons à un paramètre de qualité de service
particulier : la bande passante. Les garanties offertes dépendent uniquement de la disponibilité
du canal de transmission tant que les mobiles restent attachés au même routeur d'accès. Elles
Samer Khalil
Mémoire
Page 7
deviennent également statistiques (c'est à dire qu'il existe une probabilité de blocage des flux)
lorsque les mobiles se déplacent.
Ce document, rédigé parallèlement à mon travail de recherche est organisé comme suit :
Les environnements mobiles ont des caractéristiques particulières que nous décrivons au
début du chapitre 2. Nous présenterons ensuite brièvement le protocole Mobile IP avec ses
limites pour la gestion de la macro mobilité pour ensuite présenter et en détail la solution de
micro mobilité CellularIP.
Apres avoir présenté les environnements mobiles nous nous intéressons au problème de la
qualité de service et nous décrivons dans le chapitre 3 le protocole RSVP qui était supposé
être la solution au problème de QoS dans un réseau CellularIP. On verra par la suite que cette
solution va être très coûteuse en bande passante et en signalisation.
Cette dernière conclusion nous a conduit à étudier les différents protocoles de gestion de QoS
dans les environnements mobiles, nous retenons MRSVP, MIR (CLEP adapté au
environnements mobiles) qu’on va décrire dans le chapitre 4.
En s’inspirant de MIR nous proposons au dernier chapitre un nouveau protocole qu’on a
nommé CIRP ( Cellular IP Reservation Protocol) comme solution à la qualité de service dans
un réseau Cellular IP.
Reste à noter que cette solution proposée n’est en général qu’à sa phase de spécification et est
donc en constante évolution.
Samer Khalil
Mémoire
Page 8
Chapitre II
La Mobilité
1
Dans cette partie on va analyser l’une des solutions proposée par l’IETF pour résoudre le problème de
la mobilité dans les environnements mobiles : Mobile IP, actuellement le plus largement utilisé dans
l’Internet pour gérer la mobilité. Cependant avec l’utilisation des accès sans fils qui ne cesse pas
d’augmenter, ce protocole fait cruellement ressentir ses limites dans un tel environnement. Nous
présentons ensuite une solution de micro mobilité : Cellular IP qui permet de traiter les déplacements à
l’intérieur d’un même domaine. MIP sera donc adopté pour la macro mobilité.
2
Problème de la mobilité IP
IPv4 identifie le point d'accès d'un nœud sur l'Internet de manière unique grâce à son adresse
IP. Celle-ci se décompose en deux parties :
• le préfixe qui détermine le sous-réseau sur lequel la machine se trouve,
• l’identifiant de la machine sur son sous-réseau.
L’Internet est un réseau de trop grande taille pour que chaque routeur puisse mémoriser une
route vers toutes les machines qui y sont attachées. En fait, les routeurs ne stockent que des
entrées correspondant à des sous-réseaux, considérant que des datagrammes destinés à des
machines ayant le même préfixe seront tous routés de manière identique.
La mobilité introduit un nouveau problème de routage : les mobiles se déplacent d’un sousréseau IP vers un autre sous-réseau IP, mais ont un mauvais préfixe sur le réseau destination.
Par conséquent, un nœud doit être situé sur le réseau indiqué par son adresse IP afin de
pouvoir recevoir les paquets qui lui sont destinés. Pour qu'un nœud puisse changer de point
d'accès sans perdre la possibilité de communiquer, deux mécanismes peuvent être employés :
• le nœud doit changer d'adresse IP à chaque fois qu'il change de point d'accès,
• des chemins spécifiques à l'hôte doivent être propagés dans presque toute la structure
de routage de l'Internet.
Ces deux alternatives sont souvent inacceptables. La première ne permet pas à un nœud de
conserver des connexions au niveau de la couche transport ou des couches supérieures
lorsqu'il change de position. La seconde pose des problèmes de passage à l'échelle.
Un nouveau mécanisme flexible est nécessaire afin de s'adapter à la mobilité des nœuds sur
Internet. Le protocole Mobile IP permet aux nœuds de changer de point d'accès à l'Internet
sans changer d'adresse IP. Les spécifications minimales de la solution recherchée sont les
suivantes :
-
le déplacement d'un mobile ne doit pas provoquer de coupure des connexions
ouvertes;
l’opération doit être simple à mettre en oeuvre et d'un coût raisonnable ;
l’accès aux ressources doit être transparent ;
Samer Khalil
Mémoire
Page 9
-
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 nécessiter la
modification de tous les routeurs.
De nombreux protocoles et architectures ont été proposés pour gérer la mobilité, par exemple
Muse-IP dans [Tera 98], le réseau virtuel de Sunshine et Postel dans [Sun 80], le Réseau
Logique dans [Deer 95], des Solutions hybrides[Ion 91], VIP proposé dans [Tera 91] et
Mobile IP de l’IETF. Le protocole Mobile IP permet donc aux nœuds de changer de point
d’accès a l’Internet sans changer d’adresse IP.
3
Mobile IP
Tout d’abord on distingue deux types de réseaux selon la position du nœud mobile. On
appellera réseau mère ou réseau principal auquel est rattaché le nœud mobile
administrativement. C’est le réseau dans lequel il est déclaré dans le DNS et sur lequel il
obtient une adresse IP principale. D’un autre coté on appelle réseau visité ou réseau étranger
un réseau où le nœud mobile se trouve à un moment donné lors de ces déplacements.
Les agents de mobilité, agent mère et agent visité, (ce sont les routeur d’accès respectivement
dans le réseau mère et le réseau visité) maintiennent une liste des nœuds mobiles qu’ils
gèrent. Cette liste est appelée ‘cache d’association’ ; elle associe l’adresse principale du
mobile a son adresse temporaire. Le rôle principal de ces agents de mobilité est d’encapsuler
(resp. décapsuler) les paquets en transit entre les correspondants et les nœuds mobiles en
ajoutant (resp. en enlevant) un en-tête d’adressage.
Dans MIPV6, les correspondants d’un nœud mobiles détiennent aussi un cache d’association
ce qui leur permet de connaître l’adresse temporaire du mobile associée à son adresse
principale. Le nœud mobile devra indiquer cette adresse à son agent mère périodiquement
pour qu’il puisse maintenir une correspondance entre adresse principale et adresse temporaire.
La découverte des agents de mobilité se fait par le protocole de Découverte des Agents qui
met en place un échange de messages permettant cette décision. Lorsque le mobile détecte
qu’il a changé de sous-réseau, il acquiert une nouvelle adresse IP grâce au protocole DHCP et
s’enregistre auprès de son agent mère et de l’agent visité du nouveau réseau.
3.1
Communication
La communication entre un nœud mobile et un correspondant quelconque sur Internet est très
spécifique et requiert plusieurs mécanismes des agents de mobilité. Comme un nœud
correspondant d’un nœud mobile ne connaît pas l’adresse principale du nœud mobile, les
paquets à destination du nœud mobile sont toujours envoyés dans le sous-réseau mère du
nœud mobile . Si le nœud mobile ne s’est pas déplacé, les paquets lui seront livrés de la même
manière qu’un nœud fixe, cad sans opérations supplémentaires.
Par contre, si le nœud mobile est dans un sou-réseau visité, son agent mère devra capturer
tous les paquets destinés au nœud mobile et les lui transmettre a son adresse temporaire, grâce
à son cache d’association.
De l’autre coté les paquets envoyés par le nœud mobile ont l’adresse du correspondant
comme adresse destination et l’adresse principale du mobile comme adresse source. Ceci
présente une entorse au modèle de l’Internet puisque l’adresse source des paquets envoyés par
le nœud mobile ne correspond pas au préfixe du sou-réseau visité.
Samer Khalil
Mémoire
Page 10
Les paquets devront alors obligatoirement passer par l’agent visité pour éviter qu ‘ils ne soient
détruits. Par contre une fois que les paquets ont été routés hors du réseau visité, ils vont
directement du nœud mobile au correspondant sans passer par le réseau mère. C’est ce qu’on
appelle le routage triangulaire.
fig1 Routage Mobile IP
3.2
Limites de Mobile IP
Mobile IP est conçu pour permettre aux nœuds de se déplacer d’un réseau IP a un autre ; il
résout le problème de la « macro » mobilité. Il est moins bien adapté à la « micro » mobilité,
lorsque les mobiles effectuent des handoffs fréquents dans une même zone géographique.
Tant que le déplacement du nœuds ne se situe pas entre deux points d’accès sur des souréseaux IP différents, des mécanismes de mobilité de niveau liaison offrent probablement une
convergence plus rapide et nécessitent bien moins d’overhead que Mobile IP.
Dans la version standard de Mobile IP, la nouvelle localisation d’un mobile est toujours
signalée a son Home Agent. Ce dernier est ainsi averti de tous les déplacements des mobiles
qu’il gère. Ces opérations génèrent une grande quantité de signalisation. De plus, les pertes
des paquets pendant les handoffs peuvent être importantes puisque la procédure
d’enregistrement est longue, en particulier si le Home Agent se trouve à l’autre bout du
monde.
La durée d’un handoff peut atteindre plusieurs secondes dans l’Internet actuel.
4
Solutions de micro mobilité
La micro mobilité représente donc la gestion de la mobilité locale. La gestion de la micro
mobilité permet à des mobiles de s’enregistrer localement a l’intérieur du réseau qu’ils
visitent. Cet enregistrement local réduit le délai de signalisation, ce qui peut améliorer les
performances des handoffs.
d’autre part, pour des mobiles bénéficiant d’une certaine QoS, l’acquisition d’une nouvelle
care-of address pour chaque handoff implique de remettre en place des réservations entre
Home Agent et le nouveau Foreign Agent. Cependant, une grande partie du chemin entre le
correspondant et le mobile risque d’être identique avant et après le handoff (si le mobile ne
change pas de domaine).
Plusieurs solutions pour gérer la micro mobilité ont été proposées. Toutes reposent sur le
principe suivant : le réseau visité par un mobile se charge des déplacements locaux ; le Home
Agent n’est donc prévenu de tous les changements de localisation du mobile qu’il gère.
Samer Khalil
Mémoire
Page 11
Les solutions présentées, HMIP (Mobile IP Hiérarchique) [Gust 01], HAWAII( HandoffAware Wireless Access Internet Infrastructure) [Ram 00] et Cellular IP sont d’une certaine
façon une amélioration de Mobile IP. Ces protocoles n’ont nullement l’ambition de substituer
à Mobile IP. Ce dernier gère la macro mobilité alors que ces protocoles s’occupent de la
micro mobilité.
On verra par la suite que l’une des principales différences entre Cellular IP et les autres
solutions, est que dans Cellular IP, la gestions des hôtes oisifs (inactifs) n’es pas la même que
celles des machines qui envoient et reçoivent des données (actifs).
5
Cellular IP
5.1 Pourquoi ce nouveau protocole ?
Cellular IP est une initiative du groupe de recherche COMET de l'Université Columbia aux
Etats-Unis. [Cam 99], [Val 00], [Cam 00], [She 00]
D'un côté on cherche à ajouter des fonctionnalités de mobilité sur Internet de l'autre des
services de paquets de données dans les systèmes cellulaires de troisième génération.
Mobile IP offre une solution pour le support de la mobilité sur IP toutefois on commence à se
rendre compte qu'il n'est pas approprié au support des déplacements fréquents des mobiles et
au contrôle de ces derniers. Au contraire, les réseaux cellulaires offrent un support complet
de la mobilité mais repose sur des infrastructures complexes auxquelles manquent la
flexibilité des solutions basée sur IP. Des alternatives commencent à voir le jour, l'une d'entre
elles est Cellular IP.
Cellular IP combine la facilité de prise en compte des déplacements offerts par les réseaux
cellulaires ainsi que la gestion efficace de la localisation des équipements actifs ou non et la
robustesse et la scalabilité (résistance au facteur d'échelle) des réseaux IP.
Cellular IP représente un nouveau protocole qui optimise l'accès à Internet pour un Mobile IP
avec le support des déplacements rapides et fréquents.
Cellular IP est certainement l'un des protocoles qui permettra de faire le lien entre les
opérateurs de téléphonie mobile et le monde IP.
5.2
Introduction
Cellular IP hérite du système cellulaire ses principes technologiques pour le contrôle de
mobilité, la connexion passive et le support du handoff. Cependant il implémente ces
techniques autour du monde IP. L'élément principal d'un réseau CellularIP est le nœud qui
joue le rôle d'un point d'accès pour les connexions sans fils, et le rôle d'un routeur qui
achemine les paquets IP. De même qu'il intègre les fonctions traditionnellement trouvées dans
les MSC ( Mobile Switching Center) et les BSC (Base Station Controller) du réseau cellulaire
GSM.
Dans Cellular IP les paquets uplink sont routés à partir du mobile host( MH) de proche en
proche jusqu'au Gateway. Le trajet suivi par ces paquets est enregistré dans les caches des
nœuds traversés sur le chemin.
Pour le chemin downlink des paquets adressées à un MH le même chemin est pris sauf que
cette fois c'est dans le sens contraire.
Samer Khalil
Mémoire
Page 12
Quand le mobile n'a pas de données à émettre et n'est pas en train de recevoir, il envoie des
paquets IP vides au Gateway afin de maintenir le routage downlink actif.
Dans les nœuds, les routes correspondantes aux mobiles n'ayant pas reçu de paquets durant
une certaine période de temps, sont supprimées. Cependant et afin de maintenir une certaine
trace de ces mobiles CellularIP ut ilise le mécanisme de paging (hérité de la téléphonie
cellulaire).
Dans ce qui suit je vais présenter un aperçu du protocole Cellular IP.
La figure suivante décrit un réseau cellular IP :
Backbone Internet avec Mobile IP
GW
GW
GW
Réseau CIP
Réseau CIP
BS
MH
----
Réseau CIP
BS
MH
fig 02 Réseau Cellular IP
5.3
Routage
Le gateway du Cellular IP envoie périodiquement en Broadcast un paquet phare ( Beacon
packet) qui inonde le réseau d'accès. Les base stations enregistrent le nœud voisin duquel elles
ont reçus ce beacon, et l'utilisent pour router des paquets vers le gateway. Tous les paquets
transmis par les hôte mobiles, quel que soit leur adresse de destination, sont routées vers le
gateway selon ces mêmes routes.
En effet, chaque base station maintient une routing cache. quand un paquet de données
engendré par un hôte mobile arrive à une base station, la routing cache locale stocke l'adresse
IP de l'hôte source ainsi que le nœud voisin duquel est arrivé le paquet. Selon le scénario
illustré dans la figure ci-dessous des paquets de données sont transmis par un hôte mobile
avec l'adresse IP source de X. Dans la routing cache de BS2, cela correspond à un mapping
(X,BS3).
Ce soft-state mapping ( correspondance) reste valide pendant un temps spécifique dit route
timeout. Les paquets de données sont utilisés pour maintenir et rafraîchir les mappings. Tant
que hôte mobile X envoie régulièrement des paquets de données, les bases stations se trouvant
le long du chemin ente le point de rattachement actuel du mobile et le gateway maintiendront
des mappings valides dans leur routing cache, formant ainsi un chemin soft state ente hôte
mobile et le gateway. Les paquets adressés à X sont routés de proche en proche en utilisant
cette routing cache établie.
Samer Khalil
Mémoire
Page 13
R
BS1
BS2
BS4
Mobile X
BS3
Mobile X
Fig 03 Routage Cellular IP
Un hôte mobile peut parfois vouloir maintenir les mappings de sa routing cache même s'il
n'est pas en train de transmettre régulièrement des paquets de données. Un exemple typique
de cette situation est lorsqu'un hôte mobile reçoit un flux UDP de paquets sur la route
descendante( downlink)mais n'a aucune donnée à transmettre sur la route ascendante ( uplink)
Afin de garder les mappings valides, hôte mobile transmet alors des paquets route update sur
la route ascendante à des intervalles réguliers appelés route update time. Ces paquets sont des
paquets ICMP particuliers adressés au gateway. Les paquets route update mettent à jour les
mappings de la routing cache, comme les paquets de données ordinaires. Cependant, les
messages route update ne quittent pas le réseau d'accès Cellular IP.
5.4
Hand off
Dans Cellular IP le Handoff est basé sur un principe qui admet la perte de quelques paquets
afin de minimiser la signalisation Handoff au lieu de garantir un taux de perte nul. Handoff
est initialisé par les Mobile. Les mobiles écoutent les beacons transmis par les Base stations et
initialisent un handoff suivant la puissance du signal reçu. Le mobile devra se brancher sur le
nouveau canal et transmettre un paquet ' route-update'. L'exemple suivant décrit la procédure :
Le scénario d'un Handoff est illustré dans la figure précédente. Ici, un mobile avec une
adresse IP X passe de BBS3à BS4.pendant une session active de transmission n de données.
Quand les mesure de niveau 2 indiquent que la connexion avec BS4 est meilleure que celle
avec BS3, le mobile switche sur le canal utilisé par BS4 et émet un paquet route-update. Le
chemin de ce paquet est représenté par les flèches pointillées sur la même figure. Ce paquet
configure en premier une nouvelle route cache mapping dans BS4 qui n'a formellement pas
reçu de mapping pour ce mobile en question. Ensuite ce même paquet configure ou crée une
nouvelle mapping dans BS2. Ce nœud possédera maintenant 2 mappings pour un même
mobile, une indiquant l'ancienne position du mobile et l'autre pointant vers la nouvelle
(BS4).Pendant un certain tps déterminé 'time out of routing cache mapping' les 2
correspondances vont coexister ensemble et les paquets adressés au mobile X vont être
délivré à travers les 2 base stations.
Samer Khalil
Mémoire
Page 14
Après ce time out l'ancienne mapping s'efface et les paquet downlink sont forwardés vers
BS4. Au même instant la mapping cache de BS3 associant le mobile X a BS3 est aussi
effacée. La mapping dans BS1 reste intacte durant le processus de handoff. Ce changement de
point d’accès brut est appelé Hard Handoff, et tolère la perte des paquets pendant que le
Route-Update atteigne le point d’accès qui doit réaliser le changement de route.
Quand un nœud mobile peut interagir simultanément avec 2 points d’accès, il peut faire un
semi-soft handoff. Quand un nœud mobile décide de se déplacer a un nouveau point d’accès,
il envoie un route- update avec un flag spécifique a travers le nouveau point d’accès et
retourne écouter l’ancien. Quand le Route-Update atteint le premier point d’accès qui doit
modifier et non créer l’entrée pour le nœud mobile, une nouvelle entrée est créée sans
remplacer l’ancienne. Les paquets de données sont alors envoyés à l’ancienne et à la nouvelle
localisation du nœud mobile. Quand le nœud mobile décide par la suite de se rattacher au
nouveau point d’accès, il envoie un Route-update pour détruire l’entrée avec l’ancien point
d’accès.
Pour les nœuds mobiles ne pouvant pas être connectés simultanément à deux points d’accès,
la technique de indirect semi -soft handoff se rapproche du semi-soft handoff. Quand le
nœud mobile décide de changer de point d’accès, il envoie un Route-Update avec un flag ‘I’ à
travers son ancien point d’accès avec l’adresse du nouveau point d’accès dans le champ de
l’adresse destination. Ce paquet est transmis au routeur passerelle qui l’envoie au nouveau
point d’accès. A réception de ce paquet, le nouveau point d’accès envoie un Route-Update
avec l’adresse du nœud mobile comme adresse source et on se retrouve alors dans la même
situation que le semi- soft handoff.
5.5
Paging
Cellular Ip définit un 'idle mobile' un mobile qui n'a pas reçu de paquets de données durant un
temps déterminé nommé 'active-state-timeout'. Ces mobiles laissent leur soft-state routing
s'expire. De ce fait ils transmettent un paquet paging- update a des intervalles de temps
réguliers définis par paging- update-time. Le paquet paging update est un paquet IP vide
adressé au gateaway ce qui le distingue du paquet route- update par le type de ses paramètres
IP. Le mobile envoie son paquet paging-update a la base station qui a la meilleure qualité de
signal. De même que les paquets de données, des route-update, les paquets paging update sont
routés de proche en proche jusqu'au gateway. Les nœuds peuvent optionnellement maintenir
une paging cache. La paging cache a le même format et faits les mêmes opérations que la
routing cache sauf qu'on retient les modifications suivantes:
1.
Paging cache mapping a un timeout plus grand nommé paging timeout.
2.
les Paging cache mapping sont mises à jour par n'importe quel paquet envoyé par le
mobile en particulier le paquet paging update.
3.
d'autre part routing cache mappings sont mises a jour uniquement par les paquets de
données envoyés par le mobile et les paquets route update.
Ceci explique que les mobiles idles ont des correspondances dans leur paging caches et
pas dans routing-caches.
En plus les mobiles actives auront des correspondances dans les 2 caches. Des paquets
envoyés à un certain mobile lui sont délivrés d'après les correspondances de la routing cache.
Samer Khalil
Mémoire
Page 15
Paging intervient qd un paquet est adressé à un mobile idle et quand le nœud ne trouve pas de
routing cache mapping pour la destination.
Si un nœud n'a pas une paging cache, il transmet le paquet sur toutes ses interfaces exepcté
celle par laquelle est venu le paquet. Paging cache est utile pour éviter les procédures de
recherche se basant sur les broadcast.
Sans les paging cache un paquet adressé a un mobile idle est diffusé dans tout le réseau.
Un mobile passif (idle) qui reçoit un paquet passe de l’état passif a l’état actif, déclenché son
temporisateur active-state timer. et émet immédiatement un paquet route- update. Ceci assure
que les routing cache mappings sont vites établies.
Le tableau suivant résume un peu le fonctionnement et l’utilité des deux Cache, Route et
paging :
rafraichit par
mis e a jour par
mise a jour quand:
utilisé pour
but
5.6
Paging Caches
tous les paquet uplink
(pagin-update, route-update, data)
tous les paquets update
lors d'un passage a une nouvelle Zone de
paging ou apres une paging-update-time
MHs idles ou actifs
router les paquets downlink si il n'y a pas de
correspondancedans la routing-cache
Route Caches
paquets DATA et route-update
paquets route-update
lors d'un passage a une nouvelle cellule
ou apres route-update-time
MHs active
router les paquets downlink
Détails du protocole
5.6.1 Algorithme du Nœud :
Les nœuds d’un réseau sans fils n’ont pas rigoureusement besoin du routage IP comme tel. En
enregistrant à partir de quelle interface ils ont reçu le bacon paquet du gateway les nœuds
sachent le chemin à suivre pour atteindre le gateway. Cette interface est nommée Uplink
Interface. D’autres interfaces sont utilisées pour atteindre les hôtes mobiles. Ces dernières
sont nommées Downlink Interfaces.
Un paquet IP arrivant à un nœud via l’interface uplink, est considéré comme adressé à un hôte
mobile par suite il suit l’algorithme décrit dans la figure suivante. L’algorit hme vérifie en
premier la routing cache locale pour trouver une information sur l’adresse destination. Si le
résultat est valide, le paquet est transmis suivant l’information reçue de la routing cache. Si
aucune correspondance n’a été trouvée le paquet est routé suivant la paging cache ou émis en
broadcast si la paging cache n’est pas valable.
Samer Khalil
Mémoire
Page 16
start
Ad : adresse de destination
Ad a une
mapping
dans RC ?
Nœud a une
PC ?
Ad a une
mapping
dans PC ?
Y
paquet transmis sur l’interface
obtenue de la RC
N
Paquet transmis sur toues les
interfaces downlink
Y
Paquet transmis sur l’interface
Obtenue de la PC
Envoi du paquet
stop
Fig 04. Algorithme de routage downlink
Légende : AD : adresse de destination
PC : Paging Cache
RC : Routing Cache
Ifc : interface par laquelle le paquet est arrivé
5.6.2 Les compteurs (Timers):
les compteurs de temps ( timers) jouent u rôle important dans l'efficacité de Cellular IP. Les
valeurs de RC et PC timeout, de même que les interfaces de temps entre 2 paquets routeupdate ou paging- update, doivent être minutieusement choisi pour une meilleure performance.
L’algorithme du nœud pour le routage uplink devient :
Samer Khalil
Mémoire
Page 17
start
AS : Adresse Source
Ifc : Interface parlaquelle est arrivé le paquet.
Y
Paquet de
paging
update ?
N
SA->ifc
mapping
existe ds RC?
Créer SA-> Ifc mapping
dans RC
Reset SA ->Ifc timer dans RC
N
Nœud a une
PC ?
SA ->Ifc
mapping existe
dans PC
N
Créer SA-> Ifc mapping
dans PC
Reset SA ->Ifc timer dans PC
Envoyer le paquet sur
l’interface Uplink.
stop
Fig05- Algorithme du routage Uplink
Samer Khalil
Mémoire
Page 18
5.6.3 Algorithme du mobile :
Les MH peuvent être modélisés par un processus de deux états comme le montre la figure
suivante .
Paquet reçus
Envoi de
paquet
Pagingupdate
IDLE
ACTIF
Envoi de paquet
route-update
Qd il n’y apas
de données a
emettre
Expiration du active-state-timer
Fig 07 Algorithme du MH
Un MH passe de l’état passif (idle) a l’état actif des qu’il reçoit n’importe quel paquet IP. Qd
il arrête de recevoir il demeure à l’état actif pour une durée déterminée définie par le système
( active-state-timeout).Tout paquet IP reçu réinitialise ce timer. Qd le timer expire le MH
rente dans l’état passif.
Qd le MH passe de l’état idle a actif, il émet un paquet ‘route-update’.
A l’etat idle le MH émet régulièrement des paquets’ paging- update’ ( chaque pagin- updatetime)
5.7
Adressage et migration
Il est bien entendu que les adresses d'un hôte mobile n'ont aucune signification pour la
localisation du mobile dans un réseau Cellular IP. De ce fait n'importe quel identificateur du
hôte peut être utilisée pour cette fin. L'utilisation de l'adresse IP mère ( home IP) est une
simple solution et a l'avantage que les paquets IP ne changent pas a l'intérieur du réseau
d'accès.
Ni l'encapsulation de paquets ni la conversion d'adresse sont nécessaires dans un réseau
CellularIP. En plus l'utilisation de l'adresse IP comme identificateur unique du mobile facilite
énormément la migration entre les réseaux d'accès.
Un MH entrant dans un réseau Cellular IP doit simplement communiquer l'adresse du
Gateway local a son réseau mère. L'agent mère devra diriger les paquets destinés a ce mobile
vers le Gateway en question. Ce dernier prend en charge de la desencapsulation et de la
livraison des paquets au MH a l'intérieur du réseau Cellular IP.
Les RC et PC ne nécessitent aucune information a l'avance pour créer une correspondance
pour un mobile nouvellement arrivé dans un réseau d'accès et n'ont pas besoin être informées
une fois qu'un mobile quitte le réseau d'accès.
Samer Khalil
Mémoire
Page 19
Fig 08 Le réseau d'accès
5.8
Les messages de contrôle
Trois messages de contrôle sont nécessaires pour le fonctionnement du protocole : RouteUpdate, Paging-Update et Paging-Teardown. L’utilisation de ces messages est décrite au fil
de ce paragraphe. Le routeur passerelle envoie périodiquement des messages aux points
d’accès pour leur indiquer leur port montant (uplink port), cad le port utilisé pour atteindre le
routeur passerelle. (fig1), ceci rend le protocole Plug-and-play puisque aucune configuration
préalable n’est requise sur les point d’accès. Tous les autres ports des points d’accès sont des
ports descendants. Les points d’accès envoient aus si des Beacon contenant entre autres
l’identificateur du ré&seau cellularIP, l’adresse IP du routeur passerelle et un identifiant
d’aire de pagination sur leur interface radio.
Quand un nœud mobile ente pour la première fois dans un réseau CIP, il envoie une
authentification et des informations utilisateur dans un Paging- update a destination du routeur
passerelle. Si le routeur passerelle accepte la demande du nœud mobile, celui-ci doit faire un
enregistrement mère. Dans le cas du MIPV4, l’adresse indiquée dans cet enregistrement est
celle du routeur passerelle, alors que dans MIPV6 c’est une adresse temporaire locale créée a
partir du préfixe réseau.
Comme on l’a dit plus haut, un nœud mobile peut être dans 2 états. Lorsqu’il est inactif, il
doit mettre à jour les caches de pagination a chacune de ses entrées dans une nouvelle aire de
pagination ou juste avant que son entrée n’expire.( cas où le nœud mobile ne s’est pas
déplacé). Cette mise a jour est assurée par l’émission d’un Pagin- update. Un Paging–Update
détruit aussi les entrées dans les caches de routage. Un nœud mobile peut par ailleurs
demander explicitement la destruction de son entrée dans un cache de pagination pour éviter
tout conflit. LA suppression explicite d’une entrée dans le cache de pagina tion est faite par
l’envoie d’un Paging-teardown.
Ces paquets de contrôle( paging-update, route-update et paging) qui sont utilisés par
CelluarIP. sont de simples paquets IP. Les 3 contiennent élementairement l'identificateur du
MH. Cette information se trouve normalement dans l'un des 2 champs :adresse source et
adresse destination, suivant le sens de transmission du paquet et ceci pour les 3 types de
contrôle.
Samer Khalil
Mémoire
Page 20
Ces paquets de contrôle peuvent être implémentés dans une option du protocole IP sans
obliger les routeurs normaux de les comprendre puisque ces paquets ne quittent pas le réseau
d'accès.
Les paramètres suivants doivent être définis minutieusement. Les valeurs déclarées sont juste
pour information. Notons que la plupart du temps un MH actif émet des paquets de données et
des paquets de route- update doivent être envoyés fréquemment presque a chaque seconde.
Name
route-update-time
route-timeout
paging-update-time
paging-timeout
active-state-timeout
5.9
Meaning
Maximal inter-arrival time of packets
updating the Route Cache
Validity of Route Cache mappings
Maximal inter-arrival time of packets
updating the Paging Cache
Validity of Paging Cache mappings
Time the mobile host remains in
active state without receiving data
Typical Value
1 sec
3 sec
1 min
3 min
5 sec
Format des Paquets
5.9.1
paquet de données :
Cellular IP transmet des paquets IP réguliers sans aucune modification, segmentation
encapsulation ou tunneling.
5.9.2
Paquet de Route-Update :
Ces paquets son des paquets ICMP dans lesquels :
. l’adresse IP source est celle du MH
. l’adresse IP destination est celle du routeur passerelle
. le type est ‘CellularIP Control Packet’ et le code est Route-Update.
5.9.3
Paquet de Paging-Update :
C’est aussi un paquet ICMP dans lequel :
. le type est ‘CellularIP Control Packet’ et le code est Paging-Update.
5.9.4
Paquet de Paging-teardown :
C’est aussi un paquet ICMP dans lequel :
. le type est ‘CellularIP Control Packet’ et le code est Paging-teardown
Samer Khalil
Mémoire
Page 21
5.10 Sécurité
Cellular IP a été créé afin de supporter un handoff transparent et sécurisé. Les
systèmes mobiles doivent faire face à de nombreux problèmes de sécurité qui n’existent pas
chez leurs homologues stationnaires. En effet les hôte mobiles doivent mettre à jour leurs
emplacements lorsqu’ils se déplacent. Si ces messages ne sont pas sécurisés, ils peuvent être
interceptés. Cellular IP implémente des solutions de sécurité. D’abord, seuls les paquets
authentifiés peuvent établir ou modifier des mappings de la cache dans un réseau d’accès
Cellular IP. Seuls les paquets de contrôle sont authentifiés, car authentifier également les
paquets de données affecterait considérablement les performances de transport.
En Cellular IP, la transparence du handoff est primordiale. C’est pourquoi les clés de
session utilisées par les hôte mobiles pour l’authentification doivent être immédiatement
disponibles à la nouvelle base station durant le handoff. Les base-stations peuvent calculer
elles- même des clés de session, ce qui élimine le besoin de signalisation pour la gestion de
clés, et par là même, permet d’éviter un délai de plus au processus de handoff.
La clé de session est calculée selon une fonction de hachage qui combine :
• L’adresse IP de l’hôte mobile (IP MH)
• Une valeur aléatoire (RMH) assignée à l’hôte mobile quand il s’enregistre auprès du
réseau d’accès.
• Un secret de réseau (K network ) connu par toutes les base stations se trouvant dans le
réseau d’accès.
Ksession =MD5(IPMH, RMH, Knetwork).
Une clé de session est d’abord calculée et transmise à un hôte mobile lorsque ce
dernier contacte pour la première fois le réseau Cellular IP, durant l’authentification et
l’autorisation. C’est à ce stade que la valeur aléatoire RMH est assignée à l’hôte mobile.
Les paquets de contrôle transportent cette valeur avec l’information d’authentification. Les
base stations peuvent rapidement calculer la clé de session en combinant l’adresse IP et la
valeur aléatoire trouvée dans le paquet de contrôle avec le secret de réseau. Les base stations
peuvent alors facilement valider l’authentification avec la clé de session, sans autre forme de
communication ou base de donnée pré distribuée, ce qui permet d’obtenir un handoff rapide et
sécurisé.
Pour plus de sécurité, la clé de réseau peut être périodiquement remplacée,
déclenchant des changements de clé de session, ce qui rendrait plus difficile les brusques
attaques.
Nous souhaitons offrir des garanties de qualité de service aux utilisateurs de ces environnements
mobiles. La partie suivante est consacrée à l’étude des mécanismes de qualité de service dans
l’Internet et puis celle dans l’Internet mobile.
Samer Khalil
Mémoire
Page 22
Chapitre III
Qualité de Service
Et RSVP
5
Au début de ma recherche, l’objectif était d’intégrer RSVP dans Cellular IP, de manière à
pouvoir, tout en ayant une certaine qualité de service, gérer la micro- mobilité. Il s’agit donc
de modifier le code du RSVP daemon afin qu’il puisse réaliser les fonctions que l’on retrouve
dans Cellular IP.
Cette même recherche a été faite par une équipe d’ingénieurs à l’ESIB et malheureusement
sont arrivés à un résultat négatif. J’ai essayé dans un premier temps de compléter leur travail
en essayant cette fois de modifier le code source de Cellular IP en lui intégrant les modules de
RSVP. A fur et à mesure de mon travail je me rendais compte de la complexité de la solution
sur laquelle je travaillais. Etant dans un environnement mobile une telle solution gaspillera
énormément de bande passante et nécessitera un flux de signalisation assez important. La
légèreté et la simplicité de Cellular IP sera entièrement perdu par une telle solution.
La suite de ce chapitre décrit brièvement les solutions de QoS dans les réseaux filaires et en
détail le protocole RSVP.
2
Qualité de Service dans l’Internet
L’Internet actuel est constitué d’une multitude de réseaux utilisant différentes technologies de
couche liaison. Ils reposent sur le protocole IP (Internet Protocol) pour interopérer. IP ne fait
aucune supposition sur la nature des protocoles des couches inférieures et offre un service de
couche réseau non fiable, sans connexion, et sujet aux pertes de paquets, déséquencements et
duplications. Ces phénomènes, ajoutés aux délais que subissent les paquets dans les routeurs,
augmentent la charge globale du réseau. À cause de cette absence de garanties fermes, le
mode de remise des paquets IP est souvent qualifié de best-effort (BE) ou au mieux. Le réseau
n'essaie pas de différencier les flots issus de différents utilisateurs en terme de service.
L’introduction de la Qualité de Service (QoS) permet à l’Internet de fournir d'autres classes de
service que le traditionnel service best effort. Cette demande d'enrichissement de la gamme
des services de l'Internet augmente au fur et à mesure que l'Internet pénètre dans la société.
L'objectif de la QoS est de supporter des services de communications ayant des exigences
qualitatives spécifiques. Ces exigences proviennent des applications réparties qui ne se
contentent plus du service best effort de l'Internet. Ces applications vont du simple transfert
de données à la téléphonie, la vidéo à la demande ou la conférence multimédia. L'introduction
de la QoS dans le réseau répond également à un souci financier des prestataires de service
Internet : offrir des niveaux de QoS différents est un moyen d'augmenter les revenus. Dans ce
contexte, la garantie d'une qualité de service sur l'Internet devient nécessaire. De nombreux
travaux de recherche sont menés depuis quelques années sur ce sujet ; en effet, trouver une
solution efficace pour fournir de la QoS de bout en bout sur Internet (c'est-à-dire sur les
réseaux IP) satisfaisant à la fois les fournisseurs d'accès à l'Internet et leurs clients est une
entreprise difficile.
Samer Khalil
Mémoire
Page 23
Parallèlement, l'évolution rapide des systèmes mobiles impose la prise en compte des
utilisateurs mobiles utilisant la même variété d'applications que les utilisateurs fixes.
L'introduction de la QoS dans les réseaux mobiles est encore plus complexe, car leur
topologie et leurs ressources évoluent dynamiquement. Le besoin de mécanismes de QoS
dans ces environnements est incontestable du fait de la rareté des ressources, de
l'imprévisibilité de la bande passante et des taux d'erreurs importants.
La QoS se décline principalement en quatre paramètres : débit, latence, gigue et perte. Le
débit (ou bande passante) représente les ressources de transmission occupées par un flot. Un
flot est un ensemble de paquets résultant d'une application utilisatrice. La latence* correspond
au délai de transfert de bout en bout d'un paquet. La gigue correspond aux variations de
latence des paquets. La gigue provient essentiellement des variations de trafic sur les liens de
sorties des routeurs. Des pertes de paquets peuvent être dues à des erreurs d'intégrité sur les
données. Cependant, dans les réseaux filaires actuels où la qualité des transmissions est très
bonne, cette cause est marginale*. La perte de paquets se produit principalement lorsque
l'intensité du trafic sur les liens de sorties devient supérieure à leur capacité d'écoulement. Il
s'agit alors d'une indication de congestion.
Ces quatre paramètres apparemment indépendants sont en réalité tous sensibles à la
congestion. En l'absence de congestion, chaque flot peut utiliser le niveau de bande passante
qu'il souhaite, aucun paquet n'est perdu, la latence est minimale et la gigue quasiment nulle.
Ces paramètres se dégradent lorsque la charge du lien augmente. Tous les paquets sont traités
de la même manière quel que soit le service qu'ils souhaiteraient recevoir. La solution réside
dans la capacité du réseau à isoler les flots pour leur fournir la QoS requise en leur offrant un
traitement spécifique.
Les recherches menées pour fournir de la qualité de service sur des réseaux IP ont conduit à
trois approches différentes : l'architecture à Intégration de Services, l'architecture
àDifférenciation de Services et MPLS (Multi Protocol Label Switching) que nous décrivons
dans ce chapitre.
2.1
Principe de l’architecture à Intégration de Services
Les applications traditionnelles non temps réel comme FTP se sont longtemps satisfaites du
service best effort. Mais avec l’arrivée des communications multimédias, de nombreuses
applications sont devenues sensibles au délai si bien que le service best effort traditionnel ne
suffit plus. Bien que certaines applications soient adaptatives (c'est à dire qu'elles réagissent
dynamiquement en fonction de la charge du réseau) , il est souvent nécessaire de fournir de
nouvelles classes de service offrant une meilleure QoS (en terme de bande passante, délai ou
pertes). Ces nouvelles classes de service s’ajoutent au best effort traditionnel pour créer un
Internet à intégration de services.
Latence* : Les applications interactives, comme la téléphonie, tolèrent une latence maximale. Si un paquet subit
un retard supérieur au seuil tolérable, les données qu'il contient deviennent inutiles pour l'application. Le retard
équivaut pour ces applications à une perte de données.
Marginale* Ceci est uniquement vrai pour les réseaux filaires. Dans le cas de liens sans fil, la nature du canal de
communication influe fortement sur les probabilités de pertes. Ces pertes de la couche physique posent d’ailleurs
des problèmes aux protocoles de couches hautes. Par exemple, TCP considère à tort qu'il s'agit de congestion et
réduit la taille de sa fenêtre.
Samer Khalil
Mémoire
Page 24
L'architecture à Intégration de Services [Bra 94], développée par le groupe de travail Intserv
de l'IETF, propose un ensemble d'extensions à l'architecture d'Internet. Dans le cadre
d'Intserv, la QoS est associée au délai de transit des paquets.
L'architecture Intserv repose sur deux principes fondamentaux :
• le réseau doit être contrôlé et soumis à des mécanismes de contrôle d'admission,
• des mécanismes de réservation de ressources sont nécessaires pour fournir des
services différenciés.
Un mécanisme explicite est utilisé pour signaler les exigences de QoS par flot aux éléments
du réseau (hôtes, routeurs ou sous-réseaux). Les éléments du réseau, selon les ressources
disponibles, implémentent l'un des services Intserv en fonction du type de QoS souhaité
pendant la transmission des données. Le modèle distingue plusieurs types de services, en
fonction du délai de transit par paquet :
-
-
les services élastiques ou non temps-réel (par exemple, connexion à distance, transfert
de fichiers, messagerie). L'application attend d'avoir reçu les paquets avant de traiter
les données, le délai de transit peut varier, le service est de type best-effort.
les services temps-réel sensibles au délai et surtout à la gigue. Parmi ces services, le
modèle distingue les services tolérant une variation du délai de transit pour lesquels la
classe de service "à contrôle de charge" est définie, et les services ne tolérant pas de
variation pour lesquels la classe de service "garanti" est définie. Pour ces deux classes
de service, le modèle définit une spécification de service QoS caractérisant le service
attendu et des paramètres de trafic caractérisant le trafic à transmettre.
Le modèle spécifie également les conditions que doivent satisfaire les éléments assurant le
service. Ainsi, quatre fonctions de contrôle du trafic sont définies pour les routeurs :
- le classifieur de paquets sépare les flots entrants en fonction de la qualité de service
qu'ils demandent,
- l'ordonnanceur de paquets détermine l'ordre de traitement des paquets classifiés,
- le contrôleur d'admission permet de décider si un nouveau flot peut être admis sans
perturber les autres flots déjà établis et qui ont des garanties de QoS,
- le protocole de réservation de ressources sollicite des réservations de bande passante
sur chaque tronçon que le flot traverse.
Le modèle ne spécifie pas les mécanismes utilisés pour réaliser ces fonctions. Parallèlement
aux travaux du groupe Intserv, RSVP (Resource Reservation Setup Protocol) [Bra 97] [Wroc
97], un protocole de réservation de ressources a été développé par l'IETF, qui peut être utilisé
dans le contexte de cette architecture ou indépendamment. Le protocole RSVP est décrit dans
la section 3.
fig 09 Architecture RSVP/ Intserv
Samer Khalil
Mémoire
Page 25
2.2 L'architecture à différenciation de services
L'architecture à Différenciation de Services (DiffServ) [Nic 99] [Bla 98] résulte des efforts
menés pour résoudre les problèmes de complexité et de passage à l'échelle posés par Intserv.
Le passage à l'échelle devient possible en offrant des services à des agrégats plutôt qu'à
chaque flot et en repoussant le traitement par flot aux extrémités du réseau. L'objectif est de
laisser le coeur du réseau aussi simple que possible.
Les flots applicatifs dits micro-flots sont agrégés en fonction de leurs contraintes de QoS. Par
opposition aux micro- flots, l'agrégation se nomme macro-flot et représente une classe de QoS.
Les routeurs effectuent les traitements non plus sur des micro-flots (trop nombreux dans
l'Internet) mais sur des macro-flots dont le nombre est limité et fixé par l'administrateur du
domaine. Un domaine représente une portion contiguë de l'Internet contrôlée par une même
autorité administrative.
Dans la suite de ce chapitre, nous décrivons l'architecture à Différentiation de Services ainsi
que le protocole MPLS (Multi Protocol Label Switching).
2.2.1
Principe de l’architecture à Différenciation de Services
La différenciation de services est principalement réalisée grâce au champ Differentiated
Service (DS ou DSCP : Differentiated Services Code Point) dans l'en-tête IP et au
comportement associé (Per-Hop Behavior ou PHB). DiffServ divise le réseau en domaines;
un domaine est un groupe de nœuds qui fonctionnent avec un ensemble commun de politiques
d'allocation de service et de définitions de PHB. Un domaine DiffServ est constitué de deux
types d'éléments fonctionnels, les éléments de bordure et les éléments du coeur du réseau.
Les éléments de bordure sont responsables de la classification des paquets et du
conditionnement du trafic en fonction des accords de service (Service Level Agreement ou
SLA) entre les domaines voisins. Un SLA est un accord bilatéral entre des domaines, négocié
statiquement ou dynamiquement. Le SLA peut être qualitatif*ou quantitatif* . Selon les
SLAs, des spécifications de service (Service Level Specification ou SLS) appropriées sont
affectées aux noeuds de bordure. Le SLS contient des paramètres tels que la capacité de
transmission, la taille des rafales et le débit crête.
Les nœuds de bordure contiennent les éléments suivants :
- un métreur qui mesure le trafic afin de vérifier sa conformité par rapport au profil
établi,
- un marqueur qui positionne le champ DS à une valeur déterminée (le champ DS
identifie l'agrégat auquel le trafic appartient),
- un régulateur, pour retarder le trafic afin qu'il n'excède pas le profil,
- un éliminateur du trafic non-conforme si nécessaire.
Les éléments du cœur du réseau ne sont responsables que du transit des paquets. À chaque
nœud, les paquets sont traités selon le PHB invoqué par l'octet DS dans l'en-tête du paquet.
qualitatif* : par exemple : "le trafic offert à la couche de service A sera délivré avec un faible temps de latence".
Quantitatif* : par exemple : "90% du trafic conforme au profil du niveau de service B subira moins de 50 ms de
temps de latence".
Samer Khalil
Mémoire
Page 26
Les routeurs de cœur ne voient plus des flots utilisateurs mais des classes. Une classe
représente une agrégation de flots utilisateurs. Les routeurs appliquent un traitement aux
paquets en fonction de leur champ DS.
Ce dernier décrit un PHB traduit par exemple par :
- le niveau de priorité du paquet si le routeur gère les paquets suivant un mécanisme de
priorités (avec une file d'attente par niveau de priorité);
- la proportion minimale de la capacité du routeur associée à chaque classe de paquets si
la file est gérée suivant une discipline WFQ (Weighted Fair Queueing)[Mar 91];
- la probabilité de rejet du paquet en fonction de sa classe (et du niveau d'occupation de
la file) si le routeur gère le trafic suivant une politique RED (Random Early Discard)
[Bra 98].
L'IETF a été amené à définir deux nouveaux PHB en plus du comportement au mieux appelé
DE (Default) dans la terminologie DiffServ : EF (Expedited Forwarding) ou service premium
[Hei 95]et AF (Assured Forwarding) [Jac 99] L'Expedited Forwarding permet de réaliser le
transfert de flux à forte contrainte temps réel. L'Assured Forwarding permet de garantir à
certains paquets d'un flux de ne pas être supprimés en cas de congestion.
Fig10 Réseau Diffserv
Le modèle de gestion des ressources à deux étages de DiffServ permet à tous les domaines
DiffServ de faire leurs propres choix quant aux mécanismes à utiliser pour le support de QoS
interne, tandis que pour le support de QoS externe, ils s'appuient sur le SLA. Une QoS de bout
en bout peut être obtenue par la concaténation des allocations de ressources intra et inter
domaines. Dans ce modèle, chaque domaine possède un gestionnaire de ressources
(Bandwidth Broker) qui gère les ressources et contrôle le trafic inter et intra domaine.
DiffServ permet de définir des classes de QoS sans modifications profondes en terme de
gestion du trafic et d'offrir une solution de continuité par rapport au service best effort
couramment employé aujourd'hui.
2.3
Multi-Protocol Label Switching (MPLS)
L’objectif de Diffserv est de fournir une solution de qualité de service qui résiste au facteur
d’échelle. Le protocole MPLS, défini plus récemment, a été conçu pour répondre aux mêmes
besoins. La commutation multiprotocoles avec étiquetage des flux (Multi-Protocol Label
Switching, MPLS) est une technique réseau en cours de normalisation à l'IETF
(http://www.ietf.org/html.charters/mpls-charter.html), dont le rôle principal est de combiner les
concepts de commutation de label et de routage. MPLS doit permettre d’améliorer le rapport
performance/prix des équipements de routage, d’améliorer l’efficacité du routage (en
particulier pour les grands réseaux) et d’enrichir les services de routage (les nouveaux
Samer Khalil
Mémoire
Page 27
services étant transparents pour les mécanismes de commutation d'étiquette, ils peuvent être
déployés sans modification sur le cœur du réseau).
Le principe de MPLS s'appuie sur une technique qui permet d'attribuer une étiquette à chaque
flux de données TCP/IP. Cette étiquette courte, de longueur fixe, correspond à un bref résumé
de l'en-tête du datagramme IP ; elle fournit des informations sur le chemin que le paquet doit
parcourir, afin qu'il puisse être commuté ou routé plus rapidement sur des réseaux utilisant
différents types de protocoles. Ainsi les commutateurs/routeurs analysent l'étiquette des flux
au lieu de leur adresse de destination. Le premier routeur MPLS que le datagramme rencontre
appose une étiquette sur ce datagramme qui peut alors être envoyé très rapidement dans le
réseau MPLS en fonction de cette étiquette. De l'autre côté du réseau, le datagramme IP est
"déballé" et acheminé de manière classique.
Le protocole MPLS, comme spécifié par l'IETF, est principalement destiné à être utilisé en
combinaison avec DiffServ.
3
RSVP
3.1 La gestion de la QOS avec RSVP
La gestion de la qualité de service a toujours été prise en compte dans le modèle INTERNET.
Dès la conception du protocole UP, un champ a été réservé pour coder des informations liées
à cette qualité. L’idée était à ce moment là d’indiquer pour chaque datagramme le type de
service auquel il devrait prétendre dans chaque routeur traversé.
Dans les années 90, on s’est beaucoup intéressé à la gestion globale des ressources du réseau,
ce qui a donné naissance à un protocole de réservation de ressources connu aujourd’hui sous
le nom de RSVP (Reservation Setup Protocol). Ce protocole est un protocole de signalisation
au modèle de ce qui existe dans les réseaux classiques de télécommunications comme le
réseau téléphonique pour exemple. Le principe en est simple : chaque application déclare au
réseau ses besoins ; à partir de ces besoins, le réseau, s’il le peut, garantit la disponibilité des
ressources nécessaires à l’application.
3.2
Motivation pour la conception de RSVP
Une extension insignifiante du mécanisme traditionnel pour de livraison point à point dans
lequel l'expéditeur prend soin des réservations le long de l'arbre de multicast provoque de
nombreux problèmes. Par exemple chaque fois que un membre part ou un nouveau joint le
domaine multicast, il est de la responsabilité de l'expéditeur d'installer une liaison point à
multipoint aux récepteurs. Cette re- initiation crée une surcharge énorme quand l'adhésion au
groupe est grande.
Une réservation lancée par la source ne peut pas traiter des conditions hétérogènes de
récepteur. Par exemple, certains récepteurs peuvent utiliser un meilleur matériel, ou d'autres
peuvent avoir d'étroites bandes passantes. Et comme la source ne connaît pas a priori les
spécifications des récepteurs, elle impose un niveau uniforme de réservation tout le long du
réseau. Ceci cause éventuellement a des pertes de bandes passantes dans certains cas et par la
suite une dégradation du service.
En revanche, RSVP est un modèle basé au récepteur, où chaque récepteur est responsable de
choisir son propre niveau des ressources réservées, de lancer la réservation et de la garder
Samer Khalil
Mémoire
Page 28
aussi long actif qu'il veut. En effet c'est une solution distribuée pour le problème de
réservation de ressource, et permet aux récepteurs hétérogènes de faire des réservations
spécifiquement conçues en fonction leurs propres besoins.
Le Control Distribué (Distributed Control) peut être mis en place d'une façon centralisée à la
source en demandant à chaque récepteur d'envoyer ses caractéristiques à la source et alors la
source peut demander au réseau pour faire les réservations. Cette approche souffre de
nombreux problèmes. Par exemple, si le groupe de multicast devient trop grand, ceci même a
un sur chargement de la source quand le groupe mulicast change et que la réservation doit être
renouvelée. Le control distribué permet également à des récepteurs de commuter parmi de
divers expéditeurs (sources).
3.3
QoS et RSVP
RSVP est employé par des applications pour demander une qualité de service spécifique au
réseau. RSVP n'est pas un protocole de routage, mais plutôt un protocole de contrôle sur
Internet. Sa tâche est d'établir et mettre à jour des réservations de ressources au-dessus d'un
arbre de distribution, indépendant de la façon dont elle a été créée.
En effet RSVP est une méthode pour allouer dynamiquement de la bande passante aux
applications orientées réseau dans des environnements traditionnellement datagramme. Il est
particulièrement utile pour les applications multimédias de type CBR (constant Bit Rate), et
rend obligatoire la demande de QoS par le récepteur (l'application participante plutôt que par
l'émetteur (l'application source).
Le récepteur apprend les spécifications du flux multimédia par un mécanisme hors-bande (on
va y revenir dans la suite). Il peut ainsi faire les réservations qui lui sont appropriées.
Ceci résout évidement le problème de l'hétérogénéité des réseaux.
Les équipements d'interconnexion (routeurs) répondent aux requêtes RSVP, établissent et
maintiennent les connexions.
3.4
Fonctionnalités de RSVP
RSVP est un mécanisme de signalisation, le signal étant constitué par l'informa tion de
contrôle QoS.
RSVP établit et maintient un état logiciel entre les nœuds constituant le chemin réservé. Par
opposition à la réservation d'un chemin statique (par exemple l'établissement d'un circuit
virtuel) , cet état logiciel est caractérisé par des messages périodiques de rafraîchissement
envoyés le long du chemin pour maintenir l'état.
RSVP fournit aussi une QoS dynamique tenant compte des modifications de ressources
pouvant survenir du fait du destinataire ou de l'émetteur ou encore par l'introduction de
nouveaux membres dans un groupe multicast.
Dans RSVP, le destinataire est responsable de la réservation de ressources QoS. RSVP
demande des ressources dans une seule direction, il traite l'émetteur et le récepteur de manière
différente. L'émetteur RSVP envoie ses exigences au destinataire. Après réception, le
destinataire RSVP utilise le même chemin pour renvoyer un message spécifiant la QoS
Samer Khalil
Mémoire
Page 29
souhaitée et fixer la réservation des ressources correspondantes dans chaque nœud. L'émetteur
RSVP envoie alors les données.
RSVP travaille au-dessus de IP (IPV4 ou IPV6) . il occupe la place d'un protocole de
transport dans la pile OSI des protocoles mais ne transporte pas de données utilisateurs. Il
n'est pas un protocole de routage mais il est censé travailler avec ces protocoles unicast et
mulicast.
3.5
RSVP, comment fonctionne -t-il ?
Le protocole de signalisation RSVP, qui a été défini par le groupe de travail RSVP , est un
mécanisme dynamique conçu pour effectuer des réservations de ressources explicites dans
une architecture Intserv . RSVP est utilisé uniquement pour la communication des paramètres
de QoS, il ne comprend pas l'information qu'il transporte dans les requêtes de QoS. RSVP est
initié par une application au début d'une session de communicatio n. Une session est identifiée
par l'adresse IP de destination, le type de protocole de la couche transport et le numéro de port
de destination. Chaque paquet RSVP contient les détails sur la session à laquelle il appartient.
L'affectation des ressources demandées par l'intermédiaire de RSVP pour un flot donné est
indépendant de RSVP, elle dépend d'Intserv. Une fois que les ressources demandées par
RSVP sont réservées, elle sont utilisées pour ce flot de données.
RSVP établit et maintient un état logiciel entre les nœuds constituant le chemin réservé. Par
opposition à la réservation d'un chemin statique, cet état logiciel est caractérisé par des
messages de rafraîchissement envoyés périodiquement le long du chemin pour maintenir
l'état.
RSVP fournit aussi une QoS dynamique tenant compte des modifications de ressources;
celles-ci peuvent être dues au destinataire, à l'émetteur ou encore à de nouveaux membres
dans un groupe multicast.
Le protocole RSVP définit sept types de messages, les principaux étant les messages PATH et
RESV. Ces deux messages assurent le fonctionnement de base de RSVP. Les autres messages
RSVP, présentés dans le Tableau 4-1, sont utilisés soit pour fournir des informations sur l'état
des réservations, soit pour annuler explicitement les réservations le long d'un chemin d'une
session de communication. Tous les messages RSVP sont envoyés sur le réseau comme des
datagrammes IP avec le numéro de protocole 46, et PATH, PATH Tear et RESV Conf
doivent être envoyés avec l'option d'alerte de routeur activée [Cat95].
Fig 11 Sens
des messages
RSVP
Le message PATH est envoyé par une source qui initie la session de communication et envoie
ses exigences au destinataire. Le message PATH contient le champ Sender_Tspec
(spécification du trafic de l'émetteur), utilisé par la source pour spécifier les caractéristiques
de trafic de ses flots de données.
Samer Khalil
Mémoire
Page 30
Tous les éléments de réseau par lesquels transite le message PATH, ainsi que le destinataire
lui- même, mettent en place une information d'état sur la session décrite dans PATH. ADSPEC
est un autre champ du message PATH ; ce champ optionnel fournit une indication d'état sur le
réseau.
Après réception du message PATH, le destinataire RSVP utilise le chemin inverse pour
générer une requête RESV qui spécifie la QoS souhaitée. En dehors des informations
concernant le style de réservation souhaité par le récepteur (champ Filter), le message RESV
contient deux champs, FlowSpec et FilterSpec, qui constituent la description du flux. lowSpec
définit les exigences pour le flot de données, c'est à dire :
• le type de service demandé (garanti ou à contrôle de charge),
• les paramètres du service pour invoquer la QoS (RSpec),
• les paramètres du flot demandant ce service (TSpec).
RSpec n'est présent dans la description du flot que si le service demandé est le service garanti.
Le champ FilterSpec fixe les paramètres adéquats pour la classification des paquets.
Chaque nœud RSVP, à la réception du RESV, réalise le contrôle d'admission, réserve les
ressources appropriées et renvoie la requête au nœud en amo nt. Ce processus se répète jusqu'à
la source. L'émetteur RSVP peut alors envoyer les données.
En cas d'échec de la réservation, un message d'erreur est envoyé. Notons qu'à l'inverse des
messages PATH qui sont envoyés à l'adresse de la session (unicast ou multicast), les
messages RESV sont envoyés à une adresse unicast.
L'état des réservations RSVP est éphémère (soft state) et doit être mis à jour régulièrement.
Les messages PATH et RESV sont retransmis périodiquement, ce qui permet de mettre à jour
les informations sur l'état de la session. Cette technique évite d'allouer inutilement des
ressources à une session terminée ; elle permet également de s'adapter à des changements de
configuration du réseau, comme une modification du routage.
3.6
RSVP alloue des débits simplex
Comme la majorité des débits multimédias sont asymétriques, RSVP traite le flux de données
comme unidirectionnel (simplex). Il distingue totalement les rôles joués par la source et par le
récepteur.
Mais rien n'empêche une application de remplir ces deux rôles, par exemple un programme de
visioconférence. Dans ce cas, les deux parties doivent séparément demander une réservation
de ressources vers la partie adverse. Une conversation consistera donc en deux débits RSVP
qui auront été spécifiés individuellement. Cette approche unidirectionnelle a été favorisée de
manière à faciliter les communications multipoints.
3.7
RSVP établit des états non-permanents
La réservation initiale est établie sur les routeurs qui ont été marqués par la propagation du
message PATH de la source à l'utilisateur. Ce chemin a été calculé par l'algorithme de routage
Samer Khalil
Mémoire
Page 31
d'IP. Au cours de l'envoi des données, il se peut que le chemin optimal entre la source et le
client change. Il faut donc que la réservation sur les routeurs puisse être modifiée.
RSVP utilise donc une approche "soft-states" quant au processus de réservation des routeurs
et des hôtes, c'est-à-dire que l'état de réservation des routeurs est non-permanent, et qu'il doit
périodiquement être rafraîchi par des messages PATH et RESV.L'état d'un routeur est effacé
si aucun message de rafraîchissement ne lui est parvenu après un certain délai. Cela évite que
des états de réservation ne se maintiennent inutilement sur des routeurs qui ne font plus partie
du chemin emprunté par l'information. Il faut cependant prendre en compte le fait que certains
messages de réservation peuvent se perdre en route.
Il faut donc que la période de rafraîchissement de la réservation soit suffisamment inférieure
au temps de vie de l'état des routeurs.
L'état de réservation d'un routeur peut aussi être explicitement détruit par un hôte ("teardown
message"), si celui- ci spécifie qu'il n'a n'en a plus besoin. Cette procédure n'est pas nécessaire,
mais est conseillée pour permettre d'accélérer la libération des ressources. Il y a deux types de
messages "teardown" possibles, PATHtear et RESVtear, selon qu'ils sont envoyés vers le
client ou vers la source.
En effet, ces messages peuvent être générés par l'application côtés source ou côté client, ma is
peuvent aussi provenir d'un routeur, par exemple parce qu'il ne peut plus assurer la QoS par
suite d'un problème quelconque.
L'état maintenu par RSVP est dynamique. Pour changer de source ou de QoS, un hôte doit
simplement modifier les messages PATH et/ou RESV qu'il envoie. Il en résultera un
ajustement de l'état RSVP des différents nœuds tout le long du chemin. Les états inutilisés
suite à cette modification peuvent être explicitement détruis par les hôtes.
Dans le cas contraire, ils seront automatiquement détruits au terme de leur temps de vie.
3.8
RSVP est un protocole orienté récepteur
Le requêtes de réservation de ressources sont émises par les clients. A tous les niveaux du
chemin emprunté par l'information, un nœud est responsable d'initialiser et de maintenir la
réservation sur le nœud situé directement en amont. Le nœud aval sait vers quel nœud amont
il doit propager la réservation étant donné que tous les nœuds du chemin ont été marqués par
le message PATH.
3.9
Accroissement de l'efficacité par fusion des requêtes communes
L'orientation récepteur de RSVP va permettre d'accroître la propagation efficace de
l'information, grâce à la fusion des requêtes communes au droit des différents nœuds du
réseau. Par exemple, si deux utilisateurs font appel au même service d'une même source, et
qu'en un nœud quelconque leurs requêtes de réservation se rejoignent, seule la plus exigeante
de ces requêtes doit être propagée plus en amont.
Cela permet un gain en bande passante dans les nœuds en amont du nœud dans lequel est
effectuée la fusion. RSVP est donc bien adapté aux communications multipoints telles le
broadcast et le multicast. Ce point sera développé plus loin.
Samer Khalil
Mémoire
Page 32
SOURCE
La fusion de différentes requêtes doit cependant être appliquée avec une certaine prudence.
Considérons en effet l'exemple suivant:
D1
A
D1
C
D
Le client A bénéficie d'une réservation de ressources lui garantissant un débit d1 pour sa
connexion à la source D. Ensuite, le client B émet une requête de réservation d'un débit
D2>D1 vers la même source D. Les deux requêtes seront donc fusionnées au nœud C, et c'est
la plus exigeante qui sera propagée vers le nœud amont D.
Si celui-ci ne peut satisfaire à cette requête par manque de ressources disponibles (D ne peut
assurer le débit d2), celle-ci sera rejetée. Il faut dans ce cas veiller à ce que la connexion de A
vers D ne soit pas interrompue.
D2
D1
A
D2
A
C
D
D2>D1
La requête RSVP grimpe l’arbre nœud après nœud.
3.10
Les communications multipoints: Unicast, Broadcast et Multicast
De nombreuses applications multimédia sont conçues pour pouvoir supporter plus d'un client
à la fois. La nature orientée récepteur de RSVP lui permet d'assurer des services multiutilisateurs, tout en tenant compte des besoins de chacun, ainsi que de l'hétérogénéité des
Samer Khalil
Mémoire
Page 33
récepteurs. En d'autres mots, les différents hôtes d'un même arbre multicast peuvent avoir des
capacités différentes, et dès lors demander des QoS différentes.
Il existe plusieurs façons de procéder pour les communications multipoint. Elles portent les
noms de unicast, multicast et broadcast :
Unicast : L'ordinateur source émet une copie différente des données pour chaque client
intéressé. Cette manière d'opérer est barbare et gaspille énormément de bande passante.
Broadcast : L'ordinateur source envoie un paquet "broadcast". Ces paquets sont envoyés sur
le réseau dans toutes les directions, pour être certain qu'il parviendront bien aux clients qu'ils
intéressent, par un chemin ou un autre. On gaspille aussi beaucoup de bande passante de cette
manière.
Multicast : L'ordinateur source envoie un paquet "multicast", en spécifiant les adresses des
clients qui sont intéressés. Les nœuds du réseau ne dupliqueront ce paquet que lorsque ce sera
nécessaire. Le multicast IP est donc le plus économe en bande passante. On reconnaît, dans
cette manière de propager les paquets seulement dans les directions utiles, des propriétés
essentielles de RSVP.
Une des nombreuses possibilités du multicast sur Internet est de faire de la diffusion
d'émissions de télévision et de radio. Il faut donc que la technologie mise en oeuvre permette
à un utilisateur de joindre un groupe multicast à tout moment, et de le quitter quand bon lui
semble. Il faut donc définir les différents types de réservations qui sont proposés par RSVP.
3.11
Modèle de Reservation sur RSVP(Reservation Style)
Les réservations que RSVP permet de contrôler sont organisées pour fournir des garanties au
sein de sessions de communication. Une session est une communication de groupe ou un
ensemble d'émetteurs et de récepteur coopèrent. Le modèle de réservation s'appuie sur le
contrôle des ressources pour des flux de données qu'il est alors possible de qualifier
d'unidirectionnels.
En effet, lors d'une demande de réservation, le client doit préciser deux options importantes
quant au types de réservation qu'il souhaite: le premier choix qu'il doit faire concerne le
traitement de l'information envoyée par les différentes sources: soit il établit une réservation
distincte pour chaque source, soit il établit une seule réservation qui sera partagée entre tous
les paquets issus de chaque source. La seconde option à préciser est le contrôle des sources:
soit le client sélectionne l'ensemble des sources présentes dans la session("wildcard"), soit il
sélectionne un nombre limité de sources particulières ("explicit"). Sur le tableau qui suit on a
représenté les quatre combinaisons possibles de ces deux options et on indiqué pour chacune
d'elle, le type de réservation correspondant.
RSVP supporte donc deux classes principales de réservation:
Réservations Distinctes:Les réservations distinctes installent un flux pour chaque Source de
chaque session.
Réservations Partagées: Une réservation partagée est employée par un ensemble d'émetteurs
qui sont connus pour éviter les interférences entre ces Emetteurs.
Samer Khalil
Mémoire
Page 34
reservation
scope
Distinct
Shared
Explicit
Fixed-Filter Style (FF)
Shared-Explicit Style ( S E)
Wildcard
None defined
Wildcard-Filter Style (WF)
Modele Wildcard-Filter (WF): le modèle WF représente une réservation partagée avec une
portée (scope) globale (Wildcard).
Avec une réservation WF on crée une réservation simple dans laquelle des flux de tous les
expéditeurs ascendants sont mélangés. Les réservations peuvent être assimilées à un tunnel
partagé dont la taille satisfait la requête de réservation la plus grande indépendamment du
nombre d'émetteurs.
La réservation est propagée en amont vers tous les émetteurs et est automatiquement entendue
à de nouveaux émetteurs des qu'ils apparaissent
Modele Fixed-Filter(FF): .Le modèle FF indique une réservation distincte avec une portée
explicite.
Avec une réservation FF, une demande de réservation distincte est créée pour des paquets de
données d'un expéditeur particulier. La portée (scope) de réservation est déterminée par une
liste explicite d'expéditeurs. La réservation totale sur un lien pour une certaine session est le
total de réservation FF pour tous les expéditeurs.
Cependant, les réservations FF demandées par différents récepteurs, mais en choisissant le
même expéditeurs, doivent être fusionnés pour partager une réservation simple dans un nœud
donné.
Modele Shared-Explicit(SE): Le modèle SE indique un environnement partagé de réservation
avec une portée explicite de réservation Le modèle SE crée une réservation simple dans
laquelle les flux de tous les expéditeurs ascendants sont mélangés. Comme dans le cas d'une
réservation FF, l'ensemble d'expéditeurs est indiqué explicitement par le récepteur faisant la
réservation
3.11.1 Implications des modèles de réservation
WF et SE sont tous les deux des réservations partagées qui sont appropriées pour les
applications de multicast dans lesquelles les contraintes spécifiques à l'application rendent peu
probable que les diverses sources de données transmettront simultanément.
L'audio conférence peut être un exemple ou un nombre limité de gens parlent en même temps.
Chaque récepteur doit initier une réservation WF ou SE a 2 reprises pour un canal audio.(pour
accepter les over-speaking).
Samer Khalil
Mémoire
Page 35
Le modèle FF crée des réservation indépendantes pour les flux des différentiels expéditeurs.
Le modèle FF est plus approprié pour les signaux visuels. Malheureusement on ne peut pas
fusionner des réservations distinctes avec des réservation partagées.
3.12
Exemple de réservation RSVP
Pour illustrer cette notion de réservation, voici l'exemple tiré directement de la spécification
du protocole (RFC2205). Il s'agit de décrire le comportement d'un routeur face à une session
composée de trois sources (S1,S2 et s3) et trois récepteurs (R1,R2 et R3). Ce routeur possède
quatre connexions extérieurs a des réseaux. Le schéma est alors le suivant:
Fig12 un exemple de routeur RSVP
La notion utilisée caractérise le contenu des messages de réservation en indiquant le style de
réservation, la liste éventuelle des sources concernées et la demande de ressources associée.
Ainsi WF(*(4B))indique une demande de style WF où l'ensemble de sources (*) se
partageront un certain ensemble de ressources (4B). De même, FF(S1(3B),S3(B)) désigne une
demande de style FF où les paquets issus de la source S1 demandent à bénéficier de 3B et
ceux issus de S3 demandent à bénéficier de B seulement.
La première illustration concerne une réservation WF où les paquets issus de toutes les
sources partagent la même réservation La composition des demandes issues des récepteurs
sera donc faite au sens du maximum des demandes exprimées par chaque paquet.
fig. 13 Reservation WF dans un routeur.
La deuxième illustration se situe dans le cadre FF ici une réservation décrit les ressources
demandées pour les paquets provenant d'une liste de sources explicitement donnée. Ici, le
calcul de composition se réalise encore sous forme d'un maximum des demandes, mais
Samer Khalil
Mémoire
Page 36
calculé source par source. Le bilan du calcul est ensuite renvoyé dans les routeurs aval pour
les seules sources pertinentes.
Fig14 Reservation FF dans un routeur.
La troisième situation aborde, comme WF une notion de partage de réservation; ici les
sources partageant les ressources sont explicitement indiquées. Le calc ul de composition est
donc un maximum sur les ressources demandées pour les paquets issus d'une union de
sources. Cette union est restreinte aux sources situées en aval du routeur.
Fig 14 Reservation SE dans un routeur
Montrons maintenant ce même mécanisme protocolaire appliqué à un ensemble plus large de
systèmes (hôtes et routeurs). La figure 8 montre un exemple de réservation WF et l'allocation
de ressources correspondante dans les nœuds intermédiaires.
Les deux exemples précédents, FF(fig 13) et SE (fig 14) montrent également l'impact de ces
réservations sur les flots de données associés entre les différentes sources et les récepteurs
pour lesquelles ses réservations sont établies.
Samer Khalil
Mémoire
Page 37
Fig 15 réservation WF dans un réseau
fig 16 Reservation FF dans un reseau
Fig 17 Reservation SE dans un réseau.
Samer Khalil
Mémoire
Page 38
3.13
Tous les routeurs ne supportent pas RSVP
Une caractéristique important de RSVP est qu'il doit pouvoir opérer sur un réseau dont tous
les routeurs ne sont pas SVP. C'est bien le cas. Les messages RSVP sont simplement ignorés
par ces routeurs, qui transmettront au routeur suivant toutes les informations quant à la
réservation.
Cependant, la présence d'un routeur non-RSVP sur le chemin emprunté par l'information peut
fortement affecter le dépit réservé. En effet, pour traverser celui-ci, l'information ne
bénéficiera d'aucune priorité. De plus, il est impossible de prévoire en quelle mesure le débit
sera dégradé, car le trafic en ce nœud peut varier en tout moment. Il est donc nécessaire de
prévenir le client si un de ces routeurs se trouve sur le chemin marqué par le message PATH.
C'est ce message PATH lui- même qui remplit cette fonction. Celui-ci mémorise son passage
éventuel par un routeur ne supportant pas RSVP, et en informe le récepteur.
3.14
Réservation de ressources
Pour mettre en place ce service, il faut intervenir sur la structure du host tout de même que sur
celle des routeurs. Sur ces derniers de nouveaux mécanismes de contrôle vont être ajoutés sur
la structure habituelle d'un réseau IP. La figure suivante décrit la procédure des cotés du
récepteur et du routeur.
Upstream
HOST
RSVP
deamon
1
2
ROUTEUR
RSVP
deamon
2
Policy
control
Routing
Protocol
Deamon
Application
Admission
Control
5
Packet
Classifier
Policy
control
Admission
Control
data
4
Packet
scheduler
3
Packet
Classifie
r
Packet
scheduler
Figure 18 réservations de ressources
3.14.1 Scénario
•
•
Le récepteur envoie la requête de QoS au Deamon RSVP local.[1]
La requête de QoS est passée à 2 modules de décision
Admission Control: Qui détermine si les ressources sont suffisantes.
Samer Khalil
Mémoire
Page 39
Policy Control: qui vérifie que l'utilisateur a l'autorisation administrative de faire cette
réservation
Si un des modules a une réponse négative alors envoie d'une notification d'erreur au
demandeur.[2]
Le Host envoie des paramètres de QoS au Packet Classifier et au Packet Scheduler[3]
Le packet Scheduler détermine la route et la classe de QoS pour chaque paquet
entrant[3]
Le packet Scheduler prendra la décision de transmettre chaque paquet.[5]
Le scénario se reproduit pour le hop suivant
Une cache pour le contrôle du trafic est construite dans chaque routeur.
Pour répondre aux modifications des cessions multicast par exemple RSVP envoie des
messages de rafraîchissement le long du chemin.
En l'absence de messages de rafraîchissement le cache relatif à une réservation est
détruit.
•
•
•
•
•
•
•
Comme le montre la figure précédente 4 entités s'occupent du déroulement du scénario:
•
Packet Scheduler (l'ordonnaceur de paquets):Il gère la transmission des paquets en
utilisant un ensemble de files d'attente. Chaque file correspondant a une classe de
service gérée par différents algorithmes du style Simple Priorité, Gestion par Classe,
partage équitable, etc. permettant de partager les ressources du nœud (mémoire, unité
centrale, bande passante...)en fonctions des demandes liées aux trafic des utilisateurs.
L'un des rôles de cet ordonnaceur sera de garantir un minimum de modifications de
caractéristiques des flux d'information entre l'entrée et la sortie du routeur.
•
Packet Classifier (le Classifieur de Paquets):pour permettre le contrôle de trafic,
chaque paquet doit être identifié et reparti entre plusieurs familles possibles.
Principaleme nt il s'agit de déterminer si le paquet arrivant dans un nœud appartient à
un flux Best Effort ou s'il doit bénéficier d'une réservation Il faut également détecter
des paquets portant de nouvelles réservations terminant ou modifiant des réservations
antérieurs (signalisation). Tous les paquets appartenant à une même classe seront alors
traités de la même façon par l'odonnanceur de paquets. On peut par exemple imaginer
une classe rassemblant tous les flux attribuables à une organisation particulière, ou
alors une classe concernant un seul flux. Ici également intervient une notion politique
du traitement de l'information.
•
Admission Control (le contrôleur d'admission): Celui-ci va implanter un algorithme de
décision permettant au routeur de savoir s'il peut garantir laQoS demandée d'un flux
et ceci sans dommage pour la QoS des autres flux déjà existants.
•
Policy Controle :vérifie que l'utilisateur a les droits administratifs d'exécuter
l'application.
3.15
Flux de données
RSVP définit une session comme étant un flux de données avec une destination et un
protocole de la couche transport particuliers. RSVP traite chaque session indépendamment.
Une session RSVP est définie par le triplet:
(Adresse_Destination, Id_Protocole, [Port_Destination])
Samer Khalil
Mémoire
Page 40
-
Adresse_Destination: L'adresse IP de destination des paquets, peut être soit
unicast, soit multicast.
-
Id_Protocole: L'identificateur du protocole utilisé (UDP ou TCP).
-
Port_Destination ( optionnel): contient le numéro de port destination du
protocole de transport (UDP, TCP...)ou une information spécifique à une
application.
Le Port_destination est indispensable lorsqu'il s'agit de plus d'une session multicast sur le
même hôte récepteur.
3.16
Mise en place d'une Session Rsvp
Pour lancer une session de multicast de RSVP, un récepteur joint d'abord le groupe de
multicast indiqué par une adresse de destination Ip en utilisant le protocole IGMP.
Dans le cas d'une session unicast, le routage d'unicast remplit la fonction d'IGMP, couplé à
Multicast Protocole-Indépendant (PIM), remplit dans la caisse de multicast. Après que le
récepteur joigne un groupe, un expéditeur potentiel commence à envoyer des messages de
voie d'accès de RSVP à l'adresse IP de destination. L'application de récepteur reçoit un
message de voie d'accès et commence l'envoi approprié réservation-demandent des messages
indiquant les descripteurs désirés d'écoulement en utilisant RSVP. Après que l'application
d'expéditeur reçoive réservation-demandez le message, l'expéditeur commence à envoyer des
paquets de données.
3.17
Eléments de Protocole
Les messages RSVP sont transportés directement dans les datagrammes IP avec comme type
de protocole 46, ou utilisent le protocole UDP si le mode direct n’est pas supporté. Dans ce
cas, le port 1698 et 1699 sont utilisés.
L’utilisation normale repose sur une modification du traitement dans les routeurs des
datagrammes IP. Cette modification permet l’interception des données pour tout datagramme
dont le numéro de protocole est 46 quelle que soit l’adresse destinataire.
Cette approche doit être prise en compte au niveau du noyau des systèmes d’exploitation,
dans la partie traitement IP et relation avec les programmes utilisateurs.
Une des conséquences de cette encapsulation directe est que les datagrammes transportant des
messages RSVP peuvent traverser directement et sans modification des routeurs n’implantant
pas cette méthode de gestion de réservation
3.18
Format des messages RSVP
Chaque message est composé d'une en-tête suivie d'une certaine quantité d'"objet" de taille
variable.
La composition de l'en-tête est définie comme décrit ci-dessous:
Samer Khalil
Mémoire
Page 41
- Version : 4 bits : précise le numéro de version du protocole utilisé (actuellement 1)
- Drapeau : 4 bits : pas encore défini
- Type du message : 8 bits : précise lequel des types de messages suivants on envoie : Path,
Resv, PathErr, ResvErr, PathTear, ResvTear, PathConf
TYPE
MESSAGE
1
2
3
4
5
6
7
Path
Resv
PathErr
ResvErr
PathTear
ResvTear
ResvConf
DESCRIPTION
Message Path
Message de réservation
Erreur en réponse a un message Path
Erreur en réponse a un message Resv
Annulation du Path State
Annulation de la réservation
Confirmation de la réservation
- RSVP Checksum : 16 bits : bits de vérification de la validité du message
- TTL_envoyé : 8 bits : précise la valeur du IP TTL avec lequel le message a été envoyé
- Longueur RSVP : 16 bits : indique le nombre de bytes du message (en-tête comprise)
Chaque objet est une série de mots de 32 bits. Le premier mot est l'en-tête de l'objet:
- Longueur: 16 bits : spécifie la longueur totale de l'objet en bytes. L'objet doit contenir au
moins 4 bytes et au maximum 65528 bytes. Sa longueur totale doit être un multiple de 4.
- numéro de classe: 8 bits : identifie la classe de l'objet parmi les classes suivantes dont nous
ne citerons que les principales:
Session: contient l'adresse IP de destination. Nécessaire dans tous les messages
Samer Khalil
Mémoire
Page 42
RSVP_hop: contient l'adresse IP du noeud (compatible RSVP) qui a envoyé ce message
Time_value: contient la valeur de la période de rafraichissement. Nécessaire dans tous les
messages Path et Resv.
Style: décrit le type de la réservation (FF, WF, SE). Nécessaire dans tous les messages Resv.
FlowSpec: spécifie une certaine QoS dans un message Resv.
Filter_Spec: spécifie quelle partie des paquets de données de la session doivent recevoir la
QoS décrite plus haut.
Policy_data: contient des informations qui permettront à l'autorité compétente de décider si
oui ou non la réservation demandée est permise.
Integrity: transporte des informations cryptographiques quant à l'authentification du noeud de
départ et à l'intégrité du message.
Resv_confirm: contient l'adresse IP d'un client qui désire avoir une confirmation de sa
demande de réservation.
- C-type: 8 bits : type d'objet (unique pour chaque classe)
3.19
Réticences au déploiement de RSVP
Plusieurs domaines de recherche concernent le déploiement de RSVP à une large échelle,
ainsi que le montre le RFC2208 : "RSVP Version 1 Applicability Statement, Some Guidelines
on Deployment". Les ressources nécessaires au fonctionnement de RSVP sur les routeurs
augmentent avec le nombre de réservations, induisant un impact négatif sur les performances
de ceux-ci. Parallèlement, les performances de transmission sont également affectées par les
mécanismes fournissant le s classes différenciées de services. Ceci explique les réticences des
organisations administrant les grands réseaux face au déploiement de RSVP.
Une proposition du groupe RSVP de l'IETF ("Flow Grouping for Reducing Reservation
Requirements For Guaranteed Delay Service ") essaie de réduire partiellement les exigences
induites par un service garanti, en suggérant de regrouper les flux semblables.
Un autre problème important concerne RSVP et les politiques de contrôle. RSVP ne définit
pas la politique elle- même mais définit seulement le mécanisme pour transporter celle-ci.
Certains constructeurs désirant alors fournir des mécanismes propriétaires, un nouveau groupe
de travail RAP de l'IETF a été créé fin 1997 pour définir des extensions à RSVP relatives aux
politiques de contrôle et spécifier un protocole d'échange d'informations de contrôle entre des
nœuds RSVP et des "policy servers" capables de fournir ces informations.
4.
Conclusion du chapitre
Dans ce chapitre, nous avons décrit différentes approches proposées par l’IETF pour fournir
de la qualité de service dans l’Internet. L’architecture à intégration de services a été la
première proposée. Bien qu'elle soit conçue pour fournir de la QoS de bout en bout, la
réservation de ressources pour chaque flot entraîne de sérieux problèmes de passage à
l'échelle dans les réseaux de cœur où le nombre de flots traités se compte en millions. Par
Samer Khalil
Mémoire
Page 43
conséquent, l'utilisation de l'architecture à Intégration de Services est limitée aux réseaux
d'accès de petite taille où le nombre de flots qui utilisent des réservations est modeste.
RSVP, est un mécanisme dynamique conçu pour effectuer des réservations de ressources
explicites dans une architecture Intserv.
Nous avons également présenté l’architecture DiffServ et le protocole MPLS, dont l’objectif
est de fournir une solution de QoS globale résistant au facteur d’échelle. Les services sont
offerts à des agrégats plutôt qu’à des flux particuliers.
Samer Khalil
Mémoire
Page 44
Chapitre IV
Mobilité et Qualité de Service
1
Introduction au chapitre
L'apparition des équipements sans fil pose de nouveaux problèmes dans le monde des
réseaux. En effet, les protocoles de l'Internet ont été conçus pour les environnements filaires
et s'adaptent très mal aux environnements sans fil. Cela vient d'une part de la qualité de
l'environnement de propagation qui est plus mauvais que celui que nous trouvons dans les
réseaux filaires, et d'autre part de la mobilité de l'utilisateur. L'objectif de ce chapitre est de
proposer des mécanismes permettant d'améliorer la qualité de service offerte aux utilisateurs
dans ce type d'environnement, spécialement avec Cellular IP en terme de débit, de probabilité
de pertes et de probabilité de coupure d'une connexion en cours de déplacement.
Les environnements sans fil imposent des contraintes propres telles que l'atténuation,
l'allocation de fréquences, les interférences, la fiabilité, la sécurité, le débit et la mobilité.
Dans ce chapitre, nous nous intéressons particulièrement à ce dernier point. La mobilité va
engendrer des mécanismes supplémentaires de réservation de ressources dans toutes les
cellules traversées par le mobile; il est donc nécessaire d'adapter les protocoles et les
terminaux afin de rester connecté au réseau pendant des déplacements. En particulier, les
systèmes sans fil doivent gérer le handoff, c'est à dire le basculement d'une communication
d'une cellule à une autre.
1.1
La méthode d’accès de base : CSMA/CA
Le mécanisme d’accès de base, appelé Distributed Coordination Function est typiquement le
mécanisme Carrier Multiple Acces with Collision Avoidance (CSMA/CA). Les protocoles
CSMA sont bien connus de l’industrie, où le plus célèbre est Ethernet, qui est un protocole
CSMA/CD (CD pour Collision Detection).
Un protocole CSMA fonctionne comme suit: une station voulant émettre écoute le support de
transmission, et si le support est occupé (ie. une autre station est en train d’émettre), alors la
station remet sa transmission à plus tard. Si le support est libre, la station est autorisée à
transmettre.
Ces types de protocoles sont très efficaces quand le support n’est pas surchargé, puisqu’il
autorise les stations à émettre avec un minimum de délai, mais il y a toujours une chance que
des stations émettent en même temps (collision). Ceci est dû au fait que les stations écoutent
le support, le repèrent libre, et finalement décident de transmettre, parfois en même temps
qu’une autre exécutant cette même suite d’opérations.
Ces collisions doivent être détectées, pour que la couche MAC puisse retransmettre le paquet
sans avoir à repasser par les couches supérieures, ce qui engendrerait des délais significatifs.
Dans le cas d’Ethernet, cette collision est repérée par les stations qui transmettent, celles-ci
allant à la phase de retrans mission basée sur un algorithme de retour aléatoire exponentiel
(exponential random backoff).
Samer Khalil
Mémoire
Page 45
Si ces mécanismes de détection de collision sont bons sur un réseau local câblé, ils ne peuvent
pas être utilisés dans un environnement sans fil, pour deux raisons principales :
1. Implémenter un mécanisme de détection de collision demanderait l’implémentation
d’une liaison radio full duplex, capable de transmettre et de recevoir immédiatement,
une approche qui en augmenterait significativement le prix.
2. Dans un environnement sans fil, on ne peut être sûr que toutes les stations s’entendent
entre elles (ce qui est l’hypothèse de base du principe de détection de collision), et le
fait que la station voulant transmettre teste si le support est libre, ne veut pas
forcement dire que le support est libre autour du récepteur.
Pour combler ces problèmes, 802.11 utilise le mécanisme d’esquive de collision (Collision
Avoidance), ainsi que le principe d’accusé de réception (Positif Acknowledge), comme suit :
Une station voulant transmettre écoute le support, et s’il est occupé, la transmission est
différée. Si le support est libre pour un temps spécifique (appelé DIFS, Distributed Inter
Frame Space, dans le standard), alors la station est autorisée à transmettre. La station
réceptrice va vérifier le CRC du paquet reçu et renvoie un accusé de réception (ACK). La
réception de l’ACK indiquera à l’émetteur qu’aucune collision n’a eu lieu. Si l’émetteur ne
reçoit pas l’accusé de réception, alors il retransmet le fragment jusqu'à ce qu'il l’obtienne ou
abandonne au bout d’un certain nombre de retransmissions.
1.2
Virtual carrier Sense (CTS/RTS)
Pour réduire la probabilité d’avoir deux stations entrant en collision car ne pouvant pas
s’entendre l’une l’autre, le standard définit le mécanisme de Virtual Carrier Sense (sensation
virtuelle de porteuse) :
Une station voulant émettre transmet d’abord un petit paquet de contrôle appelé RTS
(Request To Send), qui donnera la source, la destination, et la durée de la transaction. La
station destination répond (si le support est libre) avec un paquet de contrôle de réponse
appelé CTS (Clear To Send), qui inclura les mêmes informations sur la durée.
Toutes les stations recevant soit le RTS, soit le CTS, déclencheront leur indicateur de Virtual
Carrier Sense (appelé NAV pour Network Allocation Vector), pour une certaine durée, et
utiliseront cette information avec le Physical Carrier Sense pour écouter le support.
Ce mécanisme réduit la probabilité de collision par une station « cachée » de l’émetteur dans
la zone du récepteur à la courte durée de transmission du RTS, parce que la station entendra le
CTS et considèrera le support comme occupé jusqu’à la fin de la transaction. L’information
«durée» dans le RTS protège la zone de l’émetteur des collisions pendant la transmission de
l’accusé de réception (par les stations étant hors de portée de la station accusant réception).
Il est également à noter que grâce au fait que le RTS et le CTS sont des trames courtes, le
nombre de collisions est réduit, puisque ces trames sont reconnues plus rapidement que si tout
le paquet devait être transmis (ceci est vrai si le paquet est beaucoup plus important que le
RTS, donc le standard autorise les paquets courts à être transmis sans l’échange de RTS/CTS,
ceci étant contrôlé pour chaque station grâce au paramètre appelé RTSThreshold).
Le diagramme suivant montre une transaction entre deux stations A et B, et la valeur du NAV
de leurs voisins :
Samer Khalil
Mémoire
Page 46
Fig 19 CTS /RTS
L’état NAV est combiné au Physical Carrier Sense pour indiquer l’état occupé du support.
2
MRSVP (Mobile IP Reservation Protocol)
2.1 Introduction
[Talu 98] propose MRSVP qui est une modification de RSVP [Brad 97] pour diminuer les
probabilités de blocage.
Pour réserver des ressources pour des mobiles utilisant des applications temps-réel, des
options additionnelles sont nécessaires qui ne sont pas présent dans MRSVP. Ceci pour 2
raisons :
La première, pour assurer une garantie du service indépendamment de la mobilité, il est
nécessaire de réaliser des réservations de ressources de la source vers tous les endroits où le
MH pourrait se rendre durant la durée de la communication.
La seconde, c’est que les utilisateurs mobiles (dans un réseau mobile normal sans QOS) font
des réservations actives vers leur localité courante. Quand ils passent d’un endroit à un autre,
la procédure d’établissement de réservation de ressources tout le long du chemin d’accès ente
la source et le nouvel endroit du MH doit se faire le plus vite possible pour minimiser la
perturbation causée par le Handoff. Le mécanisme de réservation RSVP est incapable de
répondre à une telle demande.
2.2
MRSVP overview
Dans MRSVP on considère un système où les Hôte mobiles MH peuvent faire des
réservations de ressources à l’avance. Le MH peut être receveur ou source de données, ou les
deux en même temps pour le même flux de données ou pour des flux différents. Les
réservations sont simplex. Elles sont faites suivant les règles de RSVP mais ce protocole
s’étend pour réaliser des réservations à l’avance.
Pour ça, il est nécessaire de spécifier les Cellules où le MH pourrait se rendre a l’avance. Un
nouveau paramètre est utilisé Mspec (Mobile Specification) qui décrit la mobilité du MH.
Cependant il est difficile de prévoir la trajectoire d’un MH. A ce sujet plusieurs mécanismes
sont mis en place pour prédire approximativement les Mspec dans un réseau.
Dans MRSVP Mspec peut changer dynamiquement durant une cession de transmission de
données. dans un cas pareil, les ressources doivent être réservées à l’avance si les ressources
sont disponibles dans la nouvelle localité.
MRSVP support des réservations actives et passives. Pour un mobile Source il fait des
réservations actives a partir de sa localité courante et des réservations passives a partir des
Samer Khalil
Mémoire
Page 47
autres localité spécifiés dans Mspec. De même pour un mobile Récepteur. Sur un lien donné,
les réservations passives et actives sont groupées ensemble. Une réservation passive ou active
pour un même flux sur un lien donné peut être annulée sans affecter l’autre.
MRSVP transport les Flowspec des réservations actives et passives comme des objets
opaques. Ils sont interprétés par les services intégré dans les routeurs.
Fig 20 Active / passive reservation
Dans le réseau ci-dessus, le lien (N1, N2) a une capacité 2b et tous
autres liens ont une capacité B chacun. Les emplacements C1, C2
et C3 sont dans le Mspec (Mobility Specification) de MH1, et les
emplacements C4 et C5 sont dans le Mspec de MH3. Dans ce cas
MH1 est le récepteur et MH3 est l'expéditeur. MH1 exige une
largeur de bande B; pour MH1 une réservation active est installée à
C3 et des réservations passives sont installées à C1 et à C2. Pour
MH3, une réservation active est installée de C5 et une réservation
passive est installée de C4.D’autre part, le mobile MH2 exige une
garantie plus faible de QoS et fait avec succès une réservation
active à partir de l'expéditeur fixe S1 à C1 pour une largeur de
bande B
MRSVP utilise des Proxy Agents pour ses réservations. Dans ce protocole la source ou le
récepteur peut être un mobile ou les deux a la fois. De même q’un Hôte peut être Source et
récepteur en même temps.
Le proxy Agent se trouvant à l’endroit du mobile est appelé Local Proxy Agent. Celui qui se
trouve dans les autres endroits spécifiés dans Mspec du mobile s’appellent Remote Proxy
Agents.
Ces derniers vont prendre en charge les réservations passives a la place du mobile.
La figure suivante décrit le fonctionnements de MRSVP.
Samer Khalil
Mémoire
Page 48
Fig 21 Fonctionnement de MRSVP
* Mspec de MH1 est (C4,C2,C3)
* MH1 envoie Spec Message aux Remote Proxy Agents des nœuds N2 et
N3.
* MH2 envoie un Spec Message au remote proxy Agent du nœud N6.
* La source S et MH2 envoient Active Path Messages ; le Proxy Agent
de N6
envoie Passive Path Message.
* Active Resv message est envoyé du mobile MH1 via le nœud N4.
* Les Proxy Agents des nœud N2 et N3 envoient des Passive Resv
Messages.
Dans MRSVP on trouve 2 types de Path Messages de même que 2 types de Resv Messages :
1. 1.Active Path message : Contient Sende_Tspec pour les réservations actives
2. Passive Path message : contient Sende_Tspec pour les réservations passives.
3. Active Resv message : Contient le Flowspec pour les réservations active ; il peut aussi
contenir le Flowspec pour des réservations passive quand ces 2 réservations sont
groupées ensemble.
4. Passive Resv message : contient le Flowspec des réservations passives uniquement.
RSVP et IntServ ne supportent pas la gestion des réservations passives. Pour ce la de
nouveaux modules doivent être augmentés pour le support des réservations passives. Le
module Admission Control et le module Packet Classifier assurent les fonctionnalités des
réservations passives. Les détails du module Admission Control se trouvent dans [Tal 22]
2.3
Réticences aux déploiement de MRSVP
MRSVP a été conçu pour diminuer les probabilités de blocage. Cependant, cette technique
nécessite des classes de service supplémentaires, des changements majeurs à RSVP, une
Samer Khalil
Mémoire
Page 49
connaissance a priori des déplacements du mobile (profil de mobilité) et beaucoup de
signalisation. Ce travail suppose que la mobilité d'un utilisateur est prédictible de telle façon
qu'une spécification de mobilité peut être définie. Cette spécification représente la liste des
localisations géographiques que le mobile va visiter pendant la durée de vie d'un flux. Trois
classes e service sont définies : MIG (Mobility Independent Guaranteed Service), MIP
(Mobility Independent Predictive Service), et MDP (Mobility Dependent Predicitve Service).
Tant que les mobiles respectent le profil de mobilité, les utilisateurs ayant souscrit aux classes
de service indépendantes de la mobilité ne sont pas affectés par la mobilité des utilisateurs.
Les autres classes peuvent avoir des changements dans leurs paramètres de QoS lorsqu'un
handoff se produit. Cependant, afin de fournir des bonnes garanties à ces classes, des
ressources sont utilisées tout au long des chemins possibles définis par le profil de mobilité.
Prédire à l'avance tous les déplacements d'un mobile est souvent irréaliste: il n'est pas possible
de donner à l'avance le déplacement du mobile. D'autre part, ces réservations induisent un
gaspillage bien trop important des ressources du réseau.
[Awd 97] améliore RSVP de manière à l'adapter aux environnements mobiles. Cette approche
est similaire à celle de [Tal 97]: de nouvelles classes de service sont définies. Cependant, cette
approche utilise des agents de gestion de la mobilité pour maintenir des profils de mobilité et
envoyer des messages pour mettre en place les réservations. D'autres propositions de support
de la QoS dans les environnements mobiles sont présentées dans [Ind 98] et [Jain 98].
3
CLEP ( Controlled Load Ethernet Protocol)
3.1 Introduction
Les LANs partagés à diffusion comme les réseaux Ethernet/IEEE 802.3 ou IEEE 802.11 ne
distinguent pas de classes de trafic. Vis à vis de la gestion de la QoS, les réseaux à diffusion
posent quelques problèmes :
- tous les émetteurs partagent la même ressource. Comme la méthode d'accès est repartie et
qu'il n'y a aucun contrôle de trafic, il n'est pas possible d'isoler des flots afin de leur garantir
une QoS spécifique.
- la bande passante du support est instable ; elle dépend de l'environnement d'exploitation
mais également de la charge offerte. Cette remarque est surtout vraie dans le cas des réseaux
filaires Ethernet/IEEE 802.3 : après avoir atteint un maximum, les performances se dégradent,
en cas de surcharge, d'une manière presque inversement proportionnelle à la charge.
- la multiplicité des accès au support complique l'ordonnancement des paquets émis. De
nombreuses autres solutions ont été proposées pour résoudre ces problèmes. Par
exemple,[Yavatkar] propose une architecture centralisée pour gérer la bande passante sur les
sous-réseaux. Cette solution repose sur un gestionnaire de bande passante par LAN et repose
fortement sur RSVP [Bra 94]. De plus, [Yav 00] ne gère pas explicitement le trafic best effort.
La solution CLEP (Controlled-Load Ethernet Protocol) proposée dans [Bou 97] permet de
fournir des garanties de qualité de service à des flux particuliers. La suite de ce chapitre est
organisée comme suit : la section 2 rappelle les faiblesses du protocole Ethernet en terme de
qualité de service. Dans la section 3, nous décrivons le principe de CLEP. Ce protocole a été
testé dans des réseaux Ethernet filaires avec l'outil NS. La mise en oeuvre et les résultats de
ces simulations apparaissent dans la section 4. Nous nous intéressons à l'utilisation de CLEP
Samer Khalil
Mémoire
Page 50
dans les environnements sans fil IEEE 802.11. CLEP a été testé dans des environnements
réels et simulé.
3.2
Limites du protocole Ethernet
Ethernet ne fournit aucune garantie de qualité de service. La Figure22 met en évidence ce
problème. Cette figure est obtenue par simulation sous NS et représente le débit obtenu par 16
sources (15 flux UDP numérotés de 1 à 15 et 1 flux TCP ) qui surchargent un réseau Ethernet.
Chaque source essaie d'envoyer des paquets de 512 octets avec un débit de 410 kbit/s vers un
nœud du même sous-réseau*.
Lorsque la charge du réseau augmente, la bande passante totale utile est nettement sousutilisée (environ 15% de la bande passante disponible dans le cas de la Figure 22 et chaque
source dispose d'un débit quasiment nul. D'autre part, un flux particulier ne peut pas avoir de
garantie de débit puisqu' Ethernet assure l'équité entre les flux.
Fig22 Débit par source dans un élément de réseau Ethernet filaire classique
* On peut argumenter sur la validité du modèle de trafic choisi, qui n'est pas nécessairement réaliste. Cependant
la plupart des paquets d'un flux sont de taille fixe. De plus, ce modèle déterministe est le pire des cas puisque
toutes les stations sont actives.
Samer Khalil
Mémoire
Page 51
3.3
Principe de CLEP
3.3.1
Contexte
Controlled- Load Ethernet Protocol (CLEP) [Bou 97] est une implémentation du service
d'équilibrage de charge proposé par Wroclawski dans [Wroc 97] Pour chaque flux de
données, on approxime la qualité de service de chaque flux par celle que ce flux obtiendrait
sur un réseau peu chargé. Le principe de la gestion de QoS sur lien partagé repose sur un
contrôle de la charge offerte et se caractérise par :
• un contrôle d'accès pour l'ensemble des flots,
• une isolation des flots avec une réservation,
• une répartition équitable de la bande passante disponible entre les flots sans QoS (best
effort) des différents nœuds, - une stabilisation de la bande passante pour les réseaux
fonctionnant sur le principe du IEEE 802.3.
Dans une architecture Ethernet en bus, toutes les sources partagent les même ressources. Cela
signifie que ces sources n'ont aucune garantie concernant la bande passante dont elles
disposent, à moins que les autres sources ne décident de limiter leur débit. Un algorithme basé
sur des simples priorités des files ne remplit pas les besoins du service Controlled-Load : si
des sources surchargent le lien, les autres sources verront leur débit chuter (Figure
precedente). Par conséquent, toutes les sources doivent coopérer pour limiter leur débit
d'émission sur le lien partagé à une valeur appelée R, qui est un débit par source.
3.3.2 Différents type de flux
La restriction du débit d'émission des sources ne permet pas d'éviter les collisions. Par
conséquent, le service offert est toujours de type best effort. Toutefois, si la somme de tous les
débits des sources est inférieure à la capacité du lien, toutes les sources vont bénéficier d'un
débit proche de leur valeur maximale R. Il existe de nombreuses manières de limiter le débit
d'un flux. La méthode la plus appropriée est d'utiliser des filtres token bucket qui contrôlent la
charge sur les interfaces sortantes des éléments de réseau. Un token bucket est une forme
particulière de Traffic Specification (TSpec), c'est à dire un descripteur de trafic pour lequel
un contrôle de QoS est requis. Un TSpec est constitué d'un débit r et d'une profondeur de file
b. Il faut utiliser un filtre par flot afin de gérer plusieurs flots ayant des besoins de QoS
différents. Le débit R représente la somme des débits des différents filtres.
Chaque station possède au moins un filtre pour écouler le trafic best effort. À ce filtre best
effort peuvent éventuellement s'ajouter d'autres filtres pour les différents flux privilégiés qui
bénéficient du service controlled load (Figure précédente). Les paquets générés par les
applications sont classifiés en fonction de leur besoin en qualité de service avant d'être soumis
aux filtres. Ces filtres doivent également s'assurer que les flots sont conformes au TSpec.
Chaque file bénéficie d'un débit déterminé par les paramètres de son token bucket et il n'y a
pas de mécanisme de priorité entre ces files pour gagner l'accès au lien. Cet accès est
conditionné par la disposition des jetons pour chaque file, ce qui engendre des délais pour les
files prioritaires si elles sont servies après la file best effort. En effet, lorsque des paquets sont
bufferisés dans la file privilégiée, cela signifie que plus aucun jeton n'est disponible pour cette
file. Par contre, des paquets best effort peuvent être servis si des jetons sont régénérés pour la
file best effort. Une fois les paquets best effort émis, si le timer de régénération des jetons
Samer Khalil
Mémoire
Page 52
pour la file privilégiée a expiré, des jetons sont régénérés pour la file privilégiée, ce qui
permet de servir les paquets en attente dans cette file.
Les paquets best effort sont simplement stockés dans une file d'attente avant d'être soumis au
filtre. Si la file déborde, les nouveaux paquets sont détruits. Lorsque des paquets privilégiés
ne sont pas conformes au TSpec, ils sont traités comme des paquets best effort, conformément
au service Controlled-Load. Cependant, ces paquets ne peuvent pas être ajoutés à la fin de la
file best effort car il se peut que de nombreux paquets soient déjà en attente dans cette file. Un
paquet non conforme subirait alors un délai important et serait vraisemblablement détruit par
le récepteur. Ces paquets doivent donc être transmis aussi rapidement que possible, sans
toutefois perturber les paquets best effort classiques. Un paquet non conforme est donc traité
comme un paquet best effort si cela ne pénalise pas les paquets best effort, c'est à dire s'il y a
suffisamment de jetons disponibles. Dans le cas contraire, les paquets privilégiés non
conformes sont détruits.
fig23 Token buckets dans chaque élément d’extrémité
Certaines applications ont de très faibles besoins en débit, mais nécessitent un service plus
élaboré que le service best effort afin de garantir une fiabilité accrue. C'est le cas par exemple
de certains protocoles de routage comme RSVP ou Mobile IP car ces protocoles deviennent
inefficaces en cas de pertes de paquets importantes. De par leur faible débit, ces flots n'ont pas
besoin d'un filtre spécifique mais simplement d'une priorité supérieure. C'est pourquoi deux
files best effort avec des priorités différentes ont été définies (Figure 24): la file à haute
priorité est systématiquement servie avant la file de basse priorité.
Samer Khalil
Mémoire
Page 53
fig 24 2 files Best-Effort
3.4
Fonctionnement du protocole
Les éléments de réseau qui implémentent l'architecture CLEP doivent échanger des
informations afin d'ajuster les paramètres de leurs token buckets. De cette manière, ils
peuvent utiliser toute la bande passante disponible sur le lien, sans toutefois la dépasser. Nous
décrivons maintenant le protocole utilisé par les éléments de réseau afin de maintenir leurs
états.
Du point de vue du partage des ressources, il ne faut prendre en compte que deux paramètres :
la quantité de bande passante allouée pour le trafic best effort et la quantité de ressources pour
les flux privilégiés. Ces ressources sont estimées et échangées afin de paramétrer les token
buckets des éléments de réseau.
Pour calculer la bande passante réservée et disponible, chaque élément doit connaître le
niveau de réservation du lien, c'est à dire la quantité de ressources réservées pour les flux best
effort et privilégiés de tous les autres éléments de réseau. Par conséquent, ces informations
(les paramètres de débit des token buckets) doivent être échangées périodiquement par les
éléments de réseaux avec le protocole CLEP.
Chaque élément de réseau diffuse périodiquement sur le lien son Rbe (taux du token bucket
best effort), son Rpriv (taux des token buckets privilégiés) ainsi qu'un drapeau WM (Wants
More) qui indique le besoin de ressources, Rmin (la valeur minimale de Rbe qui est fixée par
l'administrateur) et Rmax (le débit maximal sur le lien qui est fixé par l'administrateur).
Chaque élément de réseau stocke tous les paramètres reçus dans une table qui est utilisée pour
calculer
Rfree, la bande passante disponible pour cet élément.
Lorsqu'un cha ngement intervient dans le réseau, de nouvelles valeurs sont immédiatement
calculées, et donc des messages d'états doivent être envoyés.
L'algorithme de contrôle d'admission fonctionne donc selon le principe suivant :
• si la réservation requise est inférieure ou égale à Rfree, elle est acceptée,
• si la réservation est supérieure à la somme des Rpriv et des Rmin, la réservation est
rejetée
• dans les autres cas, on remplace Rpriv par Rpriv plus le montant de la réservation, on
diffuse un message avec ces paramètres ; le nouveau Rfree est négatif et un mécanisme
Samer Khalil
Mémoire
Page 54
de décroissance de Rbe commence ; si Rfree reste négatif après l'expiration d'un
temporisateur, la réservation est rejetée, sinon si Rfree est devenu positif, la réservation
est acceptée
Le protocole CLEP diffuse ses messages sur le port UDP 580. La structure d'un message est
décrite sur la Figure suivante.
Fig 25 Message CLEP
Vers
W
X
Rbe
Rmin
Rmax
Version du protocole
Drapeau Wants More
Drapeau de sortie
Cette valeur est un entier en octets par seconde
Cette valeur est un entier en octets par seconde. Ce paramètre est fixé par
l'administrateur
Cette valeur est un entier en octets par seconde. Cette valeur est fixée par
l'administrateur et doit être la même pour tous les nœuds.
Deux temporisateurs sont utilisés pour le contrôle : Tbroadcast et Tcheck, que l'on fixe
respectivement à 30 et 1 seconde.
Au départ, un élément met son Rpriv à zéro et son Rbe à Rmin. Ensuite, il envoie un message
CLEP et commence à écouter le port UDP. Dans des circonstances normales, c'est à dire sans
modification des paramètres locaux, un message CLEP est émis tous les (Tbrodcast - delta),
où delta est un nombre aléatoire entre 0 et 1 seconde. Cette valeur aléatoire permet d'éviter les
synchronisations des éléments de réseau.
Tous les Tcheck, l'élément de réseau vérifie ses interfaces et modifie son Rbe si cela est
nécessaire ou permis. Ensuite, il envoie la nouvelle valeur de son Rbe dans un message CLEP
avec dans le cas d'une augmentation, le drapeau W mis à 1. Ce drapeau est également mis à 1
si l'élément de réseau demande plus de ressources best effort que ce qui est actuellement
disponible.
À la réception d'un message CLEP, la version du protocole est vérifiée. Si la version est
inconnue ou non supportée par l'élément de réseau, le message est jeté et une erreur est
générée. On fait de même si les Rmax des deux nœuds ne correspondent pas.
Samer Khalil
Mémoire
Page 55
Si l'émetteur est un nouveau nœud (il n'a pas envoyé de messages CLEP auparavant), il est
ajouté à la table locale, avec le contenu du message ; sinon le contenu de la table est mis à
jour avec les paramètres reçus dans le message. Le nouveau Rfree_be est calculé.
S'il est négatif, Rbe est diminué selon les règles de l'algorithme. S'il a changé, un message
CLEP avec les nouveaux paramètres doit être envoyé immédiatement.
Lorsqu'un élément de réseau quitte le réseau, il envoie un message CLEP avec le drapeau X
et tous ses autres paramètres à zéro. Si une information concernant un élément n'est pas mise
à jour en moins de 3*Tbroadcast, le nœud est enlevé de la table et Rfree doit être recalculé.
3.5
Résultats de simulation
La Figure suivante représente le fonctionnement de CLEP sur un réseau Ethernet filaire.
Dans cet exemple, CLEP est utilisé pour partager efficacement la bande passante d'un réseau
Ethernet d'une capacité de 1 Mb/s, c'est à dire que tous les flux sont best effort et qu'aucun ne
bénéficie de garanties de débit.
Le débit par source est représenté comme un pourcentage de la bande passante disponible.
Chacune des 12 sources (UDP 0 à UDP 11) émet un flux de débit 410 kbit/s avec des tailles
de paquets de 512 octets.
Nous voyons sur cette figure que contrairement à ce qui se passe sur la Figure 22, la bande est
partagée équitablement entre les sources et que la bande passante totale reste stable (environ
70%) même lorsque la charge est très importante (environ 5 fois la capacité du lien).
Fig 26 CLEP en contrôle de la charge
Samer Khalil
Mémoire
Page 56
4
MIR ( Mobile IP Reservation Protocol)
4.1 Description
MIR [Grand 00] est une extension de CLEP conçue pour fournir des garanties de QoS à des
utilisateurs mobiles. Ce protocole vise à offrir des garanties statistiques de bande passante à
des utilisateurs mobiles, sans connaissance a priori sur la mobilité des utilisateurs.
Ce protocole est basé sur un modèle utilisant un réseau IP par cellule, (mais il serait
envisageable d'utiliser un modèle où plusieurs cellules font partie d'un même domaine IP).
Nous considérons donc que chaque station de base est aussi un Foreign Agent au sens défini
dans la RFC 2002 qui décrit Mobile IP. Les couches inférieures fonctionnent avec IEEE
802.11, mais il serait tout à fait possible de faire fonctionner MIR avec un autre protocole.
MIR est distribué, donc chaque cellule peut être gérée séparément en fonction du degré de
mobilité des terminaux dans cette cellule. Une cellule peut donc s'adapter dynamiquement aux
besoins en mobilité des terminaux et répartir sa bande passante selon ces besoins.
Dans un environnement mobile, l'objectif est de dimensionner le nombre de jetons alloués à
chaque file suivant le trafic considéré et en fonction de la mobilité des utilisateurs.
L'adaptation de CLEP dans un environnement mobile implique de mettre en place de
nouvelles réservations lors de l'exécution d'un handoff. Dans un premier temps, seules les
parties sans fil utilisent des réservations et peuvent obtenir des garanties statistiques de qualité
de service(le blocage d'une communication lors d'un handoff est toujours possible).. Nous
faisons ce choix car, dans une architecture comprenant à la fois des portions filaires et sans fil,
la capacité totale des liens sans fil est souvent inférieure à celle des liens filaires. La gestion
de la bande passante sur la partie sans fil est alors essentielle.
Sans mobilité des terminaux, le problème revient simplement à faire des réservations sur
plusieurs réseaux locaux. Par contre, lorsque l'un des terminaux se déplace et change de
cellule, les réservations (routage et paramètres MIR) doivent évoluer.
Sur la Figure 27 et la Figure 28, un mobile MN1 envoie des données à un mobile MN2. HA
est le Home Agent de MN2. Lors des étapes 1 à 4, les deux mobiles sont dans la même
cellule. A l'étape 5, l'un des deux mobiles change de cellule. On distingue deux cas selon que
le terminal qui se déplace est émetteur ou récepteur.
Déplacement de la station émettrice (Figure 27)
Après le handoff, la réservation faite par MN1 dans la cellule 1 n'a plus lieu d'être. En
revanche, il faut, si cela est possible, réserver des ressources dans la cellule 2 pour MN1.
Puisque MN2 ne bouge pas, la réservation du Foreign Agent FA1 dans la cellule 1 doit
toujours exister.
Déplacement de la station réceptrice (Figure 28)
Après le handoff de MN2, MN1 doit garder sa réservation dans la cellule 1. La réservation du
FA1 dans la cellule 1 est inutile et doit être remplacée par une réservation de FA2 dans la
cellule 2.
Dans tous les cas, on se ramène donc à un problème de routage ainsi que de réservation dans
la nouvelle localisation du mobile. Lors de l'exécution d'un handoff, il faut mettre à jour les
réservations le long de la nouvelle route entre MN1 et MN2.
Supposons qu'une machine située dans une cellule C1 dispose d'un flux privilégié Rpriv1 et
d'un trafic best effort Rbe1. Lors d'un handoff dans une cellule C2, on souhaite pouvoir
Samer Khalil
Mémoire
Page 57
écouler le même trafic privilégié Rpriv1, le flux best effort, quant à lui peut varier. Le mobile
dispose d'un intervalle de temps limité pour renégocier ses paramètres de QoS.
Fig28 Réservation lors d’un Hand-off d’une station émettrice
Dans le meilleur des cas, la bande passante disponible dans C2 est suffisante et Rpriv2 vaut
Rpriv1. Cependant, les cellules ayant probablement des caractéristiques différentes (en
particulier Rtot et surtout la charge), Rbe2, recalculé en fonction de la bande passante résiduelle
dans C2, est différent de Rbe1.
Figure 29. Réservations lorrs d'un handoff d'une station réceptrice
Si C2 ne dispose pas de la bande passante nécessaire pour garantir le même Rpriv1, le flux ne
peut pas bénéficier d'une continuité de qualité de service. En réservant une partie de la bande
passante de la cellule pour écouler ce flux privilégié lors du handoff, nous pouvons limiter le
nombre d'occurrences de ce cas de figure.
Samer Khalil
Mémoire
Page 58
4.2
Définitions
Handoff passif
Un mobile exécute un handoff passif lorsqu'il entre dans une nouvelle cellule. Le handoff
passif consiste à déclencher les mécanismes pour effectuer des réservations passives (Figure
30).
Réservation passive
Une réservation passive est réalisée par tous les flux qui sont soumis à un handoff passif. La
réservation passive consiste à réserver des ressources dans une cellule dans laquelle le mobile
risque de se déplacer.
Handoff actif ou handoff
Le handoff actif s'exécute en même temps que le handoff IP. Il consiste à transférer les
paramètres de QoS à la nouvelle localisation du mobile. Les réservations passives du mobile
sont alors activées, c'est à dire que les jetons négociés servent pour émettre des données
(Figure 30).
Réservation active
Une réservation active est une réservation faite dans une cellule pour un flux d'un mobile
enregistré dans la même cellule.
Probabilités de blocage
Les termes "blocage passif" et "blocage actif" sont utilisés pour désigner les probabilités de
blocage d'un handoff passif et d'un handoff actif conformément aux politiques d'admission
que nous décrivons au 4.4.
L’objectif de MIR est de minimiser la probabilité de blocage d’ une connexion.
Fig 30 Handoff passif / handoff actif
Samer Khalil
Mémoire
Page 59
4.3
Répartition de s ressources entre les différents utilisateurs
4.3.1
Partitionnement de la bande passante
Pour la gestion des token buckets, nous proposons de séparer la bande passante de chaque
cellule en deux parties. L'une est consacrée à l'acheminement des flux privilégiés lors du
handoff, tandis que l'autre traite le trafic CLEP classique. Dans la suite, Rtot représente la
quantité de bande passante à répartir dans une cellule. De plus, nous allons effectuer des
réservations passives pour les flux présents dans d'autres cellules et qui effectueront peut-être
un handoff. Elle ne devient active que lorsque le mobile exécute son handoff. Par ailleurs, de
manière à ne pas sous utiliser la bande passante il est toléré d'effectuer des réservations sur
des ressources non disponibles.
Figure 31. Répartition de la bande passante totale dans une cellule
4.4
Politique d'allocation des ressources
4.4.1
Pour les nouvelles connexions
Soit S1 un seuil d'admission des nouvelles connexions, représentant un pourcentage de la
bande passante totale à distribuer, Cette proportion est exprimée par x dans la suite. Ainsi le
seuil S1 est égal à x*Rtot (Figure 31). Si la charge totale de la cellule reste inférieure à S1, les
nouvelles connexions sont acceptées, sinon on diminue le débit des files best effort jusqu'au
débit minimum assuré (R min), de manière à allouer ces ressources aux nouvelles connexions.
Lorsque les sources best effort ont atteint leur débit minimum, toutes les nouvelles
connexions sont refusées.
4.4.2 Pour les handoffs
Lorsque la puissance du signal reçu sur un mobile diminue et qu'il s'approche d'autres
cellules, il effectue une réservation passive pour ses flux privilégiés dans les cellules voisines.
Cela entraîne une diminution du nombre de jetons alloués aux files best effort de tous les
mobiles dans les cellules voisines. La réservation ne devient active que si le mobile exécute le
handoff sur cette cellule.
Samer Khalil
Mémoire
Page 60
Comme des ressources passives sont réservées pour des flux qui ne sont pas réellement
écoulés dans la cellule, il est possible de sur-allouer le médium : les réservations pour les
handoff des flux privilégiés peuvent s'effectuer jusqu'à un seuil S2 (Figure 31), qu'il faut
dimensionner correctement. Après un handoff, les ressources qui ont été réservées et qui ne
sont pas utilisées sont libérées, soit par expiration d'une temporisation, soit par une libération
explicite des ressources par le mobile. Ceci permet d'augmenter de nouveau le débit des files
best effort.
Après un handoff pour du trafic best effort, les jetons attribués aux files correspondantes sont
supprimés le temps que le mobile renégocie de nouveaux jetons pour ces files. La négociation
s'effectue comme s'il s'agissait d'une nouvelle connexion.
Figure 32. Scénario d'utilisation d'une cellule
4.5
Calcul du nombre de jetons
Le nombre de jetons est lié au débit alloué à chaque mobile.
On a donc :
S2 = (1+Y).Rtot où Y correspond à la proportion de bande passante supplémentaire allouée
grâce aux réservations passives.
De plus, Rtot est constant dans une cellule mais S1 et S2 peuvent varier en fonction des
besoins en mobilité des utilisateurs. Cette mobilité est bien mesurée (La mobilité est mesurée
grâce au nombre de nouvelles connexions dans la cellule pendant un intervalle de temps
donné.). Le s nouveaux seuils calculés permettent ainsi de définir une nouvelle politique de
contrôle d'admission en fonction des besoins locaux et ponctuels de chaque cellule.
4.6
Algorithme de contrôle d'admission
Dans l'algorithme suivant, nous utilisons les notations suivantes :
• curTokens : le nombre de jetons utilisés
• need : le nombre de jetons nécessaires pour satisfaire les besoins du nouvel appel
• actTokens : nombre de jetons utilisés pour des réservations actives
• psvTokens : nombre de jetons utilisés pour des réservations passives
Samer Khalil
Mémoire
Page 61
4.6.1 Nouveau flux privilégié
Si actTokens + psvTokens + need S1 alors
faire la réservation
mettre à jour les jetons
sinon réservation refusée
fin si
Réservation passive
Si S2 curTokens + need alors
// la réservation passive peut être faite
//Y a t il assez de ressources disponibles dans la cellule ?
phyDiff = rtot - need -actTokens -psvTokens
//phyDiff vaut donc la capacité de la cellule moins tout ce qui est utilisé et demandé
Si phyDiff 0 alors
// on peut faire une réservation qui agit sur le BE
$fa make-resv $need $FID // faire une reservation de $need sur le futur FA
// du mobile pour le flow id $FID
mettre à jour les jetons passifs
sinon //PhyDiff < 0
//on récupère ce qui reste et on prend des jetons passifs
diff = rtot - actTokens - psvTokens
Si diff < 0 alors
// ne rien réserver mais mettre à jour les réservations passives
mise à jour des réservations passives
sinon // diff 0
// réserver diff et mettre à jour les jetons passifs
$fa
make-resv
$diff
$FID
fin si
fin
si
sinon Réservation Passive refusée
fin si
Réservation active
Si le flux qui fait le handoff a une réservation passive alors
Si actTokens + need rtot alors
faire la réservation active
sinon
arrêter le flux privilégié
fin si
Samer Khalil
Mémoire
Page 62
sinon
// le flux n'a pas de réservation passive, il faut l'arrêter
arrêter les flux privilégiés
fin si
Fig33 Procédé d’admission utilisé par MIR
Samer Khalil
Mémoire
Page 63
Chapitre V
CIRP (Cellular IP Reservation Protocol)
1
Introduction au chapitre
Les recherches bibliographiques que j’ai faites durant ma durée du stage et que j’ai exposé au
fil des chapitres suivant m’ont permises de tirer les conclusion suivantes :
Le protocole CLEP [Hor 97] traite le problème de la gestion de la bande passante et des
réservations pour fournir aux utilisateurs d’un réseau partagé ( par exemple un réseau Ethernet
) une garantie de bande passante . Utilisé avec la réservation de ressources il donne de très
bons résultats dans les réseaux Ethernet filaires. C’est est un algorithme distribué qui permet
de stabiliser la charge et de différencier des classes de service sur un réseau partagé en
utilisant un mécanisme à base de token buckets. Le protocole MIR étend ce protocole pour
l’utiliser dans des environnements sans fils en tenant compte de la mobilité de l’utilisateur. Le
protocole Radio utilisé étant IEEE 802.11.
D’autre part, Mobile IP [Perk 96] et [Perk 98], offre une solution pour le support de la
mobilité sur IP toutefois on commence à se rendre compte qu'il n'est pas approprié au support
des déplacements fréquents des mobiles et au contrôle de ces derniers. Au contraire, les
réseaux cellulaires offrent un support complet de la mobilité mais reposent sur des
infrastructures complexes auxquelles manque la flexibilité des solutions basée sur IP. Une
alternative assez adéquate, et qui répond à ce problème est Cellular IP.
Cellular IP [Camp 98] - CIP - , inspiré des systèmes cellulaires, se propose de résoudre la
gestion de mobilité à l’intérieur d’un domaine. Par contre c’est Mobile IP qui gère la mobilité
entre domaines. Cellular IP interagit donc avec MIP que ce soit avec sa version 4 ou 6. Le but
de CIP est de procurer un seamless Handof f* à l’intérieur d’un domaine et de cacher le
mouvement du nœud au reste de l’Internet. Il combine la facilité de prise en compte des
déplacements offerts par les réseaux cellulaires ainsi que la gestion efficace de la localisation
des équipements actifs ou non et la robustesse et la scalabilité (résistance au facteur d'échelle)
des réseaux IP.
Pour offrir une solution globale de QoS dans les environnements mobiles nous proposons
Mobile IP pour la gestion macro mobilité et Cellular IP pour la micro mobilité. Ce chapitre
s’intéresse à offrir la qualité de service au réseau Cellular IP. Pour celle de Mobile IP
plusieurs techniques ont déjà vu le jour, on en retient MRSVP [Talu 98] ou MIR [Grand 00]
duquel on s’est bien inspiré dans CIRP.
Dans la suite de ce chapitre je vais essayer de décrire CIRP qui est encore en phase d’étude.
* : seamless Handoff :la définition absolue est un handoff ou il n’ y a pas de changements de capacité, la sécurité
ou la qualité de service. En pratique, un e dégradation est tout de même observée ; la définition pratique est que
les applications et les utilisateurs ne remarquent pas cette dégradation.
Samer Khalil
Mémoire
Page 64
2
QoS et macro mobilité
Auparavant, plusieurs propositions pour le support de la QoS dans les environnements
mobiles ont déjà été publiées. MRSVP par exemple propose pour diminuer les probabilités de
blocage. Cependant, cette technique nécessite des classes de service supplémentaires, des
changements majeurs à RSVP, une connaissance a priori des déplacements du mobile (profil
de mobilité) et beaucoup de signalisation.
D’autre part on vu au chapitre 2 qu’avec Mobile IP, la nouvelle localisation d’un mobile est
toujours signalée à son Home Agent. Ce dernier est ainsi averti de tous les déplacements des
mobiles qu’il gère. Ces opérations génèrent une grande quantité de signalisation. De plus, les
pertes de paquets pendant les handoffs peuvent être importantes puisque la procédure
d’enregistrement est longue, en particulier si le Home Agent se trouve à l’autre bout du
monde.
Pour MIR la même problématique se pose à nouveau, cette fois le réseau devra transporter les
informations de QoS en plus de celle de la mobilité. La signalisation grandit de plus en plus et
met de nouveau le réseau devant un grand défi.
3
QoS et Cellular IP
Avec Cellular IP, solution de micro mobilité, les déplacements des mobiles sont
complètement indépendants du réseau au delà du routeur passerelle et ne sont pas non plus
aperçu par ce dernier.
Avec CIRP, on essaye de séparer la gestion de QoS tout comme celle des déplacements du
reste de l’Internet. CIRP prendra en charge la garanti de QoS dans le réseau Cellular IP
indépendamment du protocole de gestion de QoS implémenté au delà du réseau cellular IP.
Ainsi lorsqu’un mobile se déplace entre les cellules au sein d’un réseau cellular IP la cession
de QoS établit entre la passerelle routeur et la destination est inchangée, les négociation des
paramètres de QoS sont faites dans la partie qui a connu un déplacement du Mobile
uniquement et ne sort pas du réseau cellular IP.
4
Description du protocole
Tout comme MIR, CIRP est l’extension de CLEP mais cette fois-ci pour les réseaux cellular
IP. Il est conçu pour gérer la QoS au sein de ce réseau et de séparer cette gestion de celle du
reste de l’Internet.
En effet CIRP agit de la même manière que MIR au niveau de la répartition des ressources
entre les différents utilisateurs (4.3): les politiques de partitionnement de la bande
passante(4.3.1), d’allocation des ressources (4.4) et le calcul des jetons (4.5) . Ces parties ont
été expliquées dans la description de MIR.
La modeste modification qu’on a introduit à MIR pour son application dans un réseau
Cellular IP est au niveau du handoff
Les 2 figures suivantes décrivent le déroulement d’un handoff dans un réseau cellular IP selon
que la station émettrice se déplace ou bien la réceptrice.
Samer Khalil
Mémoire
Page 65
Fig 34 - Handoff d’une station émettrice
Fig 35 Handoff d’une station réceptrice
Samer Khalil
Mémoire
Page 66
Le scénario d'un Handoff est illustré dans les 2 figures précédentes. La figure 34 décrit le
handoff d’une station émettrice, entre 2 cellules voisines ayant CLEP qui est installé.
Sans mobilité des terminaux, le problème revient simplement à faire des réservations sur un
réseau local avec CLEP.
Ici, MN1 avec une adresse IP X passe du point d’accès1 au point d’accès2.pendant une
session active de transmission de données. Le principe du semi-soft Handoff est utilisé dans
CIRP.Quand les mesures de niveau 2 indiquent que la connexion avec le cellule 2 est
meilleure que celle avec la cellule 1, le mobile déclenche une réservation passive avec la
cellule voisine avant de réaliser son handoff. Les points d’accès 1 et 2 négocient les
paramètres de QoS demandées par l’application. Au cours de ces négociation, si les
ressources dans la cellule 2 ne satisfont pas les besoins de l’application, la QoS est rejetée et
l’application continue en Best effort si le handoff actif est réalisé.
Apres ce handoff passif (décrit dans 4.2 ch 4) le handoff actif est déclenché suivant le principe
du semi-soft handoff de Cellular IP décrit dans 5.4 du chapitre 2
La différence avec MIR est claire, les négociations de QoS sont réalisées par les points
d’accès 1 et 2. Apres c’est du simple routage cellular IP qui permet le passage de l’application
d’une cellule a une autre.
5
Amélioration de CIRP
Afin d’améliorer la QoS offerte, nous distinguons deux paramètres supplémentaires :
o la vitesse des terminaux (rapide ou lente), mesurée en nombre de handoffs
pendant un certain temps,
o le type de connexion (dégradable ou non).
Nous différencions des types de flot privilégiés : dégradable et non dégradable. Par exemple,
un flux audio sera toujours compris par l’oreille humaine si une partie aléatoire de
l’information est supprimée. Un tel flux est un flux dégradable. De la même façon, il existe
des flux qui deviennent incompréhensibles si l’on retire une toute petite partie de
l’information. Ce sont les flux non dégradables.
Dans certains cas, il peut être intéressant de dégrader certains flux pour pouvoir en admettre
d’autres. Un flux doit donc être défini par un profil de perte. On peut donc dégrader
l’information à la source suivant ce profil et autant de jetons en moins à ce flux.
Nous définissons donc quatre types de flux privilégiés suivant que le mobile se déplace
rapidement ou lentement et suivant que la connexion est dégradable ou non. Puis nous
appliquons une politique différente pour chaque type de flux. Si un mobile est lent et si le
handoff ne peut être satisfait, la connexion doit être perdue. Cependant, si le mobile est
rapide, la connexion doit simplement se suspendre le temps que le mobile reste dans la cellule
ne pouvant offrir la QoS demandée.
Nous définissons donc la politique décrite figure 36 : nous ajoutons deux seuils au modèle
précédent (décrit dans MIR). Il y a trois états possibles. Dans le premier, toutes les
connexions sont acceptées. Dans le second, tous les handoffs sont acceptés. Finalement, dans
le dernier, seuls les handoffs rapides non dégradables sont acceptés.
Samer Khalil
Mémoire
Page 67
fig 36 Amélioration avec 4 seuils
Nous choisissons de privilégier les connexions rapides pour les deux raisons suivantes :
o une connexion lente utilise la bande passante pendant longtemps,
o une réservation passive lente risque de ne pas devenir active avant longtemps.
Samer Khalil
Mémoire
Page 68
Chapitre VI
Conclusion
L’objectif de ce travail était d’étudier les problèmes liés à la gestion de la qualité de
service dans des environnements Internet mobile et d’offrir une solution au réseaux cellular
IP. . Nous avons tout d’abord étudié les mécanismes disponibles permettant de fournir un
service de mobilité aux utilisateurs mobiles. Ces derniers utilisent le plus souvent des
interfaces de communication sans fil et souhaitent utiliser leurs applications de manière
transparente lorsqu’ils se déplacent d’un réseau IP à un autre. Au niveau des couches basses,
le protocole IEEE 802.11 fournit des solutions pour donner un accès au réseau via une
connexion sans fil mais ne permet pas de se déplacer dans l’Internet (c’est à dire en changeant
d’adresse IP). Cette dernière fonctionnalité est assurée au niveau IP grâce au protocole Mobile
IP qui a la particularité de fournir deux adresses IP à un nœud mobile : l’une pour
l’identification du nœud (l’adresse mère), et l’autre pour le routage (l’adresse temporaire ou
care of address). Ainsi, un nœud, lorsqu’il se déplace, conserve, toujours la même adresse IP
(celle sur son réseau mère) vis-à-vis des couches supérieures. Ceci rend la mobilité
géographique transparente aux couches supérieures.
Bien que MIP permette à des nœuds mobiles de se déplacer tout en continuant leur
communication, des pertes de paquets ou des dé-séquencements peuvent avoir lieu. Ces pertes
peuvent se faire ressentir au niveau des applications temps réel comme de la vidéo ou la voix
sur IP.
Cellular IP est un protocole de gestion de la micro mobilité (mobilité locale à un
domaine).pour répondre a ce problème. Il gère aussi les mouvements à l’intérieur d’un
domaine et les cachent au reste de ’Internet. Cellular IP s’inspire des systèmes cellulaires en
utilisant la pagination (localisation des mobiles) et en faisant la distinction entre mobiles
actifs et inactifs. L’information de routage est totalement distribuée dans tous les noeuds IP
cellulaires. Cellular IP est prévu pour fonctionner avec un grand nombre de mobile et gérer
les handoffs de manière optimisée. Cellular IP interagit avec MIP pour ce qui est de la
mobilité entre domaines.
Nous avons décrit une solution pour offrir des garanties de bande passante à des utilisateurs
qui restent dans un même réseau IP. Cette solution s’appelle CLEP (Controlled Load Ethernet
Protocol) et s’appuie sur l’architecture Intserv. En effet, ce protocole permet d’effectuer des
réservations par flots dans un réseau local. Ces réservations sont garanties en utilisant des
limiteurs de débit (token buckets) sur les interfaces de sortie des nœuds pour les flots de type
best effort et un protocole distribué sur tous les nœuds du réseau local qui permet de calculer
les paramètres des limiteurs de débit. La principale faiblesse de ce protocole est que tous les
noeuds du réseau doivent l’utiliser. Des études ont été faites sur ce protocole dans un
environnement filaire de type Ethernet partagé ainsi que dans un environnement sans fil IEEE
802.11. Grâce à CLEP, des flots spécifiques peuvent bénéficier d’un débit garanti dans un
environnement filaire ou sans fil (si le canal de communication est suffisamment bon) et
l’utilisation globale de la bande passante reste élevée même à forte charge. Cependant, ce
protocole agit sur un seul réseau local et ne permet pas de bénéficier d’une continuité de
qualité de service (de bande passante dans ce cas) lors des déplacements d’un mobile de
réseau local en réseau local.
Samer Khalil
Mémoire
Page 69
La courte durée de mon stage ne m’a malheureusement pas suffit pour commencer
l’implémentation. La solution proposée n’est en général qu’à sa phase de spécification et est
donc en constante évolution.
Dans la continuité de ce travail présenté on pourrait tout d’abord implémenter ce protocole
dans un environnement cellular IP. L’évaluation de ce protocole pourra se faire ensuite avec
des simulateurs de réseaux comme NS2.
Bonne chance à celui qui veut s’y mettre ! J
SK01
Samer Khalil
Mémoire
Page 70
Références bibliographiques
[Awd 97] D.O. Awduche, E. Agu, Mobile extensions to RSVP, IC3N 1997
[Badr 97] B.R. Badrinath,Anup Talukdar, IPV6+Mobile IP+MRSVP=Internet Cellular
Phone?Proceeding of the IWQOS 97 Mai 97
[Bla 98] Blake, Black, Carlson, Davies, Wang, Weiss, An Architecture for Differentiated
Services, RFC 2475, Dec98
[Bou 97] Bouyer M., Horlait E., Bandwidth Management and Reservation over Shared
Media, SFBSID’97, Fortaleza, Brasil, November 1997
[Brad 94] Braden R., Clark D., Shenker S., „Integrated Services in the Internet architecture:
An Oveview”, IETF Rfc 1633 1994
[Bra 97] Braden R., Zhang L., Berson S., Herzog S, Jamin S., "Resource ReSerVation
Protocol (RSVP) – Version 1Functional Specification", RFC 2205, Septembre 1997
[Bra 98] Braden B., Clark D., Crowcroft J., Davie B., Deering S., Estrin D., Floyd S.,
Jacobson V., Minshall G., Partridge C., Peterson L., Ramakrishnan K., Shenker S.,
Wroclawski J., Zhang L., Recommendations on Queue Managemeent and Congestion
Avoidance in the Internet, RFC 2309, Avril 1998
[Cam 98] Campbell A. T., Gomez J., Kim S., Turanyi Z., Wan C-Y., Valko A. “Design,
Implementation nd Evaluation of Cellular IP ” IEEE Personnal Communications,
Special Issue on IP –Based obile Telecommunications Networks June/July 2000
[Cam 99] A. Campbell, J. Gomez, C-Y. Wan, S. Kim, Z. Turanyi, A. Valko, “Cellular IP ”,
Internet EngineeringTask Force draft- ietf- mobileip-cellularip-00.txt, Décembre 1999.
[Cam 00] A. Campbell, J. Gomez, S. Kim, A. Valko, C-Y. Wan, Z. Turanyi, “Design,
Implementation, and Evaluation of Cellular IP ”, IEEE Personal Communications,
Août 2000.
[Deer 95] Deerind S.E., Internetwork Routing for Mobile Hosts Synopsium of Wireless Access
toDistributed computing, Columbia University Center for Telecommunications
Researchs Fev95
[Grand 00] Le Grand, Ben Othman, Horlait, Réservation de ressources dans un
environnement mobile avec MIR Mobile IP Reservation Protocole, CFIP 2000
Toulouse Oct 2000
[Gust 01] Gustafsson E., Jonsson A., Perkins C., Mobile IP Regional, draft- ietf- mobileip-regtunnel-04.txt Mars 2001
[Hei99] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assured Forwarding PHB
group", IETF RFC 2597, 1999.
Samer Khalil
Mémoire
Page 71
[Horl 99] E. Horlait, M. Bouyer, CLEP (Controlled Load Ethernet Protocol): Bandwidth
Management and Reservation Protocol for Shared Media, <draft- horlait-clep-00.txt>,
Juillet 1999
[Ind 98] J. Indulska, S. Cook, New RSVP extension to support computer mobility in the
internet, SICON 1998
[Ion 91] Ionais John , Ducamp Dan, Maguire Gerald Q., IP-based protocols for mobile
Internetworking Proceeding SIGCOMM91 Sept 91
[Jain 98] R. Jain et al., Mobile Internet Acces and QoS guarantees using Mobile IP and RSVP
with Location registers, ICC 1998
[Jac99] Jacobson V., Nichols K., Poduri K., "An Expedited Forwarding PHBgroup", IETF
RFC 2598, 1999.
[Mar91] Mankin A., Ramakrishnan K., Gateway Congestion Control Survey, IETF, RFC
1254, Août1991.
[Nic 99] Nichols, K., Jacobson, V., Zhang, L., "A two-bit Differentiated Services Architecture
for the Internet", IETFRFC 2638, 1999.
[Perk 96] harles E. Perkins, Mobile-IP, Ad-Hoc Networking, and Nomadicity, Compsac'96,
1996, http:/ww.svrloc.org/~charliep/
[Perk 98] Charles E. Perkins, Mobile IP : Design Principles and practices, Addison Wesley
Wireless Communicatio ns Series, 1998
[Ram 00] Ramjee R., La Porta T., Thuel S., Varadhan K., Chalgarelli L., IP micro-mobility
using HAWAII, Internet Draft, Draft- ietf- mobileip-hawaii-01.txt, Juillet 2000
[She 00] Z. Shelby, D. Gatzounas, A. Campbell, C-Y. Wan, “Cellular IPv6”, Internet
Engineering Task Force draft-shelby-seamoby-cellularipv6-00.txt, Novembre 2000.
[Sun 80] Sunshine, Postel, Adressing Mobile Hosts in the ARPA internet envirenment,
IEN135 , University of thouthern California Information Science Institue, Marina Del
Ray, California March 1980
[Tal 97] A. K. Talukdar, B. R. Badrinath, and A. Acharya. On accommodating mobile hosts
in an integrated services packet network. In Proceedings of the IEEE INFOCOM '97,
pages 1048-1055, April 1997.
[Talu 98] A.K. Talukdar, B.R. Badrinath, A. Acharya, Integrated Services packet Networks
with Mobile Hosts : Architecture and Performance, Journal of Wireless Networks,
1998
[Tera 89] Terakoa, Yokote, Tokoro Muse-IP: A Network Layer Protocol for Large
Distributed Systems ith Mobile Hosts, rapport technique SONY CSL SCSL-TR-89003, proceeding of the forth oing workshop on Computer communications June 1989
Samer Khalil
Mémoire
Page 72
[Tera 91] Teraoka, Yokote, Tokoro, Ip-based protocols for mobile internetworking
Transparency,Proceeding SIGCOMM91 Sept 91
[Val 00] A. Valko, “Cellular IP: A New Approach to Internet Host Mobility” 2000
[Wroc 97] J. Wroclawski, Specification of the Controlled-Load Network Element Service,
RFC 2211,Sep 97
[Wroc 97] Wroclawski, J., "The use of RSVP with IETF Integrated Services", RFC 2210,
1997.
[Yav 00] R. Yavatkar, D.Hoffman, Y. Bernet, F. Baker, M. Speer, RFC 2814, SBM (Subnet
Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802Style Networks, May 2000.
Internet Draft (Cellular IP)
A. G. Valko, A. T. Campbell, J. Gomez, "Cellular IP (old version)," Internet Draft,draftvalko-cellularip-00.txt, November 1998.
A. Campbell, J. Gomez, C-Y. Wan, Z. Turanyi, A. Valko, "Cellular IP," Internet
Draft,draft-valko-cellularip-01.txt, October 1999.
A. T. Cambell, S. Kim, J. Gomez, C-Y. Wan, Z. Turanyi, A. Valko, "draft- ietf- mobileipcellularip-00.txt", IETF mobile IP Working Group Document, December 1999.
A. T. Campbell, S. Kim, J. Gomez, C-Y. Wan, Z. Turanyi, A. Valko, "Cellular IP
Performance",draft-gomez-cellularip-perf-00.txt, October 1999.
Z. D. Shelby, D. Gatzounas, A. T. Campbell, C-Y. Wan, "Cellular IPv6"draft-shelbyseamoby-cellularipv6-00.txt, November 2000.
Samer Khalil
Mémoire
Page 73

Cellular IP avec Qualité de Service

Transcription

Documents pareils

page jaune

demande de reservation structure gonflable toboggan geant

Conditions de réservation

Inscription fete

Réalisation : DIAGONALE 40, rue Bonnel 69484 LYON Cedex

Offre Hôtel de Genève pour la Ferme de Gy

Fiche de réservation 2016 - Hôtel Le Belvédère à Vallon Pont d`Arc

CNSPF - 2016 - Traiteur Chevalier

uas chiche-kebab 23 aout 2015 fr

PROGRAMME D`ACTIVITES 2010