Memoire Online - Greedy perimeter stateless routing sur omnet++

Dans une simulation d'événement discret, le travail d'un système est présenté par le déroulement chronologique de séquences d'événement. Chaque événement se produit à un instant bien déterminé et marque un changement d'état dans le système.

Une simulation d'événement discret a pour but de visualiser l'état du système à n'importe quel instant donnée.

De telles simulations obéissent à une logique de conception qui permet de valoriser certain aspect du système, comme par exemple dans notre cas, l'efficacité du protocole à échanger les données entre noeuds mobiles.

Pour cela on présente le processus de simulation que nous avons adopté pour l'élaboration de notre projet.

1. Les simulateurs:

Les besoins croissants de tester les nouvelles technologies et les nouveaux protocoles avant leur déploiement a conduit à la prolifération des simulateurs. On peut les classer en deux types: les logiciels libres et gratuits tels que OMNet++, J-Sim et NS2... et les logiciels commerciaux tels que OPNET et NetRule...

1.1.1. Présentation:

NS2 est un outil de simulation de réseaux de données. Il est bâti autour d'un langage de programmation appelé Tcl dont il est une extension. Du point de vue de l'utilisateur, la mise en oeuvre de ce simulateur se fait via une étape de programmation qui décrit la topologie du réseau et le comportement de ses composants, puis vient l'étape de simulation proprement dite et enfin l'interprétation des résultats. Cette dernière étape peut être prise en charge par un outil annexe, appelé nam qui permet une visualisation et une analyse des éléments simulés.

NS2 est en réalité un programme relativement complexe écrit en C++ et interfacé via Tcl. Pour modifier le comportement d'objets existants, il est donc nécessaire de modifier le code C++ qui en réalise l'implantation.

TCL (Tool Command Language) est un langage de commandes qui sert à contrôler les applications. C'est essentiellement un langage de scripts offrant des structures de programmation telles que les boucles, les procédures ou les notions de variables.

Application	Web, FTP, Telnet, générateur de trafic(CBR, ..)
Transport	TCP, UDP, RTP, SRM
Routage	Statique, dynamique (vecteur distance) et routage multipoint (DVMRP, PIM)
Gestion des files d'attente	RED, Drop Tail, Token bucket
Discipline de service	CBQ, SFQ, DRR, Fair queueing
Système de transmission	CSMA/CD, CSMA/CA, lien point à point

1.1.3. Modèles de mobilité:

NS-2 implémente deux modèles de mobilités :

Ce modèle génère un mouvement aléatoire du noeud de façon que le noeud choisie sa prochaine destination d'une manière aléatoire en se déplaçant avec une vitesse aléatoire constante.

C'est un mouvement généré par un scénario qui consiste à ce que l'utilisateur donne une destination bien précise et une vitesse de déplacement constante.

1.1.4. Structure d'un noeud mobile dans NS2:

1.2. Le simulateur OMNet++:

1.2.1. Présentation:

Dans ce projet, nous allons réaliser nos expérimentations à l'aide d'OMNET++ qui est un simulateur à évènements discrets orienté objet, basé sur C++. Il a été conçu pour simuler les systèmes réseaux de communication, les systèmes multi processeurs, et d'autres systèmes distribués. OMNET++ est un projet open source dont le développement a commencé en 1992 par Andras Vargas à l'université de Budapest.

Actuellement, Ce simulateur est utilisé par des dizaines d'université pour la validation de nouveaux matériels et logiciels, ainsi que pour l'analyse de performance et l'évaluation de protocoles de communication.

L'avantage de OMNET ++ est sa facilité d'apprentissage, d'intégration de nouveaux modules et la modification de ceux déjà implémentés. Nous introduisons dans la suite l'architecture du simulateur OMNET++ et les librairies Mobility Framework et INET.

L'architecture d'OMNET++ est hiérarchique composé de modules. Un module peut être soit module simple ou bien un module composé. Les feuilles de cette architecture sont les modules simples qui représentent les classes C++. Pour chaque module simple correspond un fichier .cc et un fichier .h. Un module composé est composé de simples modules ou d'autres modules composés connectés entre eux. Les paramètres, les sous modules et les ports de chaque module sont spécifiés dans un fichier .ned.

La communication entre les différents modules se fait à travers les échanges de messages. Les messages peuvent représenter des paquets, des trames d'un réseau informatique, des clients dans une file d'attente ou bien d'autres types d'entités en attente d'un service. Les messages sont envoyés et reçus à travers des ports qui représentent les interfaces d'entrer et de sortie pour chaque module.

