Résumé de l'article[modifier | modifier le code]

Ci-dessous, le résumé collectif de Florent Fouquet, Thomas Baert, Mahmoudi Oussama, et Clément Mondon de l'article concernant OLSR (oldid=73095725).

Optimized link state routing protocol[modifier | modifier le code]

Le protocole[modifier | modifier le code]

Classe[modifier | modifier le code]

Dans le domaine des MANETs, il existe deux classes de protocoles : les réactifs, qui doivent systématiquement demander leurs routes en inondant le réseau et les pro-actifs, qui s'assurent que chaque nœud possède à tout moment les informations nécessaires relatives à la topologie du réseau.

Caractéristiques techniques[modifier | modifier le code]

Le protocole OLSR est une variation du LSR (en anglais « Link State Routing » ) spécialement désigné pour les MANETs. La principale différence est l'utilisation de relais multipoint (MPR) par OLSR. Dans OLSR, l'information d'état de lien est produite seulement par des nœuds élus comme MPRs, 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.

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. Pour accomplir cela, chaque nœud diffuse périodiquement ses messages BONJOUR contenant les informations sur ses voisins et leur état de lien.

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. 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.

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

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.

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. Ils sont utilisés pour relier les adresses des interfaces OLSR et les adresses principaux pour des nœuds OLSR à interfaces multiples

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

Les messages HELLO et TC peuvent être emballés dans le même paquet. Cela permet l'émission de plusieurs messages en même temps sur le réseau.

Les relais Multipoints[modifier | modifier le code]

L'idée des relais multipoint est de minimiser l'inondation de paquets de diffusion dans le réseau. Chaque nœud sélectionne un ensemble de nœuds dans son voisinage, qui retransmet ses paquets. Cet ensemble de nœuds voisins est appelé le relais multipoint de ce nœud (MPR). Les relais multipoint sont choisis de manière à couvrir (en termes de portée) tous les nœuds qui sont situés à deux nœuds de distance.

Définition[modifier | modifier le code]

Soit N, l’ensemble des noeuds voisins de 1 saut (répondant au message «Hello») du noeud courant, pour lequel on veut déterminer le MPR. On récupère N2 : ensemble des noeuds voisins des noeuds voisins : Noeuds accessibles par 2 sauts. Cela implique les noeuds vont déclarer leurs voisins à 1 saut à leurs voisins à 1 saut. Le noeud courant saura donc quel noeud contacter pour joindre un noeud à 2 sauts. Un lien asymétrique est détecté grâce aux messages «Hello» mais ne sera pas utilisé tant qu’il ne devient pas symétrique (ou bidirectionnels).

Algorithme[modifier | modifier le code]

Pour tous les voisins à 1 saut (N), on calcule son degrés D (?) Pour tous les voisins à 2 sauts N2, si il n’existe qu’un seul lien bidirectinnel, on définit le noeud intermédiare (voisin à 1 saut ) comme MPR. Si il existe plusieurs liens bidirectionnels, on choisi le MPR en maximisant D. On supprime ensuite tous les autres noeuds de N2 joignables par le MPR (il sont maintenant reliés grâce au MPR)

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

Soit les nœuds C et F voisins à 1 saut de B, couvrant l'ensemble des nœuds voisins à deux sauts. Le nœud C est sélectionné en tant que MPR car le nœud C a 5 voisins alors que le nœud F n’en possède que 4 (le degré de C est supérieur au degré de F)

Sécurité[modifier | modifier le code]

Le protocole OLSR est vulnérable à différents types d'attaques que se soit par l’absence de point d'accès pour la connection au réseaux, l'utilisation d'une topologie dynamique ou l'absence de duplication de l’information.

Types d'attaques[modifier | modifier le code]

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

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

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 noeuds du réseau.

Brouillage[modifier | modifier le code]

Le brouillage consiste à générer une grande quantité d'interférences radio ce qui entraîne alors l'impossibilité pour les noeuds de s'échanger des informations.

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

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ôles sont envoyés.

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

Usurpation d'identité avec un message HELLO
Corruption des données du message HELLO
Usurpation d'identité d'un nœud avec un message TC
Corruption des données avec un message TC

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

Les nœuds relais peuvent trafiquer les messages TC pendant leur transfert, en ajoutant ou supprimant des MPRs.

Protections[modifier | modifier le code]

Le protocole peut-être sécurisé d’un coté au niveau de l’authentification et du chiffrement pour prévenir les attaques externes, et de l’autre au niveau de la détection d'intrusions et des méthodes de communication pour protéger le réseau d'attaques internes.

Authentification[modifier | modifier le code]

Il est possible de définir une autorité de certification distribuée, ou bien de garantir la provenance des messages et leur intégrité par un système de signature. Mais l’utilisation de clefs peut-être lourde à gérer.

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

