Optimized link state routing protocol

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

OLSR (Optimized Link State Routing Protocol) est un protocole de routage destiné aux réseaux maillés, sans fil ou mobiles. Le protocole est une optimisation de l'algorithme d'état de liaison pure. Le concept clé utilisé dans le protocole est l’utilisation des relais multipoints (MPR). L'ensemble MPR est choisi de sorte qu'il couvre tous les nœuds qui sont à deux sauts de suite[1]. Il fonctionne comme un protocole proactif, des informations de topologie avec d'autres nœuds du réseau sont échangées régulièrement [2].

Dans OLSR deux types de messages sont introduits : « Hello » et « TC » (Topology Control). Chaque nœud diffuse un message Hello contenant des informations sur son voisinage et l’état des liens. L’échange de ces messages permet de prendre connaissance de son voisinage [3]. Pour construire les tables nécessaires au routage des paquets, chaque nœud envoie périodiquement un paquet TC contenant la liste de ses voisins l’ayant choisi comme MPR. Le message TC est diffusé sur tout le réseau. Seuls les voisins MPR rediffusent un paquet TC pour éviter l’inondation[4].

Ce protocole a été proposé par l’équipe projet HIPERCOM-INRIA. Il est défini dans la RFC 3626[5] de l'IETF, qui le reconnait comme l'un des quatre protocoles de base dans l'utilisation des réseaux MANET[6].

Pour son aspect dynamique, le protocole OLSR est vulnérable à un certain nombre d'attaques, notamment du brouillage, envoi de mises à jour des messages invalides, ainsi que des attaques destinées au message de contrôle durant sa génération ou sa transmission. Des recherches sur des techniques d'authentification et de détection des intrusions ont été réalisées pour sécuriser le protocole. Des évolutions ont été réalisées au cours des études de performance du protocole en termes de qualité de service et de consommation énergétique, suivant les différentes implémentations matérielles et logicielles.

Une nouvelle version est en cours de développement (2010)[7].


Le protocole[modifier | modifier le code]

Classe[modifier | modifier le code]

Dans le domaine des MANET, il existe deux classes de protocoles : les réactifs et les pro-actifs[8].

Les protocoles réactifs doivent systématiquement demander leurs routes en inondant le réseau de leur requête et en recevant la réponse associée[8].

L'utilisation d'un protocole de cette catégorie au sein d'un MANET implique la construction d'une topologie dans la zone concernée uniquement lorsque le besoin se présente.

Les protocoles réactifs sont : AODV & DSR[8].

Les protocoles pro-actifs quant à eux s'assurent que chaque nœud possède à tout moment les informations nécessaires relatives à la topologie pour construire une route vers n'importe quel autre point du réseau. Cela est rendu possible à travers des mises à jour régulières sur la topologie[8].

Les protocoles pro-actifs sont : OLSR, TBRPF[8].

Enfin, il existe des protocoles combinant les avantages des protocoles réactifs et pro-actifs, ce sont des protocoles hybrides, tels que ZRP & TORA[9].


Caractéristiques techniques[modifier | modifier le code]

Le protocole OLSR est une variation du LSR (en) (en anglais « Link State Routing » ) spécialement conçu pour les MANET[10]. Contrairement au LSR où tous les nœuds sont indifférenciés, l'optimisation d'OLSR est d'utiliser des relais multipoints (MPR)[10]. Les MPR sont des nœuds choisis qui expédient des messages de diffusion pendant le processus d'inondation[11]. Ils sont les seuls à déclarer leurs liens et sont sélectionnés par les autres nœuds de manière à ce que ceux-ci puissent atteindre n'importe qui en deux sauts[10]. Cette technique réduit sensiblement la surcharge due aux messages par rapport à un mécanisme classique d'inondation, où chaque nœud retransmet chaque message quand il reçoit la première copie du message. Dans OLSR, l'information d'état de lien est produite seulement par des nœuds élus comme MPR, ainsi, une deuxième optimisation est réalisée en réduisant au minimum le nombre des messages de contrôle inondés dans le réseau. Comme troisième optimisation, un nœud de MPR doit rapporter seulement des liens entre lui-même et ses sélecteurs.

Les deux principales fonctionnalités d'OLSR sont[12] :

  • la découverte des voisins
  • la diffusion de la topologie

OLSR est une optimisation d'un protocole d'état de liaison pour les réseaux mobiles ad hoc [2].

Premièrement, elle réduit la taille du paquet de contrôle: au lieu de tous les liens, il déclare qu'une partie des liens avec ses voisins, qui sont ses sélecteurs de relais multipoints. Deuxièmement, il minimise les inondations de la circulation par ce contrôle en utilisant uniquement les nœuds sélectionnés, appelés relais multipoints, pour diffuser son message dans le réseau. Seuls les relais multipoints d'un nœud peuvent retransmettre ses messages diffusés. Cette technique réduit considérablement le nombre de retransmissions dans une procédure d'inondation ou de diffusion [2].

Le protocole est conçu pour fonctionner de manière complètement distribuée et n'a donc pas à dépendre de toute entité centrale. Le protocole ne nécessite pas une transmission fiable pour ses messages de contrôle : chaque nœud envoie ses messages de contrôle périodiquement, messages qui peuvent subir une perte de certains des paquets, ce qui arrive très souvent dans les réseaux radio en raison de collisions ou d'autres problèmes de transmission [2].

Détection des voisins[modifier | modifier le code]

Chaque nœud doit détecter les nœuds voisins avec lesquels il a un lien direct et bidirectionnel. Les incertitudes sur la propagation radio peuvent rendre certains liens unidirectionnels. Par conséquent, tous les liens doivent être contrôlés dans les deux directions, afin d’être considérés comme valides [13].

Pour accomplir cela, chaque nœud diffuse périodiquement ses messages BONJOUR contenant les informations sur ses voisins et leur état de lien. Ces messages de contrôle sont transmis dans le mode de diffusion. Ils sont reçus par tous les voisins situés à un saut, mais ils ne sont pas relayées à des nœuds supplémentaires [2].

Un des messages BONJOUR contient :

  • La liste des adresses des voisins pour lesquels il existe un lien bidirectionnel valide.
  • La liste des adresses des voisins qui sont entendues par ce nœud (un BONJOUR a été reçu), mais le lien n'est pas encore validé comme bidirectionnel : si un nœud trouve sa propre adresse dans un message BONJOUR, il considère le lien du nœud expéditeur comme bidirectionnel.

Type de messages[modifier | modifier le code]

Message Hello[modifier | modifier le code]

Les messages HELLO sont utilisés pour la détection de voisin et calculs MPR. Ils sont transmis périodiquement à tous les voisins à 1 saut. Les messages HELLO incluent le type de lien, la volonté du nœud de devenir MPR, des informations sur les voisins etc. Le type de lien dans ces messages indique si le lien est symétrique, asymétrique ou tout simplement perdu [14].

Ces messages ne sont destinés qu'aux nœuds voisins (à un saut) de l'expéditeur afin de détecter les liens les inter-connectant, ils ne doivent donc jamais être routés par un MPR.

Expéditeur : Chaque nœud du réseau envoie des messages HELLO

Destinataire : Adresse de broadcast