La conception d'un réseau se fait dans un fichier .ned et les différents paramètres de chaque module sont spécifiés dans un fichier de configuration (.ini). OMNET++ génère à la fin de chaque simulation deux nouveaux fichiers omnet.vec et omnet.sca qui permettent de tracer les courbes et calculer des statistiques.

1.2.3. Composants:

Application :	FTP, Telnet, générateur de trafic (IPTrfGen..), Ethernet, Ping App, UDPApp, TCPApp
Transport :	TCP, UDP, RTP
Réseau :	IPv4, IPv6, ARP, OSPF, LDP, MPLS, ICMP, TED...
Liaison :	Mgmt, MAC, Radio
Node :	Ad Hoc, Wireless, MPLS...

1.2.5. Frameworks:

1.2.5.1. Mobility Framework:

La librairie MF est une extension du simulateur OMNeT++. Elle a été développée par une équipe de chercheurs à l'université de Berlin. Sa dernière version a été proposée par Marc Loebbers en Octobre 2003. Cette librairie est destinée à soutenir les réseaux sans fil et mobiles au sein de simulations OMNeT++. En effet, elle permet une bonne manipulation des noeuds mobiles et la gestion des connexions dynamiques pour avoir un modèle de mobilité de réseau sans fils qui fournie des résultats le plus proche possible du monde réel. En outre, MF prévoit des modules de base qui peuvent être utilisés pour former de nouveaux modules. Avec ce concept, un programmeur peut facilement développer ses propres protocoles avec l'interface nécessaire.

Aujourd'hui, il y'a un développement d'une bibliothèque de protocoles normalisés pour la MF (802,11, AODV, ...), dont l'objectif est de disposer d'une bibliothèque riche de ces protocoles afin de permettre facilement Plug-and-Play des simulations de différents types de protocoles largement utilisés.

La base pour toutes les classes des modules de la couche physique est ChannelAccess qui est à son tour dérivée de BasicModule. La seule fonctionnalité que fournit ChannelAccess est la connectivité au Channel (i.e. aux autres noeuds). La fonction sendToChannel () doit être utilisée pour passer des messages au Channel. Elle enverra le message pour chaque gate connecté du module de l'hôte.

Il existe deux versions de PhyLayer. La première version est appelée P2PPhyLayer, elle assume les connections point à point entres les hôtes. C'est la plus simple couche physique que l'on puisse utiliser. Pour la seconde version, elle est appelé Nic80211 dont les fonctionnalités de la couche physique ont étés divisées en 3 modules simples qui sont Decider80211a, SnrEcal80211a et Mac80211a.. Les calculs de SNR ont été laissées séparés du Decider à cause des bits errors. Ce concept rend la création modules Decider qui utilisent le même SnrEval module plus facile, et vis versa.

On peut par exemple définir un module Decider qui compare les calculs de SNR avec un qui utilise le forward error correction et les deux modules peuvent utiliser le même SnrEval module.

La classe Mac80211a est une implémentation de la norme IEEE 802.11a. Nous nous sommes basés sur [Std00] pour extraire les différents paramètres comme le calcul de la durée de transmission packetDuration(), la taille la fenêtre de contention et les durées des périodes ST, SIFS, DIFS, EIFS.

Le module SnrEval simule un délai de transmission pour tous les messages reçus et calcule les informations SNR. Le BasicSnrEval ne tient pas compte des retards de propagation. Les SNR informations sont stockées dans un SnrList. Chaque entrée SnrList contient un timestamp et un SNR de la valeur de ce timestamp. HandleLowerMsg () est subdivisé en handleLowerMsgStart () et handleLowerMsgEnd (). En outre, nous avons défini un bufferMsg (). Juste après, un message est reçu handleLowerMsgStart (). En outre, le rapport signal / bruit de tous les renseignements d'autres messages dans le tampon de réception devrait être mis à jour si vous le souhaitez. Ensuite, le message est tamponné (fonction bufferMsg ()) pour simuler un délai de transmission. Entre temps, il y a d'autres messages qui peuvent arriver mais ils interférent avec la mémoire tampon du message, et par conséquent, il en résulte de nouvelles entrées SnrList supplémentaires pour indiquer un changement de SNR pour ce message.

