Stage-Nguyen Phan Quang

Définition du style : TM 2
Institut de la Francophonie pour l'Informatique
Mémoire de fin d’études du :

DIPLOME D’ETUDES PROFESSIONNELLES APPROFONDIES
par
NGUYEN Phan Quang
Gestion de l’Accès aux Réseaux MPLS-DiffServ par des Agents

Intelligents
Janvier, 2004
Gestion de l’accès aux réseaux MPLS-DiffServ par des agents intelligents 2
Remerciements
Je tiens à remercier Guy PUJOLLE et Dominique Gaïti de m’avoir accueilli dans leur
équipe durant mon stage de DEPA, et d’avoir encadré et animé ce stage avec
enthousiasme. Grâce à vos connaissances profondes et vastes j’ai été encouragé à
accomplir ce stage.
J’ai l’honneur d’adresser tous mes remerciements à Kim Loan THAI pour ses aides et
conseils dans la recherche et dans ma vie professionnelle durant mon stage.
Je remercie chaleureusement Hugues LECARPENTIER et Davor MALES de m’avoir
encadré durant mon stage.
J’exprime avec enthousiasme ma gratitude à Duc Minh NGUYEN et Huyen Trang VU
pour leurs aides dans la recherche et ma vie quotidienne.
Je remercie amicalement Duy LE, mon collègue pour ses travaux, sa coopération et ses
aides dans l’équipe et la vie quotidienne.
J’adresse mes remerciements à tous les membres du projet IANET pour leurs conseils et
leurs soutiens amicaux.
Je tiens aussi à remercier chaleureusement les professeurs de l’IFI pour leurs
renseignements qui ont été vraiment utiles durant mon stage.
En fin, un grand merci à ma famille, mes amis pour leur encouragement.
Résumé :
Certaines des applications d'Internet pourraient bénéficier des ressources du
réseau comme la bande passante. Une tendance réelle dans la gestion de réseau est
l’agrégation des flots du trafic. En outre, différents services exigent différentes ressources
pour garantir une meilleure qualité de service (QoS). Ces travaux proposent une
approche utilisant les systèmes multi-agents pour la gestion d'accès dans un réseau MPLS-
DiffServ. Une analyse de simulation est donnée pour 1) la modélisation d’un réseau
MPLS et 2) la gestion d'accès de réseau par les agents intelligents. L'intelligence des
agents est actionnée en fonction des comportements du QoS de trafic dans le réseau.
Mots clés : MPLS-DiffServ, Agent Intelligent, IP-QoS
Mis en forme : Anglais
(Royaume-Uni)
Abstract :
An increment of the Internet applications could benefit the network resources like
bandwidth. An actual trend in networking is aggregation of traffic streams. In addition,
with different services, it requires the different resources to guarantee the best quality of
service (QoS). In this paper, we propose an approach using agent-based systems for
access management in an MPLS-DiffServ network. A simulation analysis is provided for 1)
MPLS network modelling and 2) Network access management by intelligent agents. The
agent intelligence is operated by the behavior of the QoS of traffic in the network.
Keywords : MPLS, DiffServ, Intelligent Agent, IP-QoS
Table des matières
1 INTRODUCTION ................................................................................................................................... 8
1.1 LA GARANTIE DE LA QOS DANS LES RESEAUX IP ............................................................................... 8
1.2 L’INGENIERIE DU TRAFIC DANS LES RESEAUX MPLS ......................................................................... 9
1.2.1 L’ingénierie du trafic................................................................................................................. 9
1.2.2 MPLS et la TE ........................................................................................................................... 9
1.3 L’OBJECTIF DU PROJET ..................................................................................................................... 10
2 ETAT DE L’ART .................................................................................................................................. 12
2.1 L’AGENT INTELLIGENT DANS LES RESEAUX DE TELECOMMUNICATIONS .......................................... 12
2.2 LES RESEAUX MPLS-DIFFSERV ....................................................................................................... 13
2.3 L’ENVIRONNEMENT DE SIMULATION J-SIM ...................................................................................... 13
2.3.1 Introduction ............................................................................................................................. 13
2.3.2 Modélisation d’un réseau ........................................................................................................ 14
2.3.3 Modélisation du réseau MPLS dans J-Sim .............................................................................. 15
2.3.4 Les problématiques.................................................................................................................. 16
3 DEROULEMENT DU STAGE ............................................................................................................ 17
3.1 MODELISATION DU RESEAU MPLS-DIFFSERV ................................................................................. 17
3.1.1 Fonctionnement du réseau....................................................................................................... 17
3.1.2 La conception d’un nœud MPLS.............................................................................................. 18
3.1.3 La modélisation des sources de trafic...................................................................................... 19
3.2 MODELE DE L’AGENT ....................................................................................................................... 20
3.2.1 Introduction ............................................................................................................................. 20
3.2.2 Les critères à utiliser ............................................................................................................... 20
3.2.3 L’architecture de l’agent ......................................................................................................... 21
4 ANALYSE DES RESULTATS............................................................................................................. 23
4.1 LA TOPOLOGIE DU RESEAU ............................................................................................................... 23
4.2 METHODES D’EXPERIMENTATION ET D’EVALUATION ....................................................................... 24
4.2.1 Réseau sans agents intelligents ............................................................................................... 24
4.2.2 Réseau avec agents intelligents ............................................................................................... 24
4.2.3 Interprétation et remarques..................................................................................................... 26
5 CONCLUSION ...................................................................................................................................... 29
5.1 LES RESULTATS OBTENUS................................................................................................................. 29
5.2 AU FUTURE....................................................................................................................................... 29
6 RÉFÉRENCES ...................................................................................................................................... 30
7 ANNEXE ................................................................................................................................................ 32
7.1 LE PACKAGE INET DU SIMULATEUR J-SIM....................................................................................... 32
7.1.1 Le CSL et les services .............................................................................................................. 32
7.1.2 La décomposition du CSL........................................................................................................ 34
7.1.3 L’établissement d’un scénario de simulation d’un réseau....................................................... 36
7.2 LA CONFIGURATION ET LE MANUSCRIT DE SIMULATION DE RESEAU MPLS...................................... 37
7.2.1 La configuration du composant de FT..................................................................................... 37
7.2.2 L’établissement d’un nœud MPLS ........................................................................................... 38
7.3 GUIDE D'INSTALLATION DE LA SIMULATION DU RESEAU MPLS-DIFFSERV. ..................................... 38
7.3.1 L'Installation............................................................................................................................ 38
7.3.2 L'affichage des résultats .......................................................................................................... 39
7.3.3 Remarque................................................................................................................................. 39
7.3.4 Le fichiers de simulation ianet.tcl............................................................................................ 39

7.4 LES RESULTATS OBTENUS................................................................................................................. 46
7.4.1 La simulation du réseau sans agent......................................................................................... 46
7.4.2 La simulation du réseau avec agent intelligent ....................................................................... 47
Les acronymes
ACA Autonomous Component Architecture
AF Assured Forwarding
AS Autonomous System
ATM Asynchronous Transfer Mode
BA Behaviour Aggregated
BE Best Effort
bps bit per second
CAC Call Admission Control
CSL Core Service Layer
DiffServ Differentiated Service
DSCP DiffServ Code Point
EF Expedited Forwarding
FEC Forwarding Equivalence Class
FT Forwarding Table
FTP File Transfer Protocol
IP Internet Protocol
LDP Label Distribution Protocol
LSP Label Switched Path
LSR Label Switch Router
MPLS Multi-Protocol Label Switching
MTU Max Transfer Unit
PD Packet Dispatcher
PHB Per-Hop Behaviour
QoS Quality of Service
RSVP Reservation Protocol
RT Routing Table
SLA Service Level Agreement
SLS Service Level Specification
TE Traffic Engineering
TTL Time To Live
UPL Upper Protocol Layer
1 INTRODUCTION
Ce stage s’est déroulé dans l’équipe RESEAUX et PERFORMANCE du pole MSI
(Modélisation des Systèmes d’Informatique) du LIP6 (Laboratoire d’Informatique de Paris 6).
Aujourd’hui, les réseaux de télécommunications ont évolué vers une tendance à fournir les
divers services avec telle garantie de la qualité de service aux clients. Il est possible de transférer
des flots de données à différents niveaux de débit, de délai et de taux de perte de paquets. Dans
le but de fournir certaines garanties de la QoS adéquate aux trafics sur un AS IP, les clients
devront avoir des conventions SLA [7, 8, 26, 19] contractuelles avec des Fournisseurs des
Services d’Internet (Internet Service Provider, ISP). Les ISP voudraient satisfaire des demandes
du client qui sont décrites dans la part technique SLS [7, 8, 26] du SLA tandis qu’optimiser
l’utilisation des ressources du. La réalisation de ces deux objectifs n’est pas simple dans un
environnement de réseaux multi-services.
L’intégration de DiffServ et MPLS est une approche très efficace pour résoudre ce problème.
DiffServ fournit des mécanismes normalisés de QoS [6] tandis que MPLS fournit des techniques
de routage qui nous permettent d’optimiser l’utilisation de ressources et l’ingénierie du trafic [10].
Deux aspects intéressants de cette tendance seront abordés rapidement dans les deux sections
suivantes : la garantie de la QoS dans le monde IP et l’ingénierie du trafic (TE) dans les réseaux
MPLS.
1.1 La garantie de la QoS dans les réseaux IP

Un point majeur dans la gestion de la performance de réseaux est la QoS. Elle a été définie
dans la recommandation E.800 de l’ITU-T (International Telecommunications Union –
Telecommunication Standardization Sector) comme « un effet collectif des performances d’un
service qui détermine le degré de satisfaction d’un client du service ». Pour atteindre certaine
garantie de la QoS, des mécanismes du plan de contrôle et du plan de gestion sont utilisés [26].
Les mécanismes du plan de contrôle servent à réserver des ressources à la demande. Ceux du
plan de gestion fournissent la planification et la surveillance du réseau et la gestion des
demandes d’inscription des services dépendant des ressources valables.
Normalement, les réseaux IP n’offrent pas de qualité de service à l’origine. En effet, l’objectif
du monde IP est de partager de façon équitable l’ensemble des ressources du réseau [25].
Plusieurs solutions ont été proposées pour essayer d’introduire de la qualité de service dans les
réseaux IP.
La première solution est de surdimensionner le réseau de telle sorte que tous les paquets IP
voient le réseau comme étant fluide et puissent arriver dans un laps de temps court au récepteur.
La deuxième solution est de réserver des ressources du réseau pour des flots particuliers. Pour
cela, un protocole de signalisation RSVP a été proposé.
Associée à ce protocole, une autre solution a été proposée avec la technique IntServ
(Integrated Service). L’idée est d’introduire des classes de priorité aux trafics dans les réseaux
IP. Cependant, cette proposition bute contre le problème de passage à l’échelle du contrôle de
QoS. C’est pour quoi la technique DiffServ a été proposée.
Cette technique est considérée une technologie clé pour l’obtenir la garantie de QoS. Au lieu
de maintenir des tables indiquant les caractéristiques des flots à chaque routeur, les paquets sont
classifiés, marqués et policés au bord d’un domaine DiffServ. Les flots sont regroupés dans des
flots plus importants appelés des agrégats. Un ensemble fini des PHB différencie le traitement
des agrégats dans le noyau du réseau en fonction de la priorité d’ordonnancement (scheduling
priority), la capacité de transiter (forwarding capacity) et le tampon (buffering). Les trois types
principaux de PHB sont: EF [RFC2598], AFxy [RFC2597] et BE. Les SLS sont utilisés pour décrire
des paramètres appropriés de la QoS dont un routeur DiffServ devrait tenir compte. Le traitement
des micro flots aura lieu au bord du réseau DiffServ tandis que les routeurs internes ne travaillent
qu’avec des agrégats de flux selon le champ DSCP de l’entête de paquets IP. Cette approche a
pour avantage d’éviter le problème de passage à l’échelle du contrôle de QoS.
Le cadre de QoS tels que IntServ et DiffServ ont bien concentré à des mécanismes du plan
de contrôle pour fournir la QoS. Cependant, il ne semble que c’est possible à fournir la QoS sans
l’aide de la gestion du réseau et des services. Considérons le cas de DiffServ, il ne suggère que
les mécanismes nécessaires au traitement des paquets à chaque nœud. Il ne suggère aucune
architecture pour délivrer la QoS de bout en bout (end-to-end QoS). L’objectif d’offrir une garantie
de QoS quantitative de bout en bout sera réalisé grâce à l’augmentation des mécanismes de
DiffServ avec des fonctions de l’ingénierie du trafic intelligentes [26]. Dans la partie suivante,
nous allons présenter l’ingénierie du trafic dans les réseaux MPLS.
1.2 L’ingénierie du trafic dans les réseaux MPLS

