Banc de test de r´eseau ad hoc

Cette dissertation inclut ´egalement nos travaux de la construction et de la valida-tion d’un banc de test de r´eseau ad hoc. L’analyse de la performance par les outils de simulateur est un choix id´eal pendant la p´eriode initiale de la conception d’un algorithme. Cependant, les simulateurs ont beaucoup de limitations telles que le manque de simulation r´ealiste du comportement de la couche physique. Ces limi-tations rendent essentiel les tests en conditions r´eelles au moyen d’un banc de test.

Ce banc de test nous permettra d’analyser les performances des protocoles dans un vrai r´eseau. Il peut ´egalement ˆetre employ´e pour ´etudier des protocoles et de nouvelles applications de r´eseaux ad hoc sans fil.

Nous avons impl´ement´e Distributed Dynamic Routing (DDR) [89], un proto-cole de routage unicast et MRDC de sorte que le banc de test puisse supporter des communications en point `a point et aussi des communications multipoint.

8.6.1 Impl´ementation et validation d’un protocole de routage d’unicast, DDR

Introduction de DDR

DDR est un algorithme de structuration (“clustering”) distribu´e avec des crit`eres d´eterministes, qui traite le probl`eme de la gestion de topologie dans les r´eseaux ad-hoc sans fil. L’id´ee principale de cet algorithme est que les nœuds sauvegardent l’information de leurs voisins dans la table de voisinage (Neighboorhood table).

Ensuite, ils choissent un voisin, appel´e le voisin pr´ef´er´e (Preferered Node), qui a un degr´e maximum de connectivit´e dans le voisinage (c.-`a-d. le degr´e est le crit`ere de l’algorithme d’´election du voisin pr´ef´er´e) et ´etablissent une liaison logique avec lui. Ceci est fait en utilisant simplement un processus d’envoi p´eriodique de mes-sages balises (“beaconning”). Il est montr´e qu’en reliant chaque nœud `a son voisin pr´ef´er´e en respectant la topologie du r´eseau conduit toujours une forˆet [89]. Dans cet algorithme, chaque arbre de la forˆet forme une zone, et chaque zone est main-tenue proactivement. Des zones sont reli´ees entre elles par l’interm´ediaire des nœuds qui ne sont pas dans la mˆeme zone mais sont dans la couverture de transmis-sion directe de l’un et l’autre. Par cons´equent, le r´eseau est divis´e en un ensemble de zones non-recouvertes. En effet, cet algorithme combine deux notions: forˆet et zone. La forˆet r´eduit le surcoˆut de transmission des messages en choisissant un sous-ensemble de l’ensemble de noeuds voisins pour transf´erer les messages, et des zones sont employ´ees pour r´eduire les d´elais provoqu´es par le processus de routage et pour attendre un meilleur passage `a l’´echelle. Les nœuds sauvegardent les liaisons logiques qui appartiennent `a la mˆeme zone dans leur table d’intra zone (intra-ZT) et dans leur inter-zone table (inter-ZT). Ces tables sont aussi mises `a jour par l’information port´ee dans les beacons. Les nœuds peuvent utiliser l’information enregistr´ee dans leur table d’intra-ZT pour acheminer les paquets dont la source et la destination sont dans la mˆeme zone. Quant aux paquets envoy´es vers les

nœuds en dehors de la zone, le protocole de routage doit d´ecouvrir les chemins d’ne mani`ere r´eactive. C’est pour cela DDR est aussi classifi´e comme un protocole hybride.

Impl´ementation de DDR