Propriété 1 : Une message HELLO contient tous les voisins situés à un saut du noeud qui l'envoie, tandis qu'un message TC contient les sélecteurs de MPR du noeud.
Propriété 2 : Si un noeud MANET reçoit un message TC le listant comme un sélecteur de MPRs, alors celui à l'origine de ce message doit être dans le voisinage de ce noeud.
Propriété 3 : Si une noeud MANET reçoit un message TC de ses voisins ayant pour information qu'il est un sélecteur de MPRs, ce noeud doit d'abord avoir énuméré l'envoyeur du message comme un MPR dans son message HELLO.
Propriété 4 : Tous les messages TC transférés ont un contenu identique.

Performances[modifier | modifier le code]

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

B.A.T.M.A.N. : Vise à régler problème de synchronisation des messages TC et des informations relatives aux routes contenues dans chacun des noeuds
CE-OLSR : est une version basée sur OLSR mais intégrant la localisation des noeuds.
M-OLSR : est une variante d'OLSR modifiant le protocole afin de fournir de meilleures performances au sein de WMNs.

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

Qualité de service[modifier | modifier le code]

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 noeuds composant des MANETs elle n’est pas présente nativement dans OLSR.

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

Le comportement défini par la RFC d'OLSR indique que cette sélection s'effectue sur base du nombre de voisins, le noeud élu en tant que MPR étant celui possédant le plus de voisins à 2 sauts. Cette méthode de sélection ne prend cependant pas en compte la qualité des liens inter-connectant les noeuds, ce qui dans une optique de qualité de service est pourtant un des points les plus critiques.

Algorithme par défaut[modifier | modifier le code]

Dans sa version originale, OLSR ne prend pas en compte la bande passante disponible pour chaque lien mais celui qui possède le plus de connexions avec les autres noeuds.

Algorithme modifié #1[modifier | modifier le code]

Lorsqu'il existe plus d'un noeud à un saut, mais qu'ils couvrent tous le même nombre de noeuds à deux sauts, c'est celui qui possède la plus grande bande passante qui est élu MPR.

Algorithme modifié #2[modifier | modifier le code]

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

Algorithme modifié #3[modifier | modifier le code]

La troisième modification de l'algorithme compare chaque chemin vers chaque autre noeud 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 noeuds

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, elle peut aussi provoquer l'arrêt brutal d’un noeud. Cependant 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 à partir de l’information des liaisons unicast du réseau. Le protocole EE-OLSR établit ces mécanismes :

Mécanisme basé sur la volonté d’émettre.
Mécanisme de l’exclusion de l’écoute.
Prise en compte de l’énergie pour les paquets à transmettre.

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 noeuds avec peu d'énergie restante et de réduire la surcharge. Dans un cadre un peu différent des deux autres le protocole DE-OLSR à été conçu pour des réseaux ad-hoc VANET.

Comparaison entre protocoles[modifier | modifier le code]

Comparaison non exhaustive avec d’autre protocoles de routage dans les réseaux mobiles.

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

Les performances de OLSR se révèle meilleurs lorsque le trafic est faible pour le ratio de paquet délivré, et lorsque le nombre de noeud restent modeste pour la surcharge du trafic.

DSR, AODV & OLSR[modifier | modifier le code]

OLSR est meilleur pour les sources CBR (tels que la VOIP), car il garantit des délais plus courts que les protocoles réactifs. En revanche, OLSR consomme beaucoup plus de bande passante parce qu’il maintient en permanence ses routes disponibles. Des tests montrent également que les protocoles réactifs sont plus adaptés qu'OLSR dans le domaine de la copie de données.

OLSR, AODV & TORA[modifier | modifier le code]

TORA est un protocole Hybride entre réactif et pro-actif. Il présente l’avantage sur les deux autres protocoles de permettre le routage multiple, mais ne permet pas le multica st. Il consomme un peu plus de bande passante qu’OLSR, mais ne requiert pas de séquence de données. TORA utilise des paquets de mise à jour des routes.

Implémentations[modifier | modifier le code]

Il existe des implémentations logicielles et matérielles, puisque OLSR est au niveau de la couche 3, il est hautemant portable, et il peut être exécuté sur de nombreux systèmes standards.

Il existe des implémentations logicielles dans différents langages (C, C++, Python), comprenant des spécifications supplémentaires détaillées dans l’article comme le QoS, ou encore l’IPv6.

Il existe des implémentations matérielles dont le but est de tester le protocole OLSR lui-même, mais aussi des routeurs sans-fils de chez Cisco ou 4G System, ou encore des assistants personnels comme iPAQ ou des téléphones sous Linux Maemo ou Android G1.