Les réseaux MPLS sont de plus en plus utilisés dans le monde IP. MPLS utilise l’approche
d’intégration d’un cadre d’échanger des étiquettes (labels) avec le routage de la couche de
réseau. L’idée de base est d’assigner des étiquettes fixes et courtes à des paquets IP à l’entrée
d’un réseau MPLS (basé sur le concept de transfert en avant des classes équivalentes FEC).
Cette assignation n’est faite qu’une fois quand le paquet entre dans le réseau. Tous les paquets
qui appartiennent à un FEC particulier et qui partent d’un nœud particulier traverseront le même
chemin ou un des chemins associés à ce FEC (dans le cas de routage multi chemins) [13]. Les
paquets seront pilotés par les routeurs internes grâce à leur étiquette, aucune information
additionnelle n’est nécessaire. Ce type de réseau est vraiment adéquat à des applications de
multimédia comme la VoIP (Voix sur IP), VoD (Vidéo à la demande)…qui demandent de
transférer les paquets en ordre. Une des applications les plus significatives initiales de
l’implémentation de MPLS sera développée pour la TE [27].
1.2.1 L’ingénierie du trafic

En général, l’ingénierie du trafic (TE) est un processus pour spécifier la façon dont laquelle
des trafics sont traités dans un réseau donné. La TE concerne principalement l’optimisation de
performance des réseaux opérationnels. Elle renferme l’application des technologies et des
principes scientifiques de la mesure, de la modélisation, de la caractérisation, et du contrôle du
trafic d’Internet pour atteindre des objectifs de la performance spécifiques. Les deux aspects
d’intérêt de la TE dans les réseaux MPLS sont la mesure et le contrôle [27].
Des objectifs principaux de la performance associés à la TE devraient être classifiés en
deux types : l’orientation du trafic ou celle des ressources [27]. Les objectifs de la performance
orientés au trafic se comprennent des aspects qui améliorent la QoS des flux du trafic. Ils
pourraient être la minimisation de perte de paquets, de délai, la maximisation de débit…Ceux
orientés aux ressources concernent des aspects d’optimisation de l’utilisation de ressources,
parmi lesquelles la gestion de bande passante (bandwith) est un facteur essentiel. La
minimisation de congestions et l’équilibrage de la charge (load balancing) sont ainsi les buts
importants de la TE.
1.2.2 MPLS et la TE
MPLS est vraiment significatif pour la TE parce qu’il fournit potentiellement la plupart des
fonctionnalités valables du modèle « overlay » tel que IP sur ATM, IP sur le relais de trame(IP
over frame relay)…de façon intégrée et à coût bas par rapport aux autres. Il nous offre la
possibilité d’automatiser des fonctions de la TE [27].
MPLS, avec le concept de « traffic trunk » [RFC 2403], a quelques facteurs pour la TE [27]:
(i) les LSP explicites qui n’ont pas de contraintes du paradigme de transfert basé sur des
destinations pourraient être créés manuellement par des opérateurs du réseau ou
automatiquement par des protocoles, (ii) les LSP pourraient être maintenus efficacement, (iii) les
traffic trunks pourraient être instanciés (instantiated) et projetés (mapped) sur les LSP, (iv) un
ensemble des attributs pourrait être associés aux traffic trunks qui modulent leurs
caractéristiques comportementales, (v) un ensemble d’attributs pourrait être associés aux
ressources qui contraignent le placement des LSP et les traffic trunks traversant ces LSP…
Cependant, il y a des difficultés dans la réalisation de la TE sur MPLS. Citons les trois
problèmes fondamentaux de la TE sur MPLS. Premièrement, comment projetons-nous les
paquets sur les FEC? Deuxièmement, comment projetons-nous les FEC sur les traffic trunks?
Troisièmement, comment projetons-nous les traffic trunks sur la topologie physique d’un réseau
via les LSP? Plusieurs travaux ont été faits pour répondre ces questions. Ces travaux concernent
l’intégration de la technique DiffServ et l’infrastructure MPLS [26,31], le développement des
protocoles de routage et de distribution des étiquettes…
L’idée d’intégrer la technique DiffServ à un réseau MPLS montre un avantage. Il est possible
de spécifier les chemins à suivre et les comportements (PHB) des paquets dans les files d’attente
des routeurs. Pour cela, les FEC seront classifiés selon les classes de service de DiffServ (EF,
AFxy, BE). Il y a deux façons de projeter le DSCP de DiffServ sur les étiquettes de MPLS : E-LSP
(Exp-inferred LSP) et L-LSP (Label only inferred LSP) [28, 29]. Les étiquettes seront assignés et
distribuées aux routeurs grâce à un LDP.
Un des travaux intéressants dans l’assurance de la TE sur MPLS est la gestion dynamique
et automatique de l’accès à un réseau MPLS-DiffServ. Ce travail concerne l’affectation des flux
provenant de l’extérieur du réseau dans les divers LSPs d’un réseau MPLS-DiffServ en fonction
du SLS négocié par l’utilisateur, des caractéristiques de l’application et peut-être également du
profil d’utilisateur. Par exemple, s’il y a une application de téléphonie qui se présente, à quel LSP
affectera-t-on cette application pour que la garantie très forte soit réalisée?
Normalement, les flux sont routés statiquement par l’opérateur ou bien par un protocole de
routage et distribution des étiquettes. Avant d’affecter un flot dans un tuyau, il faut avoir une
procédure de l’appel du contrôle d’admission (Call Admission Control, CAC) [9] pour que la QoS
soit respectée. Dans le but d’introduire l’intelligence artificielle dans le domaine de la
télécommunication, nous proposons une approche d’utilisation de l’agent intelligent dans la
gestion de l’accès à un réseau MPLS-DiffServ.
1.3 L’objectif du projet

L'objectif du projet est de concevoir et de développer des techniques et des logiciels de
simulation des réseaux MPLS-DiffServ intégrant des agents intelligents. Dans ce cadre j’ai
travaillé avec un autre stagiaire qui a travaillé sur la modélisation et le développement d’un
réseau MPLS-DiffServ.
Ce stage concerne la réalisation d’un modèle d’agent générique pour le choix des LSP et la
mesure de son efficacité ainsi que ses inconvénients en terme de TE. Nous voudrons essayer
d’appliquer l’intelligence artificielle des agents à la réalisation de la TE dans un réseau MPLS-
DiffServ. Nous creusons l’aspect du choix des LSP en satisfaisant la QoS demandée et
l’équilibrage de la charge du réseau. Pour cela, on tente de répondre aux questions suivantes : (i)
Pourquoi et comment introduit-on l’agent intelligent à un réseau MPLS? (ii) Quels sont ses
avantages et inconvénients ? (iii) Comment affecte-t-on les flux de paquets à les divers LSP? (iv)
Quels sont les paramètres avec lesquels l’agent peut jouer? (v) Quelle est l’architecture des
agents? (vi)Comment évalue-t-on l’efficacité du modèle? Ces questions seront abordées dans le
reste du document.
Cette mémoire est organisée comme suit. La section 2 présente certaines applications des
agents intelligents dans le domaine de la télécommunication, la réalisation de réseaux MPLS-
DiffServ et l’environnement de simulation J-Sim. Notre approche de modélisation d’un réseau
MPLS-DiffServ et le modèle de la gestion d’accès au réseau par les agents intelligents seront
présentés dans la section 3. Nous décrivons les paramètres des simulations réalisées ainsi que
les résultats obtenus dans la section 4. La section 5 conclut cette mémoire et introduit nos
travaux futurs.
2 Etat de l’art
Dans cette partie, nous allons aborder l’utilisation des agents dans le domaine de la
télécommunication et un environnement particulier de simulation d’un réseau de
télécommunications.
2.1 L’agent intelligent dans les réseaux de Télécommunications

La complexité et la dynamicité des réseaux de télécommunications rendent leur gestion et
leur contrôle de plus en plus difficiles. L’utilisation des agents intelligents dans ce domaine réduit
l’intervention humaine et donne une bonne performance au réseau. L’agent pourrait reconnaître
une situation et fournir de meilleures solutions.
Gaïti [1] décrit un modèle d’agents pour la détection de la congestion, la gestion du trafic et
le changement dynamique des seuils des mécanismes du contrôle de congestions dans le
réseau ATM. Chaque agent travaille avec ses propres connaissances et est attaché à chaque
nœud du réseau. Ce dernier peut travailler isolément s’il est nécessaire. L’architecture de l’agent
est basée sur les principes de tableau noir «blackboard» avec trois composants : un module des
connaissances, un module de contrôle et celui de communication. Ce travail a contribué au
succès d’applicabilité de l’IAD (Intelligence Artificielle Distribuée) dans le domaine des
télécommunications.
Legge [2] propose de développer un système de la gestion de réseaux AMT par des agents
autonomes. Chaque nœud du réseau possède lui-même une société d’agents dans laquelle
chaque agent gère le contrôle d’une couche du modèle de référence ISO. Ce modèle fournit des
interfaces définies et niveaux d’abstraction permettant de développer des protocoles de
communication qui sont inter-opérables. Cependant, son travail reste encore à la réalisation de
trois couches basses: l’agent du contrôle de commutation (Switch Control Agent) pour la couche
physique, l’agent de découverture des voisins (Neighbour Discovery Agent) pour celle-ci de
liaison et l’agent du réseau (Network Agent) pour celle-ci de réseau. Il existe un agent particulier
appelant l’agent de la communication d’inter-société (Inter-Society Communication Agent, ISCA)
qui maintient une connexion au commutateur ATM et communique avec les autres agents.
Vilà[3] présente un système basé sur un système multi-agent pour la configuration
dynamique de ressources du réseau dans l’environnement utilisant des mécanismes de
réservation de bande passante et de restauration des routes. Ce système est capable de gérer
dynamiquement un réseau virtuel comme une route virtuelle dans le réseau ATM ou un LSP dans
le réseau MPLS. Il développe deux types d’agents : M-agents (agents réactifs) qui ont pour rôle
de gérer l’état d’une route virtuelle, détecter la congestion) et un P-agents (agents délibératifs)
présent à chaque nœud qui maximise la performance du réseau.
Une autre approche favorable est d’utiliser des agents mobiles pour le contrôle et le routage
dans le réseau. Vittori [33] présente un algorithme de routage intelligent, appelé Q-agents, qui
possède un ensemble des actions basées sur l’environnement d’agent d’interaction. Cet
algorithme combine les attributs de trois stratégies d’apprentissage : Q-apprentissage (Q-
learning), apprentissage duel de renfort (dual reinforcement learning) et apprentissage basé sur
les comportements de colonie des fourmis (ant colony behaviour). Il existe un ensemble d’agents
traversant dans le réseau de manière indépendante et concurrente, cherchent les meilleures
routes. Les agents partagent leur connaissance de la qualité des routes traversées par la
communication indirecte.
Dans [4,5], il parle d’une nouvelle approche de modélisation et de simulation de réseaux
actifs par un système multi-agents comportemental afin de gérer la dynamicité des réseaux. Les
agents, grâce à leurs principales propriétés (l’autonomie, la sociabilité, la communication, la
coopération, l’apprentissage…) sont utilisés pour modéliser et fonctionner dans l’environnement

des réseaux actifs. Ils effectuent un contrôle dynamique et intelligent afin d’éviter la congestion et
la perte des paquets. Chaque nœud qui est considéré comme une entité active est représenté
par un système multi-agents et possède certains comportements comme basique, sélectif,
prudent, fidèle, infidèle pour le traitement des paquets appartenant aux trois différentes classes
de qualité de service [25]. L’utilisation de comportements a pour but de représenter les actions de
chaque entité. Ce modèle a donné des résultats considérables en terme de la qualité de service
comme la minimisation de la perte de paquets, du temps de réponse…
Ces travaux ont prouvé l’efficacité des agents intelligents pour la gestion dynamique de
réseaux de télécommunications.
2.2 Les réseaux MPLS-DiffServ

