Les outils pour la capture, le rejeu et l’analyse des flux 113

Dans le cadre de certaines évaluations, la même expérience doit être réalisée un certain nombre de fois en changeant certains paramètres du système satellite (bande passante totale allouée, quantité de CRA, de RBDC, etc…). Pour être bien sûr que les différences que nous observons sont bien dues aux variations du système et non aux variations de certains paramètres des flux, il est donc nécessaire de rejouer exactement les mêmes flux pour chaque

114 expérience. En effet, dans le cas d’une vidéoconférence par exemple, le débit correspondant au flux vidéo peut beaucoup varier d’une session à l’autre en fonction des images à transmettre. Pour cela, nous avons du utiliser différents outils de capture, de rejeu et d’analyse de trafic que nous allons maintenant présenter.

IV.2.2.1.FLOC : un outil de capture de trafic

L’outil FLOC (FLOw Capturer) a été développé au LAAS et fait partie d’un ensemble de 3 logiciels appelés (FL3 (FLOC : FLOw Capturer, FLORE : FLOw REplayer, FLAN :

FLow ANalyzer) [155] permettant la capture, le rejeu et l’analyse de flux. Ce logiciel a été

conçu pour permettre de capturer à la volée, pendant une durée donnée, l’ensemble des données IPv4 ou IPv6 véhiculées par toutes les connexions provenant d’une application. Cet outil utilise les mêmes fonctionnalités que le traceur de connexion implémenté pour le QoS Agent et permet d’obtenir le nombre de connexions ouvertes, le protocole de transport associé à chaque connexion (UDP ou TCP), la date d’émission de chaque paquet capturé et la taille du paquet (charge utile du niveau transport). Ces deux dernières informations permettent d’obtenir deux fichiers contenant les informations nécessaires au rejeu de ces flux : le délai inter-paquet et la taille des paquets.

IV.2.2.2.JTG : un outil de génération, de rejeu et d’analyse de trafic

Pour la génération, le rejeu et l’analyse de trafic, nous avons choisi d’utiliser l’outil JTG (Jugi’s Traffic Generator) [156] développé par l’université d’Helsinki. Ce générateur de trafic simple et précis permet d’échanger entre un émetteur et un récepteur des flux UDP et TCP totalement configurables et notamment permet de rejouer des flux capturés à partir de deux informations obtenues grâce à l’outil FLOC : le délai inter-paquet et la taille des paquets.

JTG présente aussi l’avantage de pouvoir analyser les flux à partir des fichiers log, au format MGEN (Multi-GENerator) [157], obtenus au niveau du récepteur et de tracer les courbes correspondantes à différentes caractéristiques du flux : la gigue, le délai, la variation du délai inter-paquet ainsi que les pertes. Ces courbes sont réalisées en utilisant l’outil jtg_calc de jtg puis gnuplot. C’est principalement pour ces raisons que nous avons choisi cet outil plutôt que les parties FLORE et FLAN de Fl3.

Dans le cadre de nos expériences, nous avons dû effectuer certaines modifications sur cet outil :

• Pour permettre la gestion de flux IPv6, il existe une version JTG6 mais cette dernière ne fonctionne que sous certains systèmes d’exploitation n’incluant pas Fedora Core. Il a donc fallu modifier le code source pour ajouter cette fonctionnalité.

• Nous avons aussi ajouté la possibilité d’analyser et de tracer la courbe du débit correspondant à un flux. Plusieurs méthodes de calcul de débit ont ainsi été ajoutées. • Enfin, dans le cadre de nos expériences sur Mobile IPv6, nous avons modifié le code

source pour que le flux généré par un terminal mobile puisse continuer pendant et après un changement de réseau sans s’interrompre.

Il est important de noter que pour obtenir des résultats concluants, il est indispensable de synchroniser temporellement l’émetteur et le récepteur concerné. Pour cela, nous avons utilisé

115 la synchronisation NTP en utilisant un modèle hiérarchique. Sur la Figure 41, l’émulateur satellite sert de référence temporelle surlaquelle se synchronisent les STs et GW. De même, les clients se synchronisent sur leur ST/GW respectif, ce qui nous permet d’obtenir une précision inférieure à la milliseconde sur un réseau LAN et de l’ordre de quelques millisecondes sur un réseau WLAN.

IV.2.2.3.ORENETA

Dans le cadre des expériences correspondant aux évaluations de QoS ou de Mobile IPv6 et de ses extensions, il est possible de réaliser les tests en rejouant les différents flux mais dans le cas de la mobilité SIP, pour tester les performances de notre architecture, il nous faut utiliser les logiciels SIP puisque ce sont eux qui initient les mécanismes de mobilité et de QoS et qui permettent donc aux flux de reprendre depuis le nouveau réseau.

Cependant, pour pouvoir comparer la mobilité SIP à Mobile IPv6, il est nécessaire de pouvoir obtenir des fichiers log permettant d’analyser les flux et de tracer les mêmes courbes que celles obtenues avec JTG. C’est pour cette raison que nous avons choisi d’utiliser l’outil ORENETA (One way delay REal-time NETwork Analyser) [158] qui permet de capturer à la volée différents flux identifiés par leur quadruplet {port source, adresse source, port destination, adresse destination} au niveau de deux entités appelées meters et localisées au niveau de l’émetteur et du récepteur des flux que l’on cherche à étudier. Ces deux entités transmettent également à la volée les informations concernant les paquets capturés vers un serveur central appelé analyzer qui permet d’une part de visualiser en direct certaines caractéristiques concernant les flux (débit, délai, pertes, variation du délai) mais aussi de créer des fichiers log au format MGEN à la fin de la communication. Ces fichiers peuvent ensuite être analysés par JTG de la même manière que précédemment si bien sûr les différents meters sont synchronisés temporellement (pour cela, nous avons utilisé la synchronisation NTP).

Le désavantage d’un tel outil est qu’il génère lui-même du trafic pour transmettre les données concernant les paquets capturés. Pour ne pas fausser nos évaluations, il a donc fallu mettre en œuvre un réseau spécialement dédié à ce trafic. La Figure 42 résume les interactions existant entre nos différents outils de mesures.

116 Figure 42 – Interactions entre les différents outils de mesure utilisés