Évaluation de protocoles de routage ad hoc sur système Android

Transcription

1 Université de Mons Faculté des Sciences Année académique Évaluation de protocoles de routage ad hoc sur système Android GEORIS Antoine 2 e MASTER Informatique Mémoire réalisé sous la direction de M. Bruno Quoitin Service des Réseaux et Télécommunications Mons, le 20 août 2012

2

3 Remerciement Je remercie mon directeur de mémoire, Bruno Quoitin, pour m avoir guidé tout au long de mon travail de recherche. Je tiens aussi à remercier Maëlick Claes et Anne Debelle pour leur temps passé à la relecture de ce rapport.

4 Résumé Ce projet, réalisé dans le cadre d un mémoire de deuxième année de master en Sciences Informatiques à l Université de Mons, propose une analyse de différents protocoles de routage ad hoc sur système Android. Le principal problème traité est la mise en place d une chaîne d application permettant cette analyse. Cette chaîne d application est composée d un ensemble d émulateurs Android, chacun faisant tourner un protocole de routage. Ces émulateurs sont reliés entre-eux via un simulateur de réseau sans fil qui permet de simuler leurs positions et leurs déplacements. Différents modèles de propagation sont inclus à ce simulateur afin que l exécution des tests soit aussi proche que possible de la réalité. Un testbed est exécuté sur chaque émulateur Android et permet de placer chaque protocole dans des conditions d utilisation identiques et de récupérer des logs sur leur exécution. Le but de ce travail est de déterminer si un protocole de routage ad hoc est approprié pour les smartphones. Une première conclusion est proposée après une analyse théorique de différents protocoles. Ensuite, des tests sont exécutés à partir d un ensemble réduit de protocoles pour confirmer ou infirmer ces conclusions. Enfin, si un protocole semble être approprié pour les smartphones, d éventuelles améliorations sont proposées.

5 Table des matières Introduction 3 1 Présentation du problème Concepts de base des réseaux informatiques Routage dans les réseaux informatiques Réseaux mobiles ad hoc Définition du problème État de l art Protocoles de routage ad hoc Classes de protocoles ad hoc Principes de routage Protocoles à état de liens Protocole à vecteur de distances Protocoles proactifs OLSR B.A.T.M.A.N DSDV Protocoles réactifs AODV DSR Récapitulatif Testbeds APE DES-SERT Simulateurs de réseaux sans fil Modèles de propagation Modèle Free Space Modèle Two Ray Ground Modèle de Nakagami Simulateurs J-Sim OMNeT ns

6 OPNET Modeler Logiciels de traitement de paquets Click Smartphones et système Android Caractéristiques logicielles Caractéristiques matérielles Choix effectués Testbed Configuration Portage sur Android Récupération de données Simulateur de réseau sans fil Fonctionnement général Détails techniques Utilisation Communications entre émulateurs et simulateur Vision globale de la chaîne d applications Test de la chaîne d applications Configuration de la chaîne d application Configuration des testbeds Paramètres initiaux Données récoltées Configuration des émulateurs Configuration du simulateur et du switcher Exécution des tests Variation du nombre de noeuds Évolution du voisinage Évolution des échanges de messages Conclusion Routage de paquets Deux noeuds fixes noeuds fixes Un noeud mobile et un noeud fixe Conclusion Variation des fréquences d envoi de messages TC Conclusion Figures Conclusion 72 Annexes 75 A Puissances des émetteurs et récepteurs sans fil 76 2

7 Introduction Sur les smartphones, et plus particulièrement ceux tournant sur le système Android, la plupart des applications permettant la communication entre différents appareils, par exemple pour des jeux, passe souvent par une infrastructure centralisée. Cela a l inconvénient de nécessiter la présence d un point d accès à proximité et de dépendre entièrement de celui-ci, ce qui limite les libertés de mouvement. À l inverse, les applications en mode ad hoc permettent d établir une communication directe entre différents appareils. Ainsi, il suffit que ceux-ci soient à une distance convenable les uns des autres pour pouvoir communiquer. Malgré cette absence de mode ad hoc sur Android, il existe une grande variété de protocoles qui permettent cette communication et de nombreuses implémentations existent dans la littérature. Ces protocoles sont utilisés dans d autres contextes, par exemple lors de meetings pour distribuer rapidement des informations dans un auditoire ou lors d opérations de secours lorsque les lignes téléphoniques sont coupées [19]. Ces protocoles ont chacun leurs avantages et leurs inconvénients et il serait donc intéressant de les tester dans diverses situations liées à la mobilité pour voir si certains protocoles sortent du lot. Il peut, par exemple, être intéressant de calculer l impact d une variation du nombre de noeuds ou de d une mobilité importante. Pour ce faire, des testbeds peuvent être utilisés pour récolter des données sur l exécution des protocoles, afin de réaliser des analyses de performance. Malgré tout, une analyse sur de véritables terminaux reste assez compliquée car cela nécessiterait d être en possession d une quantité importante d appareils pour pouvoir tirer des conclusions intéressantes. Pour contourner ce problème, les tests peuvent être lancés sur des émulateurs Android comme celui fourni par Google [20]. Ceux-ci sont très semblables aux appareils physiques et fonctionnent de la même manière du point de vue des communications. Étant donné que tous ces émulateurs sont lancés sur la même machine, un simulateur de réseau sans fil peut être utilisé pour simuler un réseau virtuel. Cela permettrait également d exécuter des scénarios pour simuler le déplacement des différents émulateurs. 3

8 Le mémoire se présente comme suit. Le Chapitre 1 présente en détail le problème posé. L état de l art sur les différents protocoles, testbeds et simulateurs de réseau est développé dans le Chapitre 2. Le Chapitre 3 présente les choix effectués au sein de l état de l art et les implémentations réalisées. Le Chapitre 4 détaille la configuration des différentes applications utilisées. Le Chapitre 5 détaille la mise en place des tests et les résultats de leur exécution. Enfin une conclusion sur les différentes données analysées est proposée en fin de document. 4

9 Chapitre 1 Présentation du problème Dans le monde des réseaux et des télécommunications, il existe un grand nombre de protocoles pour s échanger des données, chacun a ses avantages et ses inconvénients, certains protocoles pouvant très bien fonctionner dans un environnement particulier mais ne pas être optimaux dans un autre. Parmi ceux-ci, il existe les protocoles de routage. Ces derniers permettent de déterminer les chemins à emprunter pour relier deux noeuds d un réseau. Plus particulièrement, nous nous intéressons aux protocoles de routage ad hoc. Ceux-ci vont être étudiés et comparés afin de déterminer s il peuvent être introduits sur des appareils mobiles. Les Sections 1.1, 1.2 et 1.3 décrivent respectivement les concepts de base des réseaux informatiques, le routage dans les réseaux informatiques et le concept de réseau mobile ad hoc. La Section 1.4 présente le problème posé et les objectifs du travail. 1.1 Concepts de base des réseaux informatiques Un réseau informatique est un ensemble d appareils reliés entre-eux dans le but de s échanger des données. Dans un réseau informatique, les appareils sont appelés des noeuds. On peut distinguer deux types de noeuds : les noeuds terminaux qui envoient et reçoivent des données (p. ex. les ordinateurs, les serveurs, les smartphones), et les routeurs qui relayent ces données. On dit qu il existe un lien entre deux noeuds si ceux-ci sont susceptibles de se contacter. Si l un des deux noeuds est capable de contacter l autre, on parle de lien unidirectionnel. Si les deux noeuds sont capables de se contacter mutuellement, on parle de lien bidirectionnel. Si un lien unidirectionnel existe entre deux noeuds, un coût peut être associé à celui-ci. Un lien bidirectionnel peut donc se voir attribuer deux coûts : un pour chaque direction. Ce coût peut indiquer la bande passante du lien, la distance entre les noeuds, la qualité du lien, 5

10 etc. La façon dont sont organisés les différents noeuds et leurs interconnexions est appelée topologie du réseau. Des changements de topologie sont possibles et peuvent être introduits manuellement en modifiant des liens entre des noeuds, ou accidentellement dans le cas de liens ou des noeuds défaillants, par exemple. La Figure 1.1 représente un réseau informatique constitué de 4 routeurs et de 3 noeuds terminaux (un ordinateur, un smartphone et un serveur), reliés entre-eux par 8 liens bidirectionnels. Chaque lien est associé à un coût. routeurs noeuds terminaux FIGURE 1.1 Réseau informatique filaire Dans un réseau sans fil, d autres concepts plus spécifiques peuvent apparaître. En effet, le fait que les noeuds doivent communiquer via des ondes radios pose quelques contraintes. Premièrement, la composition d un noeud sans fil est différente d un noeud classique. Celui-ci est composé d un émetteur et d un récepteur sans fil. L émetteur est caractérisé par une puissance d émission et le récepteur est caractérisé par une sensibilité de réception. Pour qu un noeud puisse interpréter un signal, il faut que la puissance reçue soit supérieur à la sensibilité du récepteur 1. Ensuite, des interférences peuvent apparaître lorsque plusieurs noeuds émettent en même temps. Dans ce cas, les données envoyées peuvent être corrompues, c est pourquoi des protocoles de contrôle d accès au média sont mis en place tel que CSMA/CA où les noeuds doivent demander l autorisation pour émettre. Un autre problème peut se poser lorsqu un noeud détecte la présence d un autre noeud, mais que ce dernier ne détecte pas la présence du premier. On est alors dans le cas d un lien unidirectionnel. Il s agit du problème du terminal caché. Cela peut se produire, par exemple, lorsque les deux noeuds n ont pas la même puissance d émission. D autres problèmes peuvent survenir au niveau de la fiabilité des échanges de données. Tout d abord, la puissance du signal est amenée à diminuer 1. Les détails concernant émetteurs et récepteurs sans fil sont repris en Annexe A. 6

11 exponentiellement avec la distance. Ensuite, de nombreux facteurs environnementaux peuvent interférer avec les ondes. Il peut s agir d éléments matériels comme des murs, meubles, appareils, phénomènes météorologiques comme la pluie, etc. Dans ce cas, la puissance du signal peut être affaiblie en traversant l objet et une partie des ondes peuvent être réfléchies ou diffractées. Ces comportements peuvent mener au problème de multi-chemin : étant donné que les ondes sont propagées tout autour de l émetteur, celles-ci peuvent arriver à un même point à des instants différents, suite à des réflexions sur des murs par exemple. Enfin, des interférences peuvent se produire au croisement d autres ondes. Dans ce cas, les ondes peuvent être additionnées ou soustraites selon leur direction. La plupart du temps, ces modifications entraînent des corruptions de données. Dans les réseaux sans-fil, le coût entre deux noeuds peut représenter, par exemple, la qualité de l environnement entre ces deux noeuds. Par souci de lisibilité, les schémas qui suivent ont été représentés avec un rayon de signal fixe, et sans interférences et diminution de la puissance du signal. La Figure 1.2 représente un réseau sans fil sous sa forme physique avec les portées des ondes de chaque noeud et sous sa forme logique avec les coûts des liens. Les zones superposées sont des zones où des interférences peuvent apparaître car des ondes issues de noeuds différents se rencontrent. Tous les liens sont bidirectionnels car chaque couple de noeuds peut se contacter mutuellement. Par exemple, l ordinateur se trouve dans la zone sans-fil du premier routeur, et le premier routeur est lui-même dans la zone sans fil de l ordinateur. Les deux noeuds peuvent donc communiquer entre-eux. Une fois le réseau mis en place, il peut être intéressant que les noeuds communiquent entre-eux, c est le rôle des protocoles de communication. Un protocole de communication est une convention décrivant la façon dont les noeuds d un réseau vont communiquer entre-eux. Cette convention est représentée par un ensemble de règles que chaque noeud doit respecter pour que le dialogue puisse s établir. Ces règles définissent le format des messages qui doivent être échangés et l ordre d échange de ces messages. La communication en question peut servir à établir des connexions entre des noeuds, à échanger des données, à gérer la perte ou la corruption de données, etc. 1.2 Routage dans les réseaux informatiques Lors de l envoi de données d un point du réseau à un autre, il est nécessaire de connaître la route à emprunter pour que ces données arrivent à destination. Il peut arriver que plusieurs routes soient disponibles, ou que certaines deviennent inaccessibles. Des contraintes peuvent également appa- 7

12 Topologie physique C A B D E Topologie logique A B C D E FIGURE 1.2 Réseau informatique sans fil raître : par exemple, il peut être intéressant de trouver la route la plus rapide, ou celle offrant la plus grande fiabilité. Toutes ces caractéristiques sont gérées par les protocoles de routage. Un protocole de routage est un protocole de communication décrivant la façon dont les noeuds d un réseau vont communiquer entre-eux afin de déterminer les routes à emprunter pour relier deux noeuds du réseau. Ainsi, un protocole de routage doit être capable de : distribuer et récupérer des informations sur la présence et la joignabilité d une partie ou de l entièreté du réseau ; déterminer les meilleures routes pour transmettre des messages via des algorithmes de plus court chemin ; réagir aux changements de topologie. Le premier rôle peut permettre, selon le protocole, de prendre connaissance du voisinage des noeuds du réseau, des types de lien avec ce voisinage, ou encore de générer une carte complète du réseau. Le second rôle permet de trouver les meilleures routes pour relier deux noeuds du réseau. Selon le protocole, un noeud peut stocker l entièreté d une route vers une destination, ou uniquement le prochain voisin à contacter sur une route. Le troisième rôle permet de garantir la continuité des communications entre deux noeuds, lorsque la topologie varie. Les termes suivants sont nécessaires pour une bonne compréhension des protocoles de routage. 8