Les concepts et l’architecture de routage d’un réseau MPLS-DiffServ ont été présentés dans
[28, 29]. Il y deux problèmes de base dans la réalisation des réseaux MPLS-DiffServ : le DSCP
est contenu dans l’en-tête des paquets IP tandis que les LSR n’examinent que les étiquettes des
trames (frame), le champ DSCP a 6 bits tandis que le champ EXP (experimental field) des
étiquettes a seulement 3 bits. Les deux solutions E-LSP et L-LSP ont été proposées pour
résoudre ces deux problèmes. La première utilise l’approche de projection des BA multiples sur
un même LSP. Dans ce cas, tous les paquets appartenant à ces BA auront une même étiquette.
Le champ EXP de l’en-tête MPLS est utilisé pour spécifier le PHB applicable à chaque paquet.
Ce PHB comprends les paramètres de la préférence de rejet et d’ordonnancement. La deuxième
projette un BA singulier sur un LSP, les DSCP sont encodés implicitement dans les étiquettes.
Par conséquent, le champ EXP devrait être utilisé pour le codage de la préférence de rejet des
paquets.
En ce qui concerne la réalisation de la TE dans un réseau MPLS-DiffServ, le projet
TEQUILA (Traffic Engineering for Quality of Service in the Internet at Large Scale) [26,31] a pour
objectif d’étudier, de spécifier, d’implémenter, et de valider un ensemble de définitions des
services et des outils de la TE pour obtenir la garantie de QoS quantitative de bout en bout via le
dimensionnement, le contrôle d’admission (admission control) [9], et la gestion dynamique des
ressources de réseaux DiffServ basés sur l’infrastructure MPLS. Actuellement, ces travaux ne
proposent que le développement d’un prototype du modèle DiffServ sur l’infrastructure MPLS.
2.3 L’environnement de Simulation J-Sim

Dans le cadre de ce stage, on utilise l’environnement de simulation J-Sim (Java Simulation)
pour créer et expérimenter des simulations d’un réseau MPLS-DiffServ.
2.3.1 Introduction
J-Sim est un package logiciel qui permet de réaliser des simulations de systèmes à temps
discret en Java. Il fournit un environnement de développement d'application basé sur
l'architecture des composants de base de logiciel appelant l'architecture des composants
autonomes (Autonomous Component Architecture, ACA). Tous les éléments sont considérés
comme des composants. Les composants communiquent et échangent des données via leurs
ports.
Fig 1. L’architecture des composants de base.
2.3.2 Modélisation d’un réseau

J-Sim développe un modèle de réseau abstrait qui s’appelle INET Network Model, toutes les
entités dans un réseau sont des composants, par exemple, un réseau, un nœud, une carte
d’interface de réseau, un lien physique… A partir des composants on peut établir un réseau de
télécommunications. Un réseau est un composant composé par des nœuds, des liens et des plus
petits réseaux. Un nœud est un composant lui-même qui comprends des applications, des
modules de protocoles et une couche de service du noyau (core service layer, CSL). La figure ci-
dessous présente le modèle de modélisation de réseau INET.
Fig 2. Le modèle de réseau INET
La figure suivante illustre la structure interne d’un nœud dans le modèle abstrait. Dans ce
modèle, au lieu de développer quatre couches dans le modèle TCP/IP ou sept couches dans le
modèle de référence OSI, il ne développe que deux couches. Une couche de protocoles en haut
UPL(Upper protocol layer) et celle de service du noyau CSL.
Fig 3. La structure interne d’un nœud de réseau.
La décomposition du CSL sera montrée en détails dans l’annexe concernant J-Sim.
2.3.3 Modélisation du réseau MPLS dans J-Sim

Le modèle MPLS fournit par J-Sim n’est pas flexible. En effet, on ne peut qu’associer une
interface et une étiquette de sortie (outgoing interface, outgoing label) avec ceux d’entrée
(incoming interface, incoming label). Ce n’est pas vraiment adapté si l’on veut supporter des
protocoles RSVP-TE et des chemins de commutation d’étiquettes dynamiques (dynamic Label
Switched Path). Ce pour quoi, au mois de mai 2003, le groupe Infonet de l’Université de Namur
(Infonet Group of the University of Namur) a proposé un nouveau modèle de simulation d’un
réseau MPLS. Il a rajouté deux composants : la table d’acheminement FT(Fowarding Table) et
composant de MPLS [Figure 4]. Le composant FT contient toutes les informations des étiquettes
configurées. Il associe un préfix IP ou une étiquette d’entrée avec une interface et une étiquette
de sortie. Concrètement, il relie un préfix IP ou une étiquette à une interface et une liste
d’opération. Cette liste comprends un opérateur (SWAP, PUSH ou POP) et une étiquette. Ces
opérateurs sont appliqués sur l’étiquette portée dans le paquet. Le rôle du composant MPLS est
d’acheminer des paquets selon la configuration de la FT. Il reçoit des paquets partant des autres
nœuds et décide où le paquet sera envoyé en fonction du paquet reçu et des informations dans
la FT. Si le paquet est un paquet IP, son préfix sera examiné pour trouver des opérations
adéquates. Dans le cas où le composant MPLS ne trouve pas une référence pour le paquet dans
la FT, le paquet sera rejeté. La configuration et le manuscrit de simulation détaillés seront
présentés dans l’annexe de MPLS.
Il semble que ce modèle reste encore limité. Premièrement, il n’y a pas de priorité entre les
paquets. Deuxièmement, il ne fournit que des LSP monotones, c’est à dire on ne peut créer des
LSP avec des débits, des priorités différents. De plus, il ne permet pas de choisir dynamiquement
une des routes reliées deux extrémités. Cela ne nous donne pas des possibilités de réalisation
d’ingénierie du trafic du réseau MPLS.
Fig 4. La décomposition du CSL dans le nouveau modèle de réseau MPLS.
2.3.4 Les problématiques

Dans le but d’étudier l’applicabilité des agents dans la gestion de l’accès d’un réseau MPLS-
DiffServ, on ne développe qu’un modèle de simulation de réseau simple. Le problème posé est
de développer une simulation de réseau MPLS-DiffServ avec des agents intelligents qui sont
capables de gérer l’accès des flux provenant de l’extérieur du réseau dans les divers LSP. Etant
donné un réseau MPLS-DiffServ avec une topologie fixe et un ensemble défini de LSP entre une
paire de nœuds divisés en trois niveaux de préférence. Pour une demande de transfert des
paquets d’un flot avec certains critères de QoS demandés provenant de l’extérieur du réseau,
quel LSP les paquets devront traverser pour garantir ces critères? Pour répondre à cette
question, on devra développer un modèle d’agents intelligents capables d’affecter les flots dans
les divers LSP du réseau en prenant en compte des paramètres du SLS et le trafic du réseau
ainsi que la réalisation de la TE.
Les hypothèses utilisées :
+ Un réseau MPLS-DiffServ fonctionne et sa topologie est bien simulée.
+ Les LSP sont bien créés et distribués sur ce réseau.
+ On ne s’intéresse qu’à des LSP entre une paire de nœuds car les autres LSP pourraient
être traités de manière similaire.
+ Les flots sont classifiés en trois types de priorités EF, AF, BE.
+ Toutes les connaissances du réseau sont fournies instantanément dans la base
d’information de l’agent (on ne tient compte pas du délai de propagation) [1].
+ Les critères (le délai, la gigue, la perte…) sont mesurés en terme des valeurs totales des
agrégats de paquets de bout en bout.
La section suivant mentionnera le déroulement du stage. Elle présentera la modélisation
d’un réseau MPLS/DiffServ et le modèle agent utilisé.
3 Déroulement du stage
3.1 Modélisation du réseau MPLS-DiffServ

Le simulateur J-sim ne modélise que très mal les réseaux MPLS, plusieurs améliorations
sont nécessaires. Tout d’abord J-Sim ne faisant aucune distinction entre les LSP d’une paire de
LSR, il faut introduire la notion de priorité entre les LSP. Pour cela, on rajoute une file de priorité
à chaque interface de réseau (Network Interface). Le modèle d’un nœud d’entrée du réseau
MPLS proposé et des sources sont illustrés dans la figure 5.
Fig 5. Modèle de modélisation du CSL et des sources du réseau MPLS proposé.
3.1.1 Fonctionnement du réseau

a) Les Sources
Dans ce modèle, les sources créent et n’envoient que des paquets IP au module MPLS d’un
nœud d’entrée du réseau. La description détaillée des sources sera mentionnée dans la section
suivante.
b) Le module MPLS
Ce module traite les paquets qui traversent le réseau MPLS. S’il est un nœud d’entrée, il va
encapsuler (encapsulate) des paquets IP une étiquette (label) nommé LSPacket et l’envoyer à un
des ses voisins. S’il est un nœud de sortie, il va décapsuler (decapsulate) cette étiquette. Comme
dans le fonctionnement d’un réseau MPLS, tous les paquets appartenant à un flot devront suivre
un même LSP, un flot ne sera affecté qu’une fois dans un LSP. Ce module travaille avec deux
type de paquets : les paquets IP et les paquets MPLS (LSPacket).
Quand un paquet IP arrive au module MPLS d’un nœud d’entrée, ce module testera, en
fonction de l’identité du flot, si ce paquet appartient à un nouveau flot (nouvelle connexion) ou à
un autre existant. Dans le premier cas, le module MPLS demandera au module Agent de trouver
une référence (étiquette) pour ce paquet. Grâce à cette référence, le module MPLS recherchera
le LSP correspondant dans le FT. Dans le deuxième cas, le module MPLS retrouvera le LSP du
flot auquel ce paquet appartient dans sa mémoire historique.
Quand un paquet LSPacket arrive, ce module fonctionnera comme le module MPLS de J-
Sim. Il fera une commutation et enverra ce paquet à un autre nœud ou le décapsuler et enverra
ce paquet à la couche réseau.
Une autre fonction du module MPLS est d’envoyer périodiquement des informations sur
l’état du nœud à l’agent. Il y est compris [1] des valeurs instantanées du délai, de la perte de
paquets, de l’occupation de la file d’attente et de la gigue …selon les types de priorité à chaque
carte de réseau.
c) Le module Agent
Ce module est responsable de l’affectation des flux provenant de l’extérieur du réseau dans
les divers LSP en fonction de la QoS demandée. Il sera présenté en détails dans la section de
modèle d’agent
d) Le module File d’attente.
Chaque source de trafic est assignée à un type de service correspondant au SLS entre
l’utilisateur et l’opérateur comme décrit dans la figure 6. Dans le premier exemple qui sera traité,
on introduira trois types de priorité correspondants grossièrement à EF, AF et BE.
Fig 6. La structure interne du module de file d’attente Priority Queue
Les paquets partant du module MPLS seront mis dans les trois sous-files d’attente
correspondantes à trois niveau de priorité : Haute, moyenne, basse. L’algorithme de contrôle de
ces files d’attente peut être RED (Random Early Detection), WFQ (Weighted Fair Queueing) ou
CBQ (Class Based Queueing) [25]...
Dans cette expérimentation [30], tout simplement, les types de priorité sont indiqués dans
les paquets par les sources. Le mécanisme de tour de rôle (Round Robin) est utilisé pour gérer
ces files d’attente. Cette hypothèse montre que les paquets sont servis selon leur préférence
d’ordonnancement et transférés à des débits différents. Dans le cas où la file d’attente d’une
carte de réseau est pleine, les prochains paquets arrivant à cette file seront rejetés.
3.1.2 La conception d’un nœud MPLS

a) L’architecture globale d’un nœud d’accès
Fig 7. L’architecture globale d’un nœud d’accès.
On rajoute les trois modules Agent, Queue et Source au modèle MPLS de base de J-Sim.
b) Le diagramme de composants
Fig 8. Le diagramme de composants d’un nœud d’accès.
c) Le diagramme de classes
Fig 9. Le diagramme de classes détaillé des trois composants MPLS, Agent et Database.
3.1.3 La modélisation des sources de trafic

Dans [30], on suppose que les trafics arrivant dans le domaine MPLS sont de quatre types
principaux: vidéo à la demande, téléphonie sur IP, transfert de ficher et web. Pour le type vidéo à
la demande, nous utilisons un fichier trace pour modéliser la source de trafic Mpeg4. Comme
dans les approches de [16] et [17], nous utilisons deux paramètres: le temps d'intervalle et la
taille de trame. On peut créer le trafic avec différentes qualités (haute, moyenne, mauvaise) par
l'extraction du fichier Mpeg. De plus, ce type de trafic oblige à garantir un temps de latence
maximum de 5ms. Dans [18] et [19] le modèle OnOff est utilisé pour modéliser le trafic de
téléphonie. Pour ce flot, il faut garantir un temps de réponse maximal de 100 ms, un taux de
perte maximal de 1% et une variance de 20 ms. Pour le modèle de source FTP, [20], [21] ont
montré l'accord de l'utilisation de la distribution de Poisson pour créer le trafic de l'Internet,
surtout le FTP. Ce type de transfert de fichier ne demande pas de temps de réponse mais il ne
faut pas perdre de paquets. Pour la source de trafic Web, on utilise l'association entre la
distribution de Pareto et la modèle OnOff. Le temps maximal de traversée du réseau est de 10s
et le taux de perte maximum est de 2%.
3.2 Modèle de l’agent