Fonction : Le message HELLO transmet plusieurs informations et a plusieurs utilités. Il sert d'abord à découvrir l'ensemble du réseau. Il transmet ensuite l'état et le type de lien entre l'expéditeur et chaque nœud voisin.

Il contient également trois listes[15] :

  • Voisins qui ont été "entendus" mais pour lesquels une communication bi-directionnelle n'a pu être établie.
  • Voisins avec qui le nœud a pu établir une liaison bi-directionnelle.
  • Les nœuds désignés comme MPR par le nœud originaire du message HELLO.


Datagramme [16]:

Datagramme
  • « Reserved » : Ce champ doit contenir « 0000000000000000 »
  • « Htime » : Intervalle d'émission des messages HELLO
  • « Willigness » : permet de forcer le passage d'un nœud en MPR
  • « Link Code » : Code identifiant le type de lien (pas d'information, symétrique, asymétrique, etc.) entre l'expéditeur et les interfaces listées (« Neighbor Interface Address »)


Message TC (Topology Control)[modifier | modifier le code]

Ces messages sont utilisés pour construire la table de routage. Ce sont des messages d'état de liaison, diffusés périodiquement dans des réseaux entiers [14].

Expéditeur : Seuls les MPR envoient des messages TC

Destinataire : Adresse de broadcast

Fonction : Le message TC permet au MPR de transmettre la liste de ses voisins qui l'ont choisi comme MPR. Il sert à établir les tables de routage. Aussi, pour qu'il soit diffusé sur tout le réseau, la valeur du TTL dans l'header du message est 255, la valeur maximale (voir « paquet type envoyé par le protocole »).

Datagramme [17]:

Datagramme
  • « Reserved » : Ce champ doit contenir « 0000000000000000 »
  • « ANSN (Advertised Neighbor Sequence Number) » : Entier incrémenté à chaque changement de topologie. Il permet de ne pas tenir compte des informations obsolètes, pour tenir les tables le plus à jour possible.
  • « Advertised Neighbor Main Address » : Adresse IP de nœuds à un saut. L'ensemble des nœuds publiés dans les messages TC est un sous-ensemble des voisins à un saut. La version par défaut recommande de publier les "MPR-Selectors", c'est-à-dire les voisins pour lesquels le nœud courant est un relai MPR.

Message MID (Multiple Interface Declaration)[modifier | modifier le code]

Ces messages sont transmis par les nœuds exécutant le protocole OLSR sur plus d'une interface [14].

Les messages MID sont utilisés pour relier les adresses des interfaces OLSR et les adresses principaux pour des nœuds OLSR à interfaces multiples[18],[19].

Datagramme d'un message MID

Le message MID contient la liste d’adresses des interfaces associées à son adresse principale. Il est envoyé par le nœud dans le réseau pour les déclarer à tous les autres nœuds[20]. Pour obtenir une meilleure fiabilité et un meilleur débit, les messages MID peuvent servir à sélectionner plusieurs interfaces comme principales et ainsi établir des chemins multiples entre deux nœuds voisins. Pour le routage, un nœud à interfaces multiples apparaîtra comme deux nœuds séparés. Si un lien est en panne, un nœud avec de multiples interfaces pourrait encore fournir le chemin de routage pour les autres nœuds[19].

Agrégation des messages[modifier | modifier le code]

Les messages HELLO et TC peuvent être emballés dans le même paquet[21].

Cela permet l'émission de plusieurs messages en même temps sur le réseau[21].

Le traitement et la méthode de propagation des messages restent néanmoins propres à leur catégorie. Par exemple les messages de type HELLO ne sont pas relayés tandis que ceux de type TC le sont[21].

Datagramme d'un paquet OLSR


Les relais Multipoints[modifier | modifier le code]

L'idée des relais multipoints est de minimiser l'inondation de paquets de diffusion dans le réseau en réduisant les retransmissions en double vers un même nœud. Chaque nœud dans le réseau sélectionne un ensemble de nœuds dans son voisinage, qui retransmet ses paquets. Cet ensemble de nœuds voisins sélectionné est appelé le relais multipoint de ce nœud ou MPR [2].

Les voisins du nœud N qui ne sont pas dans son ensemble MPR, peuvent lire et traiter le paquet, mais ne peuvent pas retransmettre le paquet de diffusion reçu à partir du nœud N [22]. Pour cela, chaque nœud maintient une liste de ses voisins qui sont appelés les sélecteurs de MPR de ce nœud. Chaque message de diffusion provenant de ces sélecteurs MPR d'un nœud est supposé être retransmis par ce nœud. Cet ensemble peut changer au fil du temps, ce qui est indiqué par le sélecteur de nœuds dans leurs messages [22].

Chaque nœud sélectionne ses relais multipoints parmi ses voisins situés à un saut. Un saut correspond à un nœud dont la distance est la plus proche du nœud principal [23]. Les relais multipoints sont choisis de manière à couvrir (en termes de portée radio) tous les nœuds qui sont situés à deux nœuds de distance [23]. L'ensemble de relais multipoints d'un nœud N, noté MPR (N), est un sous-ensemble arbitraire du nœud de N qui satisfait la condition suivante : chaque nœud dont la distance est à deux sauts de N doit avoir un lien bidirectionnel vers les relais multipoints du nœud N. La figure montre la sélection de relais multipoints autour du nœud N [23].

Relais Multipoints

OLSR repose sur la sélection des relais multipoints, et calcule ses routes vers toutes les destinations connues à travers les nœuds. Les nœuds MPR sont choisis comme des nœuds intermédiaires dans le chemin [24]. Pour mettre en œuvre ce schéma, chaque nœud dans le réseau envoie périodiquement des informations à ses voisins qui ont été choisis comme relais multipoint. Dès réception de l'information sur les sélecteurs MPR, chaque nœud calcule et met à jour ses itinéraires pour chaque destination connue. Par conséquent, la route est une séquence de sauts à travers les relais multipoints de la source à la destination[24].

Les relais multipoints sont choisis parmi les voisins à un saut avec un lien bidirectionnel. Ainsi, l'itinéraire en passant par les relais multipoints évite automatiquement les problèmes associés au transfert de données par paquets sur les liens unidirectionnels[23].

Pour le calcul d'itinéraire, chaque nœuds calcule sa table de routage en utilisant un "algorithme de plus court chemin hop" basé sur la topologie du réseau partiel qu'il a appris [25].


Définition[modifier | modifier le code]

Schéma d'algorithme de sélection des MPR

Sur le schéma d'algorithme de sélection des MPR, l'ensemble N est constitué des voisins à un saut du nœud (ici en rouge), dont on veut déterminer les MPR. Un saut correspond à tous les voisins qui ont répondu au message Hello, cela correspond à la portée radio pour les réseaux Wi-Fi[26],[27].

L'ensemble N2 est constitué des voisins à 2 sauts du même nœud que précédemment. Tous les voisins à un saut du nœud rouge en utilisant les messages hello, vont déclarer leurs voisins à un saut. Ainsi le nœud rouge connaîtra les nœuds à un saut qu'il faudra solliciter pour transmettre un paquet à un voisin à 2 sauts[28],[29].

Un lien asymétrique (ou unidirectionnel, le lien est valide que dans un seul sens) est représenté par un trait rouge simple[28],[29]. Ils sont détectés grâce aux messages Hello, mais ne sont pas utilisés tant qu'ils ne sont pas symétriques[28],[29].

Un lien symétrique (ou bidirectionnel, le lien est valide dans les deux sens) est représenté par un trait rouge double[28],[29].


Algorithme[modifier | modifier le code]

Les différents étapes de l'algorithme sont [28],[29]:

  1. On force tous les éléments de N à rerouter les messages.
  2. On calcule D pour chaque nœud de N.
  3. Pour tous les nœuds dans N2 qui n'ont qu'un et un seul lien symétrique avec un nœud de N, on définit ce nœud de N comme MPR, et on supprime les nœuds de N2 reliés par ce MPR (on les considère comme reliés). Si le nœud considéré dans N2 a des liens symétriques avec plusieurs nœuds de N (ensemble « E »), on prend comme MPR le nœud « X » de l'ensemble E qui a le plus haut degré D, et on efface les nœuds de N2 joignables par le nœud « X » (on les considère comme reliés).
  4. On réitère ces 3 étapes, jusqu'à ce qu’il n'y ait plus de nœud non relié dans N2.


Exemple de sélection des MPR[modifier | modifier le code]

La sélection des MPR est le point clé dans le protocole OLSR. La sélection du MPR se fait en choisissant le nœud voisin à un saut. S’il y a plusieurs nœuds, le nœud choisi est alors celui qui a le plus de voisins [1]. Le tableau montre comment le nœud B sélectionne un MPR, basé sur le réseau représenté dans la figure :

Tableau

Si on prend le nœud B, les nœuds C et F couvrent l'ensemble des nœuds voisins à deux sauts. Cependant, le nœud C est sélectionné en tant que MPR car il a 5 voisins alors que le nœud F en possède 4 (on dit alors que le degré de C est supérieur au degré de F) [1].

Exemple d'architecture MPR

Sécurité[modifier | modifier le code]

Le protocole OLSR est vulnérable à différents types d'attaques[6]. Cette vulnérabilité est accrue car il n'est pas nécessaire de passer par un point d'accès pour se connecter au réseau[10]. L'utilisation d'une topologie dynamique laisse place à de grandes failles de sécurité[10]. L'utilisation des MPR rend le protocole OLSR moins sécurisé que le LSR puisque seule la connectivité utile est exploitée, les nœuds ne dupliquent plus l'information[10].

Types d'attaques[modifier | modifier le code]

On peut répertorier les attaques en deux catégories[21] :

  • Attaques communes à tous les protocoles de routage pro-actifs.
  • Attaques inhérentes au protocole OLSR.

Cette page portant uniquement sur le protocole OLSR, les vulnérabilités présentées concernent majoritairement les attaques propres à ce protocole.


Chaque nœud a pour rôle premier de générer du trafic propre au protocole de routage, et deuxièmement est responsable de relayer les informations de routage des autres nœuds du réseau.

Un comportement incorrect résulte donc de la génération d'informations erronées sur le routage, ou de l'absence de relais de ces informations [21].

Une attaque permettant de fournir une connectivité illicite au réseau doit résulter d'un comportement anormal d'au moins un des nœuds qui le composent.

Une attitude anormale peut résulter de deux comportements[21] :

  • Un nœud supposé connecté au réseau a été compromis et ne possède plus les mêmes caractéristiques conformes au protocole qu'auparavant.
  • Un nœud fait partie du réseau alors qu'il ne le devrait pas.

Il existe de nombreuses possibilités afin d'introduire des nœuds dans le protocole OLSR (en partant d'un OLSR définit par la RFC, dépourvu de procédure de validation) pour lancer différentes attaques[10] :

  • une surcharge des routeurs en inondant le réseau afin de le saturer ("déni de service" ou "Denial_of_service");
  • l'envoi de messages de mises à jour invalides.