13 Un paquet est un ensemble de données envoyées par un noeud à destination d un ou plusieurs autres noeuds du réseau. Un paquet contient certaines informations dont l adresse de la destination. Une route est une suite de noeuds à traverser pour relier deux noeuds du réseau. Pour qu une route soit valide, il faut qu un lien existe entre chaque paire de noeuds consécutifs de cette route. Selon les cas, le coût associé à une route peut valoir la somme des coûts des liens parcourus (p. ex. pour des temps de propagation), le coût maximum des liens parcourus (p. ex. pour la bande passante), etc. Un next-hop est le prochain noeud à contacter sur une route. Dans la plupart des cas, chaque noeud appartenant à une route connaît le noeud suivant à contacter. Une table de routage est une table enregistrée par un noeud contenant les next-hops à contacter pour atteindre toutes ou une partie des destinations du réseau. La Figure 1.3 représente un réseau (filaire pour une meilleure lisibilité) contenant 5 noeuds. La route choisie pour aller de A à E est ABDE et a un coût de 5. Localement, les noeuds ne connaissent pas cette route mais uniquement le next-hop qui les concerne. Les tables de routage des noeuds A, B et D sont remplies avec les next-hop locaux pour atteindre le noeud E. Supposons que le noeud A souhaite envoyer un paquet à destination de E. Le noeud A regarde dans sa table de routage le next-hop pour atteindre E, qui est le noeud B. Le noeud A envoie donc le paquet au noeud B qui recherche à son tour dans sa table de routage le prochain next-hop, qui est le noeud D. B envoie le paquet au noeud D qui cherche dans sa table de routage le nexthop pour atteindre E. Le next-hop est le noeud E, par conséquent D envoie le paquet au noeud E. Le paquet est arrivé à destination. dest E n-h B A C 4 route dest E B n-h D 2 3 D E 1 dest n-h E E tables de routage FIGURE 1.3 Tables de routage, next-hop et routes 9

14 Dans cet exemple, le plus court chemin pour relier les noeuds A et E passe par les noeuds B et D et a un coût de 5. Pour trouver cette route, le protocole de routage doit commencer par récolter des informations sur la topologie du réseau. Cela peut signifier que chaque noeud doit découvrir l entièreté, ou une partie du réseau. Par exemple, il est important que le noeud A connaisse la présence de son voisin B pour pouvoir communiquer avec lui. Une fois les informations nécessaires obtenues, chaque noeud peut générer ou mettre à jour sa table de routage. Grâce à cette table, le noeud A sait qu il doit contacter le noeud B pour envoyer un paquet au noeud E. Enfin, il peut arriver que des changements de topologie interviennent. C est le cas, par exemple, si le noeud B disparaît ou si le lien entre les noeuds A et B est corrompu. Il faut alors en informer le réseau pour trouver une nouvelle meilleure route pour relier les noeuds A et E. Les nouvelles routes peuvent être, par exemple, ACE ou ACDE, qui ont chacune un coût de Réseaux mobiles ad hoc Globalement, les protocoles de routage peuvent être classés en deux catégories selon l utilisation ou non d une infrastructure dans le réseau. Cette présence signifie que les noeuds terminaux sont reliés par l intermédiaire de routeurs, comme expliqué dans la définition de réseau informatique. Mais il peut arriver que l infrastructure soit inexistante. Dans ce cas, on parle de réseau ad hoc. Un réseau sans fil ad hoc est un ensemble de noeuds sans fil formant un réseau temporaire ne nécessitant pas l utilisation d une infrastructure ou d une administration centralisée [3]. Dans un réseau ad hoc, il n y a donc pas de notion de noeud terminal et de routeur, ici tous les noeuds remplissent globalement les mêmes fonctions : envoyer, réceptionner et relayer des paquets. La Figure 1.4 représente un réseau ad hoc sans fil de 9 noeuds et leurs portées respectives. Les liens unidirectionnels sont représentés par des flèches simples, et les liens bidirectionnels par des flèches doubles. Les noeuds A, D et I ont un lien unidirectionnel avec F car ces trois noeuds peuvent recevoir des données de F mais n ont pas un signal assez puissant pour en envoyer à F. Tous les autres liens sont bidirectionnels car les noeuds en question émettent un signal assez puissant pour se contacter mutuellement. Plus précisément, nous nous intéresserons aux cas des réseaux mobiles ad hoc. Ces réseaux sont caractérisés par une mobilité significative des noeuds : les noeuds étant reliés sans fil, ils peuvent se déplacer librement. Ainsi, un noeud peut très vite se retrouver hors de portée des noeuds auxquels il était relié, ou se trouver à portée de nouveaux noeuds. Ainsi, dans les réseaux mobiles sans fil, les changements de topologie vont surtout se manifester à cause de la forte mobilité et des changements environnementaux, et plus unique- 10

15 Lien unidirectionnel Lien bidirectionnel A B C D E F G I H FIGURE 1.4 Réseau mobile ad hoc ment à cause de pannes ou de changements administratifs. Le fait d être en absence d infrastructure centralisée présente quelques avantages. Tout d abord, la mise en place du réseau est très facile et ne demande pas de configuration de routeur ni d administration : les protocoles de routage ad hoc permettent aux noeuds de se découvrir par eux-mêmes et de réagir aux changements de topologie. De plus, la création de ce type de réseau peut être réalisée en tout lieu et à tout moment. Par contre, les changements fréquents de topologie ajoutent une contrainte plus forte que les simples réseaux ad hoc. De nouveaux protocoles de routage doivent donc être mis en place pour tenir compte de ces nouvelles caractéristiques. 1.4 Définition du problème Du fait de leur mobilité, les smartphones sont un bon exemple d appareils qui peuvent être utilisés pour mettre en place des réseaux mobiles ad hoc. Pourtant, il existe très peu de cas d applications pour smartphone tirant profit des possibilités offertes par ces types de réseaux. La plupart des applications nécessitant la communication entre plusieurs appareils passe par des protocoles basés sur une infrastructure centralisée. Les seules applications profitant d une connexion directe entre appareils utilisent la connexion Bluetooth, qui n est pas du tout optimisée pour créer des réseaux de grande taille (voire de plus de deux noeuds). L utilisation de mode ad hoc pour smartphones pourrait servir, par exemple, dans le cas de développement de jeux multijoueurs, d applications de discussion, de partage de fichiers, etc. Suite à cette faible utilisation des réseaux mobiles ad hoc, il serait intéres- 11

16 sant de pouvoir analyser le comportement de protocoles de routage ad hoc existant sur des systèmes mobiles comme les smartphones. Cela permettrait de déterminer si certains protocoles sont meilleurs dans des situations particulières, et éventuellement de proposer des améliorations aux protocoles testés. Les tests de protocoles peuvent être réalisés via l utilisation des testbeds. Ceux-ci permettent de récolter des données lors de l utilisation d un protocole de routage. Les données à récolter peuvent concerner le temps pour déterminer les routes, l impact de changements fréquents de topologie, d un nombre grandissant de noeuds ou de la taille de paquets. Parmi les principaux systèmes d exploitation proposés sur smartphone tels que ios de Apple, Android de Google, Windows Mobile de Microsoft, BlackBerry OS de RIM et Symbian OS de Nokia, celui qui semble le plus intéressant est le système Android. En effet, celui-ci offre une grande liberté étant donné que son système est ouvert, qu une grande communauté d utilisateurs est présente sur Internet et que son système est en grand partie basé sur Linux. Ainsi, un portage de protocoles ou d une quelconque application déjà existants sur Linux est facilité. Le système Android propose également l utilisation d émulateurs qui facilitent le développement et le débogage. Un émulateur Android propose les mêmes fonctionnalités qu un véritable appareil et est capable de communiquer avec le monde extérieur. Plusieurs émulateurs pourraient être mis en réseau pour évaluer des implémentations de protocoles de routage ad hoc. Le problème avec ces émulateurs est qu ils sont tous lancés sur la même machine. Il n y a donc aucune topologie pour représenter ce réseau d émulateurs. Or, tester des protocoles sur un réseau où tous les noeuds sont au même endroit n a pas le moindre intérêt. C est pourquoi il faut simuler une topologie pour relier ces émulateurs. Cette simulation peut être réalisée via l utilisation d un simulateur de réseau sans fil. Celui-ci permet de définir une topologie, c est-à-dire la position des noeuds, et les caractéristiques des liens entre les noeuds. De plus, ce simulateur a un avantage non négligeable : il va être désormais beaucoup plus facile de définir des scénarios pour effectuer des changements de topologie. Ces scénarios permettent de déplacer les noeuds au cours du temps, impliquant des changement au niveau des liens entre les noeuds. Enfin, un dernier élément doit permettre la communication entre les émulateurs Android et le simulateur de réseau sans fil. Celui-ci doit récupérer les paquets envoyés par les émulateurs, et après avoir consulté le simulateur de réseau sans fil, les aiguiller vers le ou les émulateurs de destination. L objectif du projet est donc d exécuter et d analyser des implémentations de protocoles de routage ad hoc sur système Android afin de déterminer si des protocoles sont prêts à être utilisés sur smartphone. Si nécessaire, une amélioration de ces protocoles pourra être proposée. Ainsi, le problème qui se pose est de lancer un ensemble d émulateurs Android, chacun faisant tourner un protocole de routage ad hoc et un test- 12

17 bed. Parallèlement, un simulateur de réseau sans fil doit s occuper de définir une topologie où les noeuds représentent les émulateurs Android et de gérer des scénarios pour simuler le déplacement de ces noeuds au cours du temps. Enfin, un logiciel de traitement de paquets doit gérer des communications entre les différents composants. La Figure 1.5 représente un schéma des différentes applications qui vont devoir être utilisées. Machine Hôte Émulateur A Émulateur B Testbed Testbed A B paquet ❶ ❹ paquet A B Traitement des paquets source=a, destination=b demander au simulateur si B capte A B capte A? ❷ ❸ oui Simulateur de réseau sans fil B A FIGURE 1.5 Présentation des différentes applications 13

18 Chapitre 2 État de l art Ce chapitre décrit les protocoles de routage en réseau ad hoc dans la Section 2.1, les testbeds pour protocoles de routage dans la Section 2.2, les simulateurs de réseaux sans fil dans la Section 2.3 et les logiciels de traitement de paquets dans la Section 2.4. Enfin, la Section 2.5 décrit les caractéristiques des smartphones et du système Android. 2.1 Protocoles de routage ad hoc Il existe une grande variété de protocoles de routage, répartis selon la façon de partager l information, la façon de choisir les meilleures routes, etc. Il est bien sûr important que tous les noeuds d un réseau exécutent le même protocole de routage pour que ceux-ci puissent communiquer entreeux. Nous nous intéressons ici aux protocoles de routage dans les réseaux mobile ad hoc Classes de protocoles ad hoc On peut distinguer deux classes de protocoles de routage ad hoc : les protocoles proactifs et les protocoles réactifs [19]. Les protocoles proactifs (table driven) sont caractérisés par le fait que les noeuds tiennent à jour une table de routage de l ensemble du réseau. Chaque noeud envoie périodiquement des messages sur l ensemble du réseau afin d y informer des variations de topologie. L avantage de ce type de protocole est qu à tout moment, une route entre deux noeuds est connue et peut être utilisée pour acheminer des paquets. L inconvénient est la réaction assez lente aux changements de topologie : si un lien casse entre deux noeuds, le réseau doit attendre de recevoir l information sur le changement de topologie pour être averti du problème. 14