3.2.1 Introduction
Dans notre modèle, l’agent intelligent est situé dans le nœud d’accès du réseau MPLS-
DiffServ. Il cherche une des routes les plus satisfaisantes pour un flot provenant de l’extérieur du
réseau. Le choix d’un chemin pour une connexion est basé sur certaines informations : les
caractéristiques de la source (le débit, le type d’application, la qualité de service demandée…), le
type de priorité demandée et l’états des chemins (l’états des nœuds traversés par un LSP). S’il
n’y a aucune route satisfaisant les contraintes de QoS demandées, alors la connexion sera
refusée.
Il y a essentiellement deux types de trafic [6, 9]: le trafic sensible au délai et le trafic sensible
à la perte. Les trafics sensibles au délai sont caractérisés par leur débit et leur délai. Par
exemple, dans [10], les auteurs présentent l’utilisation de classe de service EF dans
l’environnement intégré de MPLS et DiffServ pour transférer la parole téléphonique. Les trafics
sensibles à la perte sont caractérisés par la masse d’informations transférées (les pages web, les
fichiers,…).
Les flots du trafic sensible au délai seront affectés dans les LSPs de la classe EF du réseau
DiffServ. Ceux sensibles à la perte seront affectés dans les LSP de la classe AF. Les autres
seront considérés comme des flots BE. Nous avons fait le choix au départ que les flots seraient
mis dans un des trois types de priorité (EF, AF et BE).
3.2.2 Les critères à utiliser

Les flots qui ont une forte contrainte temporelle seront mis dans des LSPs EF. Par exemple,
la demande du temps maximal de transfert d’un paquet de type parole dans le réseau est de
100ms et une variance de 20ms. Notons que le temps d’attente moyen (le délai) et sa variance
(la gigue) [6,11] dans le nœud i de type EF traversées par les paquets qui suivent un LSPj sont
respectivement t i, gi. Il faut donc que la somme T = ∑i t i (1) de tous les nœuds appartenant
au LSPj reste inférieure à 100ms et la variance totale G = ∑ig i (2) inférieure à 20ms.
Pour obtenir le temps d’attente instantané d’un paquet tai dans une file d’attente i d’un nœud,
on le mesure directement dans la simulation. Le temps de service d’un paquet du nœud i sera
calculé : tsi=sp/µi*λk (3) où sp, µi et λk sont respectivement la taille du paquet (bits), le débit du
serveur (bps), et le taux de performance du serveur pour chaque type de priorité(EF, AF, BE). La
formule 4 illustre le calcul de délai instantané d’un paquet tij = tai +tsi (4) [11].
Pour calculer le temps d’attente moyen et la gigue des paquets traversant le LSPj, nous
utilisons l’hypothèse qu’on ne s’intéresse qu’à n valeurs les plus récentes. Après une période de
p(ms), on calcule la valeur moyenne de ti,
n Code de champ modifié
∑t
j=1
ij
ti = (5), et son écart-type (la gigue):

n
n Code de champ modifié
∑ (t
j=1
ij - ti )
gi = (6), j = 1,…n.
n
Les flots qui ont une contrainte sur le taux de perte seront mis dans les tuyaux AF. Nous
tenons compte du taux de perte dans chaque nœud traversé par un LSP AF. De même façon
que cela a été fait pour le temps d’attente et sa variance, on peut calculer le taux de perte et sa
variance P = ∑i p i (7) et PV = ∑i pv i (8). Il faut que la somme SP,
SP = P + PV (9), soit inférieure à 10-3.

Les flots sans contrainte (ni temps ni perte) sont mis par défaut dans les tuyaux BE.
Après avoir calculé tous les paramètres concernés, grâce à les caractéristiques des types
de trafic, on obtient un ensemble de règles à appliquer :
i) Un flot qui demande une forte contrainte temporelle sera affecté à un LSP EF si la
condition du temps de réponse (1) et de la variance (2) sont satisfaites, et la perte
moyenne soit inférieur à 1%.
ii) Un flot qui demande une contrainte sur le taux de perte sera affecté à un LSP AF si la
condition de la probabilité de perte de paquets (9) est satisfaite, et le délai moyen soit
inférieur à 2s.
iii) Les flots sans contrainte (ni temps ni perte) sont mis par défaut dans les tuyaux BE.
La table suivante illustre les paramètres et variables utilisés dans ce modèle.
Paramètre Description
EF_CON_TIME La condition de temps de réponse de type EF(ms)
EF_CON_JITTER La condition de la variance du temps de réponse de type EF(ms)
EF_CON_LOSS La condition de taux de perte de type EF(%)
AF_CON_LOSS La condition de taux de perte de type AF(%)
AF_CON_TIME La condition de temps de réponse de type AF(ms)
UPDATE_TIME Le temps de mis à jour la base de connaissances de l’agent.
STATE_NUMBER Le nombre des états historiques des nœuds dans la base de
connaissances
Table 1. Les paramètres et les variables utilisés
3.2.3 L’architecture de l’agent

Dans [1], les auteurs ont proposé une architecture d’agent pour le contrôle de la gestion et
du trafic des réseaux ATM. Cette architecture a montré son avantage dans la gestion du trafic
des réseaux ATM. L’agent pourrait prendre des décisions locales instantanément quand il a
assez de connaissances. Quand le réseau ne serait pas trop chargé, il serait possible d’échanger
des informations pour mettre à jour et améliorer des connaissances de l’agent.
En outre, ce type de réseau est semblable aux réseaux MPLS, ils tous appliquent la
technique de commutation des trames. Donc, nous avons appliqué ce modèle de l’agent dans
notre travail. Pour cela, nous développons actuellement un agent de gestion à deux couches : la
couche réactive et la couche cognitive. La couche réactive ne contient que les règles
mentionnées dans la section ci-dessus, avec une demande de choix de route pour une
connexion, elle accepte la connexion s’il existe une route qui nous permet d’assurer des
contraintes de QoS selon le type de priorité du flot (EF, AF, BE) ou bien la refuse dans le cas
contraire.
La couche cognitive sert à la surveillance des états du réseau. Elle acquiert des informations
(les états actuels) des nœuds appartenant aux LSP associés au nœud d’accès et les classifie.
Ces informations lui donnent une vue globale de la situation des toutes les routes associées et la
charge du réseau. Une base de connaissances de l ‘agent est nécessaire pour qu’il puisse retenir
des informations et avoir la capacité de perception de la situation du réseau. Elle fournit des
informations statistiques à la couche réactive.
La section suivante présente la simulation réalisée et les résultats obtenus.
4 Analyse des résultats

Dans cette section, on va aborder à la topologie du réseau réalisé, la méthode
d’expérimentation et les résultats obtenus.
4.1 La topologie du réseau

Dans la simulation, on développe une topologie simple. Il y a quatre routeurs de bord (0-3),
des nœuds de source et de destination (4-7) (figure 10).
Fig 10. Topologie du réseau MPLS-DiffServ
Dans le but d’évaluer les trafics du nœud 0 au nœud 2, on attribue aux routeurs 0-3 les
capacités respectivement: 35Mbps, 7Mbps, 7Mbps, 35Mbps. Toutes les files d’attente des
nœuds ont une capacité de 2097152 (bits). Il y a 6 LSP divisés en 3 niveaux de préférence entre
le nœud N0 et le nœud N2. Les taux servis λ du serveur pour les trois niveaux de préférence EF,
AF, BE sont respectivement 100%, 50% et 20%.
Les LSP dans le réseau sont indiqués dans la table suivante.
LSP Les nœuds traversés L’étiquette initiale ToS
1 012 1 EF
2 012 2 AF
3 012 3 BE
4 032 55 EF
5 032 40 AF
6 032 15 BE
7 123 4 EF
8 123 5 AF
9 123 6 BE
10 230 7 EF
11 230 8 AF
12 230 9 BE
13 301 10 EF
14 301 11 AF
15 301 12 BE
Table 2. Les LSP dans le réseau.
4.2 Méthodes d’expérimentation et d’évaluation

Les flux sont créés et traversent le réseau selon trois types de priorité. On ne s’intéresse
qu’à des flots entre une paire de LSR : Nœud 0 et nœud 2. Le réseau comprend les 6 premiers
LSP indiqués dans la table 2. Pour obtenir les résultats plus objectifs, il faut rendre chargé au
réseau en rajoutant des LSP et des trafics entre des autres nœuds. Ces trafics pourraient
commencer ou terminer en cours de simulation.
La table suivante indique les caractéristiques des sources des flots traversés dans les LSP
entre le nœud 0 et le nœud 2.
Caractéristiques
Type des sources
MTU(bit) Débit (bps) TTL(s)
On-Off 16, 56, 64 131072 128
Poisson 56, 128 221184 128
Pareto 56, 128 122880 128
Trace 128 non fixé 128
Table 3. Les caractéristiques des sources reliées au nœud 0.
Des simulations ont étaient réalisées dans deux cas, sans et avec agent. Dans chaque cas,
on va mesurer les paramètres de QoS moyens des paquets dans chaque LSP. Il comprend le
temps de réponse, le taux de perte, la gigue. Dans le cas avec l’agent, on mesure ces
paramètres avec les deux aspects de l’état du réseau : stable et dynamique. Le premier signifie
l’affectation de l’agent (des moments de lancement des trafics partant du nœud 0) aura lieu après
tous les trafics supplémentaires (les trafics partant des autres noeuds) ont été lancés. Le
deuxième signifie le mélange des moments de lancement des trafics.
4.2.1 Réseau sans agents intelligents

Les sources de trafic sont lancées à différents moments. Le temps de simulation est de 20s.
Les flots sont affectés en fonction de leur priorité (EF, AF, BE) et de leur adresse de destination
aux premiers chemins présents dans le tableau d’acheminement. Dans ce cas, aucune
information sur l’état du réseau n’a été utilisée et tous les flots ont été servis. La table suivante
présente les valeurs au maximum des paramètres de QoS du réseau dans ce cas.
Chemin Priorité Le nœuds Le délai (s) La gigue (s) La perte (%) Le débit
traversés (bps)
LSP1 EF 0-->1-->2 4.46E–3 4.35E–4 20.00 9114346
LSP2 AF 0-->1-->2 0.25 0.04 19.00 4711253
LSP3 BE 0-->1-->2 11.68 1.44 19.00 4258133
LSP4 EF 0-->3-->2 9.31E–4 7.85E-4 0.00 3249493
LSP5 AF 0-->3-->2 1.86E–3 1.55E–4 0.00 4839786
LSP6 BE 0-->3-->2 0.02 3.30E–3 0.00 1133653
Total 58.00 27306664
Table 4. Les valeurs de QoS maximales
4.2.2 Réseau avec agents intelligents

Dans cette simulation, à chaque période de UPDATE_TIME (ms), les routeurs internes
appartenant aux tuyaux traversant le nœud d’accès envoient leurs états actuels. Ces
informations comprennent des valeurs du débit, du délai instantané, le taux de perte instantané
selon chaque type de priorité. À partir de ces valeurs, la couche cognitive calculera tous les
paramètres dont la couche réactive a besoin. La couche active affecte de nouveaux flux
provenant de l’extérieur du réseau en vérifiant des conditions de QoS pour chaque type de flot
indiqué dans le paquet. Les flux de type BE seront affectés de manière aléatoire dans les LSP
BE. La table suivante indique les valeurs des paramètres et des variables utilisées :
Paramètre Valeur
EF_CON_TIME 70ms
EF_CON_JITTER 15ms
EF_CON_LOSS 1.7%
AF_CON_LOSS 0.01%
AF_CON_TIME 1.7s
UPDATE_TIME 0.1s
STATE_NUMBER 15
Table 5. Les valeurs des variables utilisées
a) Etat stable du réseau

Dans ce cas, les flux partant du nœud 0 sont lancés après tous les autres trafics du réseau.
La table suivante présente les valeurs au maximum des paramètres de QoS du réseau dans
ce cas.
traversés (bps)
LSP1 EF 0-->1-->2 4.20E–3 4.30E–4 0.00 3620053
LSP2 AF 0-->1-->2 0.01 1.30E–3 0.00 6557226
LSP3 BE 0-->1-->2 10.50 0.65 0.00 3085333
LSP4 EF 0-->3-->2 3.50E–3 3.60E–4 0.00 9825173
LSP5 AF 0-->3-->2 5.25E–4 4.29E–4 0.00 2187200
LSP6 BE 0-->3-->2 0.68 0.05 0.00 2622400
Total 0.00 27897385
Table 6. Les valeurs de QoS maximales dans le cas stable
b) Etat dynamique du réseau.