Brouillage[modifier | modifier le code]

OLSR est vulnérable au brouillage, c'est d'ailleurs le cas pour tous les autres protocoles de routage utilisés sur réseaux ad-hoc.

Le brouillage consiste à générer une grande quantité d'interférences radio. Le bruit généré entraîne alors l'impossibilité pour les nœuds de s'échanger des informations utiles entre eux, notamment leurs routes respectives, et empêche ainsi la construction d'un réseau[21].

Cette vulnérabilité ne peut pas être corrigée au niveau du protocole de routage.

Envoi de messages de mises à jour invalides[modifier | modifier le code]

Un nœud a normalement deux responsabilités[10] :

  • générer des messages de contrôles;
  • les transférer.

Pour compromettre l'intégralité du protocole de routage, l'attaquant peut soit envoyer des paquets de contrôle incorrects lorsque le nœud génère les messages de contrôle, soit les modifier lorsque les messages de contrôle sont envoyés[30]. Un message de contrôle peut être trafiqué en changeant son identité (en anglais "identity spoofing") ou en endommageant ses données (en anglais "link spoofing").

Attaque sur le message de contrôle durant sa génération[modifier | modifier le code]

Dans les schémas suivants, les nœuds jaunes sont des nœuds classiques et les autres des MPR.

Usurpation d'identité avec un message HELLO