19 Les protocoles réactifs (on demand) sont caractérisés par le fait que, contrairement aux protocoles proactifs, les noeuds ne tiennent pas à jour de tables de routage. Lorsqu un noeud souhaite contacter un autre noeud, il fait une demande de route à ses voisins, qui eux-mêmes demandent à leurs voisins, jusqu à tomber sur un noeud connaissant l information. Le principal inconvénient est le temps nécessaire pour obtenir l information sur une route. Par contre, l avantage est que ce type de protocole réagit très bien aux changements de topologie : le noeud faisant la demande de route obtient toujours une route à jour. De plus, l espace mémoire nécessaire pour stocker les tables de routage est faible Principes de routage Il existe deux grands principes de routage dont la majorité des protocoles s inspire. Ces principes déterminent la manière de trouver les meilleures routes et sont appelés les protocoles de routage à état de liens et les protocoles de routage à vecteur de distances Protocoles à état de liens Dans les protocoles à état de liens, chaque noeud connaît à tout moment la topologie complète du réseau, c est-à-dire l état des liens existant entre chaque couple de noeuds du réseau. L ensemble du réseau peut être comparé à une carte routière. À chaque intersection (c.-à-d. les noeuds du réseau), il faut déterminer quelle est la meilleure direction à prendre (c.-à-d. la liaison vers un noeud voisin) pour atteindre une certaine destination. Pour ce faire, chaque noeud envoie à l ensemble du réseau tous les noeuds auxquels il est relié. Sur base de ces informations, chaque noeud peut calculer indépendamment le meilleur next-hop pour atteindre chaque destination. Il est possible que certaines routes changent, apparaissent ou disparaissent. Dans ce cas, il faut en informer l ensemble du réseau. Voici comment se déroulent les communications au sein de ce type de protocole, comme expliqué par J. Doyle [6]. On peut distinguer trois phases : la découverte du voisinage, la distribution de la topologie et la détermination des meilleures routes. 1. Découverte du voisinage Les messages HELLO sont utilisés pour gérer le voisinage sur le réseau. À intervalles réguliers, chaque noeud broadcaste un message HELLO pour avertir de sa présence. Une fois que deux noeuds se sont découverts mutuellement, ils se considèrent chacun comme voisins. Ces messages servent aussi à détecter la disparition de noeuds et les défaillances de liens : si un noeud n a pas reçu de message HELLO d un de ses voisins endéans un certain temps, le lien avec ce voisin est considéré comme rompu. 15

20 2. Distribution de la topologie Pour distribuer les informations sur l état du réseau, chaque noeud broadcaste un message LSA (Link State Advertisement) à intervalles réguliers. Ce type de message contient l identifiant du noeud originaire du paquet, une liste de tous les voisins de ce noeud et un numéro de séquence incrémenté à chaque nouvel envoi. Lorsqu un noeud reçoit un LSA, il sauvegarde les informations sur le noeud d origine du message ainsi que sur l ensemble de ses voisins. Ensuite, il rebroadcaste le message LSA à son tour. Il peut arriver qu un même noeud reçoive plusieurs messages LSA d une même origine. Dans ce cas, le numéro de séquence présent dans le message est utilisé pour déterminer si celui-ci a déjà été traité ou non. Pour ce faire, chaque noeud enregistre dans une table l identifiant du noeud ayant envoyé le message et le plus grand numéro de séquence reçu. Si un paquet est reçu avec un numéro de séquence inférieur à celui enregistré, c est qu il a déjà été traité. Par la suite, à partir de toutes les informations récupérées, chaque noeud est capable de générer une carte du réseau comprenant l ensemble des noeuds connus et leurs interconnexions. Cette carte doit être mise à jour à chaque réception d un nouveau message TC contenant des modifications de topologie. 3. Détermination des meilleures routes Une fois la carte du réseau générée, chaque noeud peut déterminer les meilleurs next-hops pour atteindre chaque destination. Pour ce faire, des algorithmes de calcul de plus court chemin sont utilisés tel que l algorithme de Dijkstra. Une table de routage contenant les next-hops pour chaque destination du réseau est maintenue et mise à jour à chaque modification de la carte du réseau. Il s agit là de l intuition de base pour tout protocole de routage à état de liens. Énormément de protocoles sont basés sur ce modèle, les plus utilisés étant IS-IS [15] et OSPF [13]. Le principal avantage de ce type de protocole est qu à tout moment, le meilleur next-hop pour atteindre tout noeud du réseau est connu. On a donc une propagation très rapide des paquets au sein du réseau. Par contre, ce type de protocole a une réaction assez lente aux changements de topologie, étant donné qu il faut attendre la réception de nouveaux messages LSA pour connaître les mises à jour à effectuer. De plus, la quantité d informations à maintenir à propos du réseau peut être très importante. Au niveau des réseaux sans fil, ce protocole a d autres défauts. Dans le cas des réseaux sans fil mobiles, les changements très fréquents de topologie mènent à l utilisation de routes rapidement périmées. De plus, les broadcasts de messages peuvent vite provoquer de la congestion sur le réseau et encouragent les risques d interférences de signal. C est pourquoi d autres protocoles ont du être inventés afin de remédier à ces problèmes. Les protocoles OLSR et B.A.T.M.A.N. sont basés sur le protocole LSR et proposent certaines optimisations propres aux réseaux mobiles sans fil. Ceux-ci sont présentés dans la Sous-section

21 Protocole à vecteur de distances Dans les protocoles à vecteur de distances, la table de routage d un noeud est calculée en fonction des tables reçues par ses voisins. Comme son nom l indique, ce protocole fonctionne selon une notion de distance. Chaque noeud enregistre dans sa table de routage les next-hops et les distances nécessaires pour atteindre toutes les destinations du réseau. Selon le protocole, cette distance peut être le nombre de hops, la bande passante, etc. À chaque modification de sa table de routage, le noeud broadcaste celle-ci. Cette table peut être modifiée lorsqu une autre table a été reçue d un voisin, ou lorsque le noeud a détecté un changement de topologie dans son voisinage. Lorsqu un noeud reçoit une table de routage d un de ses voisins, il recalcule les routes les plus courtes pour chaque destination. Ces calculs sont effectués via l équation de Bellman-Ford. Ci-après est présenté le fonctionnement global du protocole à vecteur de distances comme expliqué par J. Doyle [6]. Ensuite, les différents problèmes qui peuvent se produire sont détaillés grâce à des exemples illustrés. Vecteur de distances Les vecteurs de distances sont des messages utilisés pour distribuer les informations à propos du réseau. À la création du réseau, chaque noeud crée une table de routage contenant son propre identifiant comme destination et next-hop et un coût associé nul. À intervalles réguliers, chaque noeud envoie sa table de routage à ses voisins via des vecteurs de distances. Le nom de ces messages est issu du fait qu ils peuvent être vus comme des vecteurs où la direction est le voisin à contacter et la distance est le nombre de hops à effectuer pour atteindre la destination. Lorsqu un noeud réceptionne un tel message, il utilise l équation de Bellman-Ford pour déterminer si la table de routage actuelle doit être mise à jour avec celle reçue de son voisin. Si la table est mise à jour, le noeud envoie sa nouvelle table à ses voisins. Ce processus continue tant que des mises à jour sont à réaliser par les noeuds. Une fois que tous les noeuds ont obtenu les informations sur les meilleures routes, le réseau est stabilisé. Si un noeud détecte un changement de topologie, c est-à-dire que l un de ses voisins n est plus accessible, le noeud indique son voisin comme inaccessible dans sa table de routage, partage celle-ci à son voisinage et l information est transmise sur l ensemble du réseau. La Figure 2.1 illustre cet échange de tables de routage lors de l initialisation du réseau et l arrivée de nouveaux noeuds. Dans cet exemple, les coûts des liens sont tous unitaires. Poisoned reverse L un des défauts de cette méthode est qu elle peut mener à la création de boucles de forwarding. En effet, la Figure 2.2 montre un exemple de réseau stabilisé. Supposons que le lien DE casse, D doit en informer le réseau. D indique la destination E comme inaccessible dans sa table de routage en t 1 et attend le temps nécessaire avant d envoyer un vecteur de distances. Pendant ce temps, en t 2, D reçoit un vecteur de distances de C indiquant qu il peut accéder à E via 3 sauts. D n ayant plus de next-hop pour 17

22 t 0 A B C D A A 0 B B 0 C C 0 D D 0 < A, A, 0 > VD t 1 A B C D A A 0 B B 0 A A 1 C C 0 D D 0 < B, B, 0 >, < A, A, 1 > < B, B, 0 >, < A, A, 1 > VD VD t 2 A B C D A A 0 B B 1 B B 0 A A 1 C C 0 B B 1 A B 2 D D 0 < C, C, 0 >, < B, B, 1 >, < A, B, 2 > < C, C, 0 >, < B, B, 1 >, < A, B, 2 > VD VD t 3 A B C D A A 0 B B 1 B B 0 A A 1 C C 1 C C 0 B B 1 A B 2 D D 0 C C 1 B C 2 A C 3 d=destination, n=next-hop, #=nombre de hops, VD=vecteur de distances les tables mises à jour sont colorées en gris FIGURE 2.1 Découverte du voisinage dans les protocoles à vecteur de distances atteindre E met à jour sa table de routage avec un coût de 3 et le next-hop C. Pour la première fois depuis la rupture de lien, D envoie sa table à C, mise à jour récemment avec un coût de 3. C ne met rien à jour car le coût reçu est plus élevé que le coût enregistré. Supposons maintenant que B souhaite envoyer un paquet à E en t 3. Il regarde dans sa table de routage, le next-hop est C, il lui envoie le paquet. Ensuite C consulte sa table de routage et voit qu il doit envoyer le paquet à D. D consulte à son tour sa table de routage où le next-hop pour atteindre E est C. Le paquet passe donc à C qui le renvoie à D et ainsi de suite indéfiniment. Ce problème intervient car C a envoyé à D une information qu il avait lui-même obtenue de D. Pour contourner ce problème, on utilise le principe de poisoned reverse. Celui-ci consiste à modifier l information envoyée selon la source de l information reçue. Dans le cas présent, comme C a été informé de D qu il peut accéder à E en 2 sauts, il va modifier le vecteur de distances envoyé à D en indiquant qu il peut accéder à E en un nombre infini de sauts. 18

23 t 0 A B C D E E B 4 E C 3 E D 2 E E 1 E E 0 t 1 A B C D E E B 4 E C 3 E D 2 E - - E E 0 < E, D, 2 > VD t 2 A B C D E E B 4 E C 3 E D 2 E C 3 E E 0 B E p t 3 A B C D E E B 4 E C 3 E D 2 E C 3 E E 0 d=destination, n=next-hop, #=nombre de hops, VD=vecteur de distances, p=paquet les tables mises à jour sont colorées en gris FIGURE 2.2 Boucle infinie dans les protocoles à vecteur de distances Dans ce cas, D ne mettra jamais à jour sa table de routage avec les informations reçues de C à propos de E et ne propagera pas l information à ses voisins. Comptage à l infini Un dernier problème peut survenir, il s agit du comptage à l infini. Prenons l exemple des Figures 2.3 et 2.4. Au départ, le réseau est stabilisé. Supposons que le lien entre D et E casse. D doit modifier sa table de routage et en informer A et C. Une fois ce message reçu, A et C indiquent dans leur table que la destination E est inaccessible. Supposons ensuite que B envoie sa table de routage à A et C avant d avoir été informé du problème. Ces derniers vont avoir un coût de 4 pour atteindre E via B. Ils mettent à jour leur table et envoient l information à D. D met à jour sa table avec un coût de 5 et le next-hop selon la première information reçue. Pendant ce temps, B est averti de la défaillance de lien et indique la destination E comme inaccessible. Et ainsi de suite, l information sur l inaccessibilité de E va tourner dans la boucle A/B/C/D en même temps que le vecteur de distances dont le coût ne cessera d augmenter indéfiniment. Dans cet exemple, le principe de poisoned reverse ne permet pas de régler le problème. Au départ, A et C ont obtenu la route vers E de la part de D. Une fois que D a détecté la rupture de lien et envoyé les informations à ses 19

24 voisins, il ne va pas mettre à jour sa table avec les routes vers E reçues de ses voisins grâce au principe de poisoned reverse. Le problème intervient lorsque B envoie ses propres vecteurs de distances. À ce moment, les nouvelles routes vers E en A et C n ont plus été reçues de la part de D mais de B. De ce fait, D met à jour sa table de routage vers E à partir des informations reçues de ses voisins. Cette classe de protocole a l avantage de proposer des routes continuellement à jour mais réagit très mal aux changements de topologie, survenus suite à l apparition ou la disparition de liens. En effet, lorsque des noeuds bougent et que les liens se brisent, cela peut créer un envoi important de messages. De plus, les informations sur la topologie dépendent entièrement des informations reçues des voisins. Le problème du comptage à l infini pose également problème. C est pourquoi des améliorations ont dû être apportées et sont détaillées dans les sous-sections suivantes. Les Sous-sections et présentent différents protocoles de routage respectivement proactifs et réactifs Protocoles proactifs Les protocoles proactifs, aussi appelés protocoles table driven, sont une classe de protocoles où chaque noeud construit et tient constamment à jour une table de routage contenant, pour l ensemble des destinations du réseau, le meilleur next-hop à contacter. La façon de partager les informations sur le réseau et de construire ces tables de routage diffèrent selon les protocoles OLSR Comme son nom l indique, le protocole OLSR (Optimized Link-State Routing) [5] est une version optimisée du principe de routage à état de liens, mais destinée aux réseaux sans fil. Comme expliqué précédemment, un des problèmes du principe de routage à état de liens est le risque de congestion lié à l échange massif de messages. Le principal objectif de ce nouveau protocole est de limiter cet échange de messages tout en garantissant que chaque noeud ait en sa possession les informations suffisantes pour choisir les meilleurs next-hops. Le protocole OLSR propose de sélectionner, pour chaque noeud du réseau, un sous-ensemble de voisins qui se chargeront de retransmettre les messages de contrôle de topologie reçus. Les autres noeuds, qui ne font pas partie de ce sous-ensemble devront uniquement traiter l information reçue sans la retransmettre. De plus, le nombre de voisins déclarés dans chaque message est limité. Grâce à ces optimisations, la charge transitant sur le réseau est sensiblement réduite, ce qui implique indirectement une diminution du risque d interférence de signal [18]. 20

