MobUML

1. EcoMesh 10/05/2005 MobUML • motivation • présentation d'User Mode Linux • présentation de Wifi for UML • présentation du simulateur de mobilité simulateur de réseau de machines UML connectées par WiFi mode ad-hoc

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

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

4. Architecture applications applications noyau générique fonctions architecture UML appels système noyau générique (indépendant de l'architecture) fonctions dépendantes de l'architecture (pilotes..) matériel • 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

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

6. Wifi for UML moteur config.xml client TCP client TCP machine UML machine UML pilote hostap modifié pilote hostap modifié simulateur • Guffens de l'UCL (Louvain, Belgique) modèle du noeud serveur TCP visualisation hôte

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

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

9. 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 • …

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