Précisions sur OLSR

Le routage OLSR met en place une structure de routage en sélectionnant des n÷uds particuliers : les MPR. Les routes entre deux n÷uds passent par un ensemble de MPR. Nous présentons à la suite les principaux élements de ce processus en

s'appuyant sur les éléments du RFC 3626. [4].

Gestion de la topologie et calcul de route

Chaque n÷ud dans le réseau maintient une base contenant les informations to- pologiques du réseau qui est construite à partir des messages de contrôle de la topologie : messages TC (Topology Control). Un message TC annonce les n÷uds ayant sélectionné le n÷ud m origine du TC comme relais multipoint. Ces messages sont diusés périodiquement à tous les n÷uds du réseau avec une fréquence déter- minée par l'intervalle TC_Interval (la valeur par défaut est de 5 secondes). Un numéro de séquence est associé à l'ensemble des sélecteurs de relais multipoint et sera incrémenté à chaque changement de cet ensemble.

Fig. 4.1  Exemple de routage OLSR.

Le routage OLSR se fait saut par saut. Chaque n÷ud dans le réseau calcule sa table de routage pour atteindre tout autre n÷ud présent dans le réseau en utilisant

les informations de voisinage et de topologie rafraîchies périodiquement. La route entre le n÷ud source et le n÷ud destinataire est optimale en nombre de sauts et les n÷uds intermédiaires de cette route sont des relais multipoints. La table de routage est mise à jour chaque fois qu'il y a un changement dans la base de voisinage ou de la topologie. C'est-à-dire, quand on détecte l'apparition ou la perte d'un voisin ou lors de l'ajout ou la suppresion d'un élément de topologie.

La gure4.1 [85] donne un exemple d'une base topologique et des tables de rou-

tage du réseau ad hoc de la gure4.3. Pour le calcul des routes vers les destinations,

un n÷ud m utilise l'algorithme de Dijkstra [86].

Détection du voisinage : précisions sur le message HELLO

Une détection de voisinage est eectuée par chaque n÷ud qui diuse périodi-

quement un message HELLO (voir gure4.2) qui contient les informations relatives

aux interfaces entendues par ce n÷ud : la liste des adresses des interfaces des n÷uds voisins avec leur état de lien. Un lien entre les interfaces d'un n÷ud et son voisin peut avoir l'un des quatre états suivants :

 Symétrique le lien est validé comme bidirectionnel : il est possible de trans- mettre des données dans les deux sens.

 Asymétrique le n÷ud reçoit les messages HELLO venant de cette interface d'un voisin, c'est-à-dire que ce n÷ud entend ce voisin mais le lien n'est pas encore validé dans l'autre sens.

 MPR indique que ce n÷ud a sélectionné ce voisin comme relais multipoint et cela implique que le lien est symétrique.

 inactif le lien avec cette interface de voisin n'est plus valide.

Chaque n÷ud maintient une liste de liens pour chaque voisin. La liste de liens est mise à jour comme suit :

 Si aucun entrée de lien n'existe pour le tuple (adresse IP source, IP d'interface reçue) alors une telle entrée est ajoutée. L'adresse IP source est obtenue de l'en-tête d'IP du paquet reçu. Quand une entrée est ajoutée, le n÷ud voisin correspondant est aussi initié puisque aucune entrée correspondante n'existait.  Le temps de validité reçu est utilisé pour mettre à jour une minuterie asy- métrique. Cette minuterie indique pour combien de temps l'entrée de lien est considérée comme asymétrique si la minuterie symétrique expire.

 Si l'adresse de l'interface de réception est incluse dans le message HELLO reçu, la minuterie symétrique est mise à jour. Le statut du lien et le statut des entrées de voisin selon cette entrée de lien sont mis à jour si nécessaire.  Le maximum de minuterie asymétrique et de minuterie symétrique sont utilisés

Fig. 4.2  Détection de voisinage pour l'échange de messages HELLO.

La gure4.2montre un exemple de détection de l'état de lien. Dans cet exemple,

chaque n÷ud possède une seule interface.

 A l'instant t = t1, le n÷ud X envoie un message HELLO. Le n÷ud Y reçoit ce

message et enregistre X comme un voisin asymétrique, comme il ne peut pas trouver sa propre adresse dans le message HELLO. La minuterie asymétrique

(Asym) et le temps actuel de vie (Time) de cette entrée sont réglés à t1+ V