25 E D 2 E E 1 t 0 A D E E E 0 B C E A 3 E D 2 E < E,, > VD E t 1 A D E < E,, > VD E E 0 B C E A 3 E FIGURE 2.3 Comptage à l infini dans les protocoles à vecteur de distances 21

26 E B 4 t 2 A D E < E, B, 4 > VD < E,, > < E,, > VD VD E E E 0 E B VD < E, B, 4 > C E B 4 E < E,, > VD E C 5 t 3 A D E VD < E,, > VD < E, C, 5 > E E 0 E C 5 B VD < E, C, 5 > C E FIGURE 2.4 Comptage à l infini dans les protocoles à vecteur de distances (suite) 22

27 Relais Multipoint Les MPR (MultiPoint Relays) sont des noeuds chargés de la retransmission des messages de contrôle de topologie. Tout noeud n du réseau doit choisir un ou plusieurs de ses voisins comme MPR de telle sorte que tous les noeuds situés à deux sauts 1 du noeud d origine n soient accessibles via un de ses MPR. Chaque noeud choisi comme MPR ajoute le noeud n à sa liste de sélecteurs MPR. La principale difficulté réside dans le choix des MPR. Moins les MPR sont nombreux, moins la densité de trafic est importante. Différentes approches sont possibles pour déterminer le choix des MPR. Il est difficile de trouver une approche optimale : un algorithme trop simple choisirait des MPR peu efficaces, mais un algorithme trop complexe aurait un impact sur les performances du protocole. Ce problème s apparente à celui de couverture d un graphe et comme expliqué par A. Qayyum et al. [18], la recherche de MPR est un problème NP-complet. Dans leur rapport, ces chercheurs proposent plusieurs heuristiques. Celle de base consiste à sélectionner comme premier MPR le voisin qui couvre le plus de noeuds à deux sauts qui ne sont atteignables par aucun autre voisin. Ensuite, il reste à choisir les MPR restant en commençant par ceux couvrant le plus de noeuds à deux sauts. La Figure 2.5 illustre la diminution de l envoi de messages de contrôle de topologie grâce à l utilisation des MPR. Cette diminution a comme conséquence de réduire le taux d erreur des paquets à la réception (car moins de risques d interférences), mais aussi le temps nécessaire pour que tous les noeuds reçoivent le messages. Le rapport de recherche indique que ce temps peut être divisé par deux. Sans MPR 5 retransmissions noeud source A noeuds à 1 saut de A Avec MPR 3 retransmissions noeuds à 2 sauts de A MPR de A FIGURE 2.5 Impact de l utilisation des MPR dans OLSR (les noeuds blancs sont les MPR du noeud central) 1. Ces noeuds sont détectés via les messages HELLO comme expliqué dans la suite. 23

28 1. Découverte du voisinage La découverte du voisinage se fait par l intermédiaire de messages HELLO. Périodiquement, chaque noeud broadcaste un message HELLO contenant l ensemble de ses voisins bidirectionnels, l ensemble de ses voisins unidirectionnels et l ensemble de ses voisins choisis comme MPR. Ces messages ne doivent jamais être retransmis par les noeuds qui les reçoivent. Les messages HELLO ont deux rôles : 1. déterminer le type de liens existant entre un noeud et ses voisins (lien bidirectionnel ou unidirectionnel) ; 2. déterminer les voisins qui serviront de MPR. Pour comprendre comment ces deux rôles sont remplis, il est nécessaire d introduire les différents cas de figure qui peuvent se présenter lors de la réception d un message HELLO. Supposons qu un noeud B reçoive un message HELLO broadcasté par un noeud A. a. Si B et A ne se connaissent pas, c est-à-dire que B n a encore reçu aucun message HELLO de la part de A et inversement, alors B ajoute le noeud A à sa liste de voisins unidirectionnels. b. Si A connaît B, c est-à-dire que A a déjà reçu un message HELLO de B (et l a donc ajouté à sa liste de voisins unidirectionnels ou bidirectionnels), cela signifie que B a reçu un message contenant son propre identifiant dans la liste des voisins unidirectionnels ou bidirectionnels de A. Dans ce cas, A et B sont accessibles l un l autre, et donc B ajoute le noeud A à sa liste de voisins bidirectionnels. c. Si un autre noeud C différent de A et B est présent dans la liste des voisins bidirectionnels de A, il s agit d un noeud accessible depuis B en 2 sauts par l intermédiaire du noeud A. Un algorithme doit alors déterminer si le noeud A doit être choisi ou non comme MPR de B pour accéder au noeud C. Si c est le cas, alors B ajoute le noeud A à sa liste de MPR. d. Si B est présent dans la liste des MPR de A, alors B retient A comme étant un de ses sélecteurs MPR. Ainsi, après un certain nombre de messages échangés, chaque noeud du réseau connaît la présence et l état des liens avec ses voisins, les voisins qu il a choisi comme MPR et les voisins qui l ont choisi comme MPR. La Figure 2.6 illustre ces différents cas de figure. 2. Distribution de la topologie La distribution de la topologie du réseau se fait par l intermédiaire des messages TC (Topology Control). À intervalles réguliers, chaque MPR broadcaste un message TC contenant l ensemble de ses voisins qui l ont choisi comme MPR. Chaque message contient également un numéro de séquence pour reconnaître les messages périmés. Les messages TC ne sont retransmis que par les noeuds désignés comme MPR par le voisin ayant transmis le message. Les messages TC ont 2 rôles : 1. distribuer la topologie du réseau ; 2. détecter les changements de topologie du réseau. Les messages TC peuvent être comparés aux messages LSA du protocole de routage à état de liens. Les deux principales différences sont les suivantes : 24

29 Cas a. et b. A B HELLO uni A = {B} bi A = {B} HELLO HELLO (uni B ={A}) uni B = {A} Cas c. C A B uni C = {A} HELLO HELLO (uni C ={A}) bi A = {C}? MPR bi C = B {A} C? HELLO (bi A ={C}) HELLO (bi A ={C})? MPR B C? Cas d. MPR A = {B} A HELLO (MPR A ={B}) B select B = {A} select B = {A} FIGURE 2.6 Découverte du voisinage dans OLSR 25

30 les messages LSA diffusent sur le réseau l ensemble des voisins d un noeud A alors que les messages TC ne diffusent que les voisins ayant choisi le noeud A comme MPR ; les messages LSA sont broadcastés et retransmis par tous les noeuds du réseau alors que les messages TC ne sont retransmis que par les noeuds qui sont des MPR du voisin ayant transmis le message. La première différence a l avantage de diminuer la taille des messages diffusés sur le réseau en limitant le nombre de voisins déclarés dans un même message. La deuxième différence permet de limiter le nombre de retransmission des messages TC. Ces deux différences permettent de diminuer la charge sur le réseau tout en garantissant que les messages soient diffusés à tous les noeuds du réseau et qu un nombre suffisant de noeuds nécessaires au routage soient déclarés. Ce protocole considère que la perte de messages TC n est pas contraignante vu que ceux-ci sont broadcasté périodiquement. Comme pour le principe de routage à état de liens, chaque noeud génère une carte du réseau à partir des messages TC reçus. Étant donné que tous les voisins ne sont pas déclarés dans un message TC, la carte ne contient qu une partie du réseau. Néanmoins, cette carte simplifiée garantit que toutes les destinations accessibles par le principe de routage à état de liens le sont aussi via cette méthode. 3. Détermination des meilleures routes Comme pour le principe de routage à état de liens, un algorithme de calcul de plus court chemin est exécuté sur la carte du réseau afin de déterminer les meilleurs next-hops pour atteindre chaque destination du réseau. À partir de là, des tables de routage sont générées ou mises à jour lors de changements de topologie détectés via les messages TC B.A.T.M.A.N. Le protocole B.A.T.M.A.N. (Better Approach To Mobile Ad hoc Network) [14] est une approche destinée à remplacer peu à peu le protocole OLSR et vise à combler ses principaux défauts ; il ne s agit toutefois pas d un protocole à état de liens. Le problème d OLSR est qu il ne tient pas compte, dans ses choix de meilleurs next-hops, de la perte possible de paquets (à cause de défaillances de liens, brouillage du signal, etc.). L approche proposée par B.A.T.M.A.N. est de choisir le next-hop situé sur la route la plus fiable, c est-à-dire celle ayant le moins de risque de perte de paquets. Pour ce faire, chaque noeud garde un historique contenant, pour tout autre noeud du réseau, tous les numéros de séquence de tous les messages reçus de la part de chaque voisin. Le voisin ayant le plus de numéros de séquence dans sa table est considéré comme next-hop le plus fiable pour atteindre le noeud d origine du message. Originator Message L OGM (Originator Message) est l unique type de mes- 26

31 sage qui transite au sein du réseau. Ce message est broadcasté périodiquement par tous les noeuds afin de découvrir la topologie du réseau. Un OGM contient entre autres l identifiant du noeud d origine du message, un numéro de séquence pour déterminer les messages périmés, et un flag indiquant si le type de lien existant avec le dernier noeud ayant envoyé le message. Chaque message est retransmis par tous les noeuds afin de se répandre sur tout le réseau. 1. Découverte du voisinage La découverte des voisins s effectue grâce au flag présent dans les messages OGM indiquant si un lien avec un voisin est unidirectionnel ou bidirectionnel. La façon de déterminer le type de lien existant avec un voisin est similaire à l échange des message HELLO dans le protocole OLSR. 2. Distribution de la topologie Le contrôle de la topologie est la principale fonction des messages OGM. Chaque noeud tient en mémoire les informations suivantes pour chaque destination : l adresse de la destination ; le numéro de séquence le plus à jour, permettant de détecter les réceptions dupliquées d un même message ; un tableau contenant, pour chaque voisin bidirectionnel ayant transmis un OGM, l ensemble des numéros de séquence reçus. Le dernier tableau signifie que chaque noeud compte le nombre de messages OGM différents reçus d un même voisin pour une même destination. Le voisin pour lequel le plus de messages différents a été reçu est considéré comme se trouvant sur la route la plus fiable pour atteindre la destination. 3. Détermination des meilleures routes À partir des informations récoltées de ses voisins, chaque noeud choisit comme next-hop le voisin qui lui a envoyé le plus de paquets avec des numéros de séquence différents. Le paquet est envoyé à ce voisin, qui répète lui aussi la même opération, jusqu à ce que le paquet arrive à destination. Le protocole B.A.T.M.A.N. n est encore qu à l état d ébauche et présente encore quelques problèmes. Entre autres, celui ci ne possède pas de système de détection de boucles de routage et ne tient pas compte des coût des liens [4] DSDV Le protocole DSDV (Destination Sequence Distance Vector) [17] est une version améliorée du protocole à vecteur de distances. Les optimisations proposées permettent de mettre fin au problème de boucle et de comptage à l infini et diminuent la charge sur le réseau. 27

32 Types de messages Deux nouveaux types de messages sont introduits : les full-dumps qui transportent la table de routage complète mais qui sont envoyés plus rarement, et les mises à jour incrémentales qui informent uniquement de changements de topologie apportés depuis le dernier full dump. Les mises à jour incrémentales ont l avantage de réduire la quantité de données transmise sur le réseau. Numéro de séquence Le problème de comptage à l infini est réglé grâce à l introduction de numéros de séquence. Chaque entrée dans les table de routage est associée à un numéro de séquence pair choisi par la destination de l entrée. Chaque destination génère donc un numéro de séquence pair qu il envoie en même temps que sa table et qu il incrémente à chaque envoi. Lorsqu un voisin reçoit le vecteur de distances, il compare le numéro de séquence associé au vecteur de distances avec celui de l entrée correspondant à l envoyeur dans sa table de routage. L entrée n est mise à jour que si le numéro de séquence est supérieur. Si les deux numéros de séquence sont égaux, la route avec le coût minimum est choisie. Si un noeud détecte qu un voisin devient inaccessible, il incrémente de 1 le numéro de séquence de l entrée correspondante dans la table de routage pour rendre le numéro impair, signifiant que la route vers la destination est inaccessible. Le vecteur de distances est propagé et provoque des mises à jour par les voisins étant donné que le numéro de séquence a augmenté. En comparaison avec les protocoles à vecteur de distances, la taille des messages est sensiblement réduite. Par contre, le nombre de messages envoyés est plus important. Il est donc nécessaire d avoir une bonne fréquence d envoi de mises à jour incrémentales Protocoles réactifs Les protocoles réactifs, aussi appelés protocoles on demand, sont une classe de protocoles où le choix du meilleur next-hop se fait à la demande, lorsque c est nécessaire. Pour déterminer les meilleurs next-hops pour atteindre une destination, les noeuds doivent broadcaster des requêtes de routes sur le réseau afin d obtenir, en retour, des informations sur la direction à prendre. Chaque noeud ayant fait une demande de route construit une table de routage ayant une durée de vie limitée AODV Le protocole AODV (Ad hoc On Demand Distance Vector) [16] est une variante du protocole DSDV en y intégrant le concept des protocoles réactifs. Pour rappel, le protocole DSDV est un protocole proactif, ce qui signifie que chaque noeud conserve une table de routage de l ensemble des destinations du réseau, ce qui nécessite une place mémoire non négligeable. Le protocole 28

