Les travaux présentés dans cette section concernent les co-simulations qui ont pour objectif
d’intégrer des simulateurs IP séquentiels existants, et qui ne sont généralement pas prévus pour
communiquer avec d’autres simulateurs. Les nouvelles problématiques soulevées relèvent par
conséquent principalement de différentes formes d’hétérogénéité rencontrées, à intégrer ensemble
(e.g. au niveau de la représentation du temps et des paquets IP, de la dynamique, etc).
D’autres travaux de la même nature nature sont listés dans l’AnnexeA.3.
3.4.1 Dynamic Simulation Backplane
Le Dynamic Simulation Backplane [Riley et al., 1999, Riley et al., 2001a] (DSB) est une
plateforme de co-simulation qui a pour vocation de permettre à n’importe quel simulateur de
réseau IP d’échanger des paquets IP simulés avec d’autres simulateurs de réseau IP.
La plateforme utilise le principe de la fédération avec un RTI, en se reposant sur les
spécifi-cations propres à HLA (cf. Section2.5.3). Chacun des simulateurs participant à la co-simulation
est considéré comme un fédéré, et doit disposer à ce titre d’un connecteur logiciel approprié
pour rejoindre la fédération. Les simulateurs sont synchronisés grâce à un algorithme de type
conservatif (cf. Section2.4.4).
Durant la simulation, le DSB a pour charge de résoudre les problèmes de représentation des
paquets IP simulés, qui peuvent différer d’un simulateur à l’autre. Ainsi, lorsqu’un simulateur
souhaite transmettre un paquet IP à un autre simulateur, il le confie au DSB qui se charge de le
convertir dans un format universel grâce au connecteur. Le paquet IP sera de nouveau converti
dans le format spécifique du simulateur distant, lorsque le DSB lui transmettra.
Le DSB a également pour vocation de gérer l’absence de certaines fonctionnalités d’un
si-mulateur à l’autre. Ainsi, si un sisi-mulateur transmet un paquet IP avec du HTTP (protocole
applicatif pour le web) dans la partie applicative mais que le simulateur distant ne dispose pas
d’implémentation de ce protocole, la partie concernant HTTP sera considérée soit commerebus
soit comme baggage. Dans le premier cas, le simulateur qui reçoit le paquet aura le droit de
simplement ignorer la partie HTTP quand il transcrira le paquet fourni par le DSB dans son
propre format de représentation. Dans le second cas, le simulateur devra considérer qu’il s’agit
de données binaires, et qu’elle doivent être transportées dans le paquet, sans pour autant avoir
à en comprendre la signification.
Les données inconnues sont considérées comme pouvant être mises au rebus ou comme devant
nécessairement être transportées, par le simulateur qui a transmis le paquet comportant ces
données. Le DSB a connaissance de cette information grâce à une phase d’initialisation de la
co-simulation. Avant le démarrage de celle-ci, chaque simulateur a pour charge de communiquer au
DSB la liste de tous les protocoles et les données associées qu’il supporte (cf. exemple illustré par
la Figure3.2). Pour chaque protocole et chaque donnée, il doit préciser s’ils sont optionnels ou
indispensables. Cette première étape permet également au DSB de détecter les incompatibilités
fortes : par exemple, si deux simulateurs sont censés communiquer entre eux, mais que l’un
indique que IPv6 est obligatoire alors que l’autre ne fourni pas ce protocole dans sa liste, le DSB
refuse de démarrer la co-simulation.
Les premiers tests ont été réalisés en utilisant une version modifiée de PDNS, qui permet
de distribuer le simulateur NS-2. Cette version modifiée utilise le DSB pour faire communiquer
et synchroniser les instances de NS-2. En comparant les temps d’exécution et les résultats pour
l’exécution d’un même modèle avec et sans utilisation du DSB dans PDNS, les auteurs ont
déterminé que l’utilisation du DSB ne modifiait pas les résultats de simulation et que son impact
sur les temps d’exécution était négligeable. Une autre preuve de concept illustre l’interconnexion
Figure 3.2 – Exemple de protocoles et de données associées pour deux simulateurs différents
(source : [Riley et al., 2001a]).
réussie de NS-2 avec GloMoSim.
Un second travail [Xu et al., 2001] propose une utilisation légèrement différente du DSB.
Plutôt que de considérer que les paquets sont transmis entre les simulateurs à leur niveau le plus
bas (c’est à dire que l’intégralité du paquet est transmis, de la couche physique à la couche
appli-cative), les échanges peuvent avoir lieu entre deux couches de suite Internet qui sont adjacentes
(cf. Section3.2.2). Ainsi, par exemple, NS-2 peut être utilisé pour simuler les couches transport
et application, tandis que GloMoSim peut être utilisé pour simuler les couches inférieures. Cette
nouvelle possibilité permet d’utiliser le simulateur le plus approprié pour chaque couche d’un
même paquet.
Le DSB fournit déjà tous les outils nécessaires pour connecter les simulateurs de cette façon.
Le problème spécifique qui se pose dans cette situation concerne le lookahead (cf. Section5.4.3),
utilisé dans le cadre de l’algorithme de synchronisation conservatif utilisé par le DSB. Dans le cas
où un simulateur se contente de générer les entêtes liés à une couche spécifique pour les fournir à
un autre simulateur, le lookahead devient potentiellement nul, parce que le temps nécessaire pour
générer ces données dans le système est lui-même considéré comme nul. Ainsi, la contribution
de ce travail complémentaire est principalement de considérer qu’un simulateur (maître) peut
être directement dépendant d’un autre simulateur (esclave) pour une tâche donnée : le maître
est celui qui est connu du DSB comme faisant partie de la co-simulation et l’esclave se contente
de communiquer avec son maître, de façon purement séquentielle.
Les travaux gravitant autour du DSB ne précisent pas comment les simulateurs ont été
intégrés à la fédération. Les auteurs précisent qu’ils souhaitent à terme intégrer le simulateur
commercial OpNet [Chang, 1999], mais que l’absence de code-source disponible complique son
intégration.
3.4.2 Maya
Maya est une plateforme de co-simulation qui a pour objectif d’intégrer des simulateurs
de réseaux IP qui utilisent des formalismes hétérogènes, tout en prenant en considération des
contraintes liées au temps réel.
Ainsi, comme illustré dans la Figure3.3, Maya est capable de simuler un réseau IP complet, en
représentant un tronçon de sa topologie avec Qualnet (événements discrets) et un autre tronçon
avec un modèle basé sur des flux de fluides (équationnel). Cette simulation est également reliée
à des interfaces réseau réelles, avec lesquelles les simulateurs doivent échanger des paquets IP.
Figure3.3 – Exemple de multi-modèle hybride exécuté par Maya (source : [Zhou et al., 2003]).
La synchronisation utilise un algorithme de type conservatif (cf. Section 2.4.4), avec une
fédération et un RTI, à l’instar de HLA (cf. Section 2.5.3). Les paquets IP échangés entre les
différents composants sont convertis d’un format à l’autre de façon similaire au DSB de Riley, qui
est cité en référence. L’architecture de Maya (cf. Figure3.4) intègre également un ordonnanceur
interne et un collecteur de statistiques, principalement utilisés pour l’intégration du modèle
équationnel.
Figure 3.4 – Architecture de la plateforme Maya (source : [Zhou et al., 2003]).
Lorsqu’un paquet IP est à destination du tronçon de réseau représenté par le modèle
équation-nel, les informations liées à ce paquets sont fournies au collecteur de statistiques. Des événements
demandant l’exécution du solveur permettant de résoudre le modèle équationnel sont
régulière-ment ajoutés à l’ordonnanceur interne. Lorsque ceux-ci se déclenchent, les statistiques de flux
de trafic calculées par le collecteur sont fournies en données d’entrée au modèle équationnel,
juste avant son exécution. Une fois l’exécution terminée, un temps de transmission des paquets
est récupéré dans les ports de sorties du modèle, et stocké dans le collecteur de statistiques. Ce
temps est utilisé pour simuler la transmission des paquets IP qui sont censés traverser la partie
du réseau représentée par le modèle équationnel.
Les contraintes pour intégrer Qualnet à la fédération de Maya ne sont pas évoquées dans les
travaux.
3.4.3 NS-3 / Manifold
Les travaux de [Stoffers and Riley, 2012] s’intéressent à l’interconnexion entre NS-3 et le
simulateur d’architecture informatique Manifold. Les deux simulateurs sont intégrés à une même
co-simulation, de façon à pouvoir utiliser les modèles de NS-3 pour simuler les couches logicielles
des paquets IP, et Manifold pour pouvoir simuler des algorithmes complexes de gestion des files
d’attente.
Le couplage entre les deux simulateurs ne repose pas sur une plateforme de co-simulation
existante, et les choix sont spécifiques aux deux simulateurs choisis. Ainsi, le choix de MPI
pour faire communiquer les simulateurs entre eux vient principalement du fait que les deux
simulateurs intègrent déjà des fonctionnalités de ce protocole. Comme illustré dans la Figure3.5,
des wrappeurs sont ajoutés pour chacun des simulateurs, avec des interfaces permettant à chacun
d’entre eux de pouvoir connaître le temps du prochain événement de l’autre simulateur, et
d’en récupérer le paquet éventuellement associé. Les fonctionnalités natives de MPI pour la
synchronisation du temps n’ont pas pu être utilisées, parce que les structures utilisées par les
deux simulateurs pour représenter le temps sont différentes. Le protocole de synchronisation a
donc été réimplémenté, sans être documenté dans la publication.
Figure3.5 – Composants principaux utilisés pour relier NS-3 à Manifold (source : [Stoffers and
Riley, 2012]).
Le modèle réseau de Manifold a été entièrement implémenté pour l’exemple. Du côté
NS-3 comme Manifold, des connecteurs ont été ajoutés aux simulateurs et à leurs modèles (cf.
Figure 3.6). Ainsi, dans NS-3, la classe représentant la couche de liaison de données a été
sur-chargée, pour être en capacité de récupérer les paquets générés et pour pouvoir en ajouter de
nouveaux dans la file d’attente du nœud associé. Puisque Manifold n’utilise pas le contenu des
paquets dans son modèle, les auteurs ont choisi de ne transmettre que les informations utiles
des paquets à destination de Manifold. NS-3 doit alors garder une copie du paquet initialement
envoyé, pour pouvoir le retransmettre après son passage dans Manifold, ou le supprimer si ce
dernier lui indique qu’il a finalement été perdu.
Figure3.6 – Intégration de connecteurs à NS-3 et Manifold (source : [Stoffers and Riley, 2012]).
Comme dans le cas du DSB, un problème de lookahead nul intervient, puisque la génération
des paquets dans NS-3 prend un temps suffisamment négligeable pour ne pas pouvoir être
représenté sur la ligne de temps simulée. La simulation s’en trouve très fortement ralentie.
D’après les auteurs, la seule solution serait alors de simuler une partie du réseau physique dans
NS-3, pour obtenir un lookahead non-négligeable, ou de faire en sorte d’utiliser un couplage
à mémoire partagée lorsque NS-3 n’est couplé avec Manifold que pour ses fonctionnalités de
génération de paquets (solution similaire à celle proposée dans le cas du DSB).
3.5 Interconnexion de simulateurs IP avec des simulateurs d’autres
Dans le document
Intégration de modèles de réseaux IP à un multi-modèle DEVS, pour la co-simulation de systèmes cyber-physiques
(Page 70-75)