Dans ce cas, les flux partant du nœud 0 sont lancés indépendamment des autres trafics du
réseau.
La table suivante présente les valeurs au maximum des paramètres de QoS du réseau dans
ce cas.
traversés (bps)
LSP1 EF 0-->1-->2 1.90E–3 2.20E–4 1.00 3278933
LSP2 AF 0-->1-->2 0.41 0.07 4.00 7427413
LSP3 BE 0-->1-->2 9.85 1.57 9.00 3452906
LSP4 EF 0-->3-->2 1.51E–4 2.50E–5 0.00 8850026
LSP5 AF 0-->3-->2 1.73E–4 1.24E–5 0.00 2552746
LSP6 BE 0-->3-->2 1.36E–5 1.44E–6 0.00 296853
Total 14.00 25858877
Table 7. Les valeurs de QoS maximales dans le cas dynamique
c) Les résultats obtenus pour les différents valeurs du temps de mis à jour.
Dans ce cas, la simulation du réseau a été réalisée avec le changement du temps de mise à
jour la base de connaissances de l’agent. Les nœuds internes envoient périodiquement leur état
actuel après une période de p (s). La table suivant montre les valeurs maximales des paramètres
de QoS des flots traversant dans le réseau.
Chemin Période (s) Le délai (s) La gigue (s) La perte (%) Le débit (bps)
LSP1 0.10 2.79E-3 3.21E-4 0.00 2929600
0.25 1.71E-3 5.15E-5 1.00 2940800
0.50 3.14E-3 2.78E-4 2.00 2950720
0.10 6.56E-3 9.74E-4 0.00 6567786

LSP2 0.25 4.31E-3 7.04E-4 5.00 6979200
0.50 6.68E-3 7.51E-4 8.00 6256106
0.10 10.02 0.62 0.00 2741866

LSP3 0.25 10.27 0.60 5.00 3117120
0.50 9.93 0.56 10.00 4085120
0.10 1.60E-2 2.64E-3 0.00 9505706

LSP4 0.25 2.22E-2 2.68E-3 0.00 9195946
0.50 1.88E-2 2.70E-3 0.00 9434666
0.10 9.71E-4 8.52E-3 0.00 2486933

LSP5 0.25 7.85E-4 6.15E-5 0.00 2379200
0.50 3.981E-4 6.08E-5 0.00 2197653
0.10 11.43 0.73 0.00 1674560

LSP6 0.25 9.80 0.69 0.00 1129706
0.50 9.16 0.66 0.00 1142933
Table 8. Le délai, la gigue, la perte et le débit avec des périodes de mis à jour différentes.
4.2.3 Interprétation et remarques

Les résultats ci-dessus montrent l’avantage et les limitations de l’utilisation des agents
intelligents dans la gestion du trafic d’un réseau MPLS-DiffServ.
Dans le premier cas sans agent, les flux sont routés statiquement à l’avance, les étiquettes
sont distribuées en fonction de l’adresse de la destination et la préférence du type d’application.
On voit que la QoS des flux traversant dans les trois premiers LSP : LSP1, LSP2, LSP3 n’est pas
respectée tandis que celle dans les trois derniers est satisfaite. Cela est à l’origine, d’une part, du
problème de l’équilibrage de la charge du réseau, l’affectation des flux avait lieu de manière
déséquilibrée dans les tuyaux entre le nœud 0 et le nœud 2, la majorité des flots traverse dans
les trois premiers LSP. D’autre part, il n’y a pas de CAC dans cette affectation, tous les flots
étaient servis, donc la garantie de la QoS des flots n’a pas retenue. Ces deux raisons causent la
congestion dans les nœuds traversés par les flux.
Dans le deuxième cas que l’état du réseau est stable, pour les mêmes ressources, la QoS
pourrait être garantie. Les résultats obtenus montrent l’avantage de l’agent dans la gestion
de l’accès au réseau. La QoS était vérifiée avant d’affecter un flot dans un LSP, cela avait été
réalisé grâce à l’observation certains états historiques des nœuds tout au long d’un LSP dans
lequel un nouveau flot aura traversé. Le débit, le délai et la perte sont meilleurs que le cas ci-
dessus. La condition de délai des flots EF est toujours satisfaite car le temps de service des
nœuds sont fortement courts (6.5Mbps) tandis que la capacité des files d’attente ne sont pas
32
grande (2097152 bits). S’il on augmente la capacité de file d’attente à 4294967295 (2 -1) bits et
diminue le débit des nœuds à 1.5Mbps, la perte n’apparaîtra jamais mais le délai augmentera,
l’agent refusera des demandes de connexions prochaines.
En effet, le réseau est toujours dynamique, les flots arrivent ou partent du réseau librement
et indépendamment les uns par rapport aux autres. Dans le cas où l’affectation de l’agent est
réalisée en même temps que les autres sources, la QoS des flots n’est pas bien respectée, la
perte de paquets augmentent. Cela est l’origine du partage des ressources d’un ensemble des
nœuds des LSP traversés par un même « traffic trunk ». La base de connaissances de l’agent ne
contient que des informations sur l’historique du réseau, la QoS vérifiée avant de mettre un
nouveau flot dans un tuyau n’est pas toujours valable dans ce cas. Cela est arrivé s’il y a un LSP
dans lequel on ne pourrait affecter qu’un flot de plus pour que la garantie de la QoS soit réalisée.
Ce problème devrait être résolu par la coopération entre les agents à des nœuds aux bords du
réseau.
Cependant, à cause de la modélisation de la file d’attente, il y a toujours des influences des
paquets BE sur la QoS (la perte) des autres types. Les pertes de paquets de deux niveaux de
préférence les plus hauts sont possiblement supérieures à celle de type BE. Cela pourrait être
expliqué par l’utilisation du mécanisme de contrôle de la file d’attente des nœuds. Ce mécanisme
utilise le mode de rejet immédiat des paquets. Si un nœud n’arrive pas à mettre un paquet de
plus dans sa file d’attente (car cette dernière est pleine), il rejettera ce paquet et les paquets
suivants ne retenant pas leurs priorité. De plus, les paquets qui ont la priorité plus haute sont
toujours servis avant ceux de basses priorités. Il y a donc des paquets de type BE qui occupent
des places dans une file d’attente jusqu’à leur départ. Par conséquent, ces paquets devraient
être rester trop long dans le file car il y a toujours des paquets de haute priorité dans la file. Cela
est montré par le délai des paquets BE dans la table de résultats obtenus. C’est la raison pour
laquelle de nouveaux paquets (même de haute priorité) pourraient être perdus.
En étudiant des simulations réalisées avec des valeurs différentes des paramètres, on a
trouvé quelques remarques significatives.
i) Si l’état du réseau change trop vite par rapport au temps de mise à jour, l’efficacité de
l ‘agent sera diminuée. Ceci est causé par la manque d’information au moment de prendre des
décisions ainsi des caractéristiques du réseau MPLS (tous les paquets appartenant à un flot
devraient être transféré dans un même chemin). Par contre, si la période de mise à jour est
courte, elle rendra lourd au réseau car le temps de calcul et l’utilisation de ressources pour
envoyer des paquets de contrôle augmentent.
ii) Le nombre d’états historiques contenus dans la base de données de l’agent est aussi un
critère à jouer. S’il est trop petit, l’agent ne pourrait pas observer la situation globale du réseau, il
ne connaît près que des informations instantanées du réseau. Dans ce cas, l’agent tiendra
compte de la situation (la congestion, le délai…) provisoires [32]. Au contraire, si ce nombre est
grand, l’adaptabilité de l’agent à la situation sera basse.
iii) Les seuils des conditions dans les règles de l‘agent sont toujours les facteurs importants.
Ces paramètres sont sensibles à la garantie de la QoS du choix des LSP et l’optimisation de
l’utilisation des ressources du réseau. Cependant, ces seuils ne devraient pas être fixes pour
adapter à la situation du réseau. Dans ce stage, on ne traite pas encore cette manière.
iv) Il faut avoir une coopération des agents qui traitent des LSP partageant un ou des
ressources communes (les mêmes routeurs) du réseau dans leurs choix.
v) On pourrait faire une coordination des techniques de la gestion des files d’attente RED [9,
32], WFQ [9] et l’affectation des flots dans un LSP pour que la garantie de la QoS dans ce LSP
soit satisfaite. L’agent ne traite qu’une fois au départ le choix du LSP pour un flot donné tandis
que le RED travaillera tout au long de la transmission des paquets de ce flot. Le RED pourrait
signaler à l’agent les nœuds qui sont embouteillés. Cela résout aussi le problème de renvoyer
des paquets perdus du protocole TCP dans le cas le délai des paquets est supérieur au
« timeout » du TCP car le mécanisme de tour de rôle (Round Robin) pourrait causer l’attente trop
long temps dans la file pour les paquets de basses priorités.
vi) L’agent intelligent pourrait prendre en compte des autres informations du réseau (débits
des flots traversant dans les LSP, la durée de transmission des flots de type VoD…) dans son
choix des LSP.
vii) Comme les paquets téléphoniques devraient être rejetés de manière non pas
consécutive, on pourrait améliorer le mécanisme de gestion des files d’attente pour que ces
dernières puissent rejeter des paquets de la téléphonie dans le cas embouteillé.
On pourrait développer un autre système des agents qui sont capables de reconnaître la
situation du réseau et de régler des paramètres de mis à jour, des seuils de conditions ainsi le
nombre d’états historiques à chaque nœud.
5 Conclusion
Un modèle de gestion d’accès au réseau MPLS-DiffServ par les agents intelligents a été
présenté dans ce papier. En utilisant certaines règles de gestion d’accès à un réseau MPLS-
DiffServ, les résultats obtenus montrent que des agents pourraient être utilisés pour améliorer la
performance du réseau en optimisant le nombre de flux qui arrivent en fonction de leur QoS. Au
cours de réaliser ce stage, on a obtenu quelques résultats importants.
5.1 Les résultats obtenus