33 AODV propose de tirer parti des bénéfices de DSDV tout en évitant de surcharger la mémoire des noeuds. Si un noeud souhaite contacter une destination du réseau, et qu il ne connaît pas encore le next-hop à emprunter, il broadcaste une demande de route sous la forme d un message RREQ (Route Request). La réponse est ensuite reçue via un message RREP (Route Response). Une table de routage temporaire est créée dans laquelle sont enregistrés les next-hops pour chaque destination demandée. Une entrée dans la table de routage reste présente tant que la route est utilisée. Si un noeud détecte un lien défaillant sur une route, il en informe les noeuds de la route via un message RERR (Route Error). La suite présente plus en détails les caractéristiques de ce protocole. Demande de route Chaque noeud qui souhaite contacter une destination du réseau qui n est pas dans sa table de routage diffuse en broadcast un message RREQ contenant la source du message, la destination à atteindre et un numéro de séquence pour détecter les réceptions dupliquées d un même message. Un noeud qui reçoit ce message enregistre le voisin qui le lui a envoyé et rebroadcaste le message à son tour. L ensemble des messages envoyés crée ainsi un ensemble de routes temporaires allant de tout noeud ayant reçu le message RREQ au noeud d origine l ayant envoyé. Lorsqu un noeud possédant l information demandée reçoit le message RREQ, celui-ci renvoie un message RREP contenant l information demandée sur la destination. Le message RREP est renvoyé au noeud d origine via la route temporaire par laquelle le message RREQ est arrivé. Chaque noeud de cette route qui reçoit le RREP enregistre le voisin à contacter pour atteindre la destination et retransmet le RREP jusqu au noeud d origine. Si un noeud reçoit plusieurs RREP, il garde celle de coût de minimal via l équation de Bellman-Ford. Les informations sur la route ainsi produite sont conservées par chaque noeud concerné jusqu à ce que celle-ci ne soit plus utilisée ou devienne invalide. Si un noeud présent sur une route détecte un lien invalide, il diffuse un message RERR le long de la route jusqu à la source pour informer que cette route n est plus valide. Dans ce cas, si le noeud source souhaite encore contacter la destination, il doit relancer le processus de demande de route. Les Figures 2.7 et 2.8 illustrent le concept de demande de route. Boucles et comptage à l infini Pour éviter l apparition de comptage à l infini et de boucles, chaque route est associée à un numéro de séquence choisi par le noeud destination, comme pour DSDV. Un numéro pair signifie que la route est valide, un numéro impair signifie qu une route n est plus valide. Lorsque un noeud reçoit deux réponses ayant des numéros de séquences différents, il choisit la route ayant le numéro le plus élevé, si les deux sont pairs. Si les deux numéros de séquences sont égaux, le noeud choisit la route ayant le moins de sauts. Si un noeud reçoit une réponse avec un numéro de séquence impair, la route associée est oubliée par le noeud. Chaque noeud doit donc enregistrer deux numéros de séquence : un pour détecter les réception dupliquées de messages RREQ et un pour détecter les nouvelles routes. 29

34 A A 1 RREQ(F) B RREQ(F) D A B 2 RREQ(F) t 1 A F RREQ(F) C E G RREQ(F) A A 1 A C 2 RREQ(F) RREQ(F) A E 3 A C 3 F B 3 A A 1 F D 2 RREP(F) B RREP(F) D A B 2 F F 1 RREP(F) t 2 A F C E G F B 3 A A 1 F D 2 RERR(F) B RERR(F) t 3 A F D A B 2 F F 1 A C 3 C E G FIGURE 2.7 Demande de route dans le protocole AODV 30

35 B t 4 A F RREQ(F) RREQ(F) D C E G RREQ(F) RREQ(F) A A 1 A C 2 RREQ(F) RREQ(F) A E 3 A G 4 F C 4 B t 5 A F RREQ(F) A A 1 F E 3 D C E G RREQ(F) A C 2 F G 2 RREP(F) RREP(F) A E 3 F F 1 A G 4 FIGURE 2.8 Demande de route dans le protocole AODV (suite) Ce protocole a l avantage de proposer des routes constamment à jour. De plus, tant que des paquets de données sont envoyées à une destination, la route est gardée en mémoire et le paquet peut être directement envoyé vers la destination. Dans le pire des cas, si des changements de topologie sont fréquents, il suffit de renvoyer des demandes de routes DSR Le protocole DSR (Dynamic Source Routing) [7] est un protocole réactif où les routes sont maintenues à la source. Comme pour n importe quel protocole réactif, DSR crée des routes à la demande lorsqu une destination doit être atteinte. Contrairement à tous les protocoles de routage ad hoc présentés ci-dessus, DSR ne stocke jamais de table contenant les next-hops à emprunter pour atteindre différentes destinations. En effet, les routes complètes vers les destinations sont maintenues par chaque noeud source devant envoyer un paquet. Cette manière de faire à l avantage de faciliter la détection de boucles et de comptage à l infini. De plus, plusieurs routes vers une même destination 31

36 peuvent coexister, c est à la source de faire son choix. Par contre, cette façon de faire crée un overhead sur les paquets envoyés. En effet, la route choisie doit être insérée dans le paquet afin que les noeuds de cette route aient connaissance des next-hops à emprunter. Ce principe se nomme le source routing. Le fonctionnement de ce protocole se découpe en deux parties appelées Route Discovery et Route Maintenance et détaillées ci-dessous. Route Discovery La découverte de routes s effectue par le broadcast de messages RREQ comme pour les autres protocoles réactifs. Au fur et à mesure que le message RREQ se propage sur le réseau, la liste des noeuds parcourus est insérée dans le message. Le noeud destination ou un noeud intermédiaire ayant l information demandée stocke la liste des noeuds formant la route demandée dans un message RREP et l envoie en retour à la source en remontant la route ainsi créée. Une fois que la source reçoit la réponse voulue, elle stocke la route obtenue dans une table. Si la source reçoit plusieurs RREP, elle choisit la route qu elle souhaite emprunter. L avantage de cette pratique est que le noeud source du paquet est totalement libre de choisir la route à emprunter pour arriver à la destination. Avec cette façon de faire, plusieurs routes vers une même destination peuvent exister. Par exemple, un noeud A situé sur la route entre la source X et la destination Y peut choisir une route différente que celle de X s il souhaite envoyer des paquets à Y. Route Maintenance Pour détecter les défaillances de liens, chaque noeuds qui envoie un paquet ou un message différent d un RREQ doit vérifier que les noeuds suivants sur la route reçoivent bien le paquet. Si ce n est pas le cas, il faut renvoyer un RERR à la source pour l avertir de cette défaillance Récapitulatif Voici un récapitulatif des différents protocoles proposés ainsi que leurs avantages et inconvénients respectifs. La Figure 2.9 liste les différents protocoles détaillés ci-dessus et leurs classes respectives. La Table 2.1 reprend les avantages et inconvénients de chacun de ces protocoles. Protocoles Proactifs Réactifs OLSR B.A.T.M.A.N. DSDV AODV DSR FIGURE 2.9 Protocoles de routage ad hoc proactifs et réactifs 32

37 Protocole Spécificités Avantages Inconvénients État de lien Vecteur de distances Proactif OLSR B.A.T.M.A.N. DSDV Réactif AODV DSR maintien d une carte du réseau complète, choix des next-hops par Dijkstra mise à jour des tables de routage via Bellman-Ford grâce aux informations reçus des voisins maintien constant d une table de routage amélioration de LSR via introduction de MPR choix de la route via les voisins ayant transmis le plus de messages amélioration de DVR via suppression du problème de comptage à l infini, mises à jour incrémentales pour modifications de topologie mineures routes obtenues à la demande choix du next-hop situé sur la route de coût minimum route complète stockée dans chaque noeud, route insérée dans le paquet à envoyer calcul des routes indépendamment des autres noeuds calcul des routes très simple propagation des paquets très rapide, adapté à la mobilité diminution du nombre de messages échangés et de leur taille choix des routes les plus fiables taille des messages diminue routes toujours à jour, pas d envois excessifs de messages de contrôle idem protocoles réactifs choix de la route indépendant des autres noeuds, connaissance totale par un noeud de la route empruntée espace mémoire pour stockage de la carte du réseau, quantité de messages échangés risque de congestion si table de routages très grandes, risque de comptage à l infini réaction lente aux changements topologie, de échanges massifs de messages problème si mobilité très importante mémoire nécessaire pour stocker l historique des messages reçus envoi de messages plus important délai nécessaire pour trouver une route, pas optimisé pour la forte mobilité idem protocoles réactifs overhead sur le paquet, mémoire pour stocker les routes TABLE 2.1 Avantages et inconvénients des protocoles de routage ad hoc 33

38 On remarque que les protocoles réactifs envoient beaucoup moins de messages que les protocoles proactifs en cas de faible mobilité. En effet, un message n est envoyé que si une route doit être trouvée. De plus, une fois qu une route est trouvée, les paquets suivants sont envoyés très rapidement. Par contre dans un réseau à forte mobilité, le nombre de messages échangés sera bien plus important car il est nécessaire de réaliser de nouvelles demandes de routes plus souvent. Dans ce cas, les temps nécessaire pour qu un paquet arrive à destination peut être plus important. À l inverse, les protocoles proactifs permettent une transmission rapide des paquets en cas de faible mobilité, mais sont beaucoup moins efficaces dans les réseaux à forte mobilité. En effet, il est nécessaire d attendre que de nouvelles informations sur la topologie parviennent aux noeuds pour que ceux-ci mettent à jour leur table de routage. L avantage de ce genre de protocole est que le nombre de messages envoyés par chaque noeud reste contant, quelle que soit la mobilité du réseau. Il pourrait donc être intéressant de tester au moins un protocole proactif et un protocole réactif pour vérifier ces constatations. 2.2 Testbeds Les testbeds pour protocoles de routage ont principalement pour but de tester des implémentations de protocoles dans des environnements aussi proches que possible de la réalité et de déterminer si ces protocoles fonctionnent comme ils le devraient. Mais les testbeds permettent aussi de mettre un protocole à l épreuve dans des conditions extrêmes telles que la formation d un réseau très dense ou très épars, l envoi de paquets très longs, etc, afin de mesurer la robustesse du protocole. Il existe de nombreuses implémentations de testbeds. Celles-ci varient selon les données analysées, l environnement de test ou encore les types de protocoles étudiés. Nous nous intéressons ici aux testbeds permettant l évaluation de protocoles de routage ad hoc. Leur fonctionnement est détaillé ci-dessous APE Le testbed APE (Ad hoc Protocol Evaluation) a été implémenté conjointement par des chercheurs de l université d Uppsala et du département Ericsson Research en Suède [12]. Selon leur article, ce testbed a pour but de tester les protocoles ad hoc sur des réseaux à grande échelle en situation réelle. Ce testbed fonctionne selon un système de chorégraphie informant à chaque noeud à un moment donné à quel endroit il doit se déplacer. Ce système permet de faciliter grandement l utilisation du testbed. 34

39 Du point de vue technique, le testbed fonctionne comme suit. À chaque fois qu un noeud reçoit un paquet, celui-ci crée un fichier de log comprenant des informations variées sur le lien entre le noeud émetteur et le noeud récepteur (distance entre les 2 noeuds, nombre de hops, etc.). À intervalles réguliers, les noeuds envoient à un serveur un résumé de leurs logs et ce serveur calcule des statistiques sur le réseau complet DES-SERT DES-SERT (DES Simple and Extensible Routing-Framework for Testbeds, DES étant l abréviation du groupe de recherche Distributed Embedded System de l université libre de Berlin) est un framework implémenté par des chercheurs de l université libre de Berlin [2]. Ces derniers mettent en avant le fait que certaines fonctionnalités liées au système d exploitation demandent de nombreuses connaissances qui ne sont pas à la portée de tous, chaque OS pouvant avoir ses propres spécifications. Ainsi, un programmeur souhaitant développer un protocole de routage peut perdre beaucoup de temps alors qu il devrait s intéresser à l optimisation et aux tests du protocole. C est pourquoi certains programmeurs préfèrent implémenter et tester les protocoles en environnement de simulation plutôt qu en situation réelle, ce qui peut parfois mener à des conclusions invalides en environnement réel. Le framework DES- SERT a pour but de fournir une abstraction des fonctions du système d exploitation pour faciliter l implémentation d un protocole de routage ad hoc et/ou d un testbed. Le framework utilise la librairie pcap pour la capture et l envoi de paquets sur une interface réseau. L avantage de DES-SERT est qu il est compatible avec n importe quel système d exploitation basé sur un noyau Linux (et qui dispose donc des librairies nécessaires). Il fournit des fonctions permettant l envoi, la réception et la gestion de paquets, ainsi qu un système de logging. Il est également possible de configurer une interface TUN/TAP [10] à l initialisation permettant la réception de paquets envoyés depuis le système hôte. DES-SERT propose des implémentations de protocoles telles que AODV et OLSR et dispose d une archive facilitant la compilation pour Android. Une fois le framework lancé, il est possible de se connecter à une session telnet pour modifier les configurations en parallèle du fonctionnement d un protocole. 2.3 Simulateurs de réseaux sans fil Il existe une grande variété de simulateurs de réseau. Ceux-ci permettent de simuler une topologie dans laquelle il est possible de faire transiter des données. Un simulateur de réseau sans fil doit implémenter au moins un modèle de propagation. Celui-ci définit la façon dont les ondes se propagent dans l environnement et contraint la portée de transmission des noeuds. La 35

