MobUML

simulateur de réseau de machines UML connectées par WiFi mode ad-hoc

• motivation• présentation d'User Mode Linux• présentation de Wifi for UML• présentation du simulateur de mobilité

EcoMesh 10/05/2005

Pourquoi une nouvelle plate-forme de test ?

● inconvénients des simulateurs classiques (NS2, GloMoSim, Omnet++...) :

– adressage automatique plat

– pour tester un protocole d'autoconfiguration des adresses, il faut apporter des modifications au coeur (un peu « fouillis ») du simulateur

– impossible de passer ensuite rapidement à une implémentation réelle

– pour chaque usage, il faudra modéliser le trafic

– validité des résultats obtenus avec des noeuds mobiles discutée

● idée : utiliser des simulateurs s'appuyant sur des implémentations réelles des piles de protocoles

● tentative avec le nouveau-né NCTUns : encore trop de bugs

● adaptation de Wifi for UML

UML = User Mode Linux

● portage du noyau Linux sur une nouvelle architecture... le noyau Linux

● travail débuté en 2000 par Jeff Dike (hobby + Dartmouth ISTS), intégré à l'arbre de Linus depuis la version 2.5 du noyau

● adaptation du noyau Linux lui permettant d'être exécuté comme un (ensemble de) processus utilisateur

⇒ exécution sous gdb ou utilisation comme machine virtuelle

Architecture

● OS et ses processus : processus de l'hôte

● Matériel : émulé :

– disques : fichiers sur l'hôte

– console principale : attachée à stdin et stout, autres consoles : xterms. lignes séries : ptys

– réseau Ethernet : utilisation de multicast ou d'un démon tournant sur l'hôte pour faire un réseau virtuel, utilisation de dispositifs TUN/TAP pour se connecter à l'hôte

fonctions dépendantes de l'architecture (pilotes..)

matériel

noyau générique (indépendant de l'architecture)appels système

fonctions architecture UMLnoyau générique

applicationsapplications

Principales utilisations

● tester facilement et sans risque de nouveaux noyaux, de nouvelles distributions

● disposer sur une même machine et sans avoir à rebooter d’un jeu de configurations différentes pour le test de logiciels

● test de protocoles ou d’applications réseau

● pot de miel

● enseignement

Wifi for UML

● Guffens de l'UCL (Louvain, Belgique)

simulateur

serv

eur

TC

P

hôte

pilote hostap modifié

client TCP

machine UML machine UML

client TCP

pilote hostap modifié

config.xml

visualisation

moteur

modèle du noeud

Limitations de Wifi for UML

● Tous les nœuds ont les mêmes caractéristiques

● Un seul modèle de mobilité (aléatoire) → difficile de rejouer un scénario pour comparer des résultats !

Les modifications que j’ai apportées à Wifi for UML● « extension » du fichier XML décrivant la configuration :

chaque nœud a sa propre configuration

● introduction d’un nouveau modèle de mobilité :

les mouvements d’un nœud sont décrits par une liste de positions datées (la date 0 correspond au « chargement » de la première carte réseau sans fil)

Améliorations possibles pour en faire un outil encore plus intéressant, au delà des objectifs poursuivis pour EcoMesh

● vérifier l’intégrité du fichier XML et combler les certains trous par des valeurs de défaut définies

● introduire la possibilité de décrire des mouvements cycliques● mettre en place des filtres paramétrables pour n’afficher qu’un

seul type de trafic● mettre en place un mécanisme d’enregistrement des événements

de manière à pouvoir re-visualiser un scenario sans avoir exécuter à nouveau les UML (avec possibilité de retour arrière, ralentissement, clic sur un paquet pour afficher ses caractéristiques…)

● introduction d’obstacles aux ondes radio● pilote pour points d’accès virtuels et cartes WiFi en mode

infrastructure● intégrer les nœuds fixes à la représentation graphique● suite d’outils pour lancer automatiquement les UMLs et contrôler

la simulation● …

Autres items de la « to do list »

● étudier les performances du simulateur (scalability)

● comparer les résultats du simulateur avec ceux observés sur la plate-forme réelle