TP3 : Etude de files d'attente sous OMNeT++

Discrete Event Simulator - http://www.omnetpp.org/

H. Badis et L. George

Un rapport doit être rendu au plus tard 10 jours après le dernier TP à l’adresse e-mail suivante : badis@u-pem.fr. Le compte rendu doit contenir : un rapport pour chaque TP + les sources de chaque exercice. L’objet de l’e-mail doit respecter le format suivant : [TP-MDR][votre-formation].nom1-nom2.

I. Architecture client/serveur

La topologie à réaliser est la suivante (voir le répertoire dyna) :

Q1. Paramétrer le système pour converger vers un fonctionnement d’une file M/M/1/K

Q2. Comparer les résultats de la simulation à ceux obtenus par les formules théoriques vues en cours.

II. Le token Bucket

Il s’agit d’un mécanisme de policing utilisé pour réguler le trafic en entrée de leur réseau et garantir qu’un client n’émet pas plus de trafic en moyenne que ce que prévoit son contrat. Le principe est illustré sur la figure suivante :

Le fonctionnement est le suivant : Le token bucket correspond à une file d’attente FIFO dans laquelle des jetons sont placé régulièrement. On note Beta le taux d’arrivée des jetons. Le token bucket a d’autre part une capacité limitée : il ne peut contenir plus de K jetons. Lorsqu’un paquet IP arrive pour être transmis, il est marqué vert s’il reste des jetons dans le token bucket, et rouge sinon. Les paquets verts sont ensuite transmis de façon prioritaire, alors que les paquets rouges sont déclassés (priorité moins importante), soit directement jetés.

Pour simplifier, on suppose ici que les paquets IP arrivent suivant un processus de Poisson de paramètre Lambda. De la même façon, on supposera que les jetons arrivent suivant un processus de Poisson de taux β (Lambda != Beta).

Q3. Quelles Quel est le type et les paramètres de la file d’attente des jetons ?

Q4. Quelle est la probabilité qu’un paquet soit marqué vert ? et en déduit le débit Lambda_vert

Q5. Vérifier les résultats par simulation.