40 complexité et le réalisme des modèles varie d un simulateur à l autre. La suite de cette section présente d abord différents modèles de propagation et ensuite, quelques simulateurs de réseau sans fil ainsi que leurs avantages et inconvénients Modèles de propagation Cette sous-section présente différents modèles de propagation. Cette présentation est basée sur l article de Kuntz et al. [11] Modèle Free Space Le modèle Free Space, aussi appelé modèle de Friis est basé sur l équation de Harald T. Friis qui permet d obtenir la puissance d un signal reçu à une certaine distance d un émetteur dans un environnement vide. Ce modèle définit une décroissance exponentielle de la puissance du signal à mesure que l on s éloigne de l émetteur. L équation se présente comme suit : Pr Friis (d) = avec Pr Friis la puissance reçue, Pt la puissance émise, λ la longueur d onde, f la fréquence de l onde, c la vitesse de la lumière, d la distance par rapport à l émetteur. Pt λ2 (4π) 2 d 2 = Pt c 2 (4π) 2 f 2 d 2 Ce modèle est le plus simpliste. En effet, celui-ci ne tient pas compte de l environnement dans lequel se trouvent les noeuds. Ainsi, les différents comportements associés aux ondes tels que la réflexion ou la diffraction des ondes, qui peuvent créer des interférences constructives ou destructives, ne sont pas supportés Modèle Two Ray Ground Le modèle Two Ray Ground fonctionne de la même manière que Free Space tout en prenant en compte la réflexion des ondes sur le sol. Pour ce faire, les hauteurs d antennes d émission et de réception sont inclues dans l équation du signal. Celle-ci se présente comme suit : Pr TRG (d) = Pt h2 t h2 r d 4 36

41 avec Pr TRG la puissance reçue, Pt la puissance émise, h t la hauteur de l antenne d émission, h r la hauteur de l antenne de réception, d la distance par rapport à l émetteur. Même si ce modèle propose un résultat plus proche de la réalité, il ne tient toujours pas compte de l environnement dans son calcul de la puissance reçue Modèle de Nakagami Le modèle de Nakagami est un modèle probabiliste où les puissances de réceptions suivent une distribution Gamma. L équation de Nakagami se présente comme suit : avec Pr Nakagami la puissance reçue, Pt la puissance émise, m le facteur d atténuation, d la distance par rapport à l émetteur. Pr Nakagami (d) = Gamma(m, Pr Friis(d) ) m Ce modèle tient compte des atténuations provoquées par d éventuelles réflexions, diffractions et réfractions, qui peuvent mener au problème de multichemins. Le paramètre m permet de définir le taux d atténuation de signal. Plus ce paramètre est élevé, plus l atténuation du signal sera importante. La Figure 2.10 illustre la comparaison de puissance reçue en dbm en fonction de la distance par rapport à l émetteur entre les modèles de Friis et de Nakagami (avec un facteur d atténuation de 1,5). Dans cet exemple, la sensibilité du récepteur en écoute est de -80 dbm. En dessous de cette valeur, le récepteur ne capte pas de signal Simulateurs Cette présentation des simulateurs de réseau sans fil est majoritairement basée sur une étude comparative réalisée pas Köksal [9]. Pour chaque simulateur, l article reprend également des avantages et inconvénients constatés dans d autres études J-Sim Le simulateur J-SIM a été développé par une équipe de chercheurs de l université de l Illinois. Il est écrit en Java. Son fonctionnement repose sur 37

42 FIGURE 2.10 Comparaison entre les modèles de Friis et de Nakagami l utilisation de composants. Ceux-ci peuvent représenter des noeuds, des liens ou des protocoles, et communiquent via des ports. Les composants sont structurés de manière hiérarchique et permettent ainsi de réaliser des sous-réseaux interconnectés. J-SIM est compatible sans fil et propose différents modèles de propagation de données et de mobilité. Un outil graphique permet d éditer des topologies mais pas de visualiser les transferts sur le réseau OMNeT++ OMNET++ est un simulateur open source développé par András Varga de l université polytechnique de Budapest. Il est écrit en C++. Un réseau est composé de modules, assemblés via un langage spécifique. Comme pour J-SIM, une structure hiérarchique est possible et permet de créer des sousréseaux. Les modules peuvent s échanger des messages via des portes. Les liens entre les portes permettent l utilisation de délais de propagation et de taux d erreur. Un outil graphique permet également de définir des topologies et de visualiser les transferts sur le réseau. OMNET++ a l avantage d être flexible et simple d utilisation ns-2 Le simulateur NS-2 est maintenu par le Information Sciences Institute en Californie. Il est écrit en C++. Il propose de base des implémentations de quelques protocoles. Il supporte aussi le mode sans fil et dispose de modèles de propagation pour gérer l atténuation de signal. Il est possible de créer des scénarios, de rendre des noeuds et des liens indisponibles et de capturer du trafic extérieur. Des outils graphiques sont disponibles pour gérer les topologies. Les inconvénients rapportés sont la complexité du logiciel, et la grande quantité de ressources utilisées. Il existe une nouvelle version, NS

43 OPNET Modeler Le simulateur OPNET MODELER est un logiciel commercial développé initialement par des chercheurs du Massachusetts Institute of Technology. Il est écrit en C++. Il se base aussi sur l utilisation hiérarchique de composants permettant de créer des sous-réseaux. Diverses implémentations de protocoles sont proposées et il est également possible d en implémenter soi-même. Une extension permet l utilisation du sans fil, et gère l utilisation de modèles de propagation, d interférences et de mobilité. Un éditeur graphique permet la visualisation et la création de topologies. Enfin, il est possible d afficher des statistiques sur le réseau. 2.4 Logiciels de traitement de paquets Les logiciels de traitement de paquets ont pour principale fonction de récupérer des paquets sur une interface et de les aiguiller vers une ou plusieurs autres interfaces. Entre-temps, il est possible d appliquer des filtres sur les paquets, de modifier les paquets ou d effectuer d autres traitement. La suite présente le logiciel CLICK qui est un des principaux logiciels de traitement de paquets Click CLICK est un logiciel de création de routeurs modulaires [8]. Un routeur est composé d éléments. Chaque élément implémente une fonction simple d un routeur, comme le filtrage de paquets ou la gestion de trafic. Les éléments sont connectés entre eux via des ports. L ensemble des éléments peut être vu comme un graphe où l élément initial capture les paquets entrants (ou les génère), et le ou les éléments de finaux envoient (ou jettent) les paquets sortants. 2.5 Smartphones et système Android Cette section détaille les caractéristiques logicielles et matérielles des terminaux Android Caractéristiques logicielles Le système d exploitation Android est basé sur le noyau Linux. Cela signifie qu il est équipé d un ensemble de librairies, servant d interface entre le matériel et l utilisateur, identiques à celles de Linux. La compatibilité des 39

44 applications développées pour Linux est donc garantie pour Android dans la plupart des cas. La majorité des applications pour Android sont écrites en Java. Afin de gérer ces applications, Google fourni un SDK contenant un ensemble d outils. Il est toutefois possible d éxecuter des applications écrites en C. L outil NDK permet de compiler du code C et d insérer les exécutables dans des programmes Java. Afin de faire tourner des applications Java sur Android, une machine virtuelle spécifique, appelée Dalvik, a été développée en partenariat avec des chercheurs de Google. Google fournir également la possibilité de tester ses applications sur des émulateur Android. Il est possible de communiquer facilement avec les émulateur via l outil adb fournit avec le SDK. Cet outil permet d accéder à une console sur l émulateur, d envoyer et récupérer des fichiers, de débugger ses applications, etc. Les détails sur la création d un émulateur Android sont présents sur le site officiel d aide au développeurs Android [20] Caractéristiques matérielles Les terminaux Android, et les smartphones en général, ne cessent de gagner en puissance au fil des années. Ainsi, les premiers smartphones Android, tels que le HTC Hero ou le Samsung Galaxy, les plus puissants de l époque, avaient un processeur ARM de 528 MHz et une mémoire vive ne dépassant pas les 288 Mo. À l heure actuelle, la plupart des smartphones d entrée de gamme offrent une configuration déjà supérieure à ces premiers téléphones, on peut citer par exemple les Samsung Galaxy Y et Samsung Galaxy Ace. Les appareils haut de gamme offrent même des configurations comparables à de bons ordinateurs portables et certains vont même jusqu à proposer des processeurs quad-core comme le HTC One X ou le Samsung Galaxy S III. Faire tourner des protocoles de routage, même dans des conditions extrêmes ne devrait donc pas poser de réel problème, ou du moins pas plus que sur un ordinateur. La vraie contrainte qui peut apparaître se situe au niveau de la batterie. En effet, les configurations de plus en plus puissantes consomment une énergie beaucoup plus importante et cela se fait sentir au niveau de la batterie qui est de plus en plus mise à l épreuve. Il peut aussi être intéressant de se renseigner sur les caractéristiques techniques des émetteurs et récepteurs des terminaux. Ceci pourrait permettre une configuration des noeuds du simulateur de réseau sans-fil la plus proche de la réalité. Les informations à collecter concernent la puissance du signal émis par un émetteur et la puissance de signal minimale que peut interpréter le récepteur. En général, un émetteur WiFi dispose d une puissance de 15 dbm et un récepteur est capable d interpréter une puissance minimale de -70 dbm à -90 dbm. 40

45 Chapitre 3 Choix effectués Ce chapitre présente les choix qui ont été faits lors de la conception de la solution proposée et si nécessaire, les implémentations réalisées et les configurations possibles. La Section 3.1 discute du choix du testbed, la Section 3.2 discute du choix du simulateur de réseau sans fil et du logiciel de traitement de paquets. Enfin, la Section 3.3 détaille les configurations relatives à la communication entre les différentes applications, la Section 3.4 propose une vue d ensemble de la chaîne d applications et la Section 3.5 décrit quelques tests simples permettant de vérifier le bon fonctionnement de la chaîne d applications. 3.1 Testbed Les différents testbeds proposés pourraient être utilisés mais le choix s est porté sur le framework DES-SERT, entre autres car celui-ci propose une version pour Android. Ce framework propose des implémentations de AODV et OLSR qui permettront déjà de comparer l utilisation d un protocole proactif avec celle d un protocole réactif. Il aurait été intéressant d analyser le protocole B.A.T.M.A.N. dans le cadre d une comparaison avec OLSR, mais aucune implémentation n était disponible pour le public. Il sera éventuellement possible d implémenter plus tard d autres protocoles pour DES-SERT. Il sera alors très simple de les intégrer à de futurs tests. Les prochaines sous-sections détaillent la configuration de DES-SERT ainsi le portage sur Android et de la récupération des données de log Configuration Pour configurer le framework DES-SERT, différents fichiers de configuration sont mis à disposition. Par défaut, chaque fichier a un nom sous la forme 41

46 des-<protoname>.<ext>. Par exemple, le fichier de log pour AODV se nomme des-aodv.log. Le premier fichier de configuration, des-*.conf contient les commandes de configuration spécifiques du protocole. Pour AODV, cela comprend, entre autres, la fréquence d envoi de messages HELLO, la taille des messages RREQ, la métrique utilisée, etc. Le second fichier de configuration, des-*.default, contient les paramètres qui sont indépendants du protocole. Ceux-ci comprennent l interface réseau à utiliser, le port pour l accès via telnet, le chemin des fichiers de log et de configuration du protocole ainsi que d autres variables. Le dernier fichier, des-*.init permet de concaténer les deux fichiers de configuration et de démarrer ou arrêter le framework DES- SERT pour le protocole concerné. Par défaut, l accès à la session telnet se fait via le port De base, il est seulement possible de visualiser certaines caractéristiques comme les paramètres initiaux, le contenu de la table de routage, les informations sur le voisinage, etc. Un accès en mode privilège permet de modifier quelques paramètres. La Figure 3.1 montre l affichage de la table de routage dans AODV via la console telnet. FIGURE 3.1 Capture d un terminal telnet Enfin, pour envoyer des paquets de données à l interface TAP de DES- SERT, l outil SCAPY [21] est utilisé. Ce logiciel permet notamment, via des scripts python, de créer des paquets et de les envoyer sur une interface réseau Portage sur Android Le portage sur Android, et plus particulièrement sur émulateur Android présente quelques difficultés. Tout d abord, certaines commandes de base et très utiles de Unix ne sont pas disponibles par défaut sur Android. Il est donc fortement conseillé d installer la suite open source Busybox contenant un pack de commandes Unix, dont notamment telnet et ifconfig. Ensuite, il est nécessaire d avoir un appareil Android rooté. En effet, certaines fonctionnalités de DES-SERT demandent un accès à certains fichiers non accessibles à un simple utilisateur. Sur émulateur, les fichiers relatifs à DES-SERT sont stockés dans /data/, répertoire contenant les applications utilisateur du système. L interface par 42

