La simulation

La simulation est la méthode la plus simple pour évaluer un réseau, un mécanisme ou un algorithme au sein d'un réseau spécifique. Il existe de nombreux simulateurs réseaux à plusieurs niveaux (couches réseaux). Nous nous intéresserons plus particulièrement à la simulation des couches hautes (IP et au-dessus). Elle peut être réalisée par un certain nombre de simulateurs tels que Qualnet, Glomosim, Opnet ou NS-2. Notre choix se tourne vers NS-2 car il est libre (open source), multiplateformes, et grandement répandu dans la recherche. De plus, sa prise en main rapide le différencie des autres simulateurs comme Opnet.

Dans la simulation, des modèles abstraits établis au préalable sont utilisés pour rejouer un scénario précis, un profil d'application/protocole et un modèle de simulation de réseau spécifique. Par exemple, on peut simuler un transfert FTP (Protocole TCP) sur la voie retour d'un réseau Satellite DVB-RCS en utilisant le modèle MFTDMA-DAMA de Secchi Rafaello [43]. L'avantage est la liberté d'effectuer des tests, de manière logicielle et de rejouer exactement le même test plusieurs fois afin d'établir des analyses comparatives et des séries statistiques.

Bien que cette méthode présente beaucoup d'avantages, en particulier pour les systèmes satellites qui nécessitent de grosses infrastructures, elle reste moins réaliste à cause de l'absence de modèle adéquat du lien physique.

Dans cette partie, nous allons décrire le simulateur NS-2, son fonctionnement ainsi qu'un exemple de modèle célèbre dans le contexte d'un réseau d'accès satellite.

2.1.1 Introduction à NS-2

Network Simulator (NS) [44] est un simulateur à événements discrets pour les réseaux informatiques. NS est né d'un projet de la Defense Advanced Research Projects Agency (DARPA), une agence du Departement of Defense (DoD) des États-Unis. A sa naissance en 1989, il était considéré comme une variante de « Real Network Simulator ». Depuis, le logiciel a évolué grâce aux différents groupes qui

49

participent à son développement mais aussi aux apports des chercheurs qui l’exploitent dans leurs travaux de recherche. En plus de son efficacité, NS est en accès libre et peut être exécuté sur tout type de système d'exploitation. Il est donc rapidement devenu une référence dans le domaine.

Différentes versions sont disponibles. A la fin 2008, la version 3 du logiciel est parue, elle est le fruit de modifications récentes et d'une nouvelle architecture mêlant C++ et Python.

