Dans cette partie, nous présentons les résultats des simulations comparatives des trois algorithmes d’assemblages de rafale précédents (GHL, MCD et hybride). Les simulations sont réalisées grâce au simulateur OMNeT++ tout en gardant la même configuration matérielle de l’expérience précédente ainsi que la même topologie. Toutes les hypothèses ont été définies avant le commencement de chaque simulation. Nous rappelons qu’une rafale ne peut être envoyée que si son paquet de contrôle lui a réservé les ressources nécessaires, sinon elle sera rejetée. Un paquet de contrôle sera rejeté s’il ne trouve aucune ressource à réserver pour sa rafale (Figure 2.14), dans ce cas, la rafale correspondante sera aussi rejetée lorsqu’elle arrive au nœud interne en question.
Figure 2.14 – Echec de réservation de longueur d’onde
Les résultats des simulations précédentes seront réutilisés pour définir la propor- tion du nombre de canaux de contrôle/nombre de canaux de données. Afin de dégager l’efficacité du mécanisme GHL proposé et ces différents impacts, nous simulerons le taux de perte, le débit de rafale et de paquet, la taille moyenne des rafales et la durée de construction des rafales.
Les simulations ont été réalisées avec les hypothèses suivantes :
• La taille maximale des rafales : 625KB ; • La taille des paquets TCP : 1250B ; • La taille minimale des rafales : 30KB ;
2.4. SIMULATIONS ET ANALYSE DES RÉSULTATS 51 • Le temps maximal d’assemblage est fixé à 0.1 ms ;
• Le compteur de temps 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 est fixé à 4 ;
• Le nombre de canaux de données est fixé à 12 ; • Pas d’utilisation de ligne de retard FDL ;
• Le protocole JET est utilisé pour la signalisation ;
• OT prend en considération nombre nœuds internes, le temps de traitement et de configuration ;
• Le mécanisme LAUC est utilisé pour l’ordonnancement ;
• Toutes les simulations effectuées ont une durée égale à 30 secondes ;
Pour chaque couple (source, destination) les taux de perte des rafales et des paquets de contrôle en fonction de la charge du réseau sont illustrés dans les Figures 2.15 et 2.16 successivement. Nous remarquons d’après les simulations réalisées que pour de faible charge (entre 100 et 300 connexions TCP) les taux de perte sont élevés lorsque la charge du réseau commence à augmenter avec le mécanisme de construction hybride alors qu’avec les mécanismes "GHL" et MCD, ces taux restent quasiment faibles. Au delà de ces charges, les pertes des rafales et paquets de contrôle restent dans une limite acceptable avec le mécanisme "GHL" tandis qu’elles sont plus élevées en utilisant les mécanisme hybride et MCD.
Le taux de perte élevé des mécanismes hybride et MCD revient généralement à l’augmentation du nombre de paquets de contrôle traités due au grand nombre de rafales générées, par conséquence le problème de disponibilité de canaux de contrôle devient majeur. Le faible taux récolté avec le mécanisme GHL est relatif au fait qu’il possède une meilleure gestion des canaux de contrôle et permet de générer un moindre nombre de rafales tout en garantissant une maximisation des trafics dans ces rafales.
Figure 2.15 – Taux de perte des rafales en fonction de la charge du réseau
Figure 2.16 – Taux de perte des paquets de contrôles en fonction de la charge du réseau
Les Figures 2.17 et 2.18 présentent le débit de rafales et celui des paquets de contrôles respectivement. Le débit représente le nombre de rafales ou paquets de contrôle envoyés chaque seconde. Depuis les simulations réalisées, nous remarquons que le GHL offre un débit de rafale plus faible que les deux mécanismes hybride et MCD du faite que les rafales construites sont de très grande taille (Figure 2.19) pendant une durée plus élevée.
2.4. SIMULATIONS ET ANALYSE DES RÉSULTATS 53 Il en résulte que moins de rafales ont été construites mais le taux de perte résultant des contentions reste inférieur à celui obtenu avec le mécanisme hybride (figure 2.15). D’une autre part, nous remarquons que le nombre de paquets de contrôle générés avec le mécanisme GHL est presque semblable au nombre de rafales générées, on en déduit que les opérations de réservations des chemins de rafales s’effectuent avec succès. En revanche, avec les deux mécanismes hybride et MCD, au-delà de 1200 connexion TCP, le nombre de paquets de contrôle généré est supérieur au nombre de rafales, ceci s’explique par une sûre utilisation des canaux de contrôle et une sous utilisation des canaux de données lorsque la charge du réseau devient plus élevée.
Figure 2.17 – Impact de la charge du réseau sur le débit de rafales
Concernant la taille moyenne des rafales construites (Figure 2.19), dans le cas du mécanisme GHL, la taille des rafales (multiple de slots de rafale) change en fonction de la charge du trafic utilisateur et tend vers une consommation maximale de slots disponibles, ceci est expliqué par le débit de rafale (Figure 2.17).
Les mécanismes hybride et MCD génèrent une légère variation de la taille des rafales. La différence majeure entre GHL et ces mécanismes réside dans leur approche de construction des rafales.
Le principes de construction des rafales avec les mécanismes hybride et MCD sont identiques et tiennent compte uniquement de la taille et de la durée de construction. Le multiplexage du trafic avec le "GHL" conduit à la construction des rafales de grande taille, tout en gardant un taux de perte très inférieur (figure 2.19). La limite fixée par le temps maximal de construction des rafales permet de limiter la taille des rafales qui pourraient engendrer un taux de perte très élevée causé par le traitement excessif des paquets de contrôle générés.
2.5. CONCLUSION 55 En évaluant la durée de construction des rafales (Figure 2.20), nous observons que le GHL offre un délai supérieur à celui des deux autres mécanismes. Malgré le délai de construction des rafales plus élevé du GHL, ce dernier reste inférieure à la durée maximal de construction d’une rafale Dmax = O,lms.
Figure 2.20 – Impact de la charge sur la durrée de construction des rafales
2.5
Conclusion
Dans ce chapitre, nous avons démontré d’une part que le choix du nombre des canaux de contrôle influence le taux de perte dans un réseau OBS. Selon la charge du réseau, un bon choix du nombre de canaux de contrôle en fonction des canaux de données est très important, d’ autre part nous avons présenter la technique de multiplexage du trafic dans des rafales divisées en slots de données dont l’objectif est de maximiser les trafics des utilisateurs dans un nombre réduit de rafales.
Le mécanisme GHL proposé de construction des rafales slottées basé sur la dispo- nibilité des canaux de contrôle a permis de réduire les pertes dues aux contentions à l’entrée des canaux de contrôle tout en réduisant les pertes. Les résultats obtenus dans toutes les simulations favorisent l’utilisation de ce mécanisme au lieu des deux autres mécanismes proposés. A la fin de construction d’une rafale, un paquet de contrôle est envoyé pour faire la réservation nécessaire, ce dernier sera mis sur l’un des canaux de contrôle disponibles, ce canal peut faire l’objet d’une congestion. Nous rappelons qu’un canal congestionné ou surchargé peut être la cause d’un paquet de contrôle non traité et par la suite le rejet de sa rafale correspondante. Dans le chapitre
suivant, nous étudions les pertes dues aux congestions dans les canaux de contrôle et proposons de rajouter au GHL une extension basé sur le traitement de congestion dans les canaux de contrôle.
C h a p i t r e 3
Mécanisme de réduction de
congestion : GHL+
Sommaire
3.1 Introduction . . . 58 3.2 Calcul et sélection des canaux . . . 59 3.3 Algorithme GHL+ . . . 61 3.4 Simulations et analyse des résultats . . . 65 3.5 Conclusion . . . 68
3.1
Introduction
Les pertes dont souffrent les réseaux OBS ne sont pas dus qu’aux contentions mais aussi aux congestions qui peuvent se générer dans les canaux de contrôles. Un canal de contrôle congestionné (surchargé) augmente le délai de traitement des paquets de contrôle. Dans le cas où ce délai dépasse l’offset-time, les rafales seront envoyées avant la réservation de la totalité de leurs chemins et seront automatiquement rejetées. Dans le chapitre précédent nous avons pu constater que le choix optimal du nombre de canaux de contrôle par rapport à la charge du trafic augmente d’une part, le taux de traitement des paquets de contrôle, et d’une autre part minimise les congestions dans les canaux de contrôle. Le mécanisme GHL de construction des rafales proposé dans le chapitre précédent permet d’offrir une remarquable réduction de perte des rafales et leurs paquets de contrôle ; cependant, ce mécanisme ne garantie aucune vérification de congestion dans les canaux de transmission. Lorsque le mécanisme de construction de rafale s’achève, le paquet de contrôle est généré et envoyé sur un canal disponible en avance pour faire les réservations de ressources nécessaires à sa rafale. Un paquet de contrôle mis sur un canal congestionné augmente la probabilité de sa perte et par conséquence la perte aussi de sa rafale.
Plusieurs études ont été réalisées pour le routage des rafales sur des canaux de données moins congestionnés. Selon [14], le perfectionnement d’une connexion est relatif au choix du canal de données, la sélection d’un chemin doit prendre en considération plusieurs contraintes telles que le débit et le taux de perte. Les auteurs de [32] ont présenté une nouvelle technique basée sur la sélection dans les canaux de données les moins concernés par la congestion afin de corriger les inconvénients de l’alternation entre différents chemins.
Afin de minimiser l’avènement des congestions au moment d’envoie des paquets de contrôle, nous proposons dans ce chapitre de renforcer le mécanisme GHL pour qu’il puisse au moment d’établissement des connexions déterminer le chemin le moins congestionné sur lequel sera transmis chaque paquet de contrôle depuis le nœud source jusqu’au nœud de destination. Afin de renforcer le mécanisme GHL en sa partie de sélection dans les canaux de contrôle, l’intitulé GHL+ portera sur deux nouvelles étapes importantes lors de son implémentation qui sont le calcul et la sélection du canal de contrôle le moins congestionné avant la transmission des paquets de contrôle. Les simulations réalisées dans ce chapitre porteront sur une comparaison entre le mécanisme GHL+ et son ancien GHL décrit dans le chapitre précédent.