47 défaut eth0 est utilisée par DES-SERT pour communiquer. N ayant pas réussi à créer une interface TAP sur Android, l envoi de paquets sur le réseau se fera uniquement via le PC hôte comme expliqué dans la suite. Enfin, pour faciliter la gestion des protocoles DES-SERT, un programme pour Android a été implémenté. Celui-ci permet de choisir le protocole à utiliser et de le démarrer ou l arrêter Récupération de données La récupération des données du framework DES-SERT se fait via l utilisation de fichiers de log. Il est possible de déterminer le niveau de log à utiliser. Le niveau debug permet de sauvegarder toutes les informations nécessaires comme la réception de messages de contrôle, la recherche de routes, etc. Les logs sont précis à la milliseconde près. Une fois les tests terminés, les fichiers de log de chaque émulateur peuvent être récupérés et analysés. 3.2 Simulateur de réseau sans fil La plupart des simulateurs analysés proposent de tester des protocoles directement implémentés dans l environnement de simulation, ce qui n est pas le but recherché. De plus, on cherche ici à simuler du trafic de paquets extérieurs au simulateur. NS-2 le permet mais semble complexe à utiliser. Or, on souhaite un simulateur qui se chargerait simplement de déterminer, à partir de la source et de la destination d un paquet, si ce paquet peut passer sans fil directement entre ces deux noeuds, le tout via la création d une topologie sans fil, d un modèle de propagation et de scénarios. Ainsi, une implémentation simple a été réalisée afin de simuler un environnement sans fil et le transfert de paquets extérieurs au sein de celui-ci. De même, du côté du logiciel de traitement de paquets, le choix s est tourné vers la mise en place d une nouvelle implémentation. Même si CLICK est simple d utilisation, il ne propose pas, de base, de structure de données représentant une table de hachage 1. Une alternative aurait été de créer un nouvel élément CLICK représentant cette structure. Dans la suite, le logiciel sera appelé Switcher en référence à un aiguilleur, la principale fonction de ce logiciel étant d aiguiller les paquets entrants vers les sorties adéquates Fonctionnement général Pour résumer, les deux implémentations réalisées vont travailler ensemble pour simuler le transfert de paquets entre les différents émulateurs Android. Un paquet ne va jamais transiter au sein de ce réseau virtuel : il va 1. Cette structure est nécessaire, comme expliqué dans la suite. 43

48 simplement être analysé par le switcher, et retransmis sur la ou les interfaces nécessaires, après simulation de son transfert dans le réseau sans fil. L implémentation réalisée se divise donc en deux programmes : un simulateur de réseau sans fil et un switcher. Le premier s occupe de contrôler la topologie du réseau, les modèles de propagation et les scénarios. Le deuxième permet d établir la communication entre le simulateur et les émulateurs Android et de transférer les paquets vers les bonnes interfaces. La suite présente le fonctionnement de ces deux programmes. Au départ, le simulateur crée une topologie virtuelle représentant un réseau sans fil. Celle-ci est constituée d un ensemble de noeuds correspondant aux émulateurs Android. Chaque noeud est caractérisé par un nom, une position dans le plan, la puissance de son émetteur, la sensibilité de son récepteur et la fréquence des ondes radios. Pour chaque couple de noeuds, un délai de transmission de paquets en millisecondes est défini. Par défaut, le délai de transmission correspond au temps nécessaire pour parcourir la distance entre les noeuds à la vitesse de la lumière. Un modèle de propagation des ondes peut être choisi. Les modèles implémentés sont ceux de Friis et de Nakagami. Enfin, il est possible de définir un environnement dans lequel les noeuds vont se situer. Le switcher, lui, communique d un côté avec le simulateur via UDP et de l autre, se met en écoute sur les interfaces associées aux émulateurs Android. Lorsqu un paquet est reçu par le switcher, celui-ci commence par déterminer la source et la destination de celui-ci. Si l une des adresses ne fait pas partie du réseau virtuel ou que le paquet a déjà été reçu, le paquet est jeté. Ensuite, le switcher crée une clé unique représentant ce paquet et ajoute le paquet et sa clé à une table de hachage. Cette table permettra par la suite de retrouver le paquet et de le transférer vers une ou plusieurs interfaces lorsque ce sera nécessaire. La source, la destination et la clé du paquet sont envoyés au simulateur via UDP. Le simulateur réceptionne cette donnée, détermine les noeuds qui peuvent recevoir le paquet et renvoie au switcher les informations sur les destinations. Sur base de l information reçue du simulateur, qui contient la clé du paquet et sa destination, le paquet peut être récupéré dans la table de hachage et transféré sur l interface adéquate. Du côté du simulateur, lorsqu une donnée est reçue de la part du switcher, il faut déterminer quelles sont les informations à lui renvoyer. Tout d abord, il faut identifier si l information reçue correspond à un envoi en mode broadcast ou unicast. Si l adresse destination est FF:FF:FF:FF:FF:FF, il s agit d un broadcast. Sinon, il s agit d un envoi unicast. Dans le cas d un envoi unicast, une fois les noeuds correspondant aux adresses source et destination retrouvés, il est nécessaire de déterminer si le noeud destination capte un signal de la part du noeud source. Pour ce faire, le modèle de propagation calcule la puissance du signal reçue à la destination. Il faut ensuite comparer la puissance du signal reçue à la destination avec la sensibilité du récepteur. Si la puissance est supérieure à la sensibilité du récepteur, la destination entend la source, sinon elle ne l entend pas. Ensuite, il faut récupérer le délai de trans- 44

49 mission associé au couple de noeuds et laisser ce délai s écouler. Une fois ce temps écoulé, l adresse destination et la clé associée au paquet sont renvoyés au switcher. Dans le cas d un envoi en mode broadcast, il faut déterminer l ensemble des noeuds du réseau virtuel qui captent le signal du noeud source. La suite se déroule pour chaque destination de la même manière que pour l envoi en unicast. Il est également possible d utiliser des scénarios. Un scénario représente un suite de mouvements à effectuer à intervalles réguliers. Un gestionnaire de scénarios s occupe d actualiser les positions des noeuds à chaque intervalle de temps. Un scénario ne modifie jamais les puissances d émission et réception d un noeud. De même, il ne va jamais modifier le délai de transmission entre deux noeuds. Via les scénarios, il est aussi possible d allumer ou d éteindre l émetteur/récepteur des noeuds. Les Figures 3.2 et 3.3 illustrent le fonctionnement interne de ces deux implémentations Détails techniques L implémentation des deux programmes a été réalisée en Java. Du côté du switcher, les échanges avec les interfaces réseaux sont réalisés via la librairie Java Jpcap. Celle-ci permet, via des méthodes simples, de capturer et d envoyer des paquets sur une interface réseau grâce à l utilisation de la librairie C pcap. Les échanges avec le simulateur sont réalisés via l utilisation de sockets. Pour assurer le bon fonctionnement des deux programmes, une bonne gestion en temps réel est nécessaire. En effet, une quantité importante de paquets peut arriver et il faut pouvoir traiter ceux-ci, dans le meilleur des cas, dès leur arrivée et minimiser leur temps de traitement. Le démarrage du switcher se déroule en 4 étapes. Tout d abord, le switcher est initialisé avec les adresses MAC des noeuds à utiliser et leur interface correspondante. Ensuite différents threads sont lancés. Chaque interface réseau est associée à un thread qui permet de capturer les paquets qui arrivent sur l interface. Chaque paquet est analysé et stocké dans une queue, uniquement si celui-ci concerne des adresses MAC renseignées à l initialisation, et que l adresse MAC source du paquet est celle associée à l interface. Ce filtrage permet de ne pas encombrer la queue avec des paquets qui n ont aucun rapport avec le réseau virtuel. La queue utilisée est une LinkedBlockingQueue synchronisée et bloquante pour permettre l accès concurrentiel par les différents threads. Un autre thread se charge de défiler les paquets de cette queue. Pour chaque paquet, il détermine la source et la destination, génère une clé représentant le paquet, stocke le paquet et sa clé dans une table de hachage et envoie les informations sur le paquet au simulateur via un socket. Un dernier thread permet d écouter les réponses venant du simulateur via un deuxième socket. 45

50 SWITCHER IFACE 1 IFACE 2 Thread 1 getpacket push QUEUE poll Thread k packet p src=..., dst=..., key=hash(p) add send to simulator (key,src,dst) HASHTABLE Thread receive from simulator (key,dst) send packet to iface IFACE 3 IFACE 4 IFACE 5 Thread 2 getpacket Thread 3 getpacket Thread 4 getpacket Thread 5 getpacket p p p p p push push p dst=... find packet push push (key,packet) SIMULATOR FIGURE 3.2 Fonctionnement du switcher 46

51 SWITCHER SIMULATOR get data from switcher (key, src, dst) LOOP Thread src=..., dst=..., key=... find nodes in dst that hear src based on distance and attenuation start timer (key,dst,delay) srcnode = {x=..., y=..., Pt=...} dstnode1 = {x=..., y=..., Pr=...}, delay_src=... dstnode2 = {x=..., y=..., Pr=...}, delay_src=... dstnode3 = {x=..., y=..., Pr=...}, delay_src=... start timer (key,dst,delay) Timer wait delay Timer wait delay start timer (key,dst,delay) Timer wait delay put (key,dst) put (key,dst) put (key,dst) QUEUE poll Thread key=..., dst=... send to switcher (key,dst) SWITCHER FIGURE 3.3 Fonctionnement du simulateur de réseau sans fil 47

52 Le démarrage du simulateur se déroule en 4 étapes. La première étape consiste à analyser les fichiers d initialisation d environnement, de topologie et de scénario. Ensuite, un thread s occupe d écouter l arrivée de données depuis le switcher via un socket. Une fois les informations analysées et les noeuds source et destination retrouvés, il est nécessaire d attendre un délai de propagation entre la source et chaque destination qui entend la source. Un minuteur est utilisé pour simuler ce délai et est représenté par une instance de TimerTask. Celle-ci, lancée dans un thread, permet d attendre un certain temps avant d effectuer une tâche. Ici, le temps correspond au délai et la tâche consiste à ajouter les données à une queue. Cette queue contient toutes les données déjà traitées et en attente d être renvoyées au switcher. Comme pour le switcher, une queue synchronisée bloquante LinkedBlockingQueue est utilisée et permet l accès concurrentiel via les différents threads. Un autre thread s occupe de défiler la queue et d envoyer successivement les données au switcher via un deuxième socket. Les sockets utilisés pour la communication entre les deux programmes sont des DatagramSocket. Ceux-ci permettent une attente bloquante de données contrairement aux simples Socket qui nécessitent de boucler infiniment sur la réception de données. La gestion des scénarios est également réalisée via un minuteur (Timer- Task). Celui-ci est lancé dans un thread qui s occupe de réaliser une tâche à intervalles réguliers. La tâche à réaliser est de modifier la position des noeuds renseignés dans le scénario. Pour s assurer que ces modifications ne créent pas de conflits avec d autres accès aux positions des noeuds (p. ex. pour le calcul des distances), il est nécessaire d utiliser un sémaphore. Celui-ci s occupe de bloquer l accès aux sections critiques, celles-ci concernent tout accès ou modification de la position d un noeud. Au niveau des structures de données utilisées, les noeuds sont des instances héritées de la classe Point2D.Double. La topologie est représentée par un ensemble de noeuds stockés dans un ensemble Set. La clé associée à un paquet est calculée via la méthode hashcode(), ce qui garantit une unicité assez bonne Utilisation L initialisation du simulateur se base sur la lecture de trois fichiers : un premier indiquant l environnement, un second indiquant la topologie initiale du réseau et un troisième indiquant le scénario à utiliser. Le fichier de topologie doit renseigner l ensemble des noeuds à utiliser, ainsi que leurs positions et puissances d émission et de réception en dbm et l état du noeud (allumé ou éteint). Il est aussi possible de renseigner le modèle de propagation utilisé et la fréquence des ondes radios. Une ligne par noeud est utilisée et chaque caractéristique est séparée par une virgule selon l ordre suivant : <nom>,<x coord>,<y coord>,<tx power>,<rx sensibility>,<true/false> 48

