Une approche r´ eactive

L’utilisation de protocoles de routage `a la demande est en g´en´eral consid´er´ee comme pr´esentant un coˆut d’´etablissement de route trop ´elev´e pour des r´eseaux tels qu’Internet. Toutefois, dans des r´eseaux locaux b´en´eficiant d’un mode de transmission en diffusion locale tels que des r´eseaux ad hoc, leur utili-sation est tout `a fait envisageable. Ces protocoles r´eactifs ne sont bien ´evidemment pas adapt´es `a toutes les situations, et l’opposition entre cette philosophie et la philosophie proactive, plus proche du mode de fonctionnement d’Internet actuel, fait couler beaucoup d’encre. Toutefois, nous cherchons ici `a fournir des garanties `a des applications, ind´ependamment de leur source et de leur destination, `a la mani`ere de RSVP. Deux applications provenant de la mˆeme source et `a destination du mˆeme mobile pourront s´electionner deux chemins diff´erents en fonction de la disponibilit´e des ressources. L’´etablissement de tels circuits virtuels est proche de l’´etablissement de routes de mani`ere r´eactive, c’est pourquoi BRuIT adopte une telle approche.

Lorsqu’une application souhaite obtenir une route r´epondant `a une exigence de qualit´e de service, elle ´

emet une requˆete de r´eservation, dont le format exact est d´ecrit en annexeA.2et expliqu´e par la suite. Cette requˆete va se propager, de proche en proche, inondant le r´eseau jusqu’`a atteindre la destination.

`

A chaque fois qu’un tel message parvient `a un mobile, celui-ci effectue un contrˆole d’admission, dont les d´etails constituent la particularit´e de BRuIT et seront explicit´es en section2.3.2. Ce processus de contrˆole d’admission a pour but de s’assurer que l’introduction d’un nouveau trafic dans le r´eseau dont le volume correspond `a la requˆete de bande passante formul´ee ne provoque aucun d´epassement de la capacit´e du m´edium. Si cette condition est v´erifi´ee, la requˆete est r´e´emise et le nœud routeur potentiel conserve les caract´eristiques du flux, adresses source et destination, num´ero de flux et bande passante demand´ee. Il conserve par ailleurs l’adresse du nœud duquel il a re¸cu la requˆete. Si les ressources ne sont pas disponibles, la requˆete est simplement d´etruite.

Afin d’´eviter les cycles dans le routage, une requˆete n’est examin´ee par un mobile que lors de sa premi`ere r´eception. Un num´ero de s´equence d´etermin´e de fa¸con unique pour un ´emetteur donn´e par incr´ement permet, en conjonction avec l’adresse de l’´emetteur de la requˆete, de d´etecter les demandes dupliqu´ees. Examiner de multiples instances de la mˆeme requˆete peut cependant ˆetre envisag´e en s’as-surant que les routes ainsi form´ees ne comportent pas de cycles.

A C D B E F G 1 1 2 3 4 4 ⁵ Echec du contrôle d' admission (en F) Requête dupliquée (en D)

✗

✗

✗

✗

Fig. 2.1 – Exemple de propagation de requˆ^{ete de route}

Par exemple, sur la figure2.1, le mobile A d´esire rechercher une route `a destination de G, il envoie une requˆete qui atteint simultan´ement B et C. Chacun va alors la r´e´emettre `a son tour, et D ne r´e´emettra que la premi`ere instance qu’il aura re¸cue de cette requˆete. Le contrˆole d’admission pourra ´echouer par exemple au niveau de F pour faute de disponibilit´e de ressources. F ne retransmettra donc pas ce message et finalement, la demande parviendra `a G par l’interm´ediaire de E.

Ainsi, si l’occupation du r´eseau le permet, une ou plusieurs instances de la requˆete atteindront leur destination, d´eterminant une ou plusieurs routes admissibles selon les crit`eres de qualit´e de service sp´ecifi´es. Dans notre approche, la premi`ere requˆete `a parvenir `a la destination d´efinira la route `a utiliser. Plusieurs arguments semblent en effet aller dans ce sens plutˆot que dans celui de l’attente de multiples requˆetes permettant de s´electionner parmi l’ensemble des routes d´ecouvertes la meilleure. En effet, afin que plusieurs requˆetes parviennent `a destination, plusieurs chemins disjoints admissibles doivent ˆetre d´etermin´es, puisque chaque routeur ne retransmet qu’au plus une fois chaque requˆete. La probabilit´e de d´eterminer plusieurs chemins admissibles est donc r´eduite. De plus, la requˆete parvenant la premi`ere `a destination est potentiellement la requˆete correspondant au chemin le plus court en terme de d´elai de bout en bout. L’examen d’un seul paquet de contrˆole ne permet toutefois en aucun cas de s’assurer ce fait. Il ne s’agit l`a que d’une consid´eration a priori. Enfin, une r´eponse rapide `a une requˆete de bande passante permet de r´eduire la probabilit´e que les ressources ne soient plus disponibles lors de l’envoi d’une r´eponse confirmant la r´eservation des ressources.

A C D B E F G 4 3 2 1 Connectivité Confirmation de route

Fig. 2.2 – Exemple de transmission de confirmation de route

La bande passante n’est effectivement r´eserv´ee que lors du passage dans les routeurs du message de confirmation ´emis en r´eponse `a la requˆete par la destination. Le format de ce message est explicit´e en annexeA.3. Il n’est pas possible d’effectuer une r´eservation lors du passage de la requˆete initiale car les nœuds ne connaissent pas a priori l’´etat de l’ensemble des mobiles en aval sur la route. La destination ´

