Architecture des réseaux pour la gestion de la QoS sur Internet

Télécharger le fichier original (Mémoire de fin d’études)

Les applications de simulation distribuee et leurs besoins en QoS

Introduction

Ce chapitre a pour but de formaliser les communications temps-reel au sein d’une applica-tion de simulation distribuee. Il presentera un etat de l’art sur les applications de simulation distribuee, et tout particulierement ce qui concerne la speci cation de leurs besoins en termes de contraintes fonctionnelles, temporelles et de qualite de service. Nous presenterons respecti-vement :
1. les principes de base des approches actuelles permettant particulierement de mettre en oeuvre des simulations distribuees interactives a la section 2.2. Nous verrons notamment les concepts liees a l’architecture de communication distribuee basee sur la norme HLA a la Section 2.3 et celle sur DDS a la Section 2.4,
2. les concepts lies a la gestion de la Qualite de Service (QoS) dans les reseaux locaux et les reseaux grande distance et les mecanismes associes dans la section 2.5 : le provisionnement des ressources et le contr^ole d’admission en detaillant la signalisation.
3. Une conclusion de chapitre sera donnee a la Section 2.6.

Le protocole DIS

Le de de promouvoir le developpement des applications de simulation interactive distri-buee (applications DIS) a et aborde par la DARPA au debut des annees 1980 dans le projet SIMulator NETworking (SIMNET) [85]. Ce domaine, aujourd’hui mature mais encore en pleine evolution, recele toujours des di cultes concernant la mise en reseau de simulateurs temps reels repartis sur des grandes distances. Les e ets du reseau sur la transmission d’information entre simulateurs sont geres et compenses par des techniques relativement basiques.
Le standard IEEE 1278 nomme aussi protocole DIS (Distributed Interactive Simulation) [62] reprend les bases de SIMNET pour permettre a plusieurs simulateurs d’interoperer en impo-sant la semantique des messages echanges. Il propose des echanges de donnees asynchrones standardises, ou les paquets de donnees ou PDU (Protocol Data Units) permettent de trans-mettre des evenements pour ^etre percus par les autres entites. Les PDUs suivent un format tres precis correspondant a des evenements relevant du domaine militaire (collision, detonation, ravitaillement, etc.) [31]. Le simulateur cree des evenements, signale la creation et les mises a jour d’entites vers tous les autres simulateurs.

Principe de conception

DIS a apporte une norme d’echange de donnees entre simulateurs, de nissants des evene-ments generiques pour assurer l’interoperabilit des simulations militaires. Les informations sur les objets du monde virtuel sont censees ^etre connues de toutes les simulations et n’ont pas besoin d’^etre transmises. Les entites dynamiques de la simulation changent d’etats et informent les autres entites distantes de leurs deplacements et des evenements qu’elles produisent par l’emission des PDUs. Comme il s’agit d’une communication en multicast, tout simulateur dif-fuse et rend disponible les evenements et les objets dynamiques de la simulation a tous ceux qui participent a l’exercice. C’est au noeud recepteur de calculer l’e et de l’evenement recu sur les entites qu’il gere, voir si ces evenements re etent la realit absolue, alteree ou m^eme s’il doit ignorer ces informations.
Selon cette approche, l’emetteur ne transmet que les modi cations d’etats des entites qu’il gere pour maintenir un debit faible a l’emission et minimiser le traitement inutile des informations. Chaque entit receptrice maintient un modele simpli e de l’etat des entites adjacentes, et ex-trapole leurs etats reportes jusqu’a ce que la prochaine noti cation arrive. A n de reduire le nombre de messages de mise a jour des etats de ses entites, chaque site maintien, en plus de la representation reelle, un modele de haute delit (representation extrapolee ou modele Dead Reckoning) pour estimer les etats des entites simulees localement [82]. Les etats anticipes sont calcules a partir des informations d’etats de leur passe en utilisant des equations d’extrapola-tion. L’ecart entre l’etat extrapol et l’etat reel ne doit pas exceder l’un des seuils de nis dans le standard (T hpos pour la position et T hor pour l’orientation). Sur tous les autres sites distants, la reception d’un paquet contenant une nouvelle position engendre la mise a jour de l’etat de l’entit concernee.