Un nœud malicieux prétend en être un autre en usurpant son adresse IP (Usurpation_d'adresse_IP), afin d'envoyer un message HELLO à son voisinnage[30].

Usurpation d'identité d'un nœud


Le nœud 5 usurpe l'identité du nœud 3.


Usurpation d'identité d'un nœud


Les nœuds 1 et 2 sont persuadés d'être connectés au nœud 3 mais en réalité le sont au nœud 5, qui se fait passer pour le nœud 3.


Corruption des données du message HELLO

Les messages HELLO vont contenir des falsifications de la topologie du réseau avec l'insertion de nœuds inexistants, pour que des usurpateurs soient reconnus comme des MPR, pouvant alors contrôler tous les flux qui passent par eux.
Il est aussi possible de supprimer des nœuds existants (par omission dans les messages HELLO) afin de les rendre inaccessibles dans la topologie ainsi construite[30].

Usurpation d'identité d'un nœud avec un message TC

Le nœud 5 est censé envoyer un message TC indiquant qu'il est le dernier saut jusqu'aux nœuds 6 et 7.

Usurpation d'identité d'un nœud


Le nœud 5 usurpe l'identité du nœud 1.


Usurpation d'identité d'un nœud


Le trafic destiné aux nœuds 6 et 7 ira jusqu'au nœud 1. Le nœud 1 est devenu le dernier saut jusqu'aux nœuds 6 et 7[30].


Corruption des données avec un message TC

La corruption des données dans les messages TC consiste à insérer des MPR inexistants ou à en supprimer. La suppression de MPR au sein des tables de routage risque de fragmenter le réseau et certains MPR ne seront plus accessibles. L'insertion de nœuds MPR non existants permet de créer de faux liens et de déformer la topologie du réseau, ce qui aura pour conséquence de créer des "boucles" lors du routage ou de générer des conflits lors du calcul des tables de routage[30].

Attaque sur le message de contrôle durant la transmission[modifier | modifier le code]

Les messages TC nécessitent d'être transmis à travers les MPR à l'ensemble du réseau, afin de transporter des informations critiques sur les tables de routage. Les nœuds relais peuvent trafiquer ces messages pendant leur transfert, en ajoutant ou supprimant des MPR. Les problèmes peuvent être plus sérieux que lors du trafique des messages HELLO, car les messages TC sont utilisés par tous les nœuds. Il est donc très facile de lancer une attaque de type "trou noir", qui met en œuvre des nœuds qui font discrètement disparaître le trafic[31].

Protections[modifier | modifier le code]

Des recherches ont été réalisées afin de sécuriser le protocole sur plusieurs niveaux[6] :

  • des techniques d'authentification et de chiffrement pour sécuriser le réseau d'attaques externes;
  • des détections d'intrusions et des méthodes de communication pour protéger le réseau d'attaques internes.


Authentification[modifier | modifier le code]

Deux approches reconnues assez efficaces pour bloquer les utilisateurs ou les nœuds non autorisés[6] :

  • utiliser une Autorité_de_certification distribuée;
  • authentifier les messages de contrôle en leur introduisant des signatures permettant de vérifier l'origine et l'intégrité des informations.

Ces solutions ne permettent pas de se protéger d'attaques externes. De plus, l'utilisation de clés dans un réseau MANET est compliquée et lourde à gérer[6].


Propriétés intrinsèques des messages OLSR[modifier | modifier le code]

La redondance entre les messages HELLO et les messages TC est une opportunité pour vérifier des informations conflictuelles entre les nœuds afin de protéger le protocle OLSR[31]. Dans toutes les propriétés suivantes, TCp correspond à l'ensemble des sélecteurs de P, MPRp à l'ensemble des MPR liés à P et HELLOp à l'ensemble des voisins directs de p.

Propriété 1 Une message HELLO contient tous les voisins situés à un saut du nœud qui l'envoie, tandis qu'un message TC contient les sélecteurs de MPR du nœud (autrement dit, le message TC, envoyé par un MPR, dispose de tous les nœuds qui ont choisi celui-ci comme relai)[31]. Le message TC contient donc un sous ensemble du message HELLO, TCp ← HELLOp. Si cette propriété est violée, cela signifie que le nœud à l'origine du message TC a inséré des sélecteurs de MPR et qu'il prétend être un nœud MPR (link spoofing)[31].

Relations entre TCp et HELLOp
3 et 4 ne sont pas adjacents et ont choisi 5 comme relai. TCp = {3,4} et HELLOp = {1,2,3,4}.


Propriété 2 Si un nœud MANET reçoit un message TC le listant comme un sélecteur de MPR, alors celui à l'origine de ce message doit être dans le voisinage de ce nœud[31]. Si C Є TCp, alors P Є HELLOc doit d'abord être vrai[31]. Si ce n'est pas le cas, cela peut indiquer plusieurs attaques. Le nœud à l'origine du message TC prétend être un MPR (link spoofing sur un message TC)[31].

Relations entre TCp, HELLOc et HELLOd
Si le nœud C recoit un message TCp = { C ... } alors HELLOc = { P ... } doit être envoyé avant.


Propriété 3 Si une nœud MANET reçoit un message TC de ses voisins ayant pour information qu'il est un sélecteur de MPR, ce nœud doit d'abord avoir énuméré l'envoyeur du message comme un MPR dans son message HELLO[32]. Si Q Є TCp, alors P Є MPRq doit d'abord être vrai[32]. Si cette propriété est violée, le nœud à l'origine du message TC prétend être un nœud MPR pour le receveur et tout son voisinage, afin de détourner le trafic (link spoofing)[32].

Relations entre TCp et MPR
Si TCp = { C, D } alors P doit appartenir aux MPR liés à C et à D.


Propriété 4 Tous les messages TC transférés ont un contenu identique[32]. Afin de le vérifier, un composant peut être déployé dans tous les nœuds du réseau afin de détecter toutes les mises à jour illégitimes sur le message de contrôle. Les nœuds recevant les messages TC vont appliquer "une validation", qui sera aussi appliquée par les nœuds les transférant. La vérification de conflit permet alors d'augmenter le niveau de sécurité du protocle ainsi que la robustesse des opérations de routage[32].

Performances[modifier | modifier le code]

Protocoles dérivés (améliorations)[modifier | modifier le code]

Pour faire face aux inconvénients du protocole OLSR, différents protocoles sont en cours de développement ou ont été développés afin de répondre aux carences du protocole.

B.A.T.M.A.N.[modifier | modifier le code]

OLSR souffre d'un sérieux problème de synchronisation des messages TC et des informations relatives aux routes contenues dans chacun des nœuds[33].

En effet les routes connues par les nœuds et l'état réel de la topologie peuvent différer durant un certain laps de temps, et il est nécessaire d'attendre que la mise à jour de la topologie soit effectuée afin de disposer de routes à nouveau correctes, ce qui peut créer des boucles au sein du réseau[33].

C'est une des raisons pour lesquelles le développement du protocole B.A.T.M.A.N. fut lancé[33].

Article détaillé : B.A.T.M.A.N..

OLSRv2[modifier | modifier le code]

OLSRv2 est également en cours de développement par l'IETF depuis 2005[34], corrigeant les défauts d'OLSR et actuellement encore à phase de standardisation, une version finale (RFC) devrait bientôt voir le jour[35].

CE-OLSR[modifier | modifier le code]

CE-OLSR est une version basée sur OLSR mais intégrant la localisation des nœuds[36].

Chaque message HELLO se voit ainsi ajouter un champ dans lequel sa propre position (coordonnées GPS) ainsi que celles de ses voisins sont ajoutées[37].

Chaque message TC quant à lui se voit également ajouter par les MPR un champ dédié aux coordonnées des autres sélecteurs MPR[37].

CE-OLSR apporte ainsi les améliorations suivantes [38]:

  • Meilleure robustesse des messages de contrôle (topologie) par rapport à la perte de paquets.
  • Les changements de topologie sont détectés plus rapidement, ce qui apporte un suivi précis du voisinage.
  • Capacité à discerner les informations cartographiques récentes des obsolètes.
  • Il en résulte de meilleures performances, à la fois en termes de débit qu'en temps de réponse et également une validité accrue des routes connues.

M-OLSR[modifier | modifier le code]

M-OLSR est une variante d'OLSR modifiant le protocole afin de fournir de meilleures performances au sein de WMN (réseaux maillés sans-fil), à savoir[39] :

  • Amélioration du débit.
  • Meilleur pourcentage de paquets délivrés.
  • Réduction de la surcharge réseau liée au protocole.

Les WMN diffèrent des MANET de par leur architecture quelque peu différente. En effet, alors qu'un MANET ne possède aucun point fixe parmi tous ses nœuds, un WMN possède un nœud connu de tous les autres, jouant le rôle de colonne dorsale (backbone) au sein du réseau[39]. La répercussion d'une modification du protocole OLSR n'est donc pas forcément la même selon que le réseau concerné est de type WMN ou MANET[39].

Qualité de service[modifier | modifier le code]

La QoS n'est pas géré nativement dans OLSR, mais un projet intégrant cette fonctionnalité est en cours de développement[40].

La gestion du QoS n'est pas triviale dans le cas d'un protocole de routage à état de lien de par sa structure constamment changeante et la puissance limitée disponible au sein des nœuds composant des MANET[41].

Un protocole de routage pro-actif a l'avantage de pouvoir maintenir des routes pré-calculées sur lesquelles la QoS pourra s'appuyer afin de prendre rapidement des décisions, ce qui n'est pas le cas des protocoles de routage réactifs calculant les routes seulement à la demande[41].

Ceci est un avantage considérable dans le cadre de réseaux de nature imprévisible, comme les MANET. La couche de contrôle peut aisément vérifier si une route pré-calculée peut satisfaire la demande, et si ce n'est pas le cas ainsi éviter la génération d'un trafic inutile relatif au routage et à la topologie[41].

Sélection des MPR[modifier | modifier le code]

Une première manière de procéder consiste à modifier l'algorithme de sélection des MPR. Le comportement défini par la RFC d'OLSR indique que cette sélection s'effectue sur base du nombre de voisins, le nœud élu en tant que MPR étant celui possédant le plus de voisins à 2 sauts[5].

Cette méthode de sélection ne prend cependant pas en compte la qualité des liens interconnectant les nœuds, ce qui dans une optique de qualité de service est pourtant un des points les plus critiques[42].

Un autre algorithme pourrait consister à se baser sur la bande passante disponible en tant que premier critère de sélection des MPR. Le but est alors d'obtenir une route possédant un débit le plus élevé possible, facteur jouant un rôle prépondérant dans les applications temps-réel de plus en plus utilisées aujourd'hui[43].

À l'origine OLSR sélectionne le chemin le plus court lors de la sélection des MPR, ce qui n'est pas forcément synonyme de performance, encore faut-il définir le terme "performance" (latence, bande-passante, redondance, etc).

Dans le cas où l'on souhaite orienter les performances vers un aspect ou un autre en particulier, il faut modifier l'algorithme afin de sélectionner les MPR selon d'autres facteurs que la connectivité des nœuds, comme la vitesse, dans le cas où la bande passante est la contrainte première du QoS[43].

Une tentative de modification du protocole OLSR est illustrée ci-dessous, visant à maximiser la bande passante de bout en bout tout en assurant que chaque nœud à 2 sauts soit toujours connecté. Les valeurs indiquées représentant la bande passante : plus elle est élevée, plus la bande passante est importante.

Algorithme par défaut[modifier | modifier le code]
Sélection d'un MPR selon les spécifications originales d'OLSR
Sélection d'un MPR selon les spécifications originales d'OLSR

Dans sa version originale, OLSR ne prend pas en compte la bande passante disponible pour chaque lien.

Le nœud B sélectionnera donc C comme étant son MPR dans ce cas de figure-ci, car c'est celui qui possède le plus de connexions avec les autres nœuds[43].

Cela signifie donc que lorsque D construira sa table de routage, il sélectionnera d'office la route D-C-B pour joindre le nœud B. Cette route est la pire de toutes avec un goulot d'étranglement souffrant de la vitesse la plus restrictive de tout le MANET (valeur de 3) entre D et C[43].

Par cet exemple flagrant, on réalise qu'OLSR ne sélectionnera pas le chemin le plus rapide.

  •      nœud sujet au QoS
  •      nœud à un saut de B
  •      nœud à deux sauts de B
  •      nœud élu MPR par B
Algorithme modifié #1[modifier | modifier le code]
Sélection d'un MPR selon la version #1 modifiée de l'algorithme OLSR
Sélection d'un MPR selon la version #1 modifiée de l'algorithme OLSR

L'algorithme reste presque identique à la version originale.
Lorsqu'il existe plus d'un nœud à un saut, mais qu'ils couvrent tous le même nombre de nœuds à deux sauts, c'est celui qui possède la plus grande bande passante qui est élu MPR[43].
F est donc élu MPR à la place de C, car la liaison reliant B à F (100) possède une vitesse plus grande que la liaison entre B et C (50)[43].

Algorithme modifié #2[modifier | modifier le code]
Sélection d'un MPR selon la version #2 modifiée de l'algorithme OLSR
Sélection d'un MPR selon la version #2 modifiée de l'algorithme OLSR

L'idée de cette deuxième version consiste à choisir les nœuds ayant la meilleure bande passante avant tout, tant que tous les nœuds à deux sauts sont couverts[43].

Dans ce cas-ci, les nœuds A et F seront sélectionnés avec respectivement une bande passante de 110 et 100 en partant de B[43].

A est d'abord sélectionné grâce à sa bande passante la plus élevée, mais n'élire que le nœud A en MPR ne permettrait pas d'établir une connexion avec tous les nœuds à deux sauts (E resterait injoignable par B)[43].
C'est pourquoi le nœud F est choisi en tant que deuxième MPR (et non C, car 100 > 50)[43].


Algorithme modifié #3[modifier | modifier le code]
Sélection d'un MPR selon la version #2 modifiée de l'algorithme OLSR
Sélection d'un MPR selon la version #3 modifiée de l'algorithme OLSR

La troisième modification de l'algorithme compare chaque chemin partant de B vers chaque autre nœud se situant à 2 sauts du MANET. Il sélectionne alors le seul chemin ayant la bande passante la plus élevée vers chacun de ces nœuds[43].

Ci-dessous le tableau montre la comparaison des bandes-passante et la raison pour laquelle le nœud F est sélectionné pour connecter les nœuds B et D[43].

Tableau
nœud de départ Bande-passante entre les nœuds nœud intermédiaire Bande-passante entre les nœuds nœud d'arrivée Bande-passante maximale résultante

B

110

A

5

D

5

B

50

C

3

D

3

B

100

F

10

D

10

→ F est le MPR permettant d'avoir la bande passante la plus élevée.

Même raisonnement pour joindre les nœuds B et E : C sera le MPR choisi.


Ces différentes modifications ont le potentiel d'améliorer les performances en apportant une meilleure bande-passante à chaque nœud[44].
En revanche, elles peuvent également engendrer une surcharge du trafic de contrôle (véhiculant les informations sur la topologie), surtout dans le troisième exemple où il est potentiellement possible d'élire un MPR différent par nœud à 2 sauts[44].


Consommation énergétique[modifier | modifier le code]

Les nœuds du réseau MANET ne sont pas connectés sur le réseau électrique et il en résulte que l'énergie de leur batterie est limitée. La vie de la batterie peut aussi affecter la performance de communication du réseau. Quand un nœud épuise l'énergie disponible, il cesse de fonctionner et il peut y avoir pénurie d'hôtes mobiles dans le partitionnement du réseau. Pour cette raison la réduction de la consommation énergétique est un sujet important dans les réseaux sans fil ad hoc[45]. Le protocole OLSR ne tient pas compte de la consommation énergétique pendant l’élection des nœuds MPR, ni pendant le routage des paquets de données et ne tire aucun avantage à paritr de l’information des liaisons unicast du réseau[46],[47]. Les évolutions envisagées pour prendre en compte ces aspects sont entre autres les protocoles EE-OLSR[48], EOLSR[49] et DE-OLSR[50] :


Pour prendre en compte la consommation énergétique des nœuds certains métriques ont été introduites dans la couche réseau pour EE-OLSR [51]:

  • MTPR (Minimum Total Transmission Power Routing) : simple métrique énergétique qui représente l'énergie totale consommée pour transférer l'information sur le chemin[51],[52].
  • MBCR (Minimum Battery Cost Routing) : minimise la fonction mesurant la réticence des nœuds par rapport à l'énergie[51],[53].
  • MMBCR (Min-Max Battery Cost Routing) : choisit la route avec les meilleures conditions parmi les chemins touchés par un nœud crucial en se servant de la fonction introduite pour le MBCR[51],[53].
  • CMMBCR (Conditional MMBCR) : tente d'effectuer une approche hybride entre MTPR et MMBCR, en utilisant le premier tant que les nœuds d'une route possible ont suffisamment d'énergie restante suivant un seuil défini et le second quand parmi toutes les routes possibles il y au moins un nœud étant sous le seuil d'énergie restante[51],[54].
  • MDR (Minimum Drain Rate) : introduit une fonction de coût prenant en compte l'indice de taux de décharge et la puissance résiduelle de la batterie pour mesurer le taux de dissipation de l'énergie d'un nœud[51],[55].

Avec l'inclusion de ces métriques et encore deux autres améliorations de l'aspect énergétique du protocole OLSR le protocole EE-OLSR établit ces mécanismes :

  • Mécanisme basé sur la volonté d’émettre. La volonté d’un nœud à émettre est exprimée par une variable fixée par défaut qui représente la disponibilité de ce nœud d’agir comme un MPR. Le choix de cette variable est basé sur la capacité de sa batterie et la durée de vie estimée[48].
  • Mécanisme de l’exclusion de l’écoute. Eteindre le nœud pendant l’échange d’un message unicast dans le voisinage. Ceci est réalisé en utilisant les mécanismes de signalisation des couches inférieures qui servent à éviter les collisions (échange RTS / CTS réalisée par l'IEEE 802.11)[47].
  • Prise en compte de l’énergie pour les paquets à transmettre. Des métriques d’énergie sont introduites dans les nœuds MPR voisins pour sélectionner le prochain saut du routage à partir des mécanismes de routage MPTR, MMBCR et MDR[51]. On découple ainsi la procédure d’élection MPR du mécanisme de routage des paquets[47],[50].

Le protocole EOLSR a été conçu comme EE-OLSR à minimiser la consommation d'énergie pour la transmission d'un paquet, à faire de l'équilibrage de charge entre les nœuds du réseau, d'éviter les nœuds avec peu d'énergie restante et de réduire la surcharge[49]. Pour ce faire, la conception a été élaborée dans ces quatre aspects [49]:

  • Le calcul efficace des routes est établi suivant un modèle énergétique adapté au protocole MAC choisi[49].
  • La sélection des nœuds MPR est pris en compte dans le modèle énergétique et une nouvelle information est incluse dans le message Hello calculé avant chaque réémission[49].
  • La sélection des routes se fait en minimisant la consommation énergétique de point à point basé sur le coût du flux comme critère de chaque chemin à emprunter[56].
  • Le message de broadcast est optimisé pour les ressources énergétiques du réseau. Un nœud transfert un message pour broadcast avec un TTL non nul si et seulement s'il reçoit ce message pour la première fois d'un nœud qui l'a sélectionné comme MPR[56].

Dans un cadre un peu différent des deux autres le protocole DE-OLSR a été conçu pour des réseaux ad-hoc VANET[57]. Ceux-ci sont conceptuellement similaires aux réseaux MANET et sont destinés à la communication sans fil des véhicules équipés d'ordinateurs de bord, des éléments électroniques de la signalisation de la circulation, capteurs et aussi des piétons avec des smartphones[57]. À la base, cet algorithme n'implémente pas de solution spécialement conçue pour être performant en termes de coût d'énergie. L'idée principale est de trouver un paramétrage efficace pour optimiser la qualité de service du protocole OLSR en termes de taux de livraison de paquets de la charge de routage normalisée et un délai moyen en point à point de paquets de données des réseaux VANET[50]. Ceci est mené par le couplage avec une méta-heuristique Differential Evolution (DE)[58],[59]. Le protocole arrive à économiser presque deux tiers d'énergie en moyenne par rapport à l'OLSR standard sur l'échange des messages de contrôle dans un réseau VANET tout en diminuant la consommation d'énergie en transmission de données et la charge[60].

Comparaison entre protocoles[modifier | modifier le code]

D'autres protocoles de routage existent pour les réseaux mobiles. Voici une comparaison non exhaustive entre quelques-uns d'entre eux :

Olsr & b.a.t.m.a.n.[modifier | modifier le code]

Plusieurs tests de performances ont été effectués dont notamment une comparaison pratique entre des implémentations d'OLSRv1 et B.A.T.M.A.N. au sein de réseaux de taille et trafic variables[61].

En termes de ratio des paquets délivrés, il s'est avéré que lorsque le trafic est faible, OLSR est plus performant que B.A.T.M.A.N.. La tendance s'inverse lorsque le trafic devient important[62].

En termes de surcharge du trafic (informations relatives au routage et à la topologie), OLSR est plus performant que B.A.T.M.A.N. tant que le nombre de nœuds reste modeste, quelle que soit l'intensité du trafic[63].

Dès lors que le nombre de nœuds devient plus important, B.A.T.M.A.N. devient le protocole le plus performant des deux[63].

Dsr, aodv & olsr[modifier | modifier le code]

Une comparaison entre les protocoles DSR & AODV (réactifs) et OLSR (pro-actif) a également été réalisée, mettant en évidence l'attrait d'OLSR pour les sources CBR (tels que la VOIP), garantissant des délais plus courts que les protocoles réactifs précédemment mentionnés.

En revanche, OLSR consomme beaucoup plus de bande passante à cause des routes qu'il maintient continuellement engendrant un trafic soutenu continuel.

Les tests ont montré que les protocoles réactifs étaient plus adaptés qu'OLSR dans le domaine de copie de données (échange de fichiers par exemple), sans pour autant savoir clairement départager DSR et AODV du point de vue des performances.

Olsr, aodv & tora[modifier | modifier le code]

Une autre comparaison entre les protocoles OLSR, AODV & TORA a pu faire ressortir les résultats suivants[64] :

Comparaison entre OLSR, AODV & TORA
Contrainte de performance OLSR AODV TORA

Catégorie

Pro-actif

Réactif

Hybride

Type de protocole Schéma à état de lien Vecteur de distance Inversement de liens
Routes maintenues dans Table de routage Table de routage Table de routage
Liberté de boucle Oui Oui Oui
Philosophie des routes Plate Plate Plate
Routes multiples Non Non Oui
Multicast Oui Oui Non
Surcharge réseau Minimale Modérée Modérée
Diffusion périodique Possible Possible Possible
Requiert des séquences de données Non Oui Oui
Méthode de reconfiguration des routes Messages de contrôles envoyés en avance afin d'augmenter la réactivité Suppression des routes & notification à la source Réparation de la route par inversement de liens
Résumé Messages de contrôle pour détection de liaison, détection des voisins (MPR), détection de multiples interfaces, calcul des routes. Découverte des routes, expansion en anneau, recherche, poursuite du chemin. Inversement des liens, découverte des routes, paquets de mise à jour des routes


Performance de routage avec faible mobilité
Faible mobilité et faible trafic
Protocole Délai de bout en bout Ratio de livraison Optimalité du chemin Surcharge du protocole de routage

OLSR

Bas

Haut

Bonne

Basse

AODV Moyen Haut Moyenne Basse
TORA Bas Haut Bonne Moyenne


Performance de routage avec faible mobilité
Forte mobilité et fort trafic
Protocole Délai de bout en bout Ratio de livraison Optimalité du chemin Surcharge du protocole de routage

OLSR

Bas

Moyen

Moyenne

Basse

AODV Moyen Moyen Moyenne Basse
TORA Haut Bas Moyenne Moyenne

L'étude ayant mené la comparaison de ces trois protocoles de familles différentes a pu conduire aux constatations suivantes[64] :

Les performances des trois protocoles au sein d'un réseau à densité faible étaient relativement stables avec un trafic faible[65].

OLSR est plus efficace dans les réseaux à forte densité avec un trafic hautement sporadique. Il nécessite de disposer d'une bande-passante continuelle afin de régulièrement échanger les messages propres à la topologie. Par ailleurs, AODV préserve des performances régulières en milieu dense[65].

Enfin toujours selon cette même étude, TORA donne les meilleurs résultats pour la livraison de paquets en réseau dense grâce à son mécanisme de sélection des meilleures routes[65].

Implémentations[modifier | modifier le code]

Logicielles[modifier | modifier le code]

  • OLSRd : une implémentation libre du protocole OLSR[66].
  • nuOLSRv2[67] : première implémentation OLSRv2 réalisée par l'université de Niigata[68].
  • OOLSR [69] : implémentation en C++ avec plusieurs outils supplémentaires, développée par l'équipe HIPERCOM elle-même.
  • pyOLSR [70] : implémentation en Python avec plusieurs outils additionnels, développée par l'équipe HIPERCOM également (rendu obsolète par OOLSR).
  • Qolyester [71] : implémentation de QOLSR en C++, version modifiée d'OLSR avec ajout de la fonctionnalité "Qualité de service".
  • Une implémentation de CRC [72] (première version gérant l'IPv6)

Matérielles[modifier | modifier le code]

Puisque OLSR est une couche réseau de niveau couche 3, il est hautement portable et exécutable sur tout système d'exploitation standard I386 et PPC via le plugin d'interface utilisateur de OLSRd[73].

  • MSB-430 : un nœud de capteur conçu au CST-Freie Universitat-Berlin et utilisé pour tester les protocoles OLSR et B.A.T.M.A.N. dans un réseau WSN[74].
  • WRT54G : un routeur sans fil avec un processeur basé MIPS de chez LinkSys(Cisco)[75].
  • MeshCube : un petit routeur sans fil de chez 4G Systems avec processeur MIPS à 400Mhz et 64 Mo de mémoire vive[76].
  • iPAQ : un assistant personnel de chez Compaq/HP avec une architecture processeur strong-ARM et NetBSD en système d'exploitation[77].
  • Nokia N900 sous Linux Maemo[78].
  • Google phone sous Android, G1[79].

Notes et références[modifier | modifier le code]

  1. a, b et c Ge 2003, p. 2
  2. a, b, c, d, e et f Clausen 2004, p. 8
  3. Naimi 2003, p. 5
  4. Naimi 2003, p. 6
  5. a et b Clausen 2003
  6. a, b, c, d et e Wang 2005, p. 55
  7. (en) Spécifications du nouveau standard OLSRv2, dernière version rédigée le 20 avril 2010.
  8. a, b, c, d et e Adjih 2005, p. 5
  9. Kuppusamy, Thirunavukkarasu et Kalaavathi 2011, p. 143
  10. a, b, c, d, e, f, g et h Wang 2005, p. 56
  11. Clausen 2003, p. 1
  12. Plesse 2004, p. 705
  13. Clausen 2004, p. 3
  14. a, b et c Sharma 2009, p. 237
  15. Clausen 2003, p. 28
  16. Clausen 2003, p. 27
  17. Clausen 2003, p. 42
  18. Clausen 2003, p. 24
  19. a et b Li 2008, p. 804
  20. Clausen 2003, p. 25
  21. a, b, c, d, e, f et g Adjih 2003, p. 3
  22. a et b Clausen 2004, p. 9
  23. a, b, c et d Jacquet 2001, p. 2
  24. a et b Jacquet 2001, p. 3
  25. Ge 2003, p. 3
  26. Clausen 2003, p. 38
  27. Clausen 2004, p. 32
  28. a, b, c, d et e Clausen 2003, p. 39
  29. a, b, c, d et e Clausen 2004, p. 33
  30. a, b, c, d et e Wang 2005, p. 57
  31. a, b, c, d, e, f et g Wang 2005, p. 58
  32. a, b, c, d et e Wang 2005, p. 59
  33. a, b et c Barolli et al. 2009, p. 3
  34. The Optimized Link State Routing Protocol version 2
  35. (en) Actualité RFC OLSRv2
  36. Mohamed Belhassen 2011, p. 149
  37. a et b Mohamed Belhassen 2011, p. 151
  38. Mohamed Belhassen 2011, p. 155
  39. a, b et c Amrita Bose et Sukumar 2008, p. 147
  40. QOLSR
  41. a, b et c Ying Ge 2002, p. 1
  42. Ying Ge 2002, p. 2
  43. a, b, c, d, e, f, g, h, i, j, k et l Ying Ge 2002, p. 3
  44. a et b Ying Ge 2002, p. 4
  45. De Rango 2008, p. 1
  46. Ghanem 2005, p. 273
  47. a, b et c De Rango 2008, p. 4
  48. a et b De Rango 2008, p. 3
  49. a, b, c, d et e Mahfoudh 2010, p. 1127
  50. a, b et c Toutouh 2011, p. 720
  51. a, b, c, d, e, f et g De Rango 2008, p. 2
  52. Toh 2001, p. 141
  53. a et b Toh 2001, p. 142
  54. Toh 2001, p. 143
  55. Kim 2002, p. 565
  56. a et b Mahfoudh 2010, p. 1128
  57. a et b Toutouh 2011, p. 719
  58. Price 2005, p. 37
  59. Toutouh 2011, p. 721
  60. Toutouh 2011, p. 724
  61. Abd Al Basset Almamou 2009, p. 1
  62. Abd Al Basset Almamoup 2009, p. 3
  63. a et b Abd Al Basset Almamoup 2009, p. 4
  64. a et b Kuppusamy, Thirunavukkarasu et Kalaavathi 2011, p. 146
  65. a, b et c Kuppusamy, Thirunavukkarasu et Kalaavathi 2011, p. 147
  66. (en) Site web officiel d'OLSRd, l'implémentation OLSR pour GNU/Linux, FreeBSD, NetBSD, Android, etc.
  67. (en) Annonce de la première implémentation OLSRv2
  68. (en) nuOLSRv2
  69. (en) OOLSR
  70. (en) pyOLSR
  71. (en) Qolyester
  72. (en) « Communications Research Centre Canada » (ArchiveWikiwixArchive.isGoogleQue faire ?). Consulté le 2013-03-30
  73. Sinky 2010, p. 288
  74. Almamou 2009, p. 1
  75. (en) Linksys (Cisco) WRT54G
  76. (en) MeshCube
  77. Meraihi 2004, p. 110
  78. (en) OLSR on Nokia N900
  79. (en) OLSR ported to the Google phone

Voir aussi[modifier | modifier le code]

RFC[modifier | modifier le code]

Articles scientifiques[modifier | modifier le code]

  • (en) M. Wang, L. Lamont, P. Mason et M. M. Gorlatova, « An effective intrusion detection approach for OLSR MANET protocol », 1st IEEE ICNP Workshop on Secure Network Protocols, 2005. (NPSec), IEEE,‎ 6 novembre 2005, p. 55-60 (ISBN 0-7803-9427-5, DOI 10.1109/NPSEC.2005.1532054)
  • (en) T. Plesse, J. Lecomte, C. Adjih, M. Badel, P. Jacquet, A. Laouiti, P. Minet, P. Muhlethaler et A. Plakoo, « OLSR performance measurement in a military mobile ad-hoc network », 24th International Conference on Distributed Computing Systems Workshops, 2004. Proceedings, IEEE, vol. 24th International Conference on Distributed Computing Systems Workshops, 2004. Proceedings,‎ mars 2004, p. 704-709 (ISBN 0-7695-2087-1, DOI 10.1109/ICDCSW.2004.1284109)
  • (en) Frank Y. Li, Lorenzo Vandoni, Giampietro Zicca et Stefano Zanoli, « OLSR Mesh Networks for Broadband Access: Enhancements, Implementation and Deployment », Circuits and Systems for Communications, 2008. ICCSC 2008. 4th IEEE International Conference, IEEE,‎ mai 2008, p. 802-806 (ISBN 978-1-4244-1707-0, DOI 10.1109/ICCSC.2008.175)
  • (en) C.-K. Toh, « Maximum battery life routing to support ubiquitous mobile computing in wireless ad hoc networks », IEEE Communications Magazine, IEEE, vol. 39,‎ juin 2001, p. 138-147 (ISSN 01636804, DOI 10.1109/35.925682)
  • (en) Dongkyun Kim, J.J. Garcia-Luna-Aceves et K. Obraczka, « Power-Aware Routing Based on The Energy Drain Rate for Mobile Ad Hoc Networks », Computer Communications and Networks, 2002, IEEE,‎ octobre 2002, p. 565-569 (ISBN 0-7803-7553-X, DOI 10.1109/ICCCN.2002.1043126)
  • (en) Nabil Ghanem, Selma Boumerdassi et Éric Renault, « New energy saving mechanisms for mobile ad-hoc networks using OLSR », PE-WASUN '05 Proceedings of the 2nd ACM international workshop on Performance evaluation of wireless ad hoc, sensor, and ubiquitous networks, ACM Press,‎ 2005, p. 273-274 (ISBN 1-5959-3182-1, DOI 10.1145/1089803.1090006)
  • (en) Saoucene Mahfoudh et Pascale Minet, « Energy-aware routing in wireless ad hoc and sensor networks », Proceedings of the 6th International Wireless Communications and Mobile Computing Conference, ACM Press,‎ 2010, p. 1126-1130 (ISBN 978-1-4503-0062-9, DOI 10.1145/1815396.1815654)
  • (en) Jamal Toutouh et Enrique Alba, « An efficient routing protocol for green communications in vehicular ad-hoc networks », GECCO '11 Proceedings of the 13th annual conference companion on Genetic and evolutionary computation, ACM Press,‎ 2011, p. 719-725 (ISBN 9781450306904, DOI 10.1145/2001858.2002076)
  • (en) Hassan Sinky et Bechir Hamdaoui, « Implementation and performance measurement and analysis of OLSR protocol », IWCMC '10 Proceedings of the 6th International Wireless Communications and Mobile Computing Conference, ACM Press,‎ 2010, p. 286-290 (ISBN 978-1-4503-0062-9, DOI 10.1145/1815396.1815463)
  • (en) Floriano De Rango, Marco Fotino et Salvatore Marano, « EE-OLSR: Energy Efficient OLSR routing protocol for Mobile ad-hoc Networks », Military Communications Conference, 2008. MILCOM 2008. IEEE, IEEE,‎ novembre 2008, p. 1-7 (ISBN 978-1-4244-2676-8, DOI 10.1109/MILCOM.2008.4753611)
  • (en) Abd Al Basset Almamou, Raphaela Wrede, Pardeep Kumar, Houda Labiod et Jochen Schiller, « Performance evaluation of routing protocols in a Real-World WSN », Information Infrastructure Symposium, 2009. GIIS '09, IEEE,‎ juin 2009, p. 1-5 (ISBN 978-1-4244-4623-0, DOI 10.1109/GIIS.2009.5307052)
  • (en) Kenneth V. Price, Rainer M. Storn et Jouni A. Lampinen, « Differential Evolution A Practical Approach to Global Optimization », Natural Computing Series, Springer Berlin Heidelberg,‎ 2005, p. 37-134 (ISBN 978-3-540-31306-9, DOI 10.1007/3-540-31306-0)
  • (en) Thomas Clausen et Philippe Jacquet, « The Optimised Routing Protocol for Mobile Ad-hoc Networks: protocol specification », HIPERCOM - INRIA Rocquencourt, Rapport de recherche,‎ mars 2004, p. 1-53 (lire en ligne)
  • (en) P. Kuppusamy, K. Thirunavukkarasu et B. Kalaavathi, A Study and Comparison of OLSR, AODV and TORA Routing Protocols in Ad Hoc Networks,‎ 2011 (DOI 10.1109)
  • (en) Leonard Barolli, Makoto Ikeda, Giuseppe De Marco, Arjan Durresi et Fatos Xhafa, « Performance Analysis of OLSR and BATMAN Protocols Considering Link Quality Parameter », AINA '09 Proceedings of the 2009 International Conference on Advanced Information Networking and Applications,‎ 2009, p. 307-314 (ISSN 978-0-7695-3638-5)
  • (en) Paul Amrita Bose et Nandi Sukumar, Modified Optimized Link State Routing (M-OLSR) for Wireless Mesh Networks,‎ 17-20 décembre 2008 (ISBN 978-0-7695-3513-5)
  • (en) Thierry Plesse, Jérôme Lecomte, Cedric Adjih, Marc Badel et Philippe Jacquet, « OLSR Performance Measurement in a Military Mobile Ad-hoc Network », Ad Hoc Networks, vol. 3,‎ 2004, p. 575-588

Articles connexes[modifier | modifier le code]

  • Topologie mesh
  • Babel
  • Freifunk (en), un firmware basé sur OpenWRT utilisant OLSR. Il est conçu pour établir des réseaux mesh extérieurs avec des AP WiFi, comme le Linksys WRT54G.

Liens externes[modifier | modifier le code]