Une fois la transmission est achevée (c'est-à-dire le message est complètement reçu), handleLowerMsgEnd () est appelé juste avant que le message soit transmis au Decider module. Ici, le message devrait être supprimé du tampon de réception et de la SnrList contenant les informations SNR calculés, ainsi les valeurs devraient être passée en argument à la sendUp (). La fonction sendUp() est celle qui assure la transmission du paquet vers la couche supérieure .

Nous croyons que notre concept permet à tous ces différents modèles, sans être trop complexe, mais en même temps d'être assez sophistiqués pour soutenir également des modèles complexes.

Le module Decider ne traite que les messages provenant de la chaîne (c'est-à-dire à partir de
la couche inférieure). Les messages provenant des couches supérieures, ayant contourné le module Decider, sont directement remis au module SnrEval. Les décisions concernant la perte ou les erreurs sur les bits messages ne doivent être faites au sujet de messages provenant de la chaîne. En conséquence, il n'est pas nécessaire de traiter les messages provenant de couches superficielles du module Decider.

Quand vous évaluez la performance d'un protocole, vous avez besoin de renseignements sur le contrôle interne les changements d'état de votre protocole, peut-être même à partir de protocoles que vous utilisez. Vous pouvez suivre ces changements, en utilisant par exemple vecteur de fichiers dans votre protocole et supprimer ces moniteurs une fois que vous l'avez fait. Une autre façon est d'utiliser un tableau noir. L'état des changements sont publiés sur lui, et les moniteurs de souscrire ces valeurs. Cela permet à d'autres chercheurs d'exploiter votre protocole d'évaluation de la performance, tout en imposant presque aucun moment de l'exécution de la peine lorsque l'information n'est pas nécessaire. Peut-être même plus important encore, le tableau noir vous permet d'échanger des informations entre les couches, sans passer des pointeurs vers les modules autour. Il existe plusieurs méthodes permettant à l'abonné d'utiliser le tableau noir, parmi ces méthodes, on peut citer le BasicModule : qui fournit tout le nécessaire pour interagir avec le tableau noir. Il est dérivé de ImNotifiable qui est une classe de base virtuelle pure qui permet d'informer le tableau de votre module de changements.

Cette section décrit l'architecture de la mobilité utilisée dans la MF. Il ya deux questions à examiner concernant une architecture de mobilité dans un cadre de simulation. La première question est de savoir où traiter les d'informations sur la mobilité et la deuxième est comment gérer les mouvements des hôtes. Où et comment gérer dynamiquement les connexions de manière efficace est la deuxième décision à prendre. Nous avons décidé de gérer la mobilité d'une manière distribuée localement dans chaque module hôte. La gestion de la connexion est gérée par un contrôleur central. La composante de base de l'architecture de la MF est le module ChannelControl avec un hôte MobilityModule. ChannelControl s'occupe de tous les paramètres liés à la connexion alors que les MobilityModules ont deux tâches principales: la première tâche est de gérer les mouvements de l'Hôte qui peut être fait en utilisant différents modèles de la mobilité (comme le Manhattan Mobilité ou le mouvement brownien), alors que le second rôle des MobilityModules est de communiquer pour contrôler l'évolution de l'hôte au ChannelControl. Dans l'étape qui suit le ChannelControl met à jour toutes les connexions pour ces hôtes.

Le module ChannelControl est chargé d'établir des canaux de communication entre les modules d'accueil (qui sont à distance de communication) ainsi que de rompre ces liens une fois qu'ils perdent la connectivité à nouveau. La perte de la connectivité peut être due à la mobilité (c'est-à-dire les hôtes se déplacent trop loin) ou en raison d'un changement dans la transmission de puissance ou d'un hôte. Nous avons décidé de garder le concept de liens entre les modules d'accueil, par opposition au passage de message direct, en effet les voies de communication sont une source importante de déboggage des informations.

Malheureusement, dans OMNeT + + les liens entre les différents modules ont besoin d'au moins deux gates objets pour chaque module, un appelé IN et un autre appelé OUT sur la porte (et pour chaque sous module). Pour notre MF, le nombre minimal de portes de lien est six vu que le module Nic est intégré dans le module hôte et est elle-même subdivisée en un SnrEval et un module Decider Mac. Une approche de mémoire plus efficace est de créer dynamiquement des portes. Les gates ne sont pas attribués à l'initialisation du réseau, mais créés dynamiquement sur demande. Chaque module possède deux hôtes listes un pour free-in-gate et un pour le free-out-gate. Une fois le module ChannelControl veut établir un lien entre deux hotes, il regarde d'abord le gate dans la listes d'Hôtes pour savoir si les portes sont disponibles, si il n'existe aucune porte libre un nouveau est créé immédiatement. Lors de rupture de lien ChannelControl à la connexion on ajoute les portes nouvellement libéré à la porte de la liste correspondante. Avec cette approche, nous réduisons la mémoire nécessaire sans augmenter les frais généraux de calcul. Dans les simulations de réseau sans fil, non seulement le fait de savoir si deux hôtes sont connectés (c'est-à-dire de communiquer les uns avec les autres) est important, mais aussi le fait de savoir que les deux machines peuvent interférer les uns avec les autres.