Communication

Les informations de simulation des etats sont encodees dans des PDUs (67 di erents types regroupes en 12 familles), et l’echange des donnees entre les h^otes utilisent le protocole de la couche de transport classique a travers UDP en mode di usion. On retrouve un coupleur DIS qui joue le r^ole de processeur de tri de paquets sortant ne communiquant a chaque simulateur que ceux qui lui sont adresses. A l’inverse, localement, chaque h^ote envoie la totalite de ses paquets indiquant la progression de ses propres entites. En plus, pour reduire le nombre de messages transmis sur les reseaux distants, il est necessaire d’avoir une application qui joue le r^ole de pont pour bien gerer les PDUs. En e et, une quantite assez grande de la bande passante est dediee aux ent^etes, ce qui reduit les performances de la bande passante de moitie. L’agre-gation de paquets se fait en fusionnant les messages en 1 seul paquet a n d’eliminer l’envoi multiple des ent^etes. En outre, DIS utilise un algorithme de compression de donnees [61] a n de reduire le nombre de bits envoyes sur le reseau. Le principe est base sur les observations faites sur les informations envoyees entre deux instants consecutifs, et s’il est aver que les donnees transmises ne changent pas frequemment, alors au lieu d’envoyer a chaque fois le nouvel etat de l’objet, il su t d’envoyer les changements qui ont eu lieu par rapport a son etat precedent. Avec l’emergence de la technologie ATM au debut des annees 90, les applications DIS utilisent ce reseau comme infrastructure de base pour les communications grande distance. Le groupe OLC au LAAS avait demontr qu’il est possible de speci er, a priori, la qualite de service requise par ce type de simulation [25]. Chirieleison [28] propose de mettre les applications DIS sur un reseau ATM distant. Les fonctionnalites incluent un protocole de communication UDP Multicast pour la di usion vers des groupes agreges dans la simulation. Anshu [74] propose une evaluation de la simulation a large envergures sur un reseau ATM dedi . Il trouve que l’augmentation des tailles de paquets DIS engendre une augmentation de delai de transit de bout en bout. Ceci provient de la conversion des PDU DIS en cellules ATM. Dans [10] les auteurs etudient l’e et de l’agregation de paquets sur le delai de transmission de bout en bout. Ils deduisent que si la taille des paquets augmente le delai de transmission augmente aussi sur le reseau. A cet e et, ils considerent que la segmentation des PDUs en paquets de petites tailles, compatible a la taille des cellules ATM permet d’avoir de meilleurs delais de transmission et reduit enormement la gigue.
Cependant, DIS s’adresse uniquement aux simulations temps-reel, ce qui limitait sa di usion aux simulations militaires qui obeissent a des contraintes et des formats de donnees bien speci-ques. Malgre son succes, DIS sou re encore de plusieurs inconvenients : il n’est pas totalement distribue, du fait que chaque message doit ^etre recu et traite par chaque noeud, ce qui en-combre le reseau m^eme si les donnees sont assez reduites. De plus, tous les PDUs sont en mode multidi usion, ce qui ramene le contr^ole de la distribution au cours de l’exercice au niveau reseau (assignation des ports). Outre, DIS ne gere pas la latence et la causalite, ce qui rend la reutilisation des simulations impossible. Ces contraintes conduisent DIS a ^etre un protocole non exible.
HLA et DDS ont constitue les etapes suivantes en evitant d’imposer la semantique de DIS. Ces middlewares ont connu un essor dans les travaux de recherche qui ont conduit au deploiement de nombreuses applications distribuees. Ils reposent sur des services de communication genera-lement situes au niveau de la couche transport. Les applications qui implementent ces services doivent a leur tour s’appuyer sur les proprietes previsibles de l’infrastructure de communication pour speci er leurs besoins qu’ils ne peuvent pas formuler explicitement par les interfaces dis-ponibles. Pour cela, dans cette these, nous ne focalisons pas sur la simulation distribuee basee sur le protocole DIS a cause de ses limites, mais nous nous interessons a la simulation distribuee base sur HLA et DDS.

Simulation distribuee a base de HLA