Une réalisation d’un réseau MPLS-DiffServ avec agent intelligent a été faites. L’affectation
des flux provenant de l’extérieur dans les divers LSP d’un réseau MPLS-DiffServ a été réalisée
par l’agent intelligent en fonction de la QoS demandée et la situation actuelle du réseau.
L’avantage de ce modèle est l’applicabilité de l’intelligence artificielle à gérer dynamiquement et
automatiquement l’accès du réseau MPLS-DiffServ. Plusieurs expérimentations ont été faites par
le simulateur J-Sim de plate-forme java.
Les résultats obtenus (section 4) ont montré que l’introduction de l’agent dans la gestion de
l’accès d’un réseau MPLS-DiffServ pourrait améliorer significativement l’ingénierie du trafic (la
garantie de la QoS et l’utilisation de ressources du réseau). L’ingénierie du trafic a été réalisée
par l’affectation automatique et dynamique des flux dans des LSP les plus adéquats et la
résolution du problème de l’équilibrage de la charge du réseau. L’agent intelligent est capable
d’accepter, affecter des flots dans des LSP et refuser une demande de connecter au réseau en
vérifiant au départ l’assurance de la garantie de la QoS demandée.
Cependant, il y a des limitations dans la modélisation et la réalisation de ce modèle. La
modélisation des files d’attente qui servent tous les paquets en même vitesse causera le
gaspillage de ressources, la congestion aux nœuds suivant dans un LSP (car les paquets, même
les paquets BE entreront à la file d’attente de ce nœud avec le même débit que ceux EF). Le
mécanisme de gestion des files d’attente Round Robin cause le conflit contre le protocole TCP.
Comme on ne peut déterminer la durée d’une connexion téléphonique donc il est difficile de
mettre cette connexion en respectant la QoS demandée dans un LSP de l’autre type de priorité
(AF par exemple). Par contre, une connexion de type VoD pourrait être mise dans un LSP de
type BE s’il ce dernier est vide pendant certaines durées car le temps de transmission a été bien
déterminé.
5.2 Au future
Ces résultats nous encouragent à traiter d’autres questions concernant une telle affectation
des flots EF dans des tuyaux AF, telle que la coopération entre les agents, la création dynamique
des LSP. Une étude de vérification et validation des différents paramètres de la simulation (la
topologie du réseau, les seuils, d’autres informations…) et des différentes règles doit être
effectuée. De plus, l’amélioration de la modélisation du réseau MPLS tel que le mécanisme de
contrôle des files d’attente, le traitement des BHP à chaque nœud … est aussi notre but dans
l’avenir.
6 RÉFÉRENCES
[1] Gaïti D., Pujolle G., “Performance Management Issues in ATM Networks an Congestion Control”. Mis en forme : Anglais
IEEE/ACM Transactions on Networking, 4(2) pp. 249-257, April 1996b. (Royaume-Uni)
[2] Legge D., Baxendale P., “An Agent-Based Network Management System”. AISB’2002, Imperial Mis en forme : Français (France)
College, London, England.
[3] Vilà P., Marzo J.L., Fàbrega L., “Using a Multi-agent System for Network Management”. In
(Royaume-Uni)
Proceedings of Congrés Català d’Intel·ligència Artificial (CCIA 2002). October, 2002. Castelló de la
Plana, Spain Mis en forme : Français (France)
[4] Merghem L., Gaïti D., “Une Approche Multi-agents pour la Simulation de Réseaux de Mis en forme : Anglais
Télecommunication”, Journées Francophones pour l'Intelligence Artificielle Distribuée et les Systèmes (Royaume-Uni)
Multi-Agents 2002(JFIADSMA’2002), pp 73-85, Lille, France Mis en forme : Français (France)
[5] Merghem L., Gaïti D., “Behavioural Multi-agent Simulation of an Active Telecommunication Network”.
Stairs’2002, Lyon, France (Royaume-Uni)
[6] Pujolle G. Les réseaux. Edition 2003.
[7] Gogeris D. et all. “Draft-tequila-sls-00.txt”. Mis en forme : Français (France)
[8] Bouras C., Campanelle M., Sevast A., “SLA Definition for the Provision of an EF-based Service”. 16th Mis en forme : Anglais
International Workshop on Communications Quality & Reliability (CQR 2002), pp. 17-21, May 14-16 (Royaume-Uni)
2002, Okinawa, Japan.
[9] Chao H.J., Guo X., Quality of Service Control in High-Speed Networks. John Wiley, 2002. Mis en forme : Français (France)
[10] Al-Irhayim S., Zubairi J.A., Mohammad .Q, Latif S.A., “Issues in Voice over MPLS and DiffServ Mis en forme : Anglais
Domains”. Proc. PDCS'2000, Volume II, pp467-472, Novermber 2000, Las Vegas. (Royaume-Uni)
[11] Baynat B., Théorie des files d’attente - des chaînes de Markov aux réseaux à forme produit. Hermes
Mis en forme : Français (France)
Science Publication, 2000.
[12] Hisamatsu H., “Steady State Analysis of TCP Connections with Different Propagation Delays”. www- Mis en forme : Anglais
miya.ist.osaka-u.ac.jp/~oosaki/ papers/Hisamatu02_Society.pdf (Royaume-Uni)
[13] Rosen E., Viswanathan A., [RFC3031] – “Multiprotocol Label Switching Architecture”, January 2001.
[14] Le Faucheur F., Wu L., Davie B., Davari S., Vaananen P., Krishnan R., Cheval P., Heinanen J.,
[RFC3270] – “Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", May 2002.
[15] Jacobson V., Nichols K., Poduri K., [RFC2598] – “An Expedited Forwarding PHB”, June 1999.
[16] Heinanen J., Baker F., Weiss W., Wroclawski J., [RFC2597] – “Assured Forwarding PHB Group”, June
1999.
[17] Frank H.P., Martin R., "MPEG-4 and H.263 Video Traces for Network Performance Evaluation", IEEE
Network, Vol. 15 - No. 6 – pp. 40-54, Nov./Dec. 2001.
[18] Klaus D., Wolfgang P., "Two classes - sufficient QoS for Multimedia Traffic", Talk for COST 257, May
2000, Oslo - Norway.
[19] Wenyn J., Henning S., "Analysis of On-Off Patterns in VoIP and Their Effect on Voice Traffic
Aggregation", ICCCN 2000.
[20] Ziviani A., Rezende J. F., Duarte O. C. M. B., "Towards a Differentiated Services Support for Voice
Traffic", Proc. of the IEEE Global Telecommunications Conference - GLOBECOM'99, p. 59-63,
December 1999.
[21] Poul H., "Modelling of Internet traffic", NTNU - SINTEF Telecom & Informatics, 1999.
(http://heim.ifi.uio.no/~bryhni/I2/GenIP-trafikk.PDF)
[22] Rümmler R., Aghvami A.H., Boorn A.H., Arram B., "Traffic modelling of software download for
reconfigurable terminals", IEEE International Symposium on Personal, Indoor and Mobile Radio
Communications (PIMRC), pp. 90-94, Volume 1, September 2001.
[23] The ATM Forum, http://www.atmforum.com
[24] Vetter R.J. “ATM concepts, architectures, and protocols”. Communications of the ACM, 38(2), pp. 30-
38, 1995.
[25] Pujolle G. “Rapport d’vancement du Projet MACSI”, Janvier 2003. Mis en forme : Français (France)
[26] Trimintzios P., et al. “A Management and Control Architecture for Providing IP Differentiated Services Mis en forme : Anglais
in MPLS-based Networks”, IEEE Communications Magazine, vol.. 16, no. 5, May 2001. (Royaume-Uni)
[27] Awduche D., et al [RFC 2702] – Requirements for Traffic Engineering Over MPLS”, September 1999. Mis en forme : Français (France)
[28] Raymond L., Srihari R., “DiffServ and MPLS – Concepts and Simulation ”.
[29] Gonzalo C., “Routing Architecture in DiffServ MPLS Networks”.
(Royaume-Uni)
[30] Duy L., “Mémoire de fin d’études”, l’IFI, Novembre 2004.
[31] Panos T., Paris F. Grorge P. Loenidas G., David G., “Policy-based Network Dimensioning for IP Mis en forme : Anglais
Differentiated Services Networks”. (Royaume-Uni)
[32] Floyd S., Jacobson V., “Random Early Detection Gateways for Congestion Avoidance”, IEEE/ACM
Trans. Networking, Vol. 1, No. 4, pp. 397-413, August. 1993. Mis en forme : Français (France)
[33] Vittori K., Araújo F.R., “Agent-Oriented Routing in Telecomunications Networks”. IEICE Transactions
on Communications, E84-B(11) : 3006-3013, November 2001.
7 Annexe
7.1 Le package INET du simulateur J-Sim

7.1.1 Le CSL et les services
Les éléments de base du CSL seront présentés dans cette annexe. Il comprend un
ensemble des services et événements bien définis que le CLS fournit aux modules du UPL. Ces
informations seront nécessaires si l’on voudrait travailler avec le package INET du simulateur J-
Sim .Les listes suivantes présentent ces services et événements.
Data services Code de champ modifié
Envoyer et délivrer des paquets.
Service/événement Description du Service/Evénement Porte
Packet Sending envoie des paquets selon une des méthodes suivantes: up port group
transférer en avant(default forward), multicast (*@up)
explicite(explicit multicast), émission exclusive(exclusive
broadcast).
Packet Delivery définit des informations associées avec la livraison des
paquets du CSL à un module UPL.
Packet Arrival est exporté quand un paquet arrive au CSL. .pktarrival@
(Component event)
Identity services
Permet des modules UPL à requérir ou configurer les identitiés d’un nœud.
Default Identity Retrieval recherche l’identité par défaut du nœud. .service_id@
All Identities Retrieval recherche toutes les identités du nœud.
Identities Query requiert si une identité existe.
Identity Addition ajoute des identités au nœud.
Identity Removal supprime des identités du nœud.
Identity Timeout Query requiert le temps quand des identités expirent.
Identity Event est exporté quand un ID est ajouté à, ou supprimé du .id@
(Component event) nœud.
Routing table services

Permet des modules UPL à requérir ou configurer la table de routage d’un nœud.
Unicast Route Query est exporté quand le CSL ne peut déterminer les .ucastquery@
interfaces de sortie sur lesquelles un paquet d’unicast
devrait être expédié.
Multicast Route Query est exporté quand le CSL ne peut déterminer les .mcastquery@
interfaces de sortie sur lesquelles un paquet de multicast
devrait être expédié.
Route Lookup retrouve les interfaces de sortie pour une combinaison .service_rt@
donnée des sources, une destination, et une interface
d’entrée.
Route Entry Addition ajoute une route entry à la table de routage.
Graft greffe un ensemble des interfaces de sortie à une route

entry existante.
Prune taille un ensemble des interfaces de sortie d’une route
entry existante.
Route Entry Removal Supprime des route entries dans la table de routage.
Route Entry Retrieval recherche des route entries dans la table de routage.
Unicast Route Event est exporté quand une route de type unicast est ajoutée, .rt_ucast@
(Component event) modifiée, ou supprimée.
Multicast Route Event est exporté quand une route de type multicast est ajoutée, .rt_mcast@ Mis en forme : Anglais
(Component event) modifiée, ou supprimée. (Royaume-Uni)
Interface/Neighbor services (Royaume-Uni)
Permet des modules UPL à requérir des informations interface/voisin de(s) interface(s) d’un Code de champ modifié
nœud. Mis en forme : Anglais
(Royaume-Uni)
All Interfaces Retrieval recherche des informations de toutes les interfaces. .service_if@
One Interface Retrieval recherche des informations d’une interface.
Neighbor Event est exporté quand un voisin est découvert sur une .if@
(physical) interface physique du nœud. Mis en forme : Anglais
(Component event) (Royaume-Uni)
Neighbor Event est exporté quand un voisin est découvert sur une .vif@ Code de champ modifié
(virtual) interface virtuelle du nœud.. Mis en forme : Anglais
(Component event) (Royaume-Uni)
Multicast services (Royaume-Uni)
Service/événement Description du Service/Evénement Porte Mis en forme : Anglais

(Royaume-Uni)
Member Join La même manière que le service Identity Addition. .service_mcast@
Code de champ modifié
Member Leave La même manière que le service Identity Removal.
Member Query La même manière que le service Identities Query. (Royaume-Uni)
Multicast Group Event est exporté quand un host joint un nouveau groupe .mcastHost@ Mis en forme : Anglais
de multicast ou le dernier host quitte un groupe de (Royaume-Uni)
multicast. Mis en forme : Français (France)
Packet filter configuration services

Permet des modules UPL à configurer les filtres de paquets dans le CSL.
Packet Filter Configuration Configure un filtre de paquets .service_configswitch@
La figure suivante illustre les services fournis par le CSL et les portes associées avec ces
services.
Fig 11. Le CSL, services, evénements et portes.
7.1.2 La décomposition du CSL

Le modèle de réseau abstrait ne spécifie pas comment le CSL devrait être structuré et
implémenté. On pourrait avoir de différentes implémentations de CSL pour la simulation des
nœuds d’un réseau à différents niveaux de détail. Ce pendant, le package INET développe une
implémentation par défaut du CSL. Le CSL dans cette implémentation est un composant qui se
compose de tels sous composants. Chaque sous composant est responsable d’un ou plusieurs
services et événements du CSL. L’implémentation par défaut du CSL, les relations entre ses
sous composants et les services/événements exportés par ces sous composants sont illustrés
dans le figure suivante :
Fig 12. La décomposition du CSL.

Les sous composants, leurs fonctions, les services et les événements sont :
Composant ID Fonction Services/Evénements
PktDispatcher pd Ce composant fournit les service Packet Sending
d’envoyer /délivrer des données aux Packet Delivery
modules UPL. Spécialement, il expédie Unicast/Multicast Route Query
des paquets d’entrées à un ensemble Packet Arrival Mis en forme : Anglais
approprié des ports de sortie. (Royaume-Uni)
Identity id Ce composant maintient la base de Default Identity Retrieval Code de champ modifié
données des identités dans le CSL. Il est All Identities Retrieval
responsable de fournir les services de la Identities Query
recherche des identités et les services de Identity Addition
la configuration, ainsi exporter des Identity Removal
événements d’identité. Identity Timeout Query
Identity Events Mis en forme : Anglais
(Royaume-Uni)
RT rt Ce composant maintient la table de Route Lookup
routage du CSL. Il fournit les services Route Entry Addition Code de champ modifié
d’acheminement et configuration, et Graft
exporte des événements de changement Prune
des chemins. Route Entry Removal
Route Entry Retrieval
Unicast/Multicast Route Events Mis en forme : Anglais
(Royaume-Uni)
Hello hello Ce composant maintient les informations All Interfaces Retrieval
des interfaces. Il fournit les services des One Interface Retrieval Code de champ modifié
requêtes interface/voisin et exporte des Neighbor Events Mis en forme : Anglais
événements de voisins. Il pourrait être (Royaume-Uni)
configuré statistiquement ou
dynamiquement.
sIGMP igmp Ce composant fournit les services de Member Join Code de champ modifié
multicast. Member Leave
Member Query
Multicast Group Event Mis en forme : Anglais
(Royaume-Uni)
PacketFilter- pfs Ce composant est responsable d’envoyer Packet Filter Configuration
Switch des requêtes de configuration au filtre de (Royaume-Uni)
paquets indiqué dans la requête.
PacketFilter pf_<j> La classe de base pour implémenter un Nul
filtre de paquets.
Queue q La classe de base pour implémenter une Nul
file d’attente d’une interface de sortie.
NI ni La classe de base pour implémenter une Nul
carte d’interface de réseaux.
QueueNI ni La classe de base pour l’implémentation Nul
d’un composant intégré queue/network-
interface.
où est l’index du filtre de paquets banque/interface et <j> est l’index du filtre de
paquets dans la banque.
A partir de ces composants, on peut bâtir un host ou un routeur. La figure suivante montre
les structures génériques internes d’un routeur et d’un host.
Fig 13. La structure interne d’un routeur Fig 14. La structure interne d’un host
7.1.3 L’établissement d’un scénario de simulation d’un réseau

La construction d’un scénario de simulation de réseau dans le J-Sim est décrite dans le
manuscrit suivant de TCL:
# Créer un container pour tenir le scenario
cd [mkdir drcl.comp.Component scene] Mis en forme : Anglais
# Etape 1: Créer la topologie (Royaume-Uni)
... Mis en forme : Français (France)
# Etape 2: Bâtir des nodes
...
# Etape 3: Configurer des nodes
...
# Attacher le temps d’exécution de simulateur à la "scene"
attach_simulator .
# Lancer tous les composants actifs sous la "scene" s’il y en a
run .
Exemple : Pour créer un scénario de simulation de réseau qui a la topologie montrée dans la
figure[15], on pourrait décrire un manuscrit de TCL :
Fig 15. Une topologie de réseau
où h est le host, n<j> est le nœud <j>.

cd [mkdir drcl.comp.Component scene] Mis en forme : Anglais
2 # Create topology: (Royaume-Uni)
3 set adjMatrix_ [java::new {int[][]} 6 {{1 3 2} {3 0 4} {0 3 5}
{0 1 2} 1 2}]
4 java::call drcl.inet.InetUtil createTopology [! .] $adjMatrix_

5 # Build nodes:
6 set routerBuilder_ [java::new drcl.inet.NodeBuilder
.routerBuilder]
7 set hostBuilder_ [cp $routerBuilder_ .hostBuilder]
8 mkdir $hostBuilder_/20@up
9 $routerBuilder_ build [! n*]
10 $hostBuilder_ build [! h*]
11 # Set up traffic source:

12 set packetSize_ 512
13 set period_ .1; # send a packet of size 512 bytes every .1
second
14 set trafficModel_ [java::new
drcl.net.traffic.traffic_PacketTrain $packetSize_ $period_]
15 java::call drcl.inet.InetUtil createTrafficSource $trafficModel_
"source" [! h4] [! h5] 0 20]
16 # Set up sink:
17 set sink_ [mkdir drcl.comp.tool.DataCounter h5/sink]
18 connect -c h5/csl/20@up -to $sink_/down@
19 # Set up static routes from h4 to h5
20 java::call drcl.inet.InetUtil setupRoutes [! h4] [! h5]
21 attach_simulator .; # attach simulation runtime

