utilisée dans l’implémentation du GHL et présenter les résultats des simulations pour discuter l’impact de ce mécanisme sur les pertes dans le réseau OBS.
2.2
Impact du plan de contrôle sur les pertes
Dans un réseau OBS [62], lorsqu’un nœud périphérique source achève l’assemblage d’une rafale et désire la transmettre dans le réseau, il envoie dans un premier temps un paquet de contrôle sur un canal dédié afin de réserver les ressources nécessaires pour l’acheminement de cette rafale. L’envoie d’une rafale est précédé par l’expiration d’un temps de compensation OT "offset-time", ce délai est très important du faite qu’il doit être suffisant pour laisser assez de temps au traitement des paquets de contrôle et configuration des ports d’entrées et sorties par lesquels transitera la rafale à chaque nœud intermédiaire du réseau.
Dans un réseau OBS, une mauvaise conception du plan de contrôle peut produire une dégradation des performances. Dans un réseau mal conçu, la congestion dans les canaux de contrôle peut retarder le traitement des paquets de contrôle aux nœuds internes et par conséquence conduire à la perte des rafales.
Le délai de traitement efficace est déterminé par un retardement des paquets de contrôle en fonction de la situation de congestion et par conséquence, le traitement et la configuration de la matrice de commutation ne coïncideront pas avec l’arrivée d’une rafale à l’un des nœuds internes du réseau OBS [48].
Toutefois, lorsqu’un "offset-time" est excessivement choisi, ceci se traduira par des attentes prolongées des rafales et imposera l’utilisation des FDLs "Fiber Delay Line". Les études réalisées dans [64] et [7] traitent l’impact de la congestion dans le plan de contrôle et ses résultats sur les performances d’un réseau OBS sans aborder le problème du choix de l’OT. [29] propose un algorithme d’ordonnancement des paquets de contrôle pour corriger les délais insuffisants d’offset-time.
Lorsqu’un paquet de contrôle n’est pas traité, deux cas peuvent survenir, la congestion dans les canaux de contrôle ou la contention entre les paquets de contrôles. Un bon choix du nombre de canaux de contrôle proportionnellement aux canaux de données permet d’augmenter considérablement la qualité de service dans les réseaux OBS [48]. Afin de faire un choix optimale du couple d’initialisation (nombre de canaux de données, nombre de canaux de contrôle), nous proposons dans un premier temps d’analyser l’impact (généralement négligeable comparé à l’Offset-Time) de ce choix par rapport à des charges du réseau différentes. Les résultats récupérés serviront à estimer ces valeurs sur laquelle les prochaines simulations seront fondées à chaque initialisation.
Dans un réseau OBS, similairement aux rafales, la contention (collision) dans les canaux de contrôle se produit lorsque deux ou plusieurs paquets de contrôle accèdent à la même longueur d’onde au même moment. Ce phénomène dégrade de plus en
plus la performance proportionnellement à l’augmentation de la charge du réseau. Particulièrement, lorsque le réseau est surchargé, aucune résolution de contention ne peut être déployée sans passer par une mise en place d’un mécanisme de contrôle de congestion. Lorsqu’un paquet de contrôle envoyé dans le réseau arrive au nœud interne, il subit une conversion du domaine optique vers le domaine électronique afin d’extraire l’information de routage par l’unité de traitement et établir la matrice de commutation [65]. Entre temps, le paquet de contrôle est mis dans un tampon électronique jusqu’à sa fin de traitement. Comme n’importe quel système muni d’un tampon, la surcharge des canaux de contrôle mènera à la congestion (embouteillage) dans cette unité de traitement.
De ce faite, il est impératif d’ajuster l’OT "Offset-Time" et le rendre assez suffisant peut résoudre le problème de surcharge des canaux de contrôles sachant que pour des offset times très grands, on aura une mauvaise utilisation des canaux de contrôle et un délai élevé de données. En effet, un bon choix du nombre de canaux de contrôle et du nombre de canaux de données en fonction de la charge du trafic mène à la réduction de la congestion et fait augmenter le taux de service des paquets contrôle. Un offset time optimal permettra de laisser le temps nécessaire de traitement au paquet de contrôle avant l’envoie de sa rafale [48], dans le cas contraire la rafale sera directement envoyée après son expiration et avant même que la totalité des ressources ne soient réservées pour elle.
Les techniques d’amélioration du temps de traitement et d’ajustement de l’offset-time augmentent le traitement des paquets de contrôles, mais peuvent causer une surcharge dans les canaux de contrôles. Les travaux réalisés dans [20] et [38] adoptent des approches de contrôle de congestion basées sur la mise en place des équipements électriques. L’approche d’éviter les congestions dans les canaux de contrôle définie à cet égard dans [47] permet de prévenir dans un réseau OBS d’entrer dans la congestion avant l’envoie d’un paquet de contrôle.
Une bonne conception d’un réseau OBS doit être faite en prenant en considération des stratégies réactives pour résoudre la contention (déflexion, conversion de longueur d’onde, . . .) et des stratégies proactives pour réguler le trafic (estimation de l’OT, estimation du nombre de canaux de contrôle et de données, . . .). Nous rappelons que le problème de contention dans les canaux de contrôle est similaire à celui dans les canaux de données, c’est à dire que la contention dans un canal de contrôle survient dans le cas où deux paquets de contrôles prennent la même longueur d’onde au même moment et qu’un paquet de contrôle non traité à cause d’une contention est automatiquement rejeté.
Afin d’analyser l’influence du nombre de canaux de contrôle sur les pertes dans un réseau OBS et pour en estimer un choix pour des paramètres d’initialisation lors des prochaines expériences, nous proposons d’implémenter un modèle de réseau OBS dans le simulateur OMNeT++.
Dans le monde des simulations, plusieurs simulateurs de réseaux [2] de caractéristiques différentes peuvent être utilisés. Dans ce travail, la version académique disponible
2.2. IMPACT DU PLAN DE CONTRÔLE SUR LES PERTES 27 pour le système d’exploitation Windows XP du simulateur OMNeT ++ en sa version 4.0 a été choisi (plus de détails sur OMNeT++ sont mis en annexe). Contrairement à d’autres simulateurs, OMNeT++ n’est pas qu’un simple simulateur de réseau, c’est un simulateur à événements discrets générique avec lequel on peut surveiller le comportement d’un réseau à travers le temps. A l’arrivée des différents évènements, une interconnexion est établie entre les différents blocs fonctionnels, le fonctionnement des ces blocs est implémenté en C++, alors que les modules tels que les nœuds périphériques et liens d’interconnexions sont définis par le langage NED propre à OMNeT++ [52] [11] [3] [55].
Caractéristiques du réseau OBS implémenté sous OMNeT++
La topologie du réseau OBS proposée (Figure 2.1) est définie par dix nœuds inter- connectés entre eux par des fibres optiques dont laquelle cinq nœuds périphériques sont programmés pour assembler et désassembler les rafales et cinq nœuds de cœurs sont programmés pour le traitement des paquets de contrôle et la configuration du chemin de routage des rafales.
Figure 2.1 – Réseau OBS sous OMNeT++
La mise en place de cette topologie nécessite de programmer tout d’abord les comportements fonctionnels de bas niveau comme l’assemblage et l’ordonnancement des rafales avant de passer à la vérification du comportement du réseau OBS par le
biais des événements des simulations. La mise en œuvre de composantes du réseau OBS sous OMNeT ++ nécessite le passage par les étapes suivantes :
• Préparation des nœuds périphériques :
Les nœuds périphériques sont modélisés de telle façon à ce qu’ils agissent d’une part comme des nœuds d’entrée qui assemblent le trafic et d’une autre part comme des nœuds de sortie qui le désassemblent (Figure 2.2). Le réseau OBS proposé repose sur un transfert asynchrone, ce qui signifie que la transmission des rafales est effectuée dès qu’il est possible. Lorsqu’un nœud d’entrée reçoit les trafics, le mécanisme d’assemblage hybride est déclenché et les rafales sont mises dans des files d’attente avant d’être transmises dans le réseau. Lorsqu’une rafale ne peut pas être mise en file d’attente, elle sera automatiquement rejetée.
Figure 2.2 – Edge node sous OMNeT++
L’algorithme d’assemblage des rafales peut affecter directement les caractéristiques de celles-ci. Dans un mécanisme d’assemblage hybride, deux paramètres doivent être contrôlés : le temps d’assemblage et la taille des rafales [4].
2.2. IMPACT DU PLAN DE CONTRÔLE SUR LES PERTES 29 Algorithm 1 Assemblage Hybride
Event : IP packet Arrives if (timer not running) then {
Start Timer }
Add IP packet to burst Update burst Length
if (burst Length == Max Burst Length) then {
Send BCP
Send Burst after offset Time Reset Timer
}
Event : Timer Expires {
Send BCP
Send Burst after offset time Reset Timer
}
Au moment de la réception des rafales, le nœud désassembleur (nœud périphérique de sortie) effectue l’opération inverse en décortiquant ces rafales en paquets pour servir les utilisateurs. Le modèle du nœud proposé permet d’être étudié en fonction du trafic entrant et sortant et le mécanisme d’assemblage des rafales. L’implémen- tation du nœud périphérique actuelle peut prendre en considération les paramètres d’initialisation courants tels qu’un minuteur, taille des rafales et des paquets ou un mélange des deux. L’algorithme d’ordonnancement LAUC [53] utilisé transmettra les rafales si et seulement si la file d’attente n’est pas vide et si au moins une des longueurs d’onde dédiée au transport des données est libre.
• Préparation des nœuds de cœur :
Les nœuds de cœur sont responsables du traitement des paquets de contrôle qui sont convertis en électronique par l’unité de traitement pour configurer les commutateurs optiques "OXC". Les rafales commutent d’une fibre d’entrée vers une autre de sortie sans subir aucune conversion optoélectronique ou passer par un mécanisme de résolution de contention entre elles.
L’architecture du nœud de cœur modélisée sous le simulateur OMNeT++ est illustrée dans la (Figure 2.3).
Figure 2.3 – Core node sous OMNeT++
Dans notre modèle, nous supposons qu’il y’a toujours un convertisseur de lon- gueur d’onde disponible pour commuter entre les longueurs d’onde car dans le cas échéant, lorsqu’il n’y a pas de longueur d’onde au moment d’arrivée du paquet de contrôle, il sera rejeté et par conséquence, quand sa rafale arrive, elle sera perdue à son tour.
Mise en œuvre du réseau OBS et analyse des simulations
L’objectif de cette partie est d’étudier le comportement du réseau OBS afin d’esti- mer le nombre de canaux de contrôle et canaux de données en observant le taux de perte des rafales et paquets de contrôle pour des charges différentes. A ce stade, deux paramètres de performance ont été simulés et mesurés :
• Taux de perte des paquets de contrôle par rapport à des charges différentes. • Taux de perte des rafales par rapport aux mêmes charges.
On notera qu’il n’est pas correct de décider depuis l’étude de ces paramètres de performance que notre topologie est meilleure qu’une autre, car les technologies sont différentes et leur degré de complexité varie d’un réseau OBS à un autre.
2.2. IMPACT DU PLAN DE CONTRÔLE SUR LES PERTES 31 Toutes les simulations ont été effectuées en utilisant la même machine dotée d’un processeur Intel Core 2 Duo avec 2 Go de RAM et du système d’exploitation Windows XP SP3. Les API utilisées sont trouvées dans [1]. Grâce au simulateur OMNeT++, Nous pouvons visualiser le comportement du réseau OBS (Figure 2.4) proposé et celui de ces composants tels que les nœuds périphériques et les nœuds de cœur (Figures 2.5 et 2.6).
Figure 2.4 – Journal d’événements de simulation d’un réseau OBS
Lors des expériences, nous faisons accroitre le nombre de canaux de contrôle et décroitre celui des canaux de données pour de différentes charges de réseau.
Figure 2.5 – Nœud périphérique en simulation sous OMNeT++
Les règles de calcul de l’OT changent en fonction des mécanismes de signalisation et d’un réseau OBS à un autre. L’offset-time peut être implémenté en étant :
• fixe : dans ce cas, l’offset-time doit impérativement être supérieure ou égale à la somme totale des délais des traitements, de conversions et configurations à tous les nœuds internes depuis la source à la destination.
• statique : dans [56] est proposé un offset-time qui permet de réguler la trans- mission des rafales moyennant un mécanisme de jetons. Lorsqu’une rafale est prête à être transmise, son paquet de contrôle est automatiquement envoyé dans le réseau mais la rafale quant à elle, ne sera envoyée qu’après la reception du jeton.
• adaptatif : dans ce type de configuration, l’offset-time est implémenté de telle manière à ce qu’il soit réajusté en fonction du niveau du trafic.
2.2. IMPACT DU PLAN DE CONTRÔLE SUR LES PERTES 33
Figure 2.6 – Nœud interne en simulation sous OMNeT++
Afin d’éviter l’insuffisance de l’offset-time, nous l’avons implémenté de telle ma- nière à ce qu’il laisse le temps nécessaire de conversion et traitement à chaque nœud interne avant l’envoie d’une rafale (Figure 2.7).
La charge du réseau est formée du nombre total de connexion TCP associé à chaque nœud d’entrée et nœud de sortie. Nous considérons que le taux de perte des rafales représente le rapport du nombre de rafales perdues en fonction des rafales envoyées. Avant le démarrage de la simulation, tous les paramètres du fichier "om- netpp.ini" ont été prédéfinis.
Figure 2.7 – Offset-time implémenté
La simulation est lancée à partir de la fenêtre de contrôle (Figure 2.8) afin de visualiser tous les événements au cours de la simulation (l’assemblage des rafales, taille des rafales, l’envoie des paquets de contrôle, l’établissement des connexions, etc).
Cette fenêtre de contrôle permet d’afficher graphiquement tous les événements et le comportement du réseau OBS en temps réel et génère les données de la simulation. Lorsque les paquets de contrôle ou rafales sont envoyés sur un canal avec succès, ils sont représentés en vert, en revanche lorsqu’il s’agit d’une contention ou congestion dans un canal, ils sont représentés en rouge.
Le simulateur OMNeT++ enregistre des données qui peuvent être filtrées en chiffres tels que la durée moyenne des transmissions, le nombre de collisions, la quantité de paquets émis et reçus, etc. Ces données sont enregistrées dans le fichier d’extension "*.sca".Toutefois, avec la version académique d’OMNeT++, à chaque nouvelle simula- tion, le fichier scalaire est effacé ce qui rend impératif de faire une copie des données que nous voulons conserver.
2.2. IMPACT DU PLAN DE CONTRÔLE SUR LES PERTES 35
Figure 2.8 – Fenêtre de contrôle "Teknev"
La version académique d’OMNeT++ 4.0 permet de générer des tracés de graphe pour représenter les résultats de simulation (Figure 2.9) de chaque module. Cependant, l’inconvénient avec la version académique gratuite apparait du faite qu’elle ne permet pas de réaliser les simulations parallèles sur un même graphe de deux ou plusieurs modules ou projet différents (Figure 2.10).
Figure 2.9 – Exploration graphique des données sous OMNeT++
Afin de trouver un sens aux données récupérées depuis le simulateur et traiter leur comportement et leur qualité, nous utilisons Gnuplot pour les explorer graphiquement.
2.2. IMPACT DU PLAN DE CONTRÔLE SUR LES PERTES 37
Figure 2.10 – Exploration de données non permise sous OMNeT++
Le choix de cet outil vient du faite qu’il permet de faire des "replots" parallèles et infinis et de générer des tracés et des graphes très travaillés.
Les simulations ont été conduites avec les hypothèses suivantes :
• La taille des paquets TCP : 1250B ; • La taille maximale des rafales : 625000B ;
• Le compteur est mis à zéro à l’arrivée d’un premier paquet dans l’assembleur ; • Tous les canaux ont la même bande passante : 10Gbps ;
• Le nombre de canaux de contrôle initialisé au départ : 1 ; • Le nombre de canaux de données initialisé au départ : 20 ; • Pas d’utilisation de ligne de retard FDL ;
• Le mécanisme LAUC est utilisé pour l’ordonnancement ;
• Toutes les simulations effectuées ont une durée égale à 30 secondes ;
Lors des expériences, nous faisons accroitre le nombre de canaux de contrôle et décroitre celui des canaux de données pour de différentes charges de trafic. La charge du réseau est formée du nombre total de connexion TCP associé à chaque nœud d’entrée et nœud de sortie. Le taux de perte des rafales représente le rapport du nombre de rafales perdues en fonction des rafales envoyées. L’objectif de cette expérience est de démontrer l’impact du choix de nombre de canaux de contrôle sur le taux de perte des rafales. La (Figure 2.11) représente le taux de perte des rafales par rapport au nombre de canaux de contrôle. Les simulations ont été réalisées pour trois charges différentes : CR=10, CR =20 et CR =50, où CR représente la charge du réseau OBS.
La valeur minimale des rafales est fixée à 375 KB avec un délai maximal d’assemblage fixé à 0.1 ms. Nous remarquons une réduction du taux de perte jusqu’à la valeur NbrCC=4 (pour la charge CR=10) et NbrCC =5 (pour les charges CR=20 et CR=50). En faisant accroitre le nombre des canaux de contrôle, le taux de perte des rafales augmente en parallèle. Nous remarquons que la congestion dans les canaux de contrôle est maitrisée jusqu’à l’utilisation de 4 canaux de contrôle (pour CR=10) et 5 canaux de contrôle (pour CR=20 et CR=50). Loin de ces valeurs, le nombre de canaux des données est incapable de supporter la charge du réseau.
2.3. GHL : MÉCANISME DE CONSTRUCTION DES RAFALES 39