Sommaire
8.1 Introduction . . . 137 8.2 Plate-forme de monitorage . . . 138 8.3 Prototype de la plate-forme . . . 139 8.3.1 Composant agent-sonde . . . 139 8.3.2 Composant gestionnaire . . . 140 8.3.3 Interactions entre composants . . . 141 8.3.4 Fonctionnalit´es de base . . . 1418.4 Module d’analyses statistiques . . . 142
8.4.1 Distributions de paquets . . . 143 8.4.2 Participation au routage . . . 143 8.4.3 Centralit´e des nœuds . . . 144
8.5 Synth`ese . . . 144
8.1 Introduction
Ce chapitre pr´esente la mise en œuvre des diff´erentes contributions `a travers le d´eveloppement
d’une plate-forme de monitorage. Le monitorage est une activit´e d’observation qui nous permet
d’´evaluer l’´etat op´erationnel et le fonctionnement d’un r´eseau ad-hoc. L’activit´e comprend la
mesure, la collecte, l’analyse ainsi que le stockage des donn´ees statistiques incluant param`etres
et mesures de performance. L’objectif de cette mise en œuvre est de compl´eter la validation
de nos travaux de recherche par la pratique, en compl´ement des travaux de simulations. Le
d´eveloppement de la plate-forme provient pour l’essentiel de deux projets de recherche avec des
´etudiants en ´ecole d’ing´enieur `a ESIAL. Micka¨el Chaffangeon, Sandra Reichert et Pierre-Yves
Thomas ont travaill´e sur le prototypage de la plate-forme en s’int´eressant plus particuli`erement
au d´eveloppement d’une sonde ad-hoc [51]. Salifou Mahaman et Jean-Claude Tranquillin ont
compl´et´e l’implantation par l’ajout d’un module d’analyses statistiques [130]. L’utilisation de
patrons de conception [88] a largement ´et´e encourag´e dans le cadre de ces r´ealisations pour offrir
une infrastructure facilement extensible. Apr`es avoir pr´esent´e un aper¸cu de la plate-forme de
monitorage, nous d´etaillerons l’architecture fonctionnelle du prototype et les fonctionnalit´es du
module d’analyses statistiques que nous illustrerons `a travers un ensemble de cas d’utilisation.
8.2 Plate-forme de monitorage
Le d´eveloppement de la plate-forme de monitorage pr´esente un double enjeu. Elle permet
tout d’abord d’implanter notre mod`ele d’information pr´esent´e au chapitre 2. Ce mod`ele offre un
cadre formel pour la description des ressources et la structuration de l’information de gestion
dans le contexte des r´eseaux et services ad-hoc. Sa sp´ecification se pr´esente sous la forme d’une
extension du mod`ele commun de l’information (CIM) [56]. Notre mod`ele d’information de gestion
doit ˆetre suffisamment g´en´erique pour ˆetre applicable `a toute forme de sc´enarios. En particulier,
il est n´ecessaire de v´erifier sa correcte instanciation `a travers une implantation concr`ete.
Fig. 8.1 – Vue g´en´erale de la plate-forme de monitorage pour les r´eseaux ad-hoc
D’autre part, cette mise en œuvre permet d’exp´erimenter les diff´erentes techniques d’analyse
que nous avons utilis´ees pour organiser le plan de supervision et adapter les op´erations de gestion.
Des filtres de similitude et de diff´erence ont ´et´e employ´es `a des fins d’analyse de performance.
L’analyse de la centralit´e par vecteur propre nous a permis d’identifier les nœuds importants et
l’´etude de la distribution des paquets dans le plan de routage de d´etecter les nœuds pathologiques.
L’implantation de la plate-forme permet d’appliquer ces m´ethodes dans un environnement r´eel
et ainsi de compl´eter les exp´eriences r´ealis´ees par la simulation.
Une vue g´en´erale de notre plate-forme de monitorage est d´ecrite `a la figure 8.1 : elle dispose
d’une structure relativement l´eg`ere compos´ee d’un gestionnaire principal et d’un sous-ensemble
d’agents-sondes implant´es parmi les nœuds du r´eseau ad-hoc. Tous les nœuds du r´eseau ne
sont donc pas instrument´es, seuls les agents-sondes sont int´egr´es au plan de gestion et ont la
charge d’observer l’activit´e des nœuds situ´es dans leur voisinage. Techniquement parlant, chaque
agent-sonde dispose d’une carte r´eseau en mode promiscuit´e lui permettant d’observer toutes les
trames transmises dans son voisinage quelqu’en soit la destination. Les donn´ees de monitorage
8.3. Prototype de la plate-forme
sont ensuite collect´ees par le gestionnaire principal pour offrir une vue synth´etique du r´eseau
ad-hoc. Le monitorage est r´ealis´e de mani`ere passive par les agents-sondes, sans n´ecessiter l’injection
de paquets sp´ecifiques sur le r´eseau ad-hoc. L’activit´e consiste `a observer et analyser directement
en temps r´eel le trafic de paquets qui transite au sein du r´eseau.
Comparativement `a l’outil de monitorage WANMON (Wireless Ad-Hoc Network Monitoring
Tool) [149] d´ecrit pr´ec´edemment, nous constatons un certain nombre de similarit´es : le
d´eploie-ment d’un agent local permettant d’analyser le trafic r´eseau, ainsi que la possibilit´e d’´evaluer
la participation d’un nœud en distinguant la part du trafic g´en´er´ee par le nœud en tant que
terminal de celle g´en´er´ee par le nœud en tant que routeur. Si l’outil est capable de d´eterminer
statistiquement le coˆut du routage de mani`ere approfondie en termes de trafic, de consommation
d’´energie, d’occupation m´emoire et de charge CPU, le monitorage en tant que tel se limite `a
analyser le comportement du nœud local. L’agent-sonde permet en revanche d’observer le
com-portement de l’ensemble des nœuds ad-hoc localis´e dans le voisinage proche en sondant leur
trafic r´eseau.
8.3 Prototype de la plate-forme
La premi`ere ´etape de notre travail a consist´e `a d´evelopper un prototype de la plate-forme qui
dispose d’un minimum de fonctionnalit´es. Nous entendons par minimum de fonctionnalit´es la
capacit´e d’analyser sommairement les paquets ´echang´es et de construire la topologie du r´eseau.
La figure 8.2 pr´esente l’architecture fonctionnelle du prototype : ce dernier est compos´e d’un
gestionnaire principal ainsi que d’un agent-sonde.
La configuration choisie permet une exp´erimentation de la plate-forme de bout en bout :
de la capture des trames par l’agent-sonde `a l’interface graphique du gestionnaire offrant une
vue synth´etique du r´eseau ad-hoc. Le gestionnaire et l’agent-sonde peuvent ˆetre d´eploy´es sur
un mˆeme nœud ad-hoc dans le sc´enario le plus simple. Cependant, l’architecture doit permettre
de r´epartir les deux composants sur deux nœuds distincts en permettant des ´echanges distants.
Nous allons d´etailler le fonctionnement de chacun des composants puis en d´ecrire les diff´erentes
interactions.
L’essentiel du prototype de la plate-forme a ´et´e r´ealis´e avec le langage de programmation Java
[77]. Le choix de ce langage est motiv´e par plusieurs raisons. De part sa nature orient´ee objet,
ce langage permet une transcription ais´ee des classes de notre mod`ele d’information. Il offre par
ailleurs une grande souplesse en terme de d´eploiement et dispose d’importantes biblioth`eques de
classes qui permettront un d´eveloppement efficace de l’interface graphique du gestionnaire et du
module d’analyses statistiques. La capture des trames s’appuie en revanche sur la biblioth`eque
de fonctionslibpcap [6] d´evelopp´ee en C [121] pour des raisons ´evidentes de performance.
8.3.1 Composant agent-sonde
Le composant agent-sonde a pour fonction premi`ere la capture des paquets circulant au sein
du r´eseau ad-hoc. Son d´eploiement est r´ealis´e sur un ´equipement mobile disposant d’une carte
sans fil configur´ee en mode promiscuit´e. Par d´efaut, une carte sans fil d´etruit imm´ediatement
les trames qui ne lui sont pas destin´ees pour r´eduire la charge de traitements. Afin d’observer
le voisinage proche, nous configurons la carte avec le mode promiscuit´e qui permet de r´ecup´erer
l’int´egralit´e du trafic r´eseau sans condition sur le destinataire de la trame.
La biblioth`eque de fonctions libpcap est utilis´ee pour capturer les paquets. De nombreux
outils r´eseaux tels qu’ethereal [59] et snort [168] exploitent cette c´el`ebre biblioth`eque car elle
fournit une interface de programmation compl`ete. Elle permet d’effectuer des captures `a partir de
Fig. 8.2 – Architecture fonctionnelle de la plate-forme avec un agent-sonde
diff´erents supports, et dispose d’un m´ecanisme de filtrage int´egr´e utilisant BPF (Berkeley Packet
Filtering) [136] implant´e au sein du noyau syst`eme pour offrir de meilleures performances.
Le corps de l’agent sonde est d´evelopp´e en Java pour faciliter notamment l’implantation de
la base d’informations. Les ´echanges avec la biblioth`equelibpcap d´evelopp´ee en C reposent sur
l’utilisation de sockets. L’agent-sonde capture les paquets `a partir de cette biblioth`eque et
main-tient parall`element une base d’informations sur le trafic r´eseau observ´e. La base d’informations
est ensuite mise `a la disposition du composant gestionnaire.
8.3.2 Composant gestionnaire
Le composant gestionnaire est charg´e de configurer le composant agent-sonde et de collecter
les donn´ees de monitorage aupr`es de celui-ci afin de construire une vue synth´etique du r´eseau
ad-hoc. La collecte correspond `a des requˆetes p´eriodiques du gestionnaire `a l’agent-sonde. Le
gestionnaire dispose d’une interface graphique permettant d’interagir avec l’utilisateur et de
fournir des informations statistiques sur le r´eseau.
Le gestionnaire est enti`erement r´ealis´e en Java et implante le patron de conception
Mod`ele-Vue-Contrˆoleur. Le mod`ele repr´esente la base d’informations de gestion du gestionnaire tandis
que la vue constitue l’interface graphique fournie `a l’utilisateur. Le principe de ce patron est
relativement intuitif : lorsqu’un utilisateur ´emet une requˆete par le biais de l’interface graphique,
celle-ci est analys´ee par le contrˆoleur. Ce dernier effectue les traitements appropri´es aupr`es du
mod`ele, en l’occurence la base d’informations de gestion. La modification du mod`ele provoque
la mise `a jour de la vue, donc de l’interface graphique du gestionnaire.
8.3. Prototype de la plate-forme
8.3.3 Interactions entre composants
Dans le document
Supervision des Réseaux et Services Ad-Hoc
(Page 150-154)