emet donc, apr`es avoir effectu´e, elle aussi un contrˆole d’admission, un message de confirmation. Ce message, `a l’inverse du message de recherche de route, est ´emis en mode point `a point puisqu’il ne s’agit plus d’explorer le r´eseau. Cette confirmation emprunte la route inverse, comme le montre l’exemple de la figure2.2, provoquant la r´eservation effective des ressources apr`es une nouvelle v´erification de la disponibilit´e des ressources. En cas de r´eussite, le routeur conserve les caract´eristiques du flux ainsi que

l’adresse des nœuds voisins imm´ediats sur la route. Lorsque cette confirmation parvient `a destination, la route est ´etablie et les ressources sont r´eserv´ees.

La conservation dans chaque routeur des adresses du mobile en amont et du mobile en aval sur la route permet d’utiliser la route d´etermin´ee dans les deux sens pour peu que les applications marquent les paquets correspondant `a ce flux en accord avec l’identifiant de la route. Ce proc´ed´e permet indiff´eremment `

a une application qui sera la source d’un flux ou `a une application qui sera la destination d’un flux de r´eserver des ressources. D’autre part, il est possible d’utiliser la route ainsi d´etermin´ee dans les deux sens simultan´ement, ce qui permet aux acquittements TCP de parcourir le r´eseau en b´en´eficiant du mˆeme niveau de service que le flux auxquelles elles correspondent. Enfin, il est possible de mettre en œuvre un m´ecanisme de surveillance de l’´etat de la route bas´e sur la transmission r´eguli`ere de trames dans le sens inverse du flux de donn´ees apportant les informations collect´ees le long de la route `a la source du flux.

Une fois que le flux de donn´ees est transmis, la source comme la destination peut lib´erer explicite-ment les ressources au moyen d’un message de contrˆole particulier. Cependant, une lib´eration explicite des ressources n’est pas toujours possible par exemple en cas de panne de l’application, ou lorsque la mobilit´e des routeurs empˆeche le message de lib´erer les ressources de bout en bout. Aussi les routes et les r´eservations qui leur sont associ´ees expirent au bout d’un d´elai lorsque aucun paquet de donn´ee n’emprunte la route. Afin de ne pas p´enaliser les applications ayant un profil d’´emission irr´egulier, la source pourra, de fa¸con optionnelle, ´emettre r´eguli`erement des paquets vides qui parcourront la route `a la mani`ere du processus de maintien des sessions TCP (keep-alive).

Lorsqu’une route disparaˆıt du fait de la mobilit´e d’un routeur, les nœuds en aval du point de cas-sure n’ont plus de paquets `a transmettre, qu’il s’agisse de paquets de donn´ees effectifs ou de paquets de rafraˆıchissement de route. En revanche, les routeurs en amont du point de cassure continueront `a retransmettre les paquets du flux, ceux-ci ´etant perdus au niveau du dernier routeur avant le point de cassure. C’est ce dernier routeur qui pourra avertir la source de la cassure par l’envoi d’un message explicite, dont le format exact est explicit´e en annexe A.4 qui, traversant les routeurs, provoquera la lib´eration des ressources. `A la r´eception d’un tel message, la source devra r´eeffectuer une recherche de route. Conserver une route de secours ne semble pas appropri´e du fait de la mobilit´e des nœuds et des variations de disponibilit´e de ressources.

A C D B E F G D

✗

✗ ^✗

Fig. 2.3 – Exemple de cassure de route

Par exemple, dans la situation repr´esent´ee en figure2.3, le mobile D se d´eplace jusqu’`a sortir de la zone de couverture de B et E. Le mobile B ne recevant plus d’acquittements de la part de D constatera le d´epart de ce dernier et en avertira A. Le mobile E ne recevra plus de paquets `a retransmettre et la route expirera bientˆot. Enfin, le mobile D sera dans les deux situations `a la fois et ´eliminera la route invalide.

Le processus de r´eservation ainsi d´efini est semblable au protocole RSVP et, par l`a mˆeme, souffrira sans doute des mˆemes limitations particuli`erement concernant les probl`emes li´es au passage `a l’´echelle, du fait de la n´ecessit´e de maintenir des ´etats pour chaque flux dans chaque routeur. BRuIT ne sera sans doute pas adapt´e `a des r´eseaux ad hoc `a large ´echelle tels que, par exemple, ceux qui sont d´efinis par le projet Terminodes2. Toutefois, BRuIT peut ˆetre utilis´e tel quel dans des r´eseaux ad hoc de taille moyenne. `A titre indicatif, les tables de filtrage d’un mobile fonctionnant sous le syst`eme Linux (avec NetFilter disponible `a partir de la version 2.4) peuvent distinguer jusqu’`a 256 flux en ne se basant que sur le champ TOS (type of Service) de l’entˆete IP. Ce nombre est `a multiplier par le nombre de couples source-destination possibles dans le r´eseau. Par ailleurs, il est tout `a fait envisageable de n’utiliser ce

protocole que pour le routage des trafics multim´edias, en conjonction avec un protocole de routage ad hoc.