1.2.5.2 INET:

INET est une librairie open source pour la simulation des réseaux informatiques dans l'environnement OMNeT++. Elle contient IPv4, IPv6, TCP, UDP, des protocoles implémentés, et plusieurs modèles d'application. Elle comprend également un modèle avec MPLS RSVP-TE et de signalisation LDP. La couche liaison sont des modèles de PPP, Ethernet et 802.11.Le routage statique peut être configuré à l'aide du réseau auto configurateur, ou on peut utiliser le protocole de routage mise en oeuvre.

INET prend en charge les simulations des réseaux sans fil et mobiles, ainsi les réseaux ad-hoc. Récemment les modèles MPLS, RSVP-TE et LDP sont révisés et réécrit, sans oublier le routage dynamique (RIP et OSPFv2).

Dans ce paragraphe, nous allons présenter une étude de l'existant de la librairie INET et plus précisément l'implémentation des couches PHY, MAC, IP, RTP, UDP et TCP dans INET.

La couche physique est la partie essentielle d'un noeud sans fil. Il est responsable de l'envoi et la réception de message, détection de collision, et calcul d'erreur sur les bits. La couche physique est divisée en trois parties, qui sont décrites en détail dans les sous-sections suivantes :

· PhyLayer fournit les interfaces de la couche MAC et de la couche physique des autres noeuds.

· AnalogueModels sont responsables pour la simulation de l'atténuation d'un signal reçu.

· le Decider est responsable de l'évaluation et de démodulation des messages reçus.

A ce qui concerne notre projet, on a besoin la couche physique IEEE 802.11b qui est déjà implémentée dans OMNET++ dés 2006.

La couche MAC IEEE 802.11b est implémentée dans la librairie INET, elle supporte le mécanisme RTS/CTS. Il n'y a que l'algorithme DCF implémenté, le PCF n'est pas implémenté. Le débit de transmission physique est constant pendant la simulation.

Le simulateur OMNET++ contient deux classes de bases pour former la couche MAC :

· EyesMACLayer fournie un ensemble de fonction dont l'importante est de renvoyer les informations concernant la couche MAC d'un noeud.

Dans notre cas la couche MAC IEEE 802.11b est implémentée dans la librairie INET en utilisant RTS/CTS. Il n'y a que l'algorithme DCF implémenté, le PCF n'est pas implémenté. Le débit de transmission physique est constant pendant la simulation. Aucun des algorithmes d'adaptation du débit de transmission physique n'est implémenté. Les paquets multipoints au niveau MAC sont envoyés de la même manière que les paquets broadcast. Le filtrage de ces paquets se fait au niveau IP.

L'Internet Protocol (IPSuite) fournit des IPv4, TCP et UDP dans les modèles de simulations
OMNeT + +. D'abord, il a été développé par plusieurs personnes à l'Université de Karlsruhe. À la fin de l'année 2003, l'auteur de OMNeT + +, Andras Varga, a repris l'entretien de l'ensemble IPsuite. Il a également créé plus de documentation pour le paquet, ce qui rend plus facile à utiliser et faire des ajustements pour le modèle. Dans le même temps, un modèle l'IPv6 a été créé. Mais le routage IP est de implémenté de manière statique. Alors, l'utilisateur doit configurer les adresses IP et les adresses de groupes multicast dans les tables de routages avant la simulation. C'est au niveau IP que se passe le filtrage des paquets multicast.

Le routage multipoint au niveau IP est déjà implémenté mais de manière statique. C'est à dire que l'utilisateur doit configurer les adresses IP et les adresses de groupes multicast dans les tables de routages avant la simulation. C'est au niveau IP que se passe le filtrage des paquets multicast.

La couche RTP présente le niveau transport, elle n'est pas encore intégrée dans la librairie INET. Dans la version 20061020, il y a une implémentation de la couche RTP réalisé par Matthias Opptiz et ajouté par Andras Vargas mais elle n'est pas encore intégrée. Le problème de cette implémentation est qu'elle a été faite dans une ancienne version de l'année 2001 et que l'architecture globale de la librairie INET a changé.