(où V est le temps de Validité).

 A l'instant t = t2, Y envoie un message HELLO déclarant X comme un voisin

asymétrique. Quand X obtient ce message il trouve sa propre adresse dans le message et donc dénit Y comme un voisin symétrique.

 A l'instant t = t3, X inclut Y dans son message HELLO. Y enregistre X comme

un voisin symétrique sur la réception du message HELLO de X. De plus, la minuterie asymétrique, la minuterie symétrique (Sym) et le temps actuel de

vie de cette entrée sont réglés à t3+ V.

 A l'instant t = t4, Y envoie un message HELLO déclarant Y comme un voisin

symétrique.

 A l'instant t = t5, X transmet un message HELLO déclarant Y comme un

voisin symétrique. Y met à jour la minuterie de cette entrée = t5+ V.

Un exemple de détection du voisinage est présenté dans la gure 4.3.

Les n÷uds diusent les messages HELLO autour d'eux (c'est-à-dire à un saut) sur toutes les interfaces rattachées au n÷ud. Ces messages sont envoyés avec une fréquence déterminée par l'intervalle HELLO_Interval (la valeur par défaut est de 2 secondes). Les voisins qui reçoivent ces messages, les traitent et ne les relaient pas. Les messages HELLO permettent également de découvrir les voisins à deux sauts (c'est-à-dire, les voisins des voisins). Les informations de voisinage fournies par ces messages sont valides pendant une durée de vie Neighbor_Hold_Time qui est égale à 3 x HELLO_Interval. Une approche simple permettant de détecter la

non validité d'un lien OLSR est la perte de 3 HELLO successifs.

Fig. 4.3  Exemple d'information de voisinage maintenue par OLSR. Précisions sur les relais multipoint

Le protocole OLSR est un protocole à états de liens qui diuse périodiquement des messages de contrôle. Le concept de relais multipoint permet de diuser eca- cement les messages destinés à tous les n÷uds du réseau ad hoc (les messages TC) en réduisant de façon signicative le nombre de retransmissions lors du processus

de diusion [87] La transmission radio étant par défaut une inondation à tous les

voisins directs, les n÷uds de second saut peuvent être joints par une retransmission d'un ou plusieurs voisins directs. L'idée de base est de désigner un nombre su- sant de voisins appelés relais multipoint pour réduire le nombre de retransmissions redondantes dans la même région du réseau.

En se basant sur l'information de voisinage, chaque n÷ud m sélectionne de façon indépendante un sous-ensemble minimal de n÷uds parmi ses voisins directs pour retransmettre ses paquets. Ces n÷uds possèdent des liens symétriques avec m et leur ensemble est noté MPR(m). La seule condition est que tous les n÷uds se trouvant à deux sauts aient des liens symétriques avec des n÷uds dans MPR(m). Cela signie que les relais multipoint permettent de couvrir, en terme de couverture radio, tous les n÷uds du voisinage à deux sauts.

Les n÷uds voisins de m qui ne sont pas des relais multipoint de ce n÷ud, reçoivent et traitent les messages diusés par m, mais ne les retransmettent pas.

Chaque n÷ud maintient l'ensemble de ses sélecteurs de relais multipoint, noté mul- tipoint relay selector et ne retransmet que les paquets reçus pour la première fois de ces sélecteurs de relais multipoint.

Les relais multipoint sont calculés suite à la détection d'un changement de voi-

sinage direct ou à deux sauts. La gure 4.4.a montre un exemple où un paquet m

est diusé au voisinage à trois sauts par 24 retransmissions [87]. Dans la gure4.4.b

seuls les relais multipoint retransmettent le paquet (11 retransmissions).

Fig. 4.4  Optimisation de l'inondation par des relais multipoint

L'optimisation oerte par l'utilisation des relais multipoint est plus ecace dans des topologies de réseaux ad hoc denses et larges (cette optimisation s'avère égale- ment bénéque pour la recherche de route par inondation utilisée dans les protocoles

réactifs [88]). Le gain sera important dans les deux congurations suivantes :

1. pour les modèles de trac aléatoire et sporadique où un large sous-ensemble de n÷uds est en communication,

2. lorsque les couples [source, destination] varient dans le temps [89]. Plus le

nombre de relais multipoint est petit, plus le routage est optimal.

En s'appuyant sur ces résultats nous nous proposons d'optimiser le routage en mi- nimisant le nombre de MPR.

4.2.2 Proposition d'adaptation pour l'algorithme de sélection