22 # start "active" component: the traffic source
23 run . Mis en forme : Français (France)
7.2 La configuration et le manuscrit de simulation de réseau MPLS

7.2.1 La configuration du composant de FT
Avant d’envoyer des données, il est nécessaire d’ajouter des informations d’acheminement
à la FT. On pourrait utiliser deux méthodes :
utiliser des commandes de TCL dans le manuscrit de configuration de TCL. Mis en forme : Retrait : Première
générer un fichier de configuration qui sera chargé à la FT. ligne : 0.13", Avec puces + Niveau : 1
La commande suivante rajoute une entrée à la FT. Cette entrée relie une étiquette d’entrée + Alignement : 0.25" + Tabulation
après : 0.5" + Retrait : 0.5"
à une interface de sortie et une liste d’opérations.
node/csl/ft addLabelEntry label outif timeout operation Mis en forme : Anglais
Description des arguments : (Royaume-Uni)
Nom Description Type de donnée Note
label l’étiquette d’entrée entier (integer) nul
outif l’interface de sortie entier (integer) nul
timeout le temps avant l’effacement de réel (double) la valeur 0.0 indique
cette entrée une entrée
permanante
operation définir des opérations sur les Chaîne des « op1 lab1 : op2
étiquettes caractères lab2 :… : opN
labN »
Les opérateurs sont : SWAP, PUSH, POP.

SWAP : l’étiquette au sommet de la pile est modifié par la valeur donnée.
PUSH : rajouter une nouvelle valeur à la pile.
POP : effacer la valeur au sommet de la pile.
Exemple : Mis en forme : Anglais
(Royaume-Uni)
! n1/csl/ft addLabelEntry 1 2 90.0 "POP 0"
Pour relier un préfixe IP à une interface de sortie et une liste d’opérations on peut utiliser la
commande :
node/csl/ft addPrefixEntry destIP destMask outif timeout operation Mis en forme : Anglais
Description des arguments : (Royaume-Uni)
Nom Description Type de donnée Note
destIP l’adresse IP de destination entier (long) nul
destMask le masque de destionation entier (long)
outif l’interface de sortie entier (integer) nul
timeout le temps avant l’effacement de cette réel (double) la valeur 0.0 indique
entrée une entrée permanante
operation définir des opérations sur les étiquettes Chaîne des « op1 lab1 : op2
caractères lab2 :… : opN labN »
Les opérateurs sont les mêmes que dans le cas ci-dessus.

Exemple : Mis en forme : Anglais
! n2/csl/ft addPrefixEntry 0x05 0xFFFFFFFF 1 30.0 "PUSH 1:PUSH 1:PUSH 2" (Royaume-Uni)
Dans le cas que l’on veut charger les entrées dans la FT à partir d’un fichier, on pourrait
utiliser la commande :
node/csl/ft loadFromFile path
path : Le chemin pour trouver le fichier.
Dans le fichier de configuration du FT, chaque ligne est une entrée. On a deux type de
ligne :
L inlabel outif timeout {op label}+
I destIP destMask outif timeout {op label}+
où L indique une entrée d’étiquette, I présente celle d’adresse IP.
op = 1 (PUSH) ; 2 (POP) ; 3 (SWAP) Mis en forme : Anglais
(Royaume-Uni)
Exemple :
!n3/csl/ft loadFromFile "./ft.content"
Avec le contenu du fichier ft.content:
I 00000005 FFFFFFFF 1 90.0 1 1 1 1
I 00000007 FFFFFFFF 1 90.0 1 1 1 1 1 2
L 1 2 90.0 2 0
7.2.2 L’établissement d’un nœud MPLS

Créer un MPLSBuilder :
set mpls [mkdir infonet.javasim.MPLS.MPLSBuilder .mplsBuilder] Mis en forme : Anglais
Créer des nœuds MPLS : (Royaume-Uni)
set nb [mkdir drcl.inet.NodeBuilder .nodeBuilder]
$nb build [! n?] $mpls
Exemple complet d’un scénario de simulation du réseau MPLS sera introduit dans la section
suivante.
7.3 Guide d'installation de la simulation du reseau MPLS-DiffServ.

7.3.1 L'Installation
- Lancer la fenetre de commande DOS
- Changer le chemin (path) au repertoire C:\npquang\working\mpls\current
- Etablir les variables d'environnement par le script run.bat
- Faire marcher la simulation en utilisant le script r.bat, ou bien : java drcl.ruv.System
ianet.tcl
- Pour recompiler les fichiers *.java, utilisez le script c.bat
7.3.2 L'affichage des résultats

Les résultats sont affichés de deux façons: visuelle et textuelle:
- L'affichage visuel montre les valeurs moyennes et instantanées des paramètres de QoS
selon chaque LSP du réseau comme : la gigue, le délai, la perte.
- L'affichage textuel montre le traitement et les critères utilisés de l'agent :
Waiting for agent process Mis en forme : Anglais
Agent processing.... (Royaume-Uni)
Agent process number : 20
lookup for : 0 Alternative number : 2
Avarage : Mean parameters : delay :0.04011069242009149 jitter :

0.06244899598381361 loss : 0.0 wait :2.7843803056027165E-4
Variance parameters : delay :0.02251883567437416 jitter :
0.04886202120211075 loss : 0.0 wait :1.5353530580015497E-4
Agent return : 1
End of agent process
+ Agent process number indique le nombre de flots de données a été traités de la
simulation.
+ lookup for : "type de service" (0 : EF, 1 : AF, 2 : BE) Mis en forme : Anglais
+ Alternative number : "nombre de LSP" (Royaume-Uni)
+ Mean parameters : la somme des valeurs moyennes de tous les noeuds appartenant
d'un LSP
+ Variance parameters : la variance des valeurs moyennes
+ Agent return : "la référence pour trouver un chemin dans FT( Forwarding Table)
7.3.3 Remarque
- La topologie du réseau est présentée dans le fichier ianet.tcl.
- L'agent se trouve à noeud n0 et il ne traite que des flots de noeuds n0 à la destination n2
- L'agent a deux ports à communiquer : AGENT_SERVICE_PORT_ID pour le traitement de
flots et AGENT_UPDATE_PORT_ID pour la mise à jour des donnees
- La période de mise à jour des paramètres (le temps que les noeuds envoient leur état
actuel à l'agent):
foreach i {0 1 2 3} { Mis en forme : Anglais
[! n$i/csl/mpls] setTimeUpdate "Update" 0.1 (Royaume-Uni)
}
- L'agent ne change pas le contenu des paquets, il ne donne qu'une reference au module
MPLS pour faire "lookup" dans la FT
7.3.4 Le fichiers de simulation ianet.tcl
#LE Duy-NGUYEN Phan Quang Mis en forme : Français (France)
cd [mkdir drcl.comp.Component /ianet]
puts "\n-=Construire la topologie=-"
puts "Construire les noeuds..."
cd [mkdir drcl.comp.Component net0]
set link_ [java::new drcl.inet.Link] Mis en forme : Anglais
$link_ setPropDelay 0.1; (Royaume-Uni)
# {5,9,13}
# |
# |
# 1
# / \
# / \
# / \
# {12,8,4}---0 2---{6,10,14} 16
# \ /
# \ /
# \ /
# 3
# |
# |
# {7,11,15}
puts "Construire l'adress IP..."

set id_ [java::new {long[]} 8 {0 1 2 3 4 5 6 7 }]
set adjMatrix_ [java::new {int[][]} 8 {{1 3 4} {0 2 5} {1 3 6} {0 2 7} {0} {1}
{2} {3}}]
java::call drcl.inet.InetUtil createTopology [! .] "n" "n" $adjMatrix_ $id_
$link_
set mplsBuilder [mkdir MPLSBuilder .mplsBuilder]
set nb [mkdir drcl.inet.NodeBuilder .nodeBuilder]
$nb setBandwidth 3.5e7; #35Mbps #1.0e7 = 10Mbps

$nb build [! n0] $mplsBuilder

$nb setBandwidth 3.5e7; #6.5Mbps #1.0e7 = 10Mbps


$nb setBandwidth 1.0e8; #100Mbps #1.0e3=1Kbps

$nb build [! n4-7] $mplsBuilder
[! n4] addAddress 8
[! n4] addAddress 12
[! n5] addAddress 9
#For testing only
#Added by NGUYEN Phan Quang 12/09/03

puts "create and connect database"
mkdir Database data
#connect [! n?/csl/mpls/DATA_SERVICE_PORT_ID@] -to [! data/update@]
puts "create and connect agent and n1"

mkdir Agent agent
! agent setDatabase [ ! /ianet/net0/data]
connect agent/AGENT_SERVICE_PORT_ID@ -and [!
/ianet/net0/n0/csl/mpls/AGENT_SERVICE_PORT_ID@]
foreach i {0 1 2 3} {
connect [! n$i/csl/mpls/AGENT_UPDATE_PORT_ID@] -to [!
agent/AGENT_UPDATE_PORT_ID@]
}
connect agent/DATA_PORT_ID@ -and data/update@
! agent setActive true
#! agent setActive false
mkdir drcl.comp.tool.Plotter .plot
! agent connect2Plot [ ! .plot]
#end of addition
puts "Configuration des routeurs..." Mis en forme : Français (France)
java::call infonet.javasim.util.NetUtil setupBRoute [! n0] [! n4]

java::call infonet.javasim.util.NetUtil setupBRoute [! n4] [! n0] Mis en forme : Anglais
java::call infonet.javasim.util.NetUtil setupBRoute [! n1] [! n5] (Royaume-Uni)


puts "Configuration des table d'acheminement..." Mis en forme : Français (France)
foreach i {1 2 3} { Mis en forme : Anglais

###### Flow 1: 4 -> 0 1 2 -> 6 Label=1 => EF (Royaume-Uni)
###### Flow 2: 8 -> 0 1 2 -> 10 Label=2 => AFxy
###### Flow 3: 12 -> 0 1 2 -> 14 Label=3 => BE
# addPrefixEntry destIP destMask iface timeout operations
! n0/csl/ft addPrefixEntry [expr $i*4+2] 0xFFFFFFFF 0 90.0 "PUSH $i"
# N1
# addLabelEntry label iface timeout operations
! n1/csl/ft addLabelEntry $i 1 90.0 "SWAP $i"
# N2
! n2/csl/ft addLabelEntry $i 2 90.0 "POP 0"
#######################
###### Flow 4: 5 -> 1 2 3 -> 7 Label=4 => EF
###### Flow 5: 9 -> 1 2 3 -> 11 Label=5 => AFxy
###### Flow 6: 13 -> 1 2 3 -> 15 Label=6 => BE
# N1
! n1/csl/ft addPrefixEntry [expr $i*4+3] 0xFFFFFFFF 1 90.0 "PUSH [expr
$i+3]"
# N2
! n2/csl/ft addLabelEntry [expr $i+3] 1 90.0 "SWAP [expr $i+3]"
# N3
! n3/csl/ft addLabelEntry [expr $i+3] 2 90.0 "POP 0"
#######################
###### Flow 7: 6 -> 2 3 0 -> 4 Label=7 => EF
###### Flow 8: 10 -> 2 3 0 -> 8 Label=8 => AFxy
###### Flow 9: 14 -> 2 3 0 -> 12 Label=9 => BE
# N2
! n2/csl/ft addPrefixEntry [expr $i*4] 0xFFFFFFFF 1 90.0 "PUSH [expr
$i+6]"
# N3
# N0
#######################
###### Flow 10: 7 -> 3 0 1 -> 5 Label=10 => EF
###### Flow 11: 11 -> 3 0 1 -> 9 Label=11 => AFxy