La figure 8.4 montre l’architecture d’impl´ementation de DDR. Cette architecture profite du support de transmission des paquets IPv4 qui est d´evelopp´e dans le noyau du syst`eme d’exploitation Linux afin de mettre en application le proto-cole de routage. Un module de transmission d’IP fournit l’op´eration essentielle d’acheminer les paquets vers la couche r´eseau. Ce module analyse l’en-tˆete du paquet IP (l’adresse de destination, TTL et parfois l’adresse de source), et puis envoie le paquet `a l’interface correspondante ou rejette le paquet selon la table de routage (IP forwarding table). Linux nous permet de modifier la table de routage dans le noyau par un socket de type netlink. En cons´equence, le protocole de routage peut ˆetre impl´ement´e comme un “d´emon” dans l’espace d’utilisateur sans besoin de modifier le noyau. Cette version d’impl´ementation ouvre deux interfaces pour la communication. L’interface I1 est une socket de type UDP pour l’envoi et la r´eception des beacons et l’interface I2 est employ´ee pour modifier la table de routage d’IP (IP forwarding table) par une socket de type netlink. En se basant sur l’information fournie par les beacons, DDR ´etablit la table de voisinage et choisit le nœud pr´ef´er´e (Preferred Node). Puis, DDR construit la table d’intra-zone (intra ZT) et la table d’inter-zone (ZT inter) pour d´efinir l’arbre de recouvrement (“span-ning tree”). Dans cette version d’impl´ementation, DDR poss`ede sa propre table de routage. L’information de routage stock´e dans cette table pr´evient directement de la table de sa table d’intra-zone et du processus de d´ecouverte r´eactive dans l’´etape prochaine d’impl´ementation. Selon sa table de routage, DDR met `a jour la table de routage d’IP dans le noyau de Linux. De cette fac¸on nous avons mis en application le cheminement proactif de paquet d’unicast en employant la table d’intra-zone de DDR.

Validation de DDR

Nous validons l’impl´ementation de DDR d’abord dans une configuration de r´eseaux stable qui est repr´esent´e par la figure 8.5. Les quatre portable PCs s’alignent et for-ment une chaˆıne. Nous examinons la table de routage d’IP de noyau dans chaque portable PC et les listons dans la table 8.3. Ils prouvent que DDR ´etablit bien les routes entre ces portable PCs.

Puis nous changeons la position du portable PC radio4 et le mettons sous la couverture radio des autres portable PCs. Ainsi, une topologie en ´etoile est form´ee comme montr´e par la figure 8.6.

En cons´equence, la table de routage d’IP du noyau Linux dans chaque portable PC est modifi´ee selon les tables 8.4 qui correspondent bien `a la d´efinition de DDR.

Ce test valide donc notre impl´ementation.

Application

IP Forwarding Socket Layer

Device Driver

Hardware Interface IP Forwarding table Netlink Socket Neighborhood

Intra-ZT, Inter-ZT DDR I1

I2

Figure 8.4: DDR implementation structure

Radio1 Radio2 Radio3 Radio4

Figure 8.5: DDR validation: line scenario

Table 8.3: IP forwarding tables Dest. GW.

Radio2 Radio2 Radio3 Radio2 Radio4 Radio2

(a) Radio1

Dest. GW.

Radio1 Radio1 Radio3 Radio3 Radio4 Radio3

(b) Radio2

Dest. GW.

Radio1 Radio2 Radio2 Radio2 Radio4 Radio4

(c) Radio3

Dest. GW.

Radio1 Radio3 Radio2 Radio3 Radio3 Radio3

(d) Radio4

Radio1 Radio2 Radio3

Radio4

Figure 8.6: DDR validation: star scenario

Table 8.4: IP forwarding tables Dest. GW.

Radio2 Radio4 Radio3 Radio4 Radio4 Radio4

(a) Radio1

Dest. GW.

Radio1 Radio4 Radio3 Radio4 Radio4 Radio4

(b) Radio2

Dest. GW.

Radio1 Radio4 Radio2 Radio4 Radio4 Radio4

(c) Radio3

Dest. GW.

Radio1 Radio1 Radio2 Radio2 Radio3 Radio3

(d) Radio4

8.6.2 Impl´ementation et validation de MRDC

Cependant, l’impl´ementation de protocole de routage de multicast ne peut pas em-ployer le mˆeme d’architecture que celui d’unicast. D’abord, tous le noyaux Linux ne supportent le relais de paquets de multicast. Deuxi`emement, les noyaux qui supportent le relais de paquets de multicast, ne permettent pas le relais `a partir sur la mˆeme interface. C’est-`a-dire le noyau n’exp´ediera pas un paquet `a l’interface o`u il a rec¸u le paquet pour ´eviter des boucles de transmission. Mais dans MANET, l’exp´edition de multicast se produit sur la mˆeme interface sans fil. Pour surmonter ces limitations, une structure illustr´ee par la figure 8.7 est employ´ee pour mettre en application le protocole de routage de multicast, MRDC. Dans cette architecture, quand une application envoie un paquet de multicast, le noyau de Linux, au lieu de l’envoyer directement `a l’interface sans fil, donne ce paquet `a l’agent de routage (MRDC dans cet exemple) fonctionnant dans l’espace d’utilisateur. Alors MRDC encapsule le paquet et le transmet de proche en proche (saut par saut) d’une mani`ere appropri´ee (broadcast ou unicast) jusqu’`a l’agent de MRDC de destination. En-fin, MRDC de destination d´ecapsule le paquet et le livrent `a l’application locale.

Ce proc´ed´e permet au protocole de routage de multicast de transf´erer des paquets sur l’interface radio identique dans l’espace d’utilisateur tout en ´evitant la modi-fication de noyau. Il facilite l’impl´ementation et l’installation sous des syst`emes d’exploitation h´et´erog`enes.

Application MRDC

Socket layer

MRDC MRDC Application

User Space kernel Space Wireless Interface

(IEEE802.11) Sender Forwarder Receiver

Figure 8.7: User space multicast routing architecture

Nous avons test´e notre impl´ementation de MRDC dans un sc´enario stable et aussi un sc´enario dynamique. Le but de ces tests est de v´erifier si MRDC peut bien construire l’arbre de multicast avec des branches en multiples sauts et si MRDC r´eagit bien quand la topologie ou le groupe changent mais aussi pour avoir la premi`ere connaissance de sa performance. Dans ces tests, “Videoconference tool”