Commentaires et Remarques[modifier | modifier le code]

Nous pensons qu'il s'agit d'un très bon article concernant non seulement le protocole OLSR mais aussi tout ce qui lui est lié dans la mesure où cela permet au lecteur de mieux évaluer la portée et les implications de l'utilisation du protocole.

La vulgarisation, permettant à un lecteur non averti de comprendre l'idée générale, le rôle du protocole, ainsi que son positionnement par rapport aux besoins et aux dernières innovations technologiques, nous est apparue pertinente et relativement accessible.

En dehors de quelques imprécisions qu'un lecteur intéressé saura combler, l'explication technique du protocole, de son fonctionnement, de ses algorithmes est précieuse et bien détaillée à l'aide d'exemple pertinents et sourcés.

La comparaison avec d'autres protocoles,le positionnement d'OLSR lui-même (sa classe), ainsi que les améliorations envisagées pour combler ses «faiblesses» (Qos...) permettent une vision globale du protocole, appréciable pour comprendre les enjeux et la portée du sujet.

L'application dans la rédaction de certains paragraphes (syntaxe et orthographe) ainsi que la pertinence de la struture laissent malheureusement parfois à désirer.

Modèle:Qualité

Problèmes structurels[modifier | modifier le code]

Liens morts[modifier | modifier le code]

9 ? Kuppusamy 2011, p. 143
8 ? a, b, c, d et e Adjih 2005, p. 5
21 ? a, b, c, d, e, f et g Adjih 2003, p. 3
33 ? a, b et c Leonard Barolli 2009, p. 3
37 ? Mohamed Belhassen 2011, p. 155
38 ? a, b et c Amrita Bose Paul 2008, p. 147
59 ? Abd Al Basset Almamou 2009, p. 1
60 ? Abd Al Basset Almamoup 2009, p. 3
61 ? a et b Abd Al Basset Almamoup 2009, p. 4
62 ? a, b et c Dr Chandra Shekar Reddy Putta 2010, p. 376
64 ? a, b et c Kuppusamy 2011, p. 147

Parties de textes sans références[modifier | modifier le code]

Caractéristiques techniques :

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.

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és 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és pour sécuriser le protocole. Des évolutions ont été réalisés au cours des études des performances du protocole en termes de qualité de service et de consommation énergétique, suivant les différentes implémentations matérielles et logicielles.

Sommaire mal structuré[modifier | modifier le code]

trop long
Il n'est pas bien équilibré : pour un sous titre des fois on ne trouve rien et des fois on trouve 4 ou 5 sous sous titre.

Partie du texte où il manque des références[modifier | modifier le code]

Des grands paragraphes de 8 ou 9 phrases qui donnent plusieurs informations avec un seul référence

Exemple : (8 phrase) 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 correspondent à des nœuds qui font discrètement disparaître le trafic 31.

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.43

Dans la section "Classe" : il y a que des petites phrases séparées et une phrase sans réference :

L'utilisation d'un protocole de cette catégorie au sein d'un MANE .... (c'est pas grave je pense on peut faire a référence 8, sinon on clique sur 8 le lien marche pas! on doit chercher à l'auteur adjih-2004), En plus il ont utilisé deux publication pour cet auteur adjih (2005 et 2003) main on trouve une seul publication en plus elle est en 2004, En plus on doit prendre le nom du premier auteur qui est 'Plesse'.

Pareil dans la section: Types d'attaques

Chaque nœud a pour rôle premier de générer du trafic propre au protocole de routage .... sans référence.

Dans la section Brouillage :

OLSR est vulnérable au brouillage (pourquoi?) c'est d'ailleurs le cas pour tous les autres protocoles de routage utilisés sur réseaux ad-hoc.(Donnez nous la preuve la référence!)

Des fois une seule référence en milieux : (par exemple dans la section 'Envoi de messages de mises à jour invalides').

Dans Sélection des MPR :

A 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 la section "types de message" :

un sous titre avec un référence : Datagramme 16, Datagramme 17. sans phrase.

Des fois des titres avec que des elements sans explication :

Implémentations Logicielles 1,2,3

Pour les Articles scientifique[modifier | modifier le code]

77 ? Meraihi 2004, p. 110 :

Ils n'ont pas indiqué si l'article était en francais ou en anglais et quand on consulte le texte integrale on ne trouve pas l'information dans la page indiquée 110 (une these et pas une publication)

3 ? Naimi 2003, p. 5 :

Idem. Problème de page

Pour la référence 10 ↑ a, b, c, d, e, f, g et h Wang 2005, p. 56 : (utlisé 8 fois) quand on voit l'article à partir du lien DOI donné on trouve un article de 6 pages.