###### Flow 12: 15 -> 3 0 1 -> 13 Label=12 => BE
# N3
! n3/csl/ft addPrefixEntry [expr $i*4+1] 0xFFFFFFFF 0 90.0 "PUSH [expr
$i+9]"
# N0
# N1
}
# For testing only

###### Flow 13: 4 -> 0 3 2 -> 16 Label=13 => EF
###### Flow 14: 8 -> 0 3 2 -> 10 Label=14 => AFxy
###### Flow 15: 12 -> 0 3 2 -> 14 Label=15 => BE
! n0/csl/ft addPrefixEntry 16 0xFFFFFFFF 1 90.0 "PUSH 13"
# N3
! n3/csl/ft addLabelEntry 13 1 90.0 "SWAP 13"
# N2
! n2/csl/ft addLabelEntry 13 2 90.0 "POP 0"

# Added by Nguyen Phan Quang 25-09

! n0/csl/ft addLabelEntry 1 0 90.0 "PUSH 1"


#End of addition
set EF 0
set AF 1
set BE 2
puts "Des variables..."

foreach i {0 1 2 3} {
set sourceF$i n[expr $i+4]
# puts "sourceF$i ==> n[expr $i+4]"
foreach j {0 1 2} {
if {$i > 1} {set destF$i$j [expr $i+2+$j*4] } {set destF$i$j [expr
$i+4+2+$j*4]}
# puts "==> destF$i$j"
}
set OnOff_$i [mkdir source_OnOff OnOff_$i]

set Poisson_$i [mkdir source_Poisson Poisson_$i]
set ParetoOnOff_$i [mkdir source_ParetoOnOff ParetoOnOff_$i]
set Trace_$i [mkdir source_Trace Trace_$i]
set timePeriodSource$i -1
}
puts "Configuration des sources de trafic..."
# For testing only

set Trace_n [mkdir source_Trace Trace_n]
[! Trace_n] set [! n4] 16 "Verbose_Aladdin_duy2.dat" 256 false
[! Trace_n] setParam 16 $timePeriodSource0 $BE
set OnOff_n [mkdir source_OnOff OnOff_n]

[! OnOff_n] set [! n4] 16
[! OnOff_n] setParam 17 $timePeriodSource0 $AF
[! OnOff_n] setOnOffParam 56 221184 0.01 0.06
###### Source
[! OnOff_0] set [! $sourceF0] $destF00
[! OnOff_0] setParam 0 $timePeriodSource0 $EF
[! OnOff_0] setOnOffParam 128 13072 0.01 0.06
[! Poisson_0] set [! $sourceF0] $destF01

[! Poisson_0] setParam 1 $timePeriodSource0 $BE
[! Poisson_0] setPoissonParam 128 24576
[! ParetoOnOff_0] set [! $sourceF0] $destF02

[! ParetoOnOff_0] setParam 2 $timePeriodSource0 $BE
[! ParetoOnOff_0] setParetoOnOffParam 56 122880 0.01 0.06 3
[! Trace_0] set [! $sourceF0] $destF02 "Verbose_Jurassic_duy3.dat" 256

false
[! Trace_0] setParam 3 $timePeriodSource0 $EF
###################"


[! Poisson_1] setParam 5 $timePeriodSource1 $AF

[! Trace_1] set [! $sourceF1] $destF12 "Verbose_Aladdin_duy2.dat" 128 false

[! Trace_1] setParam 7 $timePeriodSource1 $BE
######################



[! Trace_2] set [! $sourceF2] $destF22 "Verbose_Aladdin_duy3.dat" 128 false

[! Trace_2] setParam 11 $timePeriodSource2 $AF
######################

[! OnOff_3] setParam 12 $timePeriodSource3 $AF


[! Trace_3] set [! $sourceF3] $destF32 "Verbose_Jurassic_duy2.dat" 128

false
[! Trace_3] setParam 15 $timePeriodSource3 $EF
puts "Configuration les plotteurs..."
foreach j {0 1 2} {
foreach i {0 1 2 3} {
set plot_$j$i [mkdir ianetPlotter .p$j$i]
}
}
for {set t 0} {$t<50} {incr t} {

set OnOff_[expr $t+100] [mkdir source_OnOff OnOff_[expr $t+100]]
[! OnOff_[expr $t+100]] set [! $sourceF0] $destF00
[! OnOff_[expr $t+100]] setParam [expr $t+20] $timePeriodSource0 $EF
[! OnOff_[expr $t+100]] setOnOffParam 56 131072 0.01 0.06 Mis en forme : Français (France)
set Poisson_[expr $t+100] [mkdir source_Poisson Poisson_[expr $t+100]]

[! Poisson_[expr $t+100]] set [! $sourceF0] $destF01
[! Poisson_[expr $t+100]] setParam [expr $t+150] $timePeriodSource0 $BE
[! Poisson_[expr $t+100]] setPoissonParam 128 221184
}
for {set t 0} {$t<20} {incr t} {
set OnOff_[expr $t+200] [mkdir source_OnOff OnOff_[expr $t+200]]
[! OnOff_[expr $t+200]] set [! $sourceF0] $destF01
[! OnOff_[expr $t+200]] setParam [expr $t+270] $timePeriodSource0 $AF
[! OnOff_[expr $t+200]] setOnOffParam 64 131072 0.01 0.06
set Poisson_[expr $t+200] [mkdir source_Poisson Poisson_[expr $t+200]]

[! Poisson_[expr $t+200]] set [! $sourceF1] $destF01
[! Poisson_[expr $t+200]] setParam [expr $t+350] $timePeriodSource0 $AF
#[! Poisson_[expr $t+200]] setPoissonParam 128 221184
}
###### Simulation
puts "Simulation" Mis en forme : Français (France)
set SIM [attach_simulator .] Mis en forme : Anglais

rt . stop (Royaume-Uni)
foreach i {0 1 2 3} {
[! n$i/csl/mpls] setTimeUpdate "Update" 0.1
#==========================================
script { run OnOff_0} -at 1.0 -on $SIM
script { run Poisson_0} -at 0.0 -on $SIM
script { run ParetoOnOff_0} -at 0.5 -on $SIM
script { run Trace_0} -at 0.0 -on $SIM
# testing only
script { run Trace_n} -at 0.0 -on $SIM
script { run OnOff_n} -at 0.0 -on $SIM
#==========================================
#==========================================

#==========================================



#script { run Poisson_100} -at 10.2 -on $SIM




#script { run OnOff_127} -at 6.5 -on $SIM

script { stop OnOff_101} -at 10.0 -on $SIM


script { stop Poisson_212} -at 8.5 -on $SIM
script { stop Trace_n} -at 11.0 -on $SIM
rt . resumeTo 20 Mis en forme : Français (France)
7.4 Les résultats obtenus

7.4.1 La simulation du réseau sans agent
i) Les paramètres des LSP de type EF
Fig 16. Le délai et la gigue du LSP4 Fig 17. Le délai et la gigue du LSP1
Fig 18. La perte du LSP4 Fig 19. La perte du LSP1
ii) Les paramètres des LSP de type AF
Fig 20. Le délai du LSP2 Fig 21. La perte du LSP2

Fig 22. Le délai du LSP5 Fig 23. La perte du LSP5
iii) Les paramètres des LSP de type BE
Fig 24. Le délai du LSP6 Fig 25. Le délai du LSP3
7.4.2 La simulation du réseau avec agent intelligent

a. Le cas stable
i) Les valeurs moyennes des paramètres des LSP EF
Fig 28. Les valeurs moyennes du LSP4 Fig 29. Les valeurs moyennes du LSP1
ii) Les valeurs instantanées des paramètres des LSP EF
Fig 30. Les valeurs instantanées du LSP4 Fig 31. Les valeurs instantanées du LSP1
iii) Les valeurs moyennes des paramètres des LSP AF
iv) Les valeurs instantanées des paramètres des LSP AF
v) Les valeurs moyennes des paramètres des LSP BE
vi) Les valeurs instantanées des paramètres des LSP BE
b. Le cas dynamique
i) Les valeurs des paramètres des LSP EF
Fig 40. Les valeurs moyennes du LSP4 Fig 41. Le délai et la gigue du LSP1
Fig 42. Les valeurs instantanées du LSP4 Fig 43. La perte du LSP1
ii) Les valeurs des paramètres des LSP AF
iii) Les valeurs des paramètres des LSP BE

Stage-Nguyen Phan Quang

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Stage-Nguyen Phan Quang

Enviado por

Direitos autorais:

Formatos disponíveis

Définition du style : TM 2

Institut de la Francophonie pour l'Informatique

Mémoire de fin d’études du :

Gestion de l’Accès aux Réseaux MPLS-DiffServ par des Agents

Table des matières

7.3.4 Le fichiers de simulation ianet.tcl............................................................................................ 39

1.1 La garantie de la QoS dans les réseaux IP

1.2 L’ingénierie du trafic dans les réseaux MPLS

1.2.1 L’ingénierie du trafic

1.3 L’objectif du projet

2.1 L’agent intelligent dans les réseaux de Télécommunications

coopération, l’apprentissage…) sont utilisés pour modéliser et fonctionner dans l’environnement

2.2 Les réseaux MPLS-DiffServ

2.3 L’environnement de Simulation J-Sim

Fig 1. L’architecture des composants de base.

2.3.2 Modélisation d’un réseau

Fig 2. Le modèle de réseau INET

Fig 3. La structure interne d’un nœud de réseau.

La décomposition du CSL sera montrée en détails dans l’annexe concernant J-Sim.

2.3.3 Modélisation du réseau MPLS dans J-Sim

Fig 4. La décomposition du CSL dans le nouveau modèle de réseau MPLS.

2.3.4 Les problématiques

3.1 Modélisation du réseau MPLS-DiffServ

Fig 5. Modèle de modélisation du CSL et des sources du réseau MPLS proposé.

3.1.1 Fonctionnement du réseau

Fig 6. La structure interne du module de file d’attente Priority Queue

3.1.2 La conception d’un nœud MPLS

Fig 7. L’architecture globale d’un nœud d’accès.

Fig 8. Le diagramme de composants d’un nœud d’accès.

3.1.3 La modélisation des sources de trafic

3.2 Modèle de l’agent

3.2.2 Les critères à utiliser

ti = (5), et son écart-type (la gigue):

SP = P + PV (9), soit inférieure à 10-3.

3.2.3 L’architecture de l’agent

4 Analyse des résultats

4.1 La topologie du réseau

Fig 10. Topologie du réseau MPLS-DiffServ

4.2 Méthodes d’expérimentation et d’évaluation

4.2.1 Réseau sans agents intelligents

4.2.2 Réseau avec agents intelligents

a) Etat stable du réseau

b) Etat dynamique du réseau.

0.10 6.56E-3 9.74E-4 0.00 6567786

0.10 10.02 0.62 0.00 2741866

0.10 1.60E-2 2.64E-3 0.00 9505706

0.10 9.71E-4 8.52E-3 0.00 2486933

0.10 11.43 0.73 0.00 1674560

4.2.3 Interprétation et remarques

5.1 Les résultats obtenus

7.1 Le package INET du simulateur J-Sim

Routing table services

Graft greffe un ensemble des interfaces de sortie à une route

Service/événement Description du Service/Evénement Porte Mis en forme : Anglais

Packet filter configuration services

Packet Filter Configuration Configure un filtre de paquets .service_configswitch@

Fig 11. Le CSL, services, evénements et portes.

7.1.2 La décomposition du CSL

Fig 12. La décomposition du CSL.

7.1.3 L’établissement d’un scénario de simulation d’un réseau

Fig 15. Une topologie de réseau

où h<i> est le host<i>, n<j> est le nœud <j>.

4 java::call drcl.inet.InetUtil createTopology [! .] $adjMatrix_