53 La première ligne permet d indiquer le modèle de propagation utilisé avec ses éventuels paramètres et la fréquence des ondes radios. Les commentaires sont représentés par le symbole #. Voici un exemple de fichier représentant une topologie à 4 noeuds utilisant le modèle de Nakagami avec un facteur d atténuation de 1,5 et une fréquence radio de 2,4 GHz. # Example of a topology of 4 nodes nakagami:2.4e9,1.5 A,0,0,15,-92,true B,6,3,15.5,-92,true C,12,1,13,-92,false D,2,8,12,-92,true Le fichier de scénario doit renseigner le délai avant le départ, l intervalle de temps d actualisation et une suite de temps et de positions correspondantes. Chaque temps doit être indiqué en millisecondes. Le délai et l intervalle doivent être situés en première ligne du fichier et séparés par une virgule. Ensuite, chaque ligne doit indiquer un temps supérieur au temps de départ ainsi que les positions et l état des noeuds à actualiser associés à chaque temps. Chaque ligne indique le nom du noeud et les nouvelles coordonnées, chaque coordonnée étant séparée par un symbole deux-points. Il n est pas nécessaire d indiquer les positions associées à chaque intervalle, le programme s occupe lui même de calculer ces positions 2. Il n est pas non plus obligatoire de renseigner l ensemble des noeuds dans chaque ligne. Voici un exemple de fichier de scénario qui débute après 5 secondes et qui actualise le réseau tous les dixièmes de secondes. # Example of a scenario 5000, ,A:1:1,B:6:4,C:10:2 7500,B:7:2,C:11:3,D:4:10 Ci-dessous est détaillé chaque mouvement qui sera effectué par le scénario pour chaque intervalle de temps. 5100, A:0.10:0.10, B:6.00:3.10, C:11.80:1.10, D:2.00: , A:0.20:0.20, B:6.00:3.20, C:11.60:1.20, D:2.00: , A:0.30:0.30, B:6.00:3.30, C:11.40:1.30, D:2.00: , A:0.40:0.40, B:6.00:3.40, C:11.20:1.40, D:2.00: , A:0.50:0.50, B:6.00:3.50, C:11.00:1.50, D:2.00: , A:0.60:0.60, B:6.00:3.60, C:10.80:1.60, D:2.00: , A:0.70:0.70, B:6.00:3.70, C:10.60:1.70, D:2.00: Ces positions sont calculées sur la droite reliant la position précédente à la nouvelle. 49

54 5800, A:0.80:0.80, B:6.00:3.80, C:10.40:1.80, D:2.00: , A:0.90:0.90, B:6.00:3.90, C:10.20:1.90, D:2.00: , A:1.00:1.00, B:6.00:4.00, C:10.00:2.00, D:2.00: , A:1.00:1.00, B:6.07:3.87, C:10.07:2.07, D:2.13: , A:1.00:1.00, B:6.13:3.73, C:10.13:2.13, D:2.27: , A:1.00:1.00, B:6.20:3.60, C:10.20:2.20, D:2.40: , A:1.00:1.00, B:6.27:3.47, C:10.27:2.27, D:2.53: , A:1.00:1.00, B:6.33:3.33, C:10.33:2.33, D:2.67: , A:1.00:1.00, B:6.40:3.20, C:10.40:2.40, D:2.80: , A:1.00:1.00, B:6.47:3.07, C:10.47:2.47, D:2.93: , A:1.00:1.00, B:6.53:2.93, C:10.53:2.53, D:3.07: , A:1.00:1.00, B:6.60:2.80, C:10.60:2.60, D:3.20: , A:1.00:1.00, B:6.67:2.67, C:10.67:2.67, D:3.33: , A:1.00:1.00, B:6.73:2.53, C:10.73:2.73, D:3.47: , A:1.00:1.00, B:6.80:2.40, C:10.80:2.80, D:3.60: , A:1.00:1.00, B:6.87:2.27, C:10.87:2.87, D:3.73: , A:1.00:1.00, B:6.93:2.13, C:10.93:2.93, D:3.87: , A:1.00:1.00, B:7.00:2.00, C:11.00:3.00, D:4.00:10.00 Du côté du switcher, la lancement doit être accompagné d un fichier reprenant les informations sur les noeuds externes. Ce fichier doit contenir le nom de chaque noeud, son adresse MAC et l interface associée de la façon suivante : A,6a:82:00:9b:4a:37,tapA B,52:e9:cc:12:67:ac,tapB C,76:ab:d5:98:f4:ed,tapC D,1c:8b:f7:65:fe:42,tapD Il est important que les noms des noeuds soient les mêmes que ceux du simulateur. De plus, tous les noeuds définis ici doivent avoir été créés dans le simulateur. À l inverse, il n est pas obligatoire de renseigner tous les noeuds du simulateur. 3.3 Communications entre émulateurs et simulateur Pour faire transiter les paquets issus des émulateurs Android au sein du simulateur de réseau sans fil, il est nécessaire de configurer certaines connexions. Premièrement, il faut s assurer que les émulateurs Android peuvent communiquer avec le système hôte. Pour ce faire, on se base sur l utilisation d interfaces TAP. Ces interfaces virtuelles permettent à deux applications de communiquer entre elles. Ainsi, l interface n est pas liée à un dispositif physique comme le sont les interfaces wlan (pour la carte WiFi) et eth (pour la carte Ethernet). Un paquet envoyé à une interface TAP sera reçu par le noyau Linux et renvoyé à la seconde application reliée à cette même interface. Dans 50

55 le cas présent, cette interface permettra de relier un émulateur Android à au système hôte. Avant d établir une connexion entre les deux systèmes, il est nécessaire de créer l interface TAP sur le système hôte. Ceci se réalise via l application tunctl. La commande suivante crée une nouvelle interface nommée tap0 et son utilisation future est réservée à l utilisateur antoine. # tunctl -u antoine -t tap0 Il faut ensuite activer cette interface et lui fournir une adresse IP. # ifconfig tap /24 up L interface tap0 ainsi créée est prête à être utilisée. On peut afficher ses caractéristiques via la commande ifconfig. # ifconfig tap0 tap0 Link encap:ethernet HWaddr 2e:33:0a:26:00:fe inet adr: Bcast: Masque: UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1 Packets reçus:0 erreurs:0 :0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:100 Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B) On peut désormais relier l émulateur Android à l interface tap0. L émulateur étant basé sur le système Qemu, ce paramétrage est réalisable simplement via une option renseignée à l émulateur. La commande suivante permet de lancer un émulateur Qemu et de créer une interface réseau qui sera reliée à l interface tap0 de la machine hôte. # qemu -net user -net tap,ifname=tap0 Au lancement de l émulateur Android, il est possible d indiquer des options à Qemu grâce au paramètre -qemu. La commande lors du lancement de l émulateur devient alors : # <sdk-path>/tools/emulator <options> -qemu -net tap,ifname=tap0 Ainsi, une fois l émulateur lancé, tous les paquets envoyés sur l interface réseau de l émulateur seront reçus sur l interface tap0 du système hôte, et inversement. 3.4 Vision globale de la chaîne d applications Cette section résume les communications et le fonctionnement des différents outils et applications. Tout d abord, un ensemble d émulateurs est lancé sur le système hôte, chacun étant associé à une unique interface TAP. Chaque émulateur fait tourner une instance de DES-SERT avec le même protocole. Le switcher et le simulateur de réseau sans fil sont également lancés 51

56 sur le système hôte avec un ensemble de noeuds représentant chaque émulateur Android et les caractéristiques de chaque noeud (nom, adresse MAC et interface). Le switcher écoute sur chaque interface TAP l arrivée de paquets et traite ceux-ci si nécessaire en collaboration avec le simulateur. Supposons que deux émulateurs Android A et B soient reliés respectivement aux interface tap1 et tap2 du système hôte. Voici ce qu il se passe lorsqu un paquet est envoyé par une instance de DES-SERT de l émulateur A à destination de l émulateur B : 1. le paquet est envoyé sur l interface eth0 de l émulateur A. 2. le paquet est reçu sur l interface tap1 du système hôte correspondant à l émulateur A. 3. le paquet est capturé par le switcher. 4. le switcher détermine les adresses source et destination du paquet et demande au simulateur si la destination capte la source. 5. le simulateur détermine si la destination est à portée de la source. 6. si c est le cas, il en informe le switcher et le paquet est envoyé sur l interface tap2 correspondant à l émulateur destination B. 7. le paquet envoyé sur l interface tap2 est reçu sur l interface eth0 de l émulateur destination B. 8. le paquet est analysé par l instance de DES-SERT de l émulateur B. L approche est similaire pour du broadcast, à la différence que le simulateur détermine un ensemble de noeuds destination qui sont à portée du noeud source. La Figure 3.4 représente les interactions entre les différentes applications pour l exemple détaillé ci-dessus. 3.5 Test de la chaîne d applications Un simple test peut être effectué pour vérifier le bon fonctionnement de la chaîne d applications. Pour ce faire, il suffit de lancer deux émulateurs Android en les faisant communiquer via le simulateur de réseau sans-fil. Le programme tcpdump, natif sur Android, peut être utilisé pour vérifier le transit des messages envoyés et reçus. Test de deux noeuds à portée Ce premier test permet de vérifier que si deux noeuds sont à portée l un de l autre, alors un paquet envoyé par un noeud doit être reçu par l autre noeud. Tout d abord, on lance deux émulateurs Android : 52

57 Machine Hôte Émulateur A Émulateur B DESSERT DESSERT A B paquet ❶ ❹ paquet A B Switcher source=a, destination=b demander au simulateur si B capte A B capte A? ❷ ❸ oui Simulateur de réseau sans fil B A Communications via interfaces Communications via sockets FIGURE 3.4 Communications entre les émulateurs et le simulateur 53

58 Émulateur Android 1, alias 5554 : # /usr/sbin/openvpn --mktun --dev tap user id -un # /sbin/ifconfig tap /24 promisc up # <sdk-path>/tools/emulator -avd avd-2 -port 5554 \ -qemu -net user -net nic,macaddr=52:54:00:12:55:54 \ -net tap,ifname=tap5554,script=no Émulateur Android 2, alias 5556 : # /usr/sbin/openvpn --mktun --dev tap user id -un # /sbin/ifconfig tap /24 promisc up # <sdk-path>/tools/emulator -avd avd-2 -port 5556 \ -qemu -net user -net nic,macaddr=52:54:00:12:55:56 \ -net tap,ifname=tap5556,script=no On démarre le simulateur de réseau sans fil avec deux noeuds 5554 et 5556 situés à 20 m l un de l autre, ce qui garantit une bonne réception de signal. Le switcher est exécuté avec, pour chaque noeud, les paramètres suivants : nom=5554, MAC=52:54:00:12:55:54, interface=tap5554 nom=5556, MAC=52:54:00:12:55:56, interface=tap5556 On récupère ensuite les informations envoyées entre les protocoles sur les émulateurs Android via tcpdump (affichages simplifiés). Émulateur Android 1, alias 5554 # tcpdump -i eth0 12:47: :54:00:12:55:54 > Broadcast 12:47: :54:00:12:55:56 > 52:54:00:12:55:54 12:47: :54:00:12:55:56 > Broadcast 12:47: :54:00:12:55:54 > 52:54:00:12:55:56 Émulateur Android 2, alias 5556 # tcpdump -i eth0 12:47: :54:00:12:55:54 > Broadcast 12:47: :54:00:12:55:56 > 52:54:00:12:55:54 12:47: :54:00:12:55:56 > Broadcast 12:47: :54:00:12:55:54 > 52:54:00:12:55:56 Comme prévu, on remarque que les messages envoyés par l émulateur 5554 sont reçus par l émulateur 5556 et inversement. La Figure 3.5 représente la chaîne d applications et le transfert du premier paquet de l émulateur 5554 à l émulateur Test de deux noeuds éloignés Ce deuxième test permet de vérifier que si deux noeuds ne sont à portée l un de l autre, alors un paquet envoyé par un noeud ne doit être reçu par le deuxième. On commence par lancer les deux émulateurs avec les mêmes paramètres que dans le test précédent. On exécute ensuite le simulateur de réseau sans fil avec les deux noeuds séparés d une distance de 1000 m, ce qui garantit qu ils ne peuvent se contacter. Les paramètres du switcher sont les 54

59 tap5554 tap5556 Switcher 13:20: from tap :54:00:12:55:54 -> ff:ff:ff:ff:ff:ff 13:20: to tap :54:00:12:55:54 -> ff:ff:ff:ff:ff:ff 13:20: from switcher src=5554 dst=ffff key= Simulateur 13:20: to switcher dst=5556 key= FIGURE 3.5 Test de la chaîne d applications avec deux émulateurs Android mêmes que dans le test précédent. On récupère ensuite les informations envoyées entre les protocoles de routage sur les émulateurs Android via tcpdump. Émulateur Android 1, alias 5554 # tcpdump -i eth0 12:49: :54:00:12:55:54 > Broadcast 12:49: :54:00:12:55:54 > Broadcast Émulateur Android 2, alias 5556 # tcpdump -i eth0 12:49: :54:00:12:55:56 > Broadcast 12:49: :54:00:12:55:56 > Broadcast On peut observer que les deux émulateurs Android ne peuvent communiquer entre-eux et que les paquets envoyés par l un ne sont pas reçus par l autre. 55