(vic) est choisie comme l’application de multicast. Vic peut distribuer un flux vid´eo `a un groupe. Il envoie aussi p´eriodiquement un message au reste du groupe dans le but de maintenance de l’appartenance au groupe (proc´edure de type “keep alive”). Du point vue de protocole de routage, chaque vic est par cons´equence `a la fois source et r´ecepteur dans le groupe. Cette application nous permet donc de simuler la communication multipoint `a multipoint sans besoin de mobiliser plusieurs cam´eras.

Le sc´enario stable est repr´esent´e par la figure 8.8. Les 6 nœuds (3 portable PCs et 3 PDAs) formaient un anneau autour d’un mur virtuel construit par iptables.

Nous avons d’abord lanc´e l’application de multicast sur le nœud A qui ´etait con-nect´e `a une webcam qui distribue le flux vid´eo `a ce groupe. Ensuite, nous avons lanc´e l’application de multicast sur les nœuds D et F qui rejouent la vid´eo qu’ils rec¸oivent sur leur ´ecran. Nous observons l’´evolution de la structure d’arbre par un outil de moniteur d’arbre. Un arbre de multicast qui connectait les nœuds A, D, F a bien ´et´e construit. Deux formes d’arbre apparaissaient alternativement dans le moniteur `a cause de deux chemins de mˆeme longueur du nœud A vers le nœud F. Nous avons aussi analys´e l’utilisation de bande passante dans ce sc´enario. Les r´esultats montrent que la partie contrˆole y compris celui de IGMP occupe moins 5% de bande passante pour supporter un trafic de 365 kb/s. MRDC est donc effi-cace en ce terme.

Dans le sc´enario dynamique, nous avons simul´e le changement de topologie et ´egalement le changement de groupe. Nous avons d’abord mis les nœuds dans la mˆeme couverture de radio. Nous activons les applications de multicast sur les noeuds A, D et F. Un arbre de multicast est construit et c’est le nœud A qui joue le rˆole de la racine. Alors nous d´eplac¸ons le nœud F hors de la couverture du nœud A mais toujours dans la couverture du nœud B. L’arbre est reconstruit avec

B

D E