La norme HLA [63] (High Level Architecture) est une architecture de simulation distribuee permettant de developper une infrastructure technique commune pour la modelisation et la si-mulation, favorisant l’interoperabilit et la reutilisation des composants existants. HLA permet d’exploiter de multiples programmes (simulations) pour creer une simulation a grande envergure en rajoutant la speci cation de mecanismes permettant la distribution necessaire a la communi-cation globale. Chaque simulation participante est appel un feder ; elle interagit avec d’autres federes au sein d’une collection de simulations, dite federation HLA [76]. La speci cation decrit la maniere avec laquelle les federes communiquent au sein d’une federation a travers un middle-ware indispensable pour implementer les services de HLA : le RTI (Run-Time Infrastructure), un moteur d’execution charge de fournir un ensemble de services aux federes. Chaque feder peut publier (produire) une variable pour envoyer les donnees et souscrire (consommer) a une variable pour re eter certaines informations, sans avoir aucune connaissance des autres federes (tout echange entre federes passent obligatoirement par le RTI), comme l’illustre la Figure 2.1.
Figure 2.1: RTI et Federes d’une simulation HLA
Le standard HLA est constitue de 4 elements :
{ Les regles (HLA-Rules) de nissent les responsabilites des federes et de la federation,
{ le modele objet (HLA-OMT pour Object Management Template) fournit une standardi-sation de la documentation du modele objet HLA,
{ les speci cations de l’interface de programmation (HLA-IS pour Interface Speci cation) (API) permettent de programmer des applications de haut niveau,
{ le FEDEP (Federation Development and Execution Process) o re un certain nombre de recommandations pour la conception de federations HLA [69].

Les regles HLA

Les regles [64] sont des principes et des conventions qui doivent ^etre respectees pour per-mettre les interactions entre les federes au cours de l’execution de la federation. Ils expriment des concepts et des contraintes pour la conformite du standard HLA. Le standard speci e 10 regles : 5 pour les federes et 5 pour la federation. Les cinq regles concernant la federation sont :
1. Respect du formalisme OMT de HLA pour decrire les federations : les federations au- ront, obligatoirement, un modele objet (FOM : Federation Object Model), document conformement a l’OMT.
2. Representation des objets au niveau des federes et non de la RTI : toutes les representa-tions d’objets, decrites dans le FOM du modele OMT, doivent se trouver au niveau des federes, et non au niveau du moteur d’execution (RTI).
3. Passage par la RTI pour les echanges de donnees publiques entre les federes : Au cours d’une simulation (Federation Execution) au sein d’une federation, tous les echanges de donnees gurant dans la FOM et agissant entre federes devront s’e ectuer via la RTI.
4. Respect de la speci cation d’interface pour l’utilisation de la RTI : pendant l’execution d’une federation, les federes doivent s’accorder pour respecter, obligatoirement, les inter-faces de programmation (API) de HLA pour interagir avec le RTI.
5. Pendant la simulation, un attribut n’appartient qu’a un feder : pendant l’execution d’une federation, un attribut d’une instance d’objet ne sera la propriet que d’un seul feder (interdiction de l’heritage multiple).
Les cinq regles concernant les federes :
1. Obligation du respect du formalisme OMT de HLA pour decrire les federes : Comme pour la federation, les federes auront, obligatoirement, un modele objet de simulation (SOM : Simulation Object Model), document conformement a l’OMT.
2. Transparence des attributs contr^oles par un feder et capacite d’interaction : d’apres leur SOM, les federes seront capables d’envoyer et/ou de recevoir des valeurs d’attributs d’instances d’objets ainsi que d’envoyer et/ou recevoir des interactions conformement au SOM.
3. Capacite des federes a transferer et/ou a accepter le contr^ole d’attributs d’apres leur SOM : les federes seront capables de transferer ou d’accepter le contr^ole d’attributs dynamique-ment pendant l’execution de la federation, conformement au modele objet de simulation (SOM).
4. Faculte des federes a faire varier les conditions de mise a jour des attributs d’apres leur SOM : les federes seront capables de faire varier les conditions (exemple : seuil) par les-quelles ils fournissent des mises a jour pour les attributs publics des objets, conformement a leur modele objet de simulation (SOM).
5. Aptitude des federes a gerer un temps local, selon les principes decrits dans HLA : les federes seront capables de gerer un temps local de telle sorte que cela leur permette de coordonner les donnees echangees avec les autres membres d’une federation.

HLA Object Management Template (HLA-OMT)

Le modele HLA-OMT [68] speci e une structure commune standardisee pour documenter le modele objet generique de HLA (la syntaxe et le format) qui permet de de nir les federes d’une federation HLA. Ce formalisme decrit le support d’echange intervenant dans la creation de la federation. Toutefois, HLA n’est pas fortement type, il ne de nit pas des types de donnees a echanger, c’est a chaque feder de decrire ces propres objets. Le modele OMT de nit, d’une part, le descriptif d’une federation fourni par le FOM (Federation Object Model), et d’autre part le comportement des federes dans une federation est decrit par le SOM (Simulation Object Model) de chaque feder .
La Figure 2.2 presente un exemple de HLA-OMT sous forme de document XML qui nous ser-vira pour la description du tra c applicatif que nous avons utilise dans notre implementation. La classe d’objet HLA denommee VehicleSimule est decrite par 4 attributs nommes VoitureVites-seArbre, VoitureCoe DerapT, voitureFeux et voitureClignotant. Chaque attribut est caracterise, outre son nom, par un mode de transport (ici reliable) et une politique de gestion du temps (ici timestamp). A titre d’exemple, la classe d’interaction Observateur est decrite par 6 parametres (ObsTypeVue, ObsReculX, lMasqueVue, etc.). Observons d’ores et deja que les descripteurs des modes de transport et des politiques de gestion du temps decrivent l’ensemble de l’interaction et non ses parametres individuellement. Ceci constitue une premiere di erence fondamentale entre les 2 supports de communication HLA, objets et interactions. Lorsqu’un feder publie ou souscrit a une classe d’objets, il peut speci er quels attributs de la classe il desire publier ou souscrire. En revanche, un feder ne peut que publier ou souscrire a l’ensemble des parametres d’une classe d’interaction.
L’autre di erence fondamentale entre classes d’objets et classes d’interactions concerne la crea-tion d’instances de la classe. En e et, pour toute classe d’objets, un feder doit creer des instances de la classe, conformement a tout langage objet, alors que la creation d’instances de classes d’interactions est impossible. La creation d’instances de classes d’objets est assuree par des services de l’interface de programmation, qui devront ^etre invoques par le feder . Ces 2 di erences, entre les classes d’objets et les classes d’interactions, sont justi ees par les cas d’utilisation de l’un ou de l’autre en tant que support de communication. Sur ce point, les speci cations HLA ne fournissent que les recommandations suivantes : les objets sont utilises pour echanger des informations persistantes, alors que les interactions sont utilisees pour echanger des informations fugaces.
Les modes de transport disponibles sont non able (best-e ort) et able (reliable). Le mode able permet de garantir, pour l’attribut concerne, que chaque valeur envoyee sera recue (ty-piquement il utilise le protocole TCP). En revanche, le mode non able, s’il est plus rapide, ne veri e pas qu’une valeur envoyee a ete recue (typiquement il utilise le protocole UDP). Les politiques de gestion du temps disponibles sont a estampille temporelle (note dans la Figure 2.2 timestamp) et selon l’ordre de reception (receive order). Le mode timestamp indique que la valeur de l’attribut concern pourra ^etre associee (sous certaines conditions) a une estampille de temps. Cette estampille de temps est utilisee dans les simulations a temps coordonne par les messages horodates, appeles messages TSO (TimeStamp Ordered). Le mode receive-order in-dique qu’il sera impossible d’associer une estampille de temps a la valeur de l’attribut concern . L’absence d’estampilles de temps pour les valeurs d’attributs correspond aux messages non horodates, les messages RO (Receive Order) sont utilises dans les simulations evenementielles.
Federation Object Model (FOM) : le FOM d’une federation permet de speci er un contrat d’echange de toutes les informations pouvant ^etre echangees au cours de l’execution d’une federation. On decrit donc l’ensemble des classes d’objet avec leurs attributs, ainsi que l’ensemble des classes d’interactions, avec leurs parametres pouvant ^etre echanges durant l’execution de la federation. L’objectif est de fournir une speci cation d’echange de donnees publiques entre federes, passant par :
{ une enumeration de toutes les classes d’objets participant a une federation, { une description d’attributs de ces classes d’objets,
{ une description des interactions entre classes,
{ une speci cation des parametres des interactions.
Simulation Object Model (SOM) :
Le SOM d’un feder decrit les classes d’objets et les classes d’interactions qu’un feder pourra publier et/ou souscrire, c’est-a-dire les donnees qu’un feder va produire pour le reste de la federation et celles qu’il va consommer. C’est une speci cation complete d’un feder qui pourrait fournir de la matiere a une federation en declarant les objets, leurs attributs, leurs associations et leurs interactions. La construction d’un FOM s’appuie sur l’integration des parties des SOMs des federes participant a la federation. En e et, ecrire un SOM ou un FOM consiste a renseigner les composants de l’OMT, qui sont un ensemble de tables, les principales etant la table d’identi cation et les tables liees aux donnees echangees.
HLA impose que les composants (classes d’objets et leurs attributs, classes d’interactions et leurs parametres) soient documentes sous forme des tableaux permettant d’implementer l’application de simulation. Ces tableaux sont organises de la maniere suivante :
{ le tableau d’identi cation modele objet de nit les caracteristiques d’une application de simulation sous HLA,
{ le tableau structure classes d’objets decrit les classes d’objets, leurs sous-classes dans une simulation ou une federation,
{ le tableau structure classes d’interactions decrit les classes d’interactions, leurs sous-classes dans une simulation ou une federation,
{ le tableau attributs speci e les caracteristiques des attributs d’objets dans une simulation ou une federation,
{ le tableau parametres speci e les caracteristiques des parametres d’interactions dans une simulation ou une federation,
{ le tableau de l’espace de routage speci e une zone d’echange protegee pour les attributs d’objets et d’interactions dans une federation.
Nous decrivons en details dans le prochain chapitre, les tables d’attributs et des interactions qui serviront a la caracterisation du tra c de simulation.

HLA-RTI

Rappelons que c’est RTI (Run-Time Infrastructure), implementation des speci cations de l’interface de programmation [67], qui est responsable de la gestion de la communication, en o rant les services de HLA aux federes. Le modele objets de HLA ne concerne que la commu-nication et les echanges de donnees entre federes au sein d’une federation. Ces speci cations, illustrees a la Figure 2.3, de nissent les services et les callbacks permettant a un ensemble de federes de dialoguer par echange de donnees, au sein d’une m^eme federation. Il est important de comprendre que le standard HLA ne fournit que les speci cations de ces services et en aucun cas des regles d’implementation dans un langage de programmation donne.
L’implementation des speci cations HLA est assuree par RTI, qui constitue un ensemble de pro-cessus informatiques capables d’o rir les services de nis par les speci cations a un ensemble de federes participant a une m^eme federation. Ces services sont classes en 6 familles fondamentales:
1. Gestion de la federation : traite la creation, l’initialisation, le contr^ole dynamique, la modi cation et la suppression des federations en se basant sur les documents de donnees des FOM (FDD), la facon avec laquelle les federes peuvent rejoindre ou quitter la fed – ration, la sauvegarde et la restauration des etats au cours de l’execution de l’exercice, la gestion des points de synchronisation et la destruction de la federation.
2. Gestion de declarations : regroupe les services et callbacks permettant aux federes de declarer au RTI leurs intentions de publier ou de recevoir les informations des interactions et des etats et des attributs des objets.
3. Gestion des objets : Ce service genere la plupart du tra c reseau au cours de la simu-lation. Il permet a un feder d’enregistrer et de creer les instances des objets d’une classe d’objet qu’il publie et d’^etre informe de la creation d’une instance de cette classe par un autre feder . En plus, elle permet aux federes publiant une classe d’objet de mettre a jour, supprimer et de noti er les autres federes de ces operations.
4. Gestion de temps : fournit les services permettant la con guration, la synchronisation et la modi cation des horloges de simulation. Chaque feder maintient deux horloges locales : une horloge physique utilisee pour la synchronisation entre les individus et les entites reelles et une horloge logique (temps simule) pour assure la delivrance des messages et des evenements dans le bon ordre.
5. Gestion de propriet : ces services permettent aux federes d’acquerir ou de ceder la propriet des attributs des objets aux autres participants de la simulation. Ceci facilite la creation d’un modele cooperatif d’une entit a travers de multiples h^otes et fournit les moyens de migration des objets d’un h^ote vers un autre. Un feder se depossede des proprietes sur l’objet vers RTI qui les assigne a un autre feder interess par ces proprietes ou bien a un des federes qui peut se coordonner avec le premier pour echanger ces donnees avec lui.
6. Gestion de distribution des donnees : Ce service facilite le transfert et les mises a jour entre les federes en utilisant le modele producteur-consommateur. Ce modele etend les mecanismes utilises dans le predecesseur de HLA (DIS, ALSP [46]) pour les commu-nications en multicast en fournissant un service de livraison a la demande. Les federes peuvent imposer des conditions strictes pour gouverner la distribution de leurs propres donnees ou pour interdire l’acces a certaines informations.

Fonctionnement de HLA sur les reseaux distants

L’enjeu pour permettre une simulation a grande envergure est de respecter les limites de la bande passante, du delai et de la variation du delai. Chen [26] propose une methode de groupement des simulations HLA sous une forme de pont pour interconnecter les federations. Se basant sur l’avantage que presentent les ambassadeurs des federes pour gerer la communica-tion avec ambassadeur des RTI, cette approche permet d’interconnecter les RTIs de di erentes federations distantes pour assurer l’interoperabilit et la scalabilite des simulations.
Petty et Wood [134] ont propose une passerelle externe pour supporter l’interoperabilit entre des federations HLA et DIS. Cette approche a l’avantage de ne pas necessiter des changements sur les simulations existantes et de permettre a deux protocoles di erents de communiquer entre eux. La passerelle convertit les PDUs DIS a des appels de services au niveau du RTI en utilisant les donnees de nies dans le FOM.
Dambrogio [6] decrit une approche combinant HLA et CORBA pour des applications distri-buees sur le web. Le composant central de la communication (CRC) ou se trouve le RTI est installe sur le serveur et les clients CORBA sont consideres comme des simulations. Les com-munications entre les federes sont geres par RTI via un proxy CORBA. L’inconvenient de cette solution reside dans le fait que les requ^etes et les reponses au sein de la simulation doivent passer par le bus CORBA. Cette approche ajoute des latences a la communication et exclut les communications en multicast. A n de remedier a cet inconvenient, l’architecture est orientee vers les services Web distribues. Le management des simulations se fait via un navigateur web classique et les requ^etes sont gerees par le protocole IIOP de CORBA.
Carlos O’Ryan and Douglas [103] decrivent une maniere d’implementer CORBA pour satisfaire la QoS requise pour les applications de la simulation distribuee. Ils presentent une extension a CORBA par la mise en place d’une communication distribuee via le middleware RTI-NG de DMSO. De m^eme, [132] propose d’utiliser le protocole SIP pour assurer l’interoperabilit entre des RTI di erents a n de pouvoir partager des applications de conference sous HLA sur des reseaux grandes distances.
Wentong [131] discute l’utilite de developper des federations hierarchiques pour la structuration de la simulation a grande distance. Il decrit l’utilisation d’une passerelle pour la structuration de la simulation et pour contr^oler l’acces aux donnees de la simulation. Dans ce contexte, Jung [2] presente une autre approche pour implementer des federations hierarchiques. Beno^t [17] pre-sente l’utilisation d’un pont pour la communication inter-federations.

Table des matières

1 Introduction 
1.1 Contexte
1.2 Contribution et Solutions proposées
1.3 Organisation de ces travaux
2 Les applications de simulation distribuée et leurs besoins en QoS 
2.1 Introduction
2.2 Le protocole DIS
2.2.1 Principe de conception
2.2.2 Communication
2.3 Simulation distribuée à base de HLA
2.3.1 Les règles HLA
2.3.2 HLA Object Management Template (HLA-OMT)
2.3.3 HLA-RTI
2.3.4 Fonctionnement de HLA sur les réseaux distants
2.3.5 Techniques de réduction du trac et d’optimisation de la bande passante
2.4 Simulation distribuée à base de DDS
2.4.1 Modèle de Communication
2.4.2 Spécicité de la distribution des données avec DDS
2.4.3 Conclusion sur la simulation distribuée
2.5 Gestion de la Qualité de Service
2.5.1 Métriques pour la QoS
2.5.2 Gestion de la QoS dans les réseaux locaux
2.5.3 Gestion de la QoS dans les réseaux grande distance
2.5.4 MPLS et ingénierie du trac
2.5.5 Modèles existants pour la gestion la QoS
2.5.6 Signalisation pour La QoS
2.5.7 Contr^ole par politiques
2.5.8 Intégration de COPS et SIP dans la réservation de ressources
2.5.9 Signalisation générique NSIS
2.5.10 Architecture des réseaux pour la gestion de la QoS sur Internet
2.6 Conclusion
3 Interconnexion sur des réseaux locaux 
3.1 Introduction
3.2 Le projet PlatSim
3.2.1 Description fonctionnelle
3.2.2 Description des données échangées
3.2.3 Fourniture de la QoS pour PlatSim
3.2.4 Lien entre la QoS IP et les QoS applications
3.3 Implémentation de la Simulation distribuée sur HLA
3.3.1 Définition des ux applicatifs
3.3.2 Définition des paramètres de la QoS
3.3.3 Modélisation de l’application sous HLA
3.3.4 Implémentation des mécanismes de synchronisation
3.3.5 Les interfaces de programmation
3.3.6 Conclusion sur La Simulation avec HLA
3.4 Implémentation de la Simulation distribuée basée sur DDS
3.4.1 Analyse, Spécification et caractérisation du trafic
3.4.2 Caractérisation de la communication entre l’application et le middleware
3.4.3 Caractérisation de la communication entre le middleware et le réseau
3.4.4 Implémentation du schéma de communication avec DDS
3.5 Environnement de développement et évaluations dans les réseaux locaux
3.5.1 Environnement de développement et plateforme d’évaluation
3.5.2 Evaluations des performances dans les réseaux locaux
3.6 Conclusion
4 Interconnexion sur des réseaux grande distance sans QoS 
4.1 Introduction
4.2 Interconnexion sur des réseaux grande distance sans QoS : Approche ANFIS Reckoning
4.2.1 Introduction
4.2.2 La navigation à l’estime (Dead Reckoning)
4.2.3 Qualité de service requise par les applications
4.2.4 Modèle théorique de l’approche ANFIS Reckoning
4.2.5 Impact du ANFIS Reckoning sur l’erreur d’extrapolation
4.2.6 Conclusion sur Dead Reckoning
4.3 Interconnexion par Internet Sans QoS avec DDS
4.3.1 Introduction
4.3.2 Problématique de l’interconnexion par Internet avec DDS
4.3.3 Interconnexion de Simulation Distribuée avec le pont-fédéré
4.3.4 Interconnexion de Simulation Distribuée par Proxy DDS
4.4 Conclusion
5 Interconnexion sur des réseaux grande distance à QoS 
5.1 Introduction
5.2 Couplage de SIP et DDS pour la signalisation
5.2.1 Introduction
5.2.2 Proposition de l’architecture
5.2.3 Les outils pour la gestion de la QoS
5.2.4 Mise en place de la signalisation pour gérer la QoS
5.2.5 Conclusion sur la signalisation de la QoS DDS avec SIP
5.3 Interconnexion sur des réseaux Internet multi-domaines à QoS
5.3.1 Architecture EuQoS pour la garantie de QoS
5.3.2 Interconnexion de Proxy DDS sur Internet à QoS
5.3.3 Dénition de la politique de QoS réseau pour Platsim QoS sur DDS
5.3.4 Mise en oeuvre de la QoS pour PlatSim QoS dans un réseau multidomaines à QoS
5.3.5 Conclusion sur la QoS avec EuQoS
5.4 Evaluation des solutions dans les réseaux distants sans QoS
5.4.1 Evaluation des performances en réseaux distants sans QoS
5.4.2 Evaluation de l’architecture couplant SIP et DDS
5.4.3 Evaluation des performances de PlatSim QoS à travers un réseau multidomaine à QoS
5.5 Conclusion
6 Conclusion et Perspectives 
References 

Télécharger le rapport complet