La couche UDP est implémentée dans la librairie INET. Elle présente le niveau transport et elle est très utilisable dans la simulation car son implémentation est simple et elle est rapide par rapport aux autres couches de même niveau.

Dans la librairie INET, cette couche est une couche de transport comme UDP et RTP et elle est implémentée à l'aide des sockets.

Elle présente la couche supérieure. De nombreuses applications sont implémentées dans la librairie INET comme Ethernet, TCPApp, PingApp, UDPApp.

2. Le choix du simulateur adéquat:

2.1. Besoins généraux:

Pour pouvoir choisir le meilleur simulateur, il faut spécifier nos besoins. Nous devons disposer de:

Module ARP:

Ce module du noyau implémente le protocole de résolution d'adresse ARP. Il sert à la conversion entre les adresses matérielles de niveau 2 et les adresses du protocole IPv4 sur les réseaux connectés en direct. L'utilisateur n'a normalement pas d'interactions avec ce module sauf pour le configurer. En fait ce module fournit des services aux autres protocoles du noyau.

Le module ARP maintient un cache des correspondances entre les adresses matérielles et les adresses logiques. Le cache a une taille limitée, ainsi les entrées anciennes et utilisées moins fréquemment sont récupérées. Les entrées qui sont marquées comme permanentes ne sont jamais effacées.

Ce module permet de fournir l'adressage MAC et encapsuler les paquets en trames 802.11.

Il est composé de 3 modules simples qui sont Decider80211a, SnrEcal80211a et Mac80211a. Comme le montre la figure 3.4, ce module possède deux interfaces de sortie avec la couche IP et avec le canal.

Module de mobilité:

Ce module fournit un modèle de mobilité qui permet de faire déplacer les noeuds.

Simulateur	OMNeT++	NS-2
Flexibilité	OMNeT++ est un simulateur flexible et générique, il peut simuler n'importe quel type de réseau. Par exemple, il peut être utilisé pour simuler les files d'attente, les systèmes multiprocesseurs, les architectures de matérielles (routeurs, les commutateurs optiques, les serveurs etc.). Plusieurs modèlent sont utilisables pour les différents domaines (INET Fw, Mobility Fw, OverSim, NesCT, MACSimulator, etc.)	NS-2 a été conçu comme un (TCP/IP) simulateur de réseau, et il est difficile de simuler les choses autre que paquet-commutant les réseaux et les protocoles.
Mobilité	OMNeT++ fournit plusieurs modes de mobilités comme le Random Waypoint Mobility Model, le Linear Mobility Model, le Constant Speed Mobility Model, le Basic Mobility Model, etc.	NS-2 ne fournit que le Random Waypoint Mobility Model et le Trajectory Based Mobility Model, ce qui rend difficile de présenter une mobilité linéaire.
La gestion de modèle	Le OMNeT++ noyau de simulation est une bibliothèque de classe, c'est à dire, les modèles dans OMNET++ sont indépendants du noyau de simulation. Les chercheurs ont écrit leurs composants (les modules simples) contre noyau de simulation API du simulateur.	Dans les NS-2, la limite entre le coeur de la simulation et les modèles sont barbouillés d'encre, sans un clair API.
Support pour Les Modèles Hiérarchiques	La structure hiérarchique dans OMNET++ facilite la complexité des méthodes.	Dans NS-2, les modèles sont plats, la création d'un sous réseau ou l'exécution d'un protocole complexe (composition de plusieurs unités indépendantes) n'est pas possible.
Support de traçage	OMNeT++ peut montrer les transmissions de paquets pendant une simulation.	Pas de traçage.
Documentation	La documentation est très bonne et contient tous ce qu'on a besoin pour la simulation (définitions, méthodes, modules, implémentations, etc).	Bonne documentation.
Habileté à courir les grands réseaux	OMNeT++ peuvent simuler une grande topologie de réseaux.	Les NS-2 ont beaucoup de problèmes dans la simulation des grandes topologies de réseaux.

Après une comparaison approfondie entre les deux simulateurs, nous constatons que NS2 ne peut pas supporter plusieurs noeuds dans la simulation ce qui dessert nos besoins d'implémentation.
C'est pour cette raison que nous optons pour le simulateur OMNet++.

Dans ce chapitre, nous avons comparé entre différents simulateurs et nous avons choisi celui qui est le plus apte à nous satisfaire. Le chapitre suivant présentera une spécification de notre projet avec une analyse des besoins à l'aide de diagrammes de cas d'utilisation.

Greedy perimeter stateless routing sur omnet++

Introduction: