HAL Id: inria-00071886
https://hal.inria.fr/inria-00071886
Submitted on 23 May 2006
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of
sci-entific research documents, whether they are
pub-L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
l’état de noeud
Claude Chaudet, Isabelle Guérin Lassous
To cite this version:
Claude Chaudet, Isabelle Guérin Lassous. Routage QoS et réseaux ad-hoc : de l’état de lien à l’état
de noeud. RR-4700, INRIA. 2003. �inria-00071886�
a p p o r t
d e r e c h e r c h e
TH `EME 1
Routage QoS et r´eseaux ad-hoc : de l’´etat de lien `a
l’´etat de nœud
Claude Chaudet — Isabelle Gu´erin Lassous
N
◦4700
l’´
etat de nœud
Claude Chaudet , Isabelle Gu´
erin Lassous
Th`eme 1 — R´eseaux et syst`emes Projet Ares
Rapport de recherche n◦4700 — Janvier 2003 —15pages
R´esum´e :L’engouement suscit´e par la t´el´ephonie cellulaire laisse `a penser que l’utilisateur va devenir de plus en plus mobile. Les r´eseaux ad-hoc r´epondent `a ce besoin en ´eliminant le besoin d’infrastructure fixe pour communiquer. L’activit´e du groupe IETF Manet cr´e´e en 1996 montre que le d´eveloppement de ces r´eseaux sans fil et sans infrastructure est en plein essor. Parall`element `a ce ph´enom`ene, on assite `a un d´eploiement des services multim´edia aussi bien dans les r´eseaux dits grand public que dans les r´eseaux professionnels. Ce type d’applications est exigeant en terme de qualit´e de la transmission et l’on voit apparaˆıtre un r´eel besoin de garanties sur la qualit´e du service offert. Toutefois, les r´eseaux ad-hoc intro-duisent un grand nombre de contraintes dont il faut tenir compte lors de l’´elaboration d’un protocole de qualit´e de service. Dans cet article, apr`es avoir d´efini ce que nous entendions par qualit´e de service et avoir pr´esent´e les sp´ecificit´es des r´eseaux ad-hoc et leur impact sur les protocoles cherchant `a offrir des garanties aux applications, nous pr´esenterons une solution au probl`eme du routage avec qualit´e de service bas´ee sur l’´etat des mobiles dans le r´eseau.
node state
Abstract:The commercial success of cellular telephony prefigures that the user will become more and more mobile. Ad-hoc networks were designed in this purpose, freeing the user from the need of a fixed infrastructure to communicate. The activity of the MANET working group at the IETF shows that the deployment of these networks is in real expansion. At the same time, multimedia services are developing fast in the customer’s life as well as in the industrial world. These applications often require strong guarantees on the transmission quality. Ad-hoc networks introduce new problems that have to be addressed in order to provide an efficient quality of service solution. In this article, we will first define what the term ”quality of service” means to us. Then we will have a look at the specificities of the ad-hoc networks and their impact on QoS protocols. Finally, we will present a solution to the QoS routing problem based on the state of the network nodes.
Introduction
Depuis l’apparition et le grand succ`es commercial de la t´el´ephonie cellulaire, le d´eveloppement d’´equipements mobiles n’a cess´e de prendre de l’importance. Grˆace aux assistants person-nels et aux ordinateurs portables, l’utilisateur devient de plus en plus nomade. Dans un tel contexte il n’est pas surprenant de voir apparaˆıtre des solutions de communication sans fil de plus en plus performantes. En 1999, l’IEEE a standardis´e le protocole d’acc`es au m´edium radio 802.11 [fITTbS99] visant `a assurer la communication entre ordinateurs personnels uti-lisant le m´edium radio. Aujourd’hui, le protocole IEEE 802.11 a subi plusieurs ´evolutions et est devenu un standard. De nombreux constructeurs proposent maintenant des cartes d’interfaces inter-op´erables bas´ees sur cette norme.
Le protocole IEEE 802.11 a ´et´e con¸cu dans une optique d’utilisation administr´ee. Les terminaux communiquent entre eux et avec le r´eseau filaire par le biais d’une borne d’acc`es administrant une zone g´eographique. Faisant suite aux travaux effectu´es sur les packet radio networks dans les ann´ees 1980, des recherches ont d´ebut´e afin d’´etudier la possibilit´e de se passer de ces bornes d’acc`es et de former ainsi des r´eseaux mobiles totalement dynamiques et spontan´es. Il s’agit des r´eseaux ad-hoc.
Cette absence d’infrastructure fixe pose un certain nombre de probl`emes non triviaux. En particulier, afin d’assurer la transmission des informations d’un bout `a l’autre du r´eseau, les terminaux mobiles doivent avoir la capacit´e de retransmettre des informations, jouant ainsi le rˆole de routeurs. Cependant, les sp´ecificit´es du lien radio ainsi que la mobilit´e potentielle des utilisateurs rendent les protocoles de routage utilis´es dans les r´eseaux usuels peu performants. C’est pourquoi un groupe de travail de l’IETF travaille actuellement `a la standardisation d’un ou plusieurs protocoles de routage pour ce type de r´eseaux.
Le travail de ce groupe, nomm´e Manet1, s’inscrit dans un contexte de routage au mieux.
Cependant, l’attrait suscit´e par les applications multim´edia laissent penser que certaines applications pourraient tirer parti de certaines garanties qui pourraient ˆetre offertes par le r´eseau. Par exemple, garantir une borne sur le d´elai de transmission des paquets peut ˆetre profitable aux applications de t´el´ephonie ; garantir un d´ebit peut ˆetre n´ecessaire pour les applications de vid´eo `a la demande, etc. C’est pourquoi il semble important de s’inter-roger sur la meilleure fa¸con d’assurer une certaine qualit´e de service aux mobiles d’un tel r´eseau. Le terme “qualit´e de service” regroupe un grand nombre de concepts et de techniques compl´ementaires. Nous avons choisi ici de nous int´eresser au probl`eme sp´ecifique du routage avec qualit´e de service pour ces r´eseaux radio mobiles et sans infrastructure fixe car ce point soul`eve beaucoup de probl`emes auxquels il n’existe pas encore de solution satisfaisante.
En section1, nous essaierons de d´efinir de fa¸con claire et compl`ete ce que signifie le terme routage avec qualit´e de service : quels en sont les enjeux et les objectifs ? Puis, apr`es avoir pr´esent´e les contraintes introduites par les r´eseaux ad-hoc en section2, nous examinerons les diff´erentes approches pour le routage propos´ees `a ce jour en section3. Enfin, en section 4, nous pr´esenterons les principales caract´eristiques de la solution que nous proposons. Notam-ment, nous int´egrons dans ce protocole une connaissance de l’´etat des mobiles, qui permet
d’obtenir des informations sur le r´eseau plus r´ealistes qu’une connaissance bas´ee sur l’´etat des liens.
1
Objectifs du routage avec qualit´
e de service
Tout d’abord, il convient de pr´eciser ce que recouvre le terme “routage avec qualit´e de service”. Le routage au mieux consiste souvent `a rechercher le plus court chemin en terme de distance [FF62] ou de d´elai [Moy91] entre une source et une destination afin de transf´erer des donn´ees. Dans le cas du routage avec qualit´e de service, le but n’est pas simplement de trouver le meilleur chemin selon un certain crit`ere mais de trouver le meilleur chemin admissible. On ajoute un certain nombre de contraintes sur les routes afin de d´eterminer leur ´eligibilit´e. Par exemple, on peut vouloir rechercher une route disposant d’une certaine quantit´e de bande passante pour un trafic vid´eo. On peut vouloir rechercher une route assurant que les paquets seront re¸cus par la destination moins d’un certain temps apr`es leur ´emission par la source. Toute route satisfaisant un certain crit`ere quantitatif peut ˆetre qualifi´ee de route assurant une certaine qualit´e de service.
Pour d´efinir la qualit´e de service, il existe un certain nombre de crit`eres usuels bien iden-tifi´es : une application peut d´esirer obtenir des garanties sur le d´ebit des communications, sur le d´elai, le taux ou le profil de pertes, la gigue, etc. En revanche, chaque application a des besoins sp´ecifiques et seule l’application est consciente de ses besoins. Il est difficile de d´efinir globalement des niveaux de service. Les applications doivent pouvoir indiquer expli-citement, par exemple, quel d´elai maximal elles peuvent supporter. On voit alors apparaˆıtre une sp´ecificit´e du routage avec qualit´e de service. Les routes doivent ˆetre d´etermin´ees flux par flux et non plus destination par destination comme dans le routage au mieux. Il serait en effet inacceptable de conclure qu’il n’existe pas de route permettant de transmettre un flux d’une source `a une destination simplement parce qu’il existe d´ej`a une route reliant ces deux terminaux mais ne satisfaisant pas le crit`ere demand´e. De plus, assurer un routage par flux permet d’assurer un contrˆole plus fin des ressources du r´eseau. On peut d´ecider de supprimer un flux particulier sans couper totalement la communication entre deux mobiles. Par exemple, on peut scinder un trafic vid´eo en un flux principal et en plusieurs sous-flux am´eliorant le niveau de d´etail. Il est alors concevable de supprimer les flux secondaires lorsque des congestions apparaissent dans le r´eseau.
Il est aussi primordial de prendre en compte la disparition ou la faible fiabilit´e d’un lien. Dans les r´eseaux filaires, cette situation survient rarement. Les liens sont fiables et ne sont coup´es que lorsqu’un ´equipement tombe en panne. Il n’en est pas de mˆeme dans les r´eseaux ad-hoc. En effet, le simple fait d’utiliser le m´edium radio pour communiquer introduit une grande variation dans la fiabilit´e des liens. Les ondes radio sont extrˆemement sensibles `a leur environnement. Fermer une porte , par exemple, peut suffire `a couper un lien existant. D’autre part, les terminaux dans un r´eseau ad-hoc sont mobiles. En cons´equence, il est impossible de pr´evoir si un lien existant `a une certaine date sera toujours valide `a une date ult´erieure. Il est encore plus incertain qu’il conserve les mˆemes propri´et´es. Il s’agit ici d’une diff´erence importante par rapport aux r´eseaux filaires. La topologie du r´eseau
d´epend maintenant de l’environnement du r´eseau, sur lequel on ne peut pas agir. Dans ces conditions, il semble primordial de concevoir un m´ecanisme de maintenance des routes qui soit suffisamment performant pour que ces changements de topologie occasionnent une gˆene minimale pour les applications. De plus, les contraintes apport´ees lorsqu’on cherche `a assurer une certaine qualit´e de service rendent encore plus complexe ce m´ecanisme de maintenance. En effet, les applications concern´ees sont par nature moins tol´erantes vis-`a-vis de la perte momentan´ee de service que les application ´elastiques usuelles.
Enfin, il est aussi important d’assurer une certaine optimalit´e du processus de routage. Toutefois, quel est le crit`ere `a consid´erer lorsqu’on parle d’optimalit´e ? Doit-on rechercher le plus court chemin admissible, le chemin de plus faible d´elai, etc. ? Il semble ici important de garder comme objectif d’utiliser au mieux le r´eseau. Ceci peut se traduire par la maximisation de l’utilisation de la bande passante du r´eseau ou encore par la maximisation du nombre de clients servis. Encore une fois, si le routage plus faible d´elai (bas´e sur l’´etat des liens) [Moy91] semble donner de bons r´esultats dans des r´eseaux filaires cherchant `a offrir un service au mieux, il ne semble pas ´evident qu’il soit le meilleur choix ici Nous d´evelopperons ce point en section4.1.
Nous pouvons maintenant proposer une d´efinition du routage avec qualit´e de service : il s’agit du processus d’´etablissement et de maintenance de routes optimales (pour la paire communicante comme pour le r´eseau) satisfaisant un certain crit`ere sur la qualit´e de la transmission de donn´ees. Si l’on peut consid´erer que cet objectif sera bientˆot atteint dans les r´eseaux locaux filaires, les r´eseaux ad-hoc pr´esentent un grand nombre de sp´ecificit´es qui rendent la conception d’un tel algorithme difficile.
2
Contraintes introduites par les r´
eseaux ad-hoc
Les r´eseaux ad-hoc sont avant tout des r´eseaux radio. Les cartes d’interface sans fil pr´esentes sur le march´e implantent essentiellement le standard IEEE 802.11, en cons´equence les r´eseaux ad-hoc con¸cus actuellement sont bas´es sur ce standard. Mˆeme si ce protocole se comporte comme un lien Ethernet vis-`a-vis des couches sup´erieures, il poss`ede un certain nombre de sp´ecificit´es dont il faut tenir compte.
Tout d’abord, la propagation radio dans l’air est soumise `a bon nombre de contraintes sp´ecifiques. Nous avons d´ej`a entrevu au paragraphe pr´ec´edent les probl`emes de fiabilit´e dus `a l’environnement d’utilisation et `a la mobilit´e. Une variation a priori anodine dans l’environnement d’un mobile peut se traduire par la disparition d’un lien dans le r´eseau. La topologie peut donc ´evoluer de fa¸con impr´evisible. Il ne suffit pas de mesurer la qualit´e du signal re¸cu par un ´emetteur pour en d´eduire sa position et son mod`ele de mobilit´e. Si une telle strat´egie peut donner des r´esultats satisfaisants en espace libre, l’utilisation de terminaux radio dans des bˆatiments ne sera pas soumise aux mˆemes lois.
D’autre part, le m´edium radio est partag´e. Ce qui signifie que lorsqu’un mobile ´emet un signal, tous les mobiles dans un certain p´erim`etre ne pourront pas transmettre de donn´ees simultan´ement, sous peine de provoquer des interf´erences `a la r´eception. Si l’on consid`ere ce ph´enom`ene dans un r´eseau mobile, le d´eplacement d’un ´emetteur dans le r´eseau le conduira
probablement dans une zone o`u ses ´emissions empˆecheront d’autres mobiles d’´emettre. Par cons´equent, du fait de la mobilit´e des terminaux, la qualit´e des liens (en terme de bande passante et de d´elai) peut varier, encore une fois sans qu’il soit possible de le pr´evoir `a l’avance `a un coˆut raisonnable.
Le partage du m´edium radio est assur´e par le protocole d’acc`es au m´edium de 802.11. Ce protocole de type CSMA/CA a ´et´e con¸cu pour limiter les risques de collision entre des paquets de donn´ees, au prix du d´elai d’acc`es au m´edium. En effet, une collision est tr`es coˆuteuse dans un r´eseau radio puisqu’il est impossible `a l’´emetteur de se rendre compte au cours de la transmission qu’un paquet est brouill´e. Le seul moyen de d´etecter les collisions est d’utiliser des acquittements de paquets au niveau MAC. Pour se rendre compte du surcoˆut introduit par ce protocole d’acc`es au m´edium, consid´erons une transmission entre deux nœuds seuls dans leur r´eseau (afin de s’affranchir des possibilit´es de collisions), transmettre un paquet de 1000 octets `a un d´ebit de 10 Mb/s sur un m´edium Ethernet prendra 848 µs. Sur un lien 802.11 `a 11 Mb/s, la transmission du mˆeme paquet prendra 2122 µs ou 1954 µs selon le mode de transmission utilis´e2, soit plus de deux fois plus qu’Ethernet. En cons´equence,
les transmissions souffrent d’un d´elai nettement plus grand que leurs homologues filaires et la bande passante disponible pour les applications est moindre mˆeme si la bande passante effective est du mˆeme ordre de grandeur.
Afin de limiter les collisions entre deux transmissions, le protocole d’acc`es au m´edium IEEE 802.11 n’autorise qu’un seul ´emetteur `a transmettre dans une zone g´eographique d´efinie. Pour ce faire, lorsqu’un mobile veut ´emettre un paquet il commence pas scruter le canal radio afin de d´eterminer s’il est libre. Si le canal radio est occup´e, on remet la transmission `a plus tard. Cependant ce type de m´ecanisme pr´esente plusieurs d´efauts. Tout d’abord, il est difficile de localiser les autres mobiles d’un r´eseau. Les collisions surviennent lors de la r´eception du paquet, et non lors de l’´emission. Or, l’´emetteur refuse de transmettre un paquet si le m´edium est occup´e. Ceci peut conduire `a des situations comme celle de la figure 1. Dans cet exemple, connu comme le probl`eme de la station expos´ee, les deux ´emetteurs pourraient transmettre en mˆeme temps sans risque de collision. D’un autre cot´e, les interf´erences provoqu´ees par des transmissions radio s’ajoutent. Prenons par exemple la situation repr´esent´ee en figure2. Si les transmissions des mobiles hors de port´ee ne gˆenent pas individuellement la transmission du mobile A, l’ajout des bruits provoqu´es par ces transissions provoquera une interf´erence `a la r´eception par B. Ce m´ecanisme peut donc dans certaines situations conduire `a une sous-utilisation du m´edium radio, comme `a une situation de collision entre transmissions.
Les r´eseaux ad-hoc actuels, bas´es sur la norme 802.11, souffrent donc de la versatilit´e et de la faible bande passante du m´edium radio, du d´elai important introduit par le protocole d’acc`es au m´edium, et de l’impossibilit´e d’utiliser des techniques de d´etection de collision qui conduit soit `a l’utilisation d’un m´ecanisme al´eatoire coˆuteux, soit `a une perte importante de paquets. Toutes ces contraintes sont pr´esentes quel que soit le type de routage effectu´e. Il faut donc en tenir compte lorsqu’on souhaite concevoir un protocole, qu’il permette de
2Paquets UDP de 1000 octets transmis avec ou sans ´echange RTS-CTS — Les param`etres de la couche
A B C D
Fig.1 – Probl`eme de la station expos´ee
✂✁☎✄✆✝✟✞✡✠✂✞✡☛☞✁☎✌✍✌✍✎✑✏✟✒☛☞✓✂✆✒✁☎✏ ✔ ✏✆✞☎✄✕✝☎✄✞☎✏☞☛✞ ✖ ✁☎✌✡✌✍✎✑✏✟✒☛✓✂✆✒✁☎✏ B A
Fig.2 – Interf´erences additives
garantir une certaine qualit´e de service ou non. Par la suite, on suppose que le protocole assurant la transmission aux niveaux physique et liaison est le protocole 802.11, car il s’agit du seul protocole actuellement implant´e dans des cartes d’interface.
3
Des algorithmes adapt´
es ?
Les r´eseaux ad-hoc sont donc construits sur un m´edium changeant et peu fiable, avec un fort d´elai de transmission de paquets et une bande passante relativement faible compte tenu du surcoˆut du protocole d’acc`es au m´edium. Afin de s’adapter `a ces contraintes, de nombreux travaux ont ´et´e r´ealis´es dans le domaine du routage, principalement sans qualit´e de service.
3.1
Routage au mieux
Le groupe Manet de l’IETF est actuellement en passe de standardiser un ou plusieurs protocoles de routage au mieux pour les r´eseaux ad-hoc. Parmi toutes les propositions, deux approches s’opposent : le routage r´eactif et le routage proactif.
Dans un protocole de routage r´eactif, les mobiles ne conservent pratiquement aucune information sur la topologie globale du r´eseau. Seules sont stock´ees les informations sur les routes actives. Les routes sont construites `a la demande et sont d´etruites lorsqu’elles ne sont plus utilis´ees.
Dans un protocole de routage proactif, la topologie du r´eseau est connue de tous les mobiles. Les routes sont disponibles imm´ediatement mais, en contrepartie, il faut diffuser r´eguli`erement des informations sur les changements de topologie du r´eseau.
Les protocoles r´eactifs g´en`erent a priori un volume plus faible de signalisation mais en contrepartie engendrent un d´elai lors de la construction (ou de la reconstruction) des routes et produisent plus difficilement des routes optimales (quel que soit le crit`ere). Les protocoles proactifs disposent en permanence d’une route pour chaque destination dans le r´eseau mais g´en`erent en contrepartie un volume de signalisation important. De nombreux d´ebats ont lieu sur la performance des deux approches. Dans [JV00], une comparaison des deux approches
montre que la performance de chacune d´epend ´enorm´ement des conditions d’utilisation. Les protocoles construisant des routes par diffusion sont plus performants que leurs concurrents lorsque le nombre de routes actives est faible ou lorsque la mobilit´e dans le r´eseau est ´elev´ee. Il existe par ailleurs une approche de routage hybride. Dans ce cas de figure, le routage est proactif jusqu’`a un certain nombre de sauts fix´es puis r´eactif ensuite. Ainsi, chaque nœud connaˆıt la topologie avoisinante jusqu’`a une certaine distance et effectue une recherche de route au-del`a. On peut aussi noter l’existence de protocoles g´eographiques qui utilisent des informations de localisation fournies par un syst`eme GPS pour affiner le routage. Il faut noter que ce syst`eme fournit une localisation en deux dimensions et est donc peu pr´ecise `a l’int´erieur de bˆatiments. De plus, il n’y a pas ´equivalence entre distance physique et connectivit´e radio.
De nombreuses optimisations ont ´et´e r´ealis´ees afin de r´eduire le volume de signalisation ´echang´e, le d´elai de construction de routes, etc. Plus de 45 protocoles de routage ont ´et´e propos´es jusqu’ici3Les protocoles r´eactifs AODV [PRD02] et DSR [JMHJ02] et les protocoles
proactifs OLSR [JMQ+02] et TBRPF [OLTB02] ont ´et´e retenus et sont maintenant les
derniers en comp´etition pour la standardisation `a l’IETF.
AODV implante un routage r´eactif `a la demande alors que DSR adopte une approche de routage par la source. La principale diff´erence entre les deux approches r´eside dans la technique de stockage des informations de routage. Dans AODV, chaque nœud connaˆıt, pour chaque destination avec laquelle il communique le saut suivant sur la route alors que dans DSR, la source stocke toute les informations et inclut la route dans l’entˆete des paquets de donn´ees.
OLSR et TBRPF sont deux protocoles de routage bas´es sur l’´etat des liens. Chaque mobile calcule, pour toute destination dans le r´eseau, le meilleur chemin `a emprunter en terme de nombre de sauts et stocke le saut suivant. Les diff´erences fondamentales entre les deux protocoles r´esident dans la mani`ere de propager les informations de topologie. L`a o`u OLSR utilise une ´election de nœuds particuliers pour limiter l’impact des diffusions, TBRPF ne diffusent que les changements dans la topologie du r´eseau plutˆot que la topologie compl`ete. Toutefois, toutes ces approches souffrent de certaines faiblesses dues aux al´eas de la propagation radio. Dans [LNT02], les auteurs mettent en avant le fait que, avec le protocole 802.11, les paquets ´emis en diffusion (mises `a jour de topologie, recherches de route . . .) n’ont pas les mˆemes propri´et´es que les paquets transmis en point `a point. Ces paquets sont transmis `a un d´ebit faible (2Mb/s). En cons´equence, ils peuvent atteindre des distances plus ´elev´ees que les paquets de donn´ees transmis `a 11Mb/s. Les information sur le voisinage des nœuds peuvent donc ˆetre erron´ees. Ceci peut avoir un impact important sur les performances des protocoles de routage.
D’autre part, les paquets envoy´es en diffusion ne sont ni prot´eg´es par un ´echange RTS-CTS, ni acquitt´es. Des collisions peuvent survenir fr´equemment entre ces paquets. Ceci conduit tr`es vite `a de nombreuses pertes de paquets de signalisation lorsque le r´eseau devient dense. Il semble donc assez peu recommand´e d’´etablir un protocole de routage reposant uniquement sur des diffusions de paquets. Toutefois, compte tenu du caract`ere dynamique
3
du r´eseau, il est difficile de se passer de la diffusion. C’est pourquoi, en d´epit du manque de fiabilit´e de cette approche, les quatre principaux protocoles de routage pour r´eseaux ad-hoc se basent des diffusions de paquets pour la d´ecouverte de route ou pour la propagation d’informations topologiques. TBRPF utilisent un m´ecanisme de diffusion avec acquittement n´egatif permettant de d´etecter certaines pertes de paquets mais cette approche ne r´esout pas les probl`emes de validit´e de l’information li´es `a l’allongement du temps de propagation de ces informations.
Pour palier `a ce probl`eme, et assurer dans une certaine mesure une diffusion fiable, on pourrait imaginer ´elire un nœud privil´egi´e parmi son voisinage `a qui l’on enverrait les pa-quets de signalisation en mode point-`a-point, les autres nœuds du voisinage “´ecoutant” cette transmission. Cette approche pr´esente, en plus de la protection relative des paquets de signa-lisation, l’avantage de permettre une transmission rapide de ces paquets et une transmission `a la mˆeme port´ee que les paquets de donn´ees. Le voisinage calcul´e par la transmission de paquets de signalisation correspond alors bien au voisinage `a un saut r´eel. Toutefois, ce mode de fonctionnement est tr`es consommateur en batteries (les cartes d’interfaces devant traiter un grand nombre de paquets inutiles) et semble peu performant lorsque la mobilit´e est trop importante pour ´elire un voisin privil´egi´e.
Une autre solution consisterait `a envoyer syst´ematiquement les paquets de signalisation les plus importants en mode point `a point. Cette approche est cependant tr`es consommatrice en d´ebit et est peu adapt´ee `a la mobilit´e. Il faut en effet prendre en compte les apparitions et disparitions de voisins, et on ne profite plus de la diffusion locale lorsque le r´eseau est dense.
On peut enfin imaginer utiliser plusieurs canaux de communication. Un canal serait d´edi´e `
a la signalisation et l’autre aux donn´ees. Cette approche n’est cependant pas envisageable partout, la l´egislation de certains pays, comme le Japon, ne permettant pas d’utiliser plus d’un canal. Elle interdit aussi la coexistence de plusieurs r´eseaux.
Ces techniques ne sont cependant que des correctifs et ne r`eglent en aucun cas les probl`emes pos´es par l’utilisation en mode ad-hoc d’un protocole initialement con¸cu pour des r´eseaux administr´es. 802.11 semble, en effet ˆetre assez peu adapt´e `a une utilisation mobile et sans infrastructure. Toutefois, lorsque les r´eseaux ad-hoc auront ´evolu´e et seront devenus commercialement viables, il sera possible de concevoir des cartes d’interface d´edi´ees.
3.2
Etat de l’art sur le routage QoS dans les r´
´
eseaux ad-hoc
Les travaux publi´es concernant le routage avec qualit´e de service reposent beaucoup sur les protocoles de routage du groupe Manet. En effet, d’une part les travaux effectu´es en routage au mieux peuvent et doivent aider `a concevoir un protocole de routage qualit´e de service efficace. D’autre part, il est important de pr´evoir l’inter-op´erabilit´e des deux types de routage. Un certain nombre de recherches ont ´et´e men´ees dans le domaine du routage avec qualit´e de service d´edi´e aux r´eseaux ad-hoc.
Les r´eseaux radio 802.11 disposent d’une bande passante limit´ee, or la recherche de routes par diffusion (AODV, DSR) est tr`es coˆuteuse en terme de bande passante car elle n´ecessite de nombreux ´echanges de messages. C’est pourquoi dans [CN99], les auteurs du
protocole Ticket based probing proposent de r´eduire ce coˆut en associant `a chaque demande de route un certain nombre de tickets en fonction de l’importance de la recherche. Les tickets repr´esentent le nombre de routes `a explorer en parall`ele. Plus une requˆete contient de tickets, plus elle aura de chances d’aboutir mais plus la recherche d’une route admissible consommera de bande passante. Un certains nombre de travaux ont ´et´e effectu´es `a partir de ce protocole. Les auteurs de [RHZ00], [LTWS01] cherchent `a d´eterminer le bon nombre de tickets `a associer `a une requˆete et dans [LTWS01] ils proposent de consid´erer tous les chemins trouv´es par la recherche de route afin de faire du routage multi-chemins. Ce type d’approche peut devenir tr`es int´eressante d`es lors qu’elle serait coupl´ee `a un m´ecanisme de localisation g´eographique des mobiles permettant de d´eterminer, par exemple, dans quelle direction envoyer les requˆetes de route ou, au contraire, de couvrir une grande aire avec peu de messages.
Le protocole de routage au mieux ABR [Toh97] a introduit la notion de stabilit´e des routes. Il s’agit, en privil´egiant les terminaux peu mobiles, de limiter la fr´equence des re-construction de routes. C’est aussi ce que pr´econisent les auteurs de CEDAR ([SSB99]), un algorithme de routage avec qualit´e de service reposant sur l’´election dynamique d’un cœur de r´eseau stable approximant un sous-ensemble dominant minimum. Ce cœur de r´eseau, re-lativement stable, est en charge du routage et de la propagation des informations sur l’´etat des liens permettant de contrˆoler l’admission des requˆetes de routes avec qualit´e de service. Ce type de m´ecanisme permet de confier la tˆache d’administration du r´eseau aux nœuds qui semblent les plus `a mˆeme de la r´ealiser.
Par ailleurs, certaines propositions ([Lin01], [ZSC02]) visent `a construire des routes poss´edant une certaine qualit´e de service au dessus d’un protocole d’acc`es au m´edium fonc-tionnant en multiplexage temporel (TDMA). Leur but est essentiellement de trouver une politique d’allocation d’unit´es de temps permettant de faire cohabiter plusieurs trafics avec qualit´e de service. Ils ne correspondent pas aux r´eseaux bas´es sur la norme 802.11 consid´er´es ici.
Les r´esultats obtenus par les protocoles TBP et CEDAR montrent qu’il est possible d’obtenir des bonnes performances en terme d’acceptation (rapport entre le nombre de requˆetes accept´ees et le nombre de requˆetes totales) et de nombre de messages envoy´es. Les simulations men´ees dans [SSB99] s’int´eressent `a la recherche de routes ayant suffisamment de bande passante, tandis que les simulations r´ealis´ees dans [CN99] sont bas´ees sur des recherches de routes ayant de faibles d´elais. Les auteurs ´etudient aussi l’impact de la mobilit´e sur le taux d’acceptation lors de la reconstruction de routes et des d´elais n´ecessaires pour reconstruire ces routes. Les protocoles comme CEDAR ou TBP construisent des routes r´epondant `a un certain crit`ere (d´elai ou autre) mais les auteurs n’indiquent pas comment ils maintiennent des informations sur l’´etat des liens ou comment ils les utilisent pour construire leurs routes. Or ces informations sont fondamentales pour la mise en place d’un protocole de routage avec qualit´e de service puisque l’acceptation ou le refus de requˆetes sera bas´e sur ces informations. Il nous a donc sembl´e important de d´eterminer pr´ecis´ement les informations `a utiliser dans un tel protocole ainsi que de clarifier la maintenance de ces informations. Dans
la section4, nous pr´esentons un protocole de routage avec qualit´e de service bas´e sur l’´etat des mobiles et non plus sur l’´etat des liens comme dans TBP et CEDAR.
4
Vers un routage r´
eactif bas´
e sur l’´
etat des mobiles
4.1
De l’´
etat de lien vers l’´
etat de nœud
Les protocoles de routage filaire de type ´etat de lien reposent sur la transmission d’in-formations sur le d´elai des liens dans le r´eseau. Cependant, le mode de fonctionnement d’un r´eseau radio est diff´erent d’un r´eseau filaire. Si l’on peut parler de liens lorsqu’on cherche `a d´eterminer la connectivit´e d’un r´eseau, cette approche est insuffisante dans un r´eseau ad-hoc car les nœuds ´emettent en diffusion locale. Ainsi, une ´emission sur un lien va avoir un impact sur la capacit´e des autres liens du voisinage, comme le montre le sc´enario de la figure3.
A B C D A B C D E
Fig.3 – Si en filaire, l’utilisation d’un switch permet d’isoler des liens, en radio, le m´edium est toujours partag´e
✂✁☎✄✆✝✄✞✟✆✡✠☎✄☛☞✍✌✏✎✆
A B C D E
✑✒✁☎☛✎✓✝☞
Fig.4 – Une chaˆıne de nœuds sans fil n’est pas un bus
Le m´edium radio n’a cependant pas le comportement d’un bus classique. Dans un r´eseau multi-sauts, si deux nœuds sont voisins, ils n’ont pas forc´ement le mˆeme ensemble de voisins. Par exemple, sur la figure4, les nœud A et B sont voisins et le nœud C fait partie de l’en-semble des voisins de B mais pas de celui de A. La relation de voisinage n’est pas transitive comme sur un bus usuel. C’est pourquoi, si les r´eseaux filaires sont souvent repr´esent´es pas
des graphes classiques, les r´eseaux ad-hoc correspondent plutˆot `a un mod`ele d’hypergraphe
[Ber99] dans lequel chaque hyperlien repr´esente un nœud du r´eseau et l’ensemble de son
voisinage `a un saut. On peut alors affecter une capacit´e `a chaque hyperarˆete `a partir des informations sur l’´etat des mobiles qui le composent.
✂✁✂✁☎✄✝✆✝✞✟ ✠✂✂✁✡✄✆✝✞✟ B A H G C D F E ☛☞✂✌✎✍✑✏✒✓✍✑✔ ✒✓✍✑✔✖✕✌✎✗✑✏✘✙✂✍✛✚ ✜ ✗✣✢✖✢✥✤✛✔✛✓✜✝✦✘✓✗✑✔
Fig.5 – Hyperliens associ´es `a certains nœuds d’un r´eseau ad-hoc
L’exemple de la figure5repr´esente un r´eseau ad-hoc simple. Les trois zones repr´esent´ees en pointill´es correspondent aux hyperliens associ´es aux sommets A, B et C. Deux transmis-sions ont lieu dans le r´eseau : B communique avec D `a un d´ebit de 750 kb/s et C communique avec E `a un d´ebit de 500 kb/s. Mˆeme si le nœud A ne prend part `a aucune communication, la pr´esence dans son voisinage de la transmission du nœud C va avoir un impact sur le d´ebit maximum dont peut disposer A. La communication se r´ealise donc dans l’hyperlien associ´e `
a A et C
Il est imp´eratif pour chaque nœud du r´eseau de connaˆıtre l’´etat des mobiles dans son hyperlien si l’on veut garantir une certaine qualit´e de service. C’est pourquoi nous proposons de baser notre protocole de routage et le contrˆole d’admission associ´e sur l’´etat des mobiles du voisinage (donc des hyperliens) plutˆot que sur l’´etat des liens `a proprement parler.
Dans [CGL02], nous pr´esentons un m´ecanisme de r´eservation de bande passante bas´e sur l’´etat des mobiles du voisinage. Dans ce m´ecanisme, un mobile, avant d’accepter une requˆete de bande passante, doit d´eterminer si le canal radio environnant a la capacit´e de transmettre un tel flux. Le terminal peut connaˆıtre le d´ebit maximal auquel lui et chacun de ses voisins peut ´emettre (d´ependant principalement de la version du protocole utilis´ee). Il peut aussi, si chaque mobile transmet r´eguli`erement ces informations `a tous ses voisins, ´evaluer la quantit´e de bande passante utilis´ee par ses ´emissions et celles de ses voisins.
En fonction de ces donn´ees, le mobile est capable de d´eterminer si l’ajout d’un trafic provoquera dans son voisinage un d´epassement de la capacit´e du canal ou non. Il peut alors d´ecider s’il accepte ou refuse une requˆete de r´eservation, en sachant si ce nouveau trafic entrera en conflit avec ses trafics existants ou ceux de ses voisins. Toute la difficult´e est
alors de d´eterminer pr´ecis´ement les interactions entre les mobiles. En effet, il est difficile de d´eterminer quel ensemble de voisins sont affect´es par les ´emissions d’un mobile particulier d`es lors qu’on consid`ere les interf´erences entre transmissions distantes. En effet, l’exemple5
et le mod`ele d’hypergraphe pr´esent´e est bas´e sur la connaissance du voisinage `a un saut des mobiles. Or, deux communications ´eloign´ees peuvent interf´erer entre elles et donc conduire `a un partage du m´edium radio. La difficult´e est donc de d´efinir pour chaque nœud son hyperarˆete associ´ee, c’est-`a-dire l’ensemble des mobiles communiquant ou interf´erant avec lui. Nous verrons en section4.2que c’est un probl`eme difficile.
Ce m´ecanisme est destin´e `a r´esoudre le probl`eme de la r´eservation de bande passante. Toutefois, d`es lors qu’on souhaite fournir des garanties sur le d´elai des transmissions, les interactions entre les liens sont peu claires. En effet, `a cause du caract`ere al´eatoire du protocole d’acc`es au m´edium, il est semble difficile de pr´evoir l’impact qu’aura l’ajout d’un nouveau flux sur le d´elai de transmission des flux existants. C’est pourquoi, nous ne nous int´eresserons dans un premier temps qu’au probl`eme de la r´eservation de bande passante.
Dans la suite de cet article, nous proposons un m´ecanisme d’´evaluation de la bande passante disponible dans un voisinage de chaque nœud puis nous d´ecrirons un protocole de routage avec qualit´e de service bas´e sur cette connaissance.
4.2
Le probl`
eme de l’´
evaluation des ressources disponibles
Une ´enorme difficult´e, lorsqu’on souhaite fournir des garanties sur une ressource consiste `
a ´evaluer la quantit´e de ressources disponibles. Comment, en effet garantir un niveau de service si l’on ne connaˆıt pas cette information. La plupart des protocoles propos´es occultent cet aspect qui est pourtant fondamental. Or, estimer la quantit´e de ressources disponible est impossible si l’on ne consid`ere pas l’environnement des nœuds.
Si l’on veut fournir des garanties sur la bande passante disponible sur une route, il faut pouvoir ´evaluer correctement le d´ebit maximal que peut transmettre chaque nœud interm´ediaire. Or, les cartes d’interface 802.11 ne fournissent pas aux couches sup´erieures des informations pr´ecises sur les communications en cours dans le r´eseau. Les seules informations sur l’utilisation du canal dont peut disposer un protocole de niveau 3 ou sup´erieur sont la bande passante utilis´ee par les ´emissions du nœud concern´e et ´eventuellement le d´ebit des communications de ses voisins directs. Toutefois, il n’est pas possible d’´evaluer la quantit´e de ressources consomm´ees par les trafics des mobiles `a plus d’un saut. Le rapport signal sur bruit fourni par les cartes d’interface ne permet pas d’effectuer un calcul satisfaisant. Pourtant ces trafics peuvent avoir une influence importante sur la bande passante disponible, comme le montre le sc´enario de la figure6. Dans cette simulation effectu´ee sous NS-2, deux paires de nœuds communiquent de mani`ere `a saturer le canal. Les deux paires sont ´eloign´ees d’une distance sup´erieure `a la port´ee de communication. On constate que lorsque les deux ´emissions ont lieu en mˆeme temps, les ´emetteurs se partagent le canal. Il existe donc une zone d’interf´erence au-del`a de la port´ee de communication. Sous NS-2 la zone d’interf´erence a une taille double de la zone de communication. Les exp´erimentations que nous avons r´ealis´ees montrent qu’en espace libre, il s’agit bien approximativement de la bonne valeur,
et ceci mˆeme dans la version b du protocole 802.114qui repose sur une couche physique `a ´etalement de spectre (DSSS). A B C D 0 0.5 1 1.5 2 2 4 6 8 10 12 14 16 18 20 Bande passante (Mb/s) Temps (s) A−>B C−>D Total
Fig.6 – Illustration du ph´enom`ene d’interf´erences
De fa¸con analogue, on consid`ere souvent qu’on peut avoir une estimation du d´elai de transmission entre deux mobiles en utilisant des requˆetes ICMP mesurant le d´elai d’aller-retour d’un paquet. Mesurer le d´elai r´eel de transmission d’un paquet est difficile car il faut synchroniser les horloges des correspondants. Si la m´ethode de l’aller-retour peut donner une approximation correcte en filaire, l’incertitude est beaucoup plus importante en sans fil. Les “liens” radio peuvent ˆetre fortement asym´etriques `a cause de la nature mˆeme du m´edium. Prenons l’exemple de la figure7. Le nœud A n’a aucun voisin avec qui il rentre en contention. Il peut donc transmettre un paquet `a tout moment. En revanche, son correspondant, le nœud B se trouve dans une zone perturb´ee par des ´emissions concurrentes. La r´eponse `a la requˆete ICMP ´etant un paquet totalement dissoci´e de la requˆete pour les couches 802.11 sous-jacentes, avant de renvoyer un paquet, B devra attendre que le m´edium soit libre. Le d´elai de A vers B pourra donc ˆetre beaucoup plus faible que le d´elai de B vers A. Le d´elai est lui aussi une notion qu’il semble plus r´ealiste d’associer aux nœuds du r´eseau car il d´epend fortement de l’environnement des mobiles.
d1
d2 > d1
A B
C
D
Fig.7 – En radio, le d´elai est asym´etrique
Il semble donc difficile en se basant uniquement sur la perception d’un mobile de connaˆıtre son environnement. L’utilisation d’un protocole de signalisation permettant aux nœuds d’ob-tenir des informations sur leur voisinage semble ˆetre profitable d`es lors qu’on souhaite offrir des garanties dans un r´eseau ad-hoc.
4.3
Connaissance du voisinage ´
etendu
Dans [CGL02], nous avons propos´e un premier m´ecanisme pour apporter aux mobiles une connaissance du voisinage ´etendu. Dans cette section, nous d´etaillons et expliquons plus pr´ecis´ement les choix effectu´es pour ce m´ecanisme.
Apporter de la connaissance aux nœuds sur l’´etat des mobiles de leur voisinage peut se faire en diffusant p´eriodiquement des paquets de signalisation (que nous nommerons Hello par la suite). Si ces paquets contiennent des informations sur le nœud ´emetteur et sur tous les nœuds de son voisinage jusqu’`a n sauts. Ce m´ecanisme permet alors de propager des informations `a n + 1 sauts.
Afin de permettre un contrˆole d’admission relativement fiable dans le cadre d’un m´ecanisme de r´eservation de bande passante, il est int´eressant de transmettre des informations sur la capacit´e de chaque nœud `a ´emettre et sur la quantit´e de bande passante qu’il consommera. Si tous les nœuds propagent cette information dans tous les hyperliens auxquels ils appar-tiennent, il est alors possible pour chaque nœud d’estimer la bande passante restante dans son hyperlien.
Il est cependant difficile d’obtenir une estimation exacte de la bande passante disponible dans le voisinage ´etendu. En effet, plusieurs ph´enom`enes viennent perturber le partage de la bande passante.
Tout d’abord, lorsque n ´emetteurs `a port´ee de communication sont en comp´etition pour l’acc`es au m´edium, la bande passante utilisable au niveau application par chaque ´emetteur est sup´erieure `a la bande passante qu’obtiendrait un seul ´emetteur divis´ee par n [GK00]. En effet, avant d’´emettre chaque nœud doit s’assurer que le canal radio a ´et´e libre pendant un certain temps al´eatoire. Lorsque plusieurs ´emetteurs sont en concurrence, ces attentes ont lieu en parall`ele, ce qui permet de r´eduire globalement le surcoˆut du protocole d’acc`es au m´edium. Toutefois, on ne peut augmenter ind´efiniment le nombre d’´emetteurs sans risquer de collisions. Dans ce cas, les d´elais sont `a nouveau allong´es car le protocole 802.11 retransmet les paquets perdus.
Dans un r´eseau multi-sauts, il y a de plus un ph´enom`ene d’interf´erences qui diminue le d´ebit atteignable par chaque station. En effet, dans 802.11, lorsqu’un mobile d´esirant ´emettre capte un signal sur le m´edium qu’il ne peut d´ecoder (une transmission distante par exemple), il diff`ere sa transmission plus longuement que s’il captait un signal qu’il pouvait d´ecoder (utilisation de EIFS `a la place de DIFS) afin de ne pas brouiller l’acquittement de cette transmission, augmentant ainsi le surcoˆut de l’acc`es au m´edium.
Ces deux ph´enom`enes antinomiques dans 802.11 (recouvrement des attentes, ajout de EIFS) montrent qu’il est tr`es complexe d’´evaluer exactement la capacit´e du m´edium. En l’´etat actuel de nos connaissances, il semble difficile d’obtenir un m´ecanisme distribu´e, peu coˆuteux, qui permette d’obtenir une information pr´ecise sur cette capacit´e. Par cons´equent, un m´ecanisme de diffusion des paquets Hello, contenant des informations sur la capacit´e et la bande passante consomm´ee des nœuds, sur une certaine distance (en nombre de sauts), nous semble ˆetre une approximation raisonnable de la capacit´e restante sur chaque nœud. Il est int´eressant de noter que l’´evaluation ainsi faite donne une sous-´evaluation de la bande passante restante. Si cette sous-´evaluation ne conduit pas `a une utilisation optimale de la
bande passante, elle permet n´eanmoins d’assurer aux requˆetes accept´ees une bonne qualit´e en terme de bande passante.
Il reste maintenant `a d´eterminer la distance sur laquelle les informations de bande pas-sante et de voisinage seront diffus´ees. Nous tombons l`a encore sur des ph´enom`enes op-pos´es, puisque d’une part la propagation des paquets Hello sur une trop longue distance peut conduire `a un surcoˆut important de signalisation et `a une maintenance d’informations p´erim´ees ´etant donn´e le d´elai n´ecessaire pour propager l’information, et d’autre part une propagation sur une distance trop courte peut donner une sous-approximation de la capacit´e des hyperliens du r´eseau et donc donner de mauvaises garanties sur les routes construites.
La figure8montre une propagation d’informations sur une distance de deux sauts. Jouer sur la fr´equence d’envoi des paquets Hello permet aux nœuds d’obtenir des informations plus ou moins r´ecentes : plus la fr´equence sera ´elev´ee, plus les informations sur le voisinage seront r´ecentes. De plus une fr´equence ´elev´ee permet de propager des informations r´ecentes sur une plus longue distance qu’une fr´equence faible. En contrepartie, une fr´equence ´elev´ee introduit une signalisation importante.
A Hello(A,B) E Hello(E,B) B Hello(A,B,C,E) C Hello(C,B,D) F Hello(F,D) D Hello(D,C,F)
Fig.8 – Propagation d’informations sur le voisinage jusqu’`a 2 sauts
Les protocoles comme CEDAR ou TBP utilisent des informations sur les liens directs (`a un saut) pour chaque nœud. Or comme le montre la figure6, deux mobiles se situant `a plus d’un saut radio l’un de l’autre partage la bande passante. Il nous semble donc important d’´elargir la connaissance du voisinage `a plus de un saut sans pour autant augmenter de mani`ere drastique la signalisation. C’est pourquoi nous proposons, dans un premier temps de propager les informations de bande passante `a deux sauts, ce qui donne une meilleure connaissance du voisinage que dans les protocoles actuellement propos´es. Chaque mobile a donc p´eriodiquement une connaissance sur la bande passante consomm´ee de tous les mobiles qui se trouvent `a deux sauts radio de lui. Chaque mobile peut donc maintenant utiliser cette information pour faire un contrˆole d’admission sur les requˆetes qu’il peut ´eventuellement router. Dans la section suivante, nous proposons un protocole de routage qui utilise ce contrˆole d’admission bas´e sur cette connaissance.
4.4
Un routage r´
eactif bas´
e sur l’´
etat des mobiles
Nous avons choisi, dans un premier temps, de proposer un protocole de routage avec qualit´e de service r´eactif. En effet, il existe une analogie dont on peut tirer parti entre les
protocoles de routage r´eactifs — particuli`erement AODV [PRD02] — et le protocole de signalisation RSVP [ZDE+93] utilis´e pour fournir des garanties de qualit´e de service fortes
dans les r´eseaux filaires. Les deux protocoles recherchent en effet des routes `a la demande par envoi d’un message particulier qui parcourt le r´eseau jusqu’`a atteindre la destination recherch´ee.
Les critiques adress´ees au mod`ele IntServ/RSVP concernant son extensibilit´e semblent, dans le contexte des r´eseaux ad-hoc, assez peu pertinentes. En effet, les r´eseaux ad-hoc sont des r´eseaux locaux. Il est peu probable que les m´ecanismes actuellement utilis´es dans ce type de r´eseaux soient adaptables `a des r´eseaux de grande taille de type Internet, ou des r´eseaux d’´equipements embarqu´es disposant de faibles capacit´es de stockage. Le routage r´eactif, par exemple, pr´esente `a un facteur pr`es les mˆemes d´efauts que le mod`ele IntServ.
Si un mobile se contente de stocker pour chaque destination vers laquelle il route un flux le saut suivant dans le r´eseau, l’espace de stockage n´ecessaire est multiple de n − 1 dans le pire cas, o`u n est le nombre de nœuds du r´eseau. Si l’on conserve dans la table de routage une entr´ee par flux dans le r´eseau, on a au plus (n − 1) ∗ f entr´ees o`u f est le nombre de flux maximal par source (255 si l’on identifie les flux en utilisant le champ TOS de l’entˆete IP). Compte tenu de la bande passante limit´ee de ces r´eseaux et du surcoˆut important introduit par le protocole d’acc`es au m´edium, il est peu r´ealiste d’imaginer un r´eseau comportant `a la fois un grand nombre de nœuds et un grand nombre de flux privil´egi´es.
Dans notre proposition, la recherche de route s’effectue de fa¸con classique par diffusion d’une requˆete de route avec qualit´e de service. Cette requˆete se propage dans tout le r´eseau et chaque nœud la recevant effectue un contrˆole d’admission avant de la retransmettre. Si le contrˆole d’admission ´echoue, la requˆete n’est pas retransmise. Il est important ici de noter que le protocole de signalisation sous-jacent doit propager suffisamment d’informations pour que tout nœud puisse effectuer seul un contrˆole d’admission pr´ecis et juste.
Comme pour AODV, chaque nœud potentiellement impliqu´e dans le routage d’un flux m´emorise les information concernant chaque requˆete, particuli`erement le pr´ed´ecesseur sur la route (afin de propager la confirmation de route sur le chemin inverse), la quantit´e de res-sources demand´ees et des informations permettant d’identifier les paquets du flux (adresses source et destination, identifiant de flux).
Plusieurs requˆetes se propagent en parall`ele et les chemins ainsi d´etermin´es auront des propri´et´es diff´erentes. La destination, lorsqu’elle re¸coit une requˆete de route, patiente afin de laisser le temps `a des requˆetes moins rapides de lui parvenir. Lorsque plusieurs chemins admissibles au regard des crit`eres de qualit´e de service sont disponibles, elle a alors `a choisir un chemin principal parmi ceux qui lui seront propos´es. On peut ici associer un coˆut `a chaque requˆete. Il suffit ensuite de choisir le chemin de coˆut le plus faible.
Le crit`ere de coˆut peut ˆetre choisi en regard de l’application ou en regard du fonction-nement global du r´eseau. Du point de vue de l’application, le crit`ere de coˆut peut ˆetre la stabilit´e de la route ou le nombre de sauts. Du point de vue du fonctionnement global du r´eseau, le crit`ere de coˆut peut ˆetre bas´e sur la bande passante disponible sur les chemins ou sur les interf´erences g´en´er´ees par cette communication, c’est-`a-dire sur le nombre de trafics concurrents sur les hyperliens du chemin. Comme le contrˆole d’admission que nous proposons
est bas´e sur une approximation de la notion d’interf´erences, le crit`ere de minimisation des interf´erences g´en´er´ees par les routes calcul´ees nous semble un crit`ere adapt´e `a nos objectifs. Une fois le choix de la route effectu´e, la destination renvoie une confirmation de r´eservation qui traverse le r´eseau en suivant le chemin inverse de celui qui sera utilis´e pour router le trafic. Chaque nœud interm´ediaire recevant un tel message proc`ede alors `a la r´eservation ef-fective des ressources apr`es avoir effectu´e `a nouveau un contrˆole d’admission afin de s’assurer que les ressources sont toujours disponibles. En effet, un mobile sur la route a pu, entre le premier contrˆole d’admission et le moment o`u il re¸coit la confirmation de route, accepter un nouveau trafic qui ne lui permet plus d’acheminer celui-ci. Un mobile a aussi pu recevoir de nouvelles informations sur son voisinage qui ne lui permettent plus de transmettre ce trafic. Si le contrˆole d’admission ´echoue dans un nœud interm´ediaire, ce nœud envoie un message d’erreur `a la destination qui peut fournir une autre route admissible.
Lorsque le message de confirmation parvient `a la source, la transmission des donn´ees peut d´ebuter. Celle-ci se poursuit jusqu’`a la fin du flux — auquel cas un message est envoy´e par la source afin de lib´erer explicitement les ressources — ou jusqu’`a ce que la route ne corresponde plus aux crit`eres n´egoci´es. La figure9illustre le processus d’´etablissement d’une communication entre les mobiles A et F .
A B E F C D RREQ(A,F) RREP(A,F)
Fig.9 – Processus de recherche de route et r´eservation
4.5
D´
egradation des routes
Le routage que nous proposons fonctionne en mode circuit virtuel. En effet, il semble difficile d’offrir des garanties fortes en mode datagramme. Cependant, lorsqu’un mobile sur la route se d´eplace, la route peut perdre en qualit´e ou ˆetre d´econnect´ee. Il faut alors trouver un moyen de poursuivre la transmission des donn´ees. Une reconstruction syst´ematique des routes `a la source est coˆuteuse puisqu’elle implique une inondation du r´eseau.
Deux alternatives `a une reconstruction `a la source sont possibles. La premi`ere est la reconstruction locale des routes. Un mobile sur une route active peut d´etecter que le mobile suivant sur la route n’est plus joignable lorsqu’il ne re¸coit pas un certain nombre d’acquitte-ments. Lorsque cela se produit, il doit alors trouver une route de secours vers la destination. Il peut essayer de r´eparer la route initiale en essayant de joindre un nœud en aval sur cette route ou reconstruire enti`erement la route `a partir de ce point en recherchant une route admissible vers la destination du flux. La seconde approche consiste `a conserver en r´eserve une ou plusieurs routes de secours `a partir de la source ou des nœuds interm´ediaires.
Conserver plusieurs routes de secours au sein des nœuds interm´ediaires permet de limiter fortement les d´elais lors des reconstructions des routes. Cette approche permet de limiter les interruptions de service.
En revanche, que faire lorsque la route est toujours valide et que la qualit´e de service n´egoci´ee `a l’´etablissement de cette route se d´egrade ? Ceci peut ais´ement se produire lorsque un nœud ´emettant un certain trafic, en se d´epla¸cant, vient `a perturber une transmission pr´ealablement accept´ee. Faut-il alors reconstruire syst´ematiquement la route, compte tenu du fait qu’il n’existe peut ˆetre qu’une seule route permettant de relier la source et la desti-nation de la transmission perturb´ee ? Qui plus est, une recherche de route est une op´eration pouvant introduire une interruption importante dans la communication.
Les auteurs d’INSIGNIA [LAZC00] proposent de d´efinir deux niveaux de service et d’al-terner entre les deux niveaux en fonction de la disponibilit´e des ressources sur la route. INSIGNIA n’effectue cependant aucun routage avec qualit´e de service dans le sens o`u il n’y a aucun contrˆole d’admission de la part du r´eseau. Le seul but est d’informer les correspon-dants de ce que peut leur offrir le r´eseau.
Cette approche est int´eressante dans le sens o`u il nous semble important d’assurer une certaine souplesse dans le m´ecanisme de r´eservation. Si certaines applications peuvent avoir un besoin rigide en terme de ressource sur la route, certaines applications pourront se satis-faire momentan´ement d’une qualit´e de service restreinte. Afin d’assouplir le m´ecanisme de r´eservation, nous proposons d’ajouter aux requˆetes de bande passante quelques param`etres indiquant comment r´eagir `a une diminution des ressources sur la route.
Nous proposons de d´efinir un profil de d´egradation qui consiste en trois param`etres : le d´ebit d´esir´e, le d´ebit minimal en dessous duquel l’application ne peut plus fonctionner correctement et l’incr´ement de d´egradation. Lorsqu’un mobile constate une d´egradation dans la qualit´e des routes transitant par lui, il d´egrade ses flux en commen¸cant par les flux les plus consommateurs en terme de bande passante. Si les d´ebits ne peuvent toujours pas ˆetre satisfaits, on recommence jusqu’`a ce que la situation soit arrang´ee.
`
A chaque it´eration du processus, le nœud qui a choisi de d´egrader ses flux doit en informer tous les nœuds sur la route afin que ceux-ci prennent les mesures appropri´ees. Lorsque toute perturbation a disparu, le mobile restaure les d´ebits de ses flux de mani`ere incr´ementale jusqu’`a atteindre le d´ebit initial ou constater `a nouveau une une perturbation.
Conclusion
Nous ´etudions dans cet article les probl`emes li´es au routage avec qualit´e de service dans les r´eseaux ad-hoc. Apr`es avoir pr´esent´e les caract´eristiques du routage avec qualit´e de ser-vice et les contraintes li´ees aux r´eseaux ad-hoc, nous avons pr´esent´e les protocoles de routage avec qualit´e de service propos´es pour de tels r´eseaux. Ces protocoles se basent sur l’´etat des liens du r´eseau pour construire des routes pouvant offrir certaines garanties. Or, une connais-sance sur l’´etat des liens nous semble inadapt´ee aux r´eseaux ad-hoc qui sont bas´es sur la caract´eristique partag´ee du m´edium radio. Il semble alors plus naturel de parler d’hyperlien radio. Or, obtenir une connaissance, sur la capacit´e d’un hyperlien par exemple, peut se
faire simplement d`es lors que les mobiles dans cet hyperlien ´echangent des informations, sur leur consommation de ressources par exemple. Partant de cette constatation, nous propo-sons un protocole de routage r´eactif avec qualit´e de service bas´e sur l’´etat des mobiles. Ce protocole maintient p´eriodiquement des informations qui approximent la capacit´e (bande passante utilis´ee) des hyperliens. Avec cette connaissance, chaque mobile est en mesure d’ef-fectuer un contrˆole d’admission qui va garantir une certaine qualit´e aux routes construites. La construction des routes se fait par inondation du r´eseau. Pour finir, nous abordons le probl`eme de d´egradation des routes qui peut intervenir de par la mobilit´e. Si ce probl`eme inclut les d´econnexions de routes qui interviennent classiquement dans le routage au mieux, il concerne aussi la mobilit´e de routes valides qui peuvent se positionner dans des zones qui ne peuvent honorer les d´ebits demand´es sur ces routes. Ce dernier point est un probl`eme de mobilit´e sp´ecifique `a la qualit´e de service.
Dans cet article, nous consid´erons la bande passante comme ´etant le crit`ere d´eterminant dans le choix des routes. En effet, ce param`etre est primordial lorsqu’on souhaite offrir des garanties de qualit´e de service puisque maˆıtriser les d´ebits dans le r´eseau permet de limiter la congestion dans le r´eseau et par cons´equent d’am´eliorer les d´elais de transmission et les taux de pertes. Toutefois nous n’offrons aucune garantie sur ces param`etres. Nous pensons donc ´etendre notre travail aux autres m´etriques de qualit´e de service usuelles.
R´
ef´
erences
[Ber99] C. Berge. Hypergraphs. Elsevier, Amsterdam NL, 1999.
[CGL02] Claude Chaudet and Isabelle Gu´erin Lassous. Bruit : Bandwidth reservation under interferences influence. In European Wireless 2002 (EW2002), Florence, Italy, February 2002.
[CN99] Shigang Chen and Klara Nahrstedt. Distributed quality-of-service routing in ad-hoc networks. IEEE Journal on Special Areas in Communications, 17(8) :1–18, August 1999.
[FF62] L.R. Jr. Ford and D.R. Fulkerson. Flows in Networks. Princeton University Press, 1962.
[fITTbS99] IEEE Standard for Information Technology Telecommunications and Informa-tion Exchange between Systems. Local and Metropolitan Area Network – Speci-fic Requirements – Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. The Institute of Electrical and Electronics Engineers, 1999.
[GK00] Piyush Gupta and P.R. Kumar. The capacity of wireless networks. IEEE Tran-sactions on Information Theory, IT-46(2) :388–404, March 2000.
[JMHJ02] David B. Johnson, David A. Maltz, Yih-Chun Hu, and Jorjeta G. Jetcheva. The dynamic source routing protocol for mobile ad hoc networks. IETF internet draft (work in progress), Internet Engineering Task Force, February 2002.
[JMQ+02] Philippe Jacquet, Paul Muhlethaler, Amir Qayyum, Anis Laouiti, Laurent
Vien-not, and Thomas Clausen. Optimized link state routing protocol. IETF internet draft (work in progress), Internet Engineering Task Force, November 2002. [JV00] Philippe Jacquet and Laurent Viennot. Overhead in mobile ad-hoc network
protocols. Technical Report 3965, INRIA, June 2000.
[LAZC00] Seoung Bum Lee, Gahng Seop Ahn, Xiaowei Zhang, and Andrew T. Campbell. Insignia : An ip-based quality of service framework for mobile ad hoc networks. Journal on Parallel and Distributed Computing, 60(4), 2000.
[Lin01] Chunchun Richard Lin. On-demand QoS routing in multihop mobile networks. In IEEE Infocom 2001, Anchorage, Alaska, USA, April 2001.
[LNT02] Henrik Lundgren, Erik Nordstr¨om, and Christian Tschudin. Coping with com-munication gray zones in IEEE 802.11b based ad hoc networks. Technical report, Uppsala University, Sweden, June 2002.
[LTWS01] Wen Hwa Liao, Yu Chee Tseng, Shu Ling Wang, and Jang Ping Sheu. A multi-path qos routing protocol in a wireless mobile ad hoc network. In International Conference on Networking 2001 (ICN 2001), Colmar, France, July 2001. [Moy91] J. Moy. Open shortest path first (ospf) version 2. Internet Request For
Com-ments RFC 1247, Internet Engineering Task Force, July 1991.
[OLTB02] Richard G. Ogier, Mark G. Lewis, Fred L. Templin, and Bhargav Bellur. Topo-logy dissemination based on reverse-path forwarding (TBRPF). IETF internet draft (work in progress), Internet Engineering Task Force, November 2002. [PRD02] Charles E. Perkins, Elizabeth M. Royer, and Samir R. Das. Ad hoc on-demand
distance vector (AODV) routing. IETF internet draft (work in progress), Inter-net Engineering Task Force, November 2002.
[RHZ00] G.V.S. Raju, G. Hernandez, and Q. Zou. Quality of service routing in ad hoc networks. In IEEE Wireless Communications and Networking Conference 2000(WCNC 2000), Chicago, IL, United States, September 2000.
[SSB99] Prasun Sinha, Raghupathy Sivakumar, and Vaduvur Bharghavan. CEDAR : a core extraction distributed ad hoc routing algorithm. IEEE Journal on Se-lected Areas in Communications, special issue on Wireless Ad Hoc Networks, 17(8) :1454–1465, August 1999.
[Toh97] C.K. Toh. Associativity-based routing for ad hoc mobile networks. International Journal on Wireless Personal Communications, 4(2), 1997.
[ZDE+93] L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala. RSVP : A new
resource reservation protocol. IEEE Network Magazine, 7(5) :9–18, September 1993.
[ZSC02] C. Zhu and M. Scott Corson. QoS routing for mobile ad hoc networks. In IEEE Infocom 2002, New York, NY, USA, June 2002.
Unit´e de recherche INRIA Futurs : Domaine de Voluceau - Rocquencourt - BP 105 - 78153 Le Chesnay Cedex (France) Unit´e de recherche INRIA Lorraine : LORIA, Technopˆole de Nancy-Brabois - Campus scientifique
615, rue du Jardin Botanique - BP 101 - 54602 Villers-l`es-Nancy Cedex (France)
Unit´e de recherche INRIA Rennes : IRISA, Campus universitaire de Beaulieu - 35042 Rennes Cedex (France) Unit´e de recherche INRIA Rocquencourt : Domaine de Voluceau - Rocquencourt - BP 105 - 78153 Le Chesnay Cedex (France)