Notons que les protocoles fournis avec la version de base ont été testés par les concepteurs dans un nombre important de configurations. Néanmoins, toutes les configurations n'ont pu être testées. Cette mise en garde est donnée dans les premières pages du manuel de NS, et sur la page d'accueil du site officiel. Il faut donc garder un œil critique sur les résultats obtenus. Ainsi, il faut vérifier que ceux-ci sont cohérents par rapport aux résultats obtenus avec d'autres méthodes d'évaluation (l'émulation ou les tests de piles réelles).

2.1.2 Fonctionnement

NS-2 est un simulateur orienté objet écrit en langage C++ avec une interface de programmation en Tcl. Son architecture lui confère une grande modularité, et une réutilisation facile du code. Les utilisateurs ont ainsi la possibilité de modéliser des réseaux filaires ou sans-fil, et d’effectuer des simulations de trafics avec de nombreux protocoles, topologies et applications :

· Génération de trafic selon des lois générales (PARRETO, poisson…etc.), CBR, FTP, telnet, etc.

· Couche Transport TCP, UDP, SRM, SCTP, PLM.

· Couche Réseaux IP, routage dans les réseaux ad hoc (aodv, dsr, dsdv, tora, amodv), routage dans les réseaux filaires (link state, distance vector), les réseaux multicast, IntServ, DiffServ

· Couche MAC CSMA, CDMA, 802, X, Token ring, MPLS, liens satellite, etc.

Le simulateur supporte une hiérarchie en classes C++, et une hiérarchie semblable dans l'interface Otcl. Les deux hiérarchies sont reliées entre elles et, du point de vue utilisateur, les classes correspondent l'une à l'autre. Le lien entre les deux est fait avec un objet Tcl, dit TclObject en anglais. Lorsqu'un utilisateur crée un objet au travers de l'interface, celui-ci est instancié dans l'interface Tcl, puis relié à un objet correspondant dans les structures C++.

L'utilisation de deux langages de programmation permet d'avoir les avantages du C++ et du Tcl, sans en avoir forcément les inconvénients. En effet, le C++ est un code rapide à exécuter, mais qui peut être long à modifier (compilation, débogage). Il est donc bien adapté à la modélisation détaillée de protocoles, gérant facilement les paquets comme les variables. Le langage Otcl peut être modifié plus facilement (pas de compilation). Par contre, son exécution est plus longue,mais il est mieux adapté à la configuration des simulations, à la création des liens entre les objets, et au réglage des paramètres des différents protocoles.

En ayant une approche simpliste, on peut comparer l'architecture réseau classique avec l'architecture interne des modèles utilisés par NS (voir Figure 15). Il faut néanmoins garder en mémoire que les modifications faites par les utilisateurs sont correctes d'un point de vue réseau si et seulement si celles-ci ont été faites judicieusement et aux bons emplacements.

50

Figure 15 : Correspondance entre les composantes NS et les couches réseau [44]

Comme on peut le voir sur la Figure 15, les composants primaires d'un modèle sous NS sont les nœuds, les liens, les agents et les applications. Les différentes variables et méthodes relatives à ces composants sont définies dans des classes C++, et vont être déclarées dans le script écrit par l'utilisateur ou dans les procédures invoquées depuis ce script.

L'architecture d'un nœud est inspirée de la réalité. Lorsqu'un paquet est généré par une application, celle-ci l'envoie à l'entrée du nœud via un agent. Les paquets arrivant à l'entrée d'un nœud passent d'abord par un démultiplexeur (address classifier) qui va diriger le paquet en fonction de son adresse de destination. Si celui-ci n'est pas destiné au nœud où il se situe, il est envoyé vers un des liens dans un réseau maillé, ou vers un agent de routage dans un réseau plus complexe. Ce dernier le dirigera vers le bon lien. Si le paquet est destiné au nœud où il se situe, il passe par un second démultiplexeur (port classifier) qui va le diriger vers son port de destination qui contient un agent.

En ce qui concerne la simulation satellite, on peut ajouter tout simplement un délai au lien (i.e. 250 ms) et limiter la bande passante, sinon utiliser directement un modèle existant. Dans cette optique, plusieurs modèles NS-2 célèbres ont fait leurs preuves. Parmi ces modèles, on peut citer celui de Rafaello Secchi MF/TDMA-DAMA, qui simule l'allocation dynamique DAMA.

2.1.3 Le modèle MF/TDMA-DAMA

MF/TDMA-DAMA [43] [45] est un ensemble de modules NS-2, pour la simulation détaillée du DVB-RCS. Le Framework vise à fournir un bon niveau de détail de la couche MAC du DVB-DVB-RCS. La signalisation, à partir de requêtes de capacité et le plan d'allocation de ressources TBTP (Terminal Burst Time Plan) sont conformes au standard. Cela permet une simulation au niveau paquet dans le DVB-RCS et aux environnements hétérogènes contenant un réseau DVB-RCS.

MFTDMA-DAMA vise à être une aide importante pour le problème de dimensionnement de réseau (par exemple, la détermination du nombre de transpondeurs et leur composition pour satisfaire un SLA spécifique). Il peut aussi être utilisé pour identifier des problèmes au niveau 2, tels que l'efficacité d'encapsulation dans certains types d'applications ((Trafic Internet, VoIP…etc.).

51

Bien que NS-2 présente une grande flexibilité et une facilité d'utilisation, ainsi que la possibilité de simuler presque tous les types de réseau, flux et profils d'application, il présente quelques limitations, telles que l'incapacité à fragmenter les paquets. En effet, il traite ceux-ci comme des variables en les numérotant et en y accédant via des pointeurs, le réveil des composants se faisant via des handlers. Ceci va poser un problème lorsque nous voudrons modéliser le passage des protocoles ATM ou MPE vers IP. Néanmoins, la facilité que donne NS pour manipuler les paquets (changement dans l'en-tête, modification de la taille ou du type) va pallier ce défaut et ne portera pas trop préjudice à la simulation.