Faculté des Sciences, 4 Avenue Ibn Battouta B.P. 1014 RP, Rabat – Maroc Tel +212 (0) 37 77 18 34/35/38, Fax : +212 (0) 37 77 42 61, http://www.fsr.ac.ma
N° d’ordre : 2881
THÈSE DE DOCTORAT
Présentée par
Fahd LOUKDACHE
Discipline : Informatique
Spécialité : Informatique, Réseaux, télécommunications
Titre :
Nouveau mécanisme GHL+ d’assemblage des
rafales et de réduction des pertes dans les réseaux
OBS
Soutenue le 20/06/2016
Devant le jury
Président :
Mme Souad EL BERNOUSSI Professeur d’Enseignement Supérieur (PES) à la
Faculté des Sciences, Rabat.
Examinateurs :
M. El Mamoun SOUIDI Professeur d’Enseignement Supérieur (PES) à la
Faculté des Sciences, Rabat.
M. Jalal LAASSIRI
Professeur Habilité (PH) à la Faculté des
Sciences, Kénitra.
M. Saïd EL HAJJI
Professeur d’Enseignement Supérieur (PES) à la
Faculté des Sciences, Rabat.
M. Abdellatif EL GHAZI
Professeur Assistant (PA) à l’Université
Internationale de Rabat.
Invitée :
Mme Ghizlane ORHANOU Professeur Assistant (PA) à la Faculté des
Sciences, Rabat.
Le présent travail a été réalisé au laboratoire des mathématiques, informatique et applications sous la direction de Monsieur Said EL HAJJI, Professeur d’enseignement supérieur à la faculté des sciences de Rabat.
Mes premiers remerciements vont d’abord à mon directeur de thèse, Monsieur Said EL HAJJI, qui a dirigé mes recherches et corrigé mes rapports et m’a accompagné tout au long de mon travail de re-cherche. Sa disponibilité et ses généreux secours au cours de certains de mes moments difficiles ont été d’une très grande qualité.
Je remercie Monsieur Abdellatif EL GHAZI, Professeur assistant à l’ Université Internationale de Rabat, mon co-encadrant pour le volet algorithmique, qui a aussi dirigé mes recherches et corrigé mes rapports.
J’adresse mes remerciements à Madame Souad EL BERNOUSSI, Professeur de l’ Enseignement Supérieur à la Faculté des Sciences de Rabat, pour votre acceptation d’être présidente du jury de ma soutenance. Je vous suis très reconnaissant et vous assure mes sentiments respectueux.
Mes remerciements vont également à Monsieur El Mamoun SOUIDI, Professeur de l’ Enseigne-ment Supérieur à la Faculté des Sciences de Rabat, pour votre acceptation de juger ce travail en tant que rapporteur et m’avoir fait l’honneur de participer au Jury de soutenance.
Je tiens aussi à remercier Monsieur Jalal LAASSIRI, Professeur Habilité à la Faculté des Sciences de Kénitra d’avoir accepté de faire partie des membres de jury et d’ être rapporteur dans ce travail. Je tiens à vous exprimer ma profonde reconnaissance.
ii Remerciements J’aimerais remercier Madame Ghizlane ORHANOU, Professeur assistant à l’ Université Moha-med V de m’avoir orienter pour mes simulations avec OMNeT++.
Je n’aurais pas pu finir cette thèse sans l’aide des collègues doctorants du laboratoire MIA, qui m’ ont encouragé et partagé leurs idées intéressantes avec moi, je les remercie infiniment.
J’adresse mes remerciements aux personnels administratifs qui m’ont aidé pendant la durée de mes études doctorales à l’Université Mohamed V.
Mes remerciements vont aussi à Monsieur Ahmed KOUARA, Doctorant à l’Université Ibn Tofail de Kenitra et Professeur d’anglais qui m’a aidé et corrigé mes articles. Votre cœur ancré dans les valeurs solidement humaines et votre enthousiasme qui m’ont aidé dans mon parcours méritent d’être soulignés. Mes remerciements seraient incomplets sans rajouter mes très bons amis qui m’ont solidement sou-tenu et que je les remercie infiniment.
Je dédie ce modeste travail à : A mes parents .Aucun hommage ne pourrait être à la hauteur de l’amour Dont ils ne cessent de me combler. Que dieu leurs procure la bonne santé et la longue vie. A ma chère femme Loubna FOUZI et à ceux que j’aime beaucoup qui m’ont soutenue tout au long de
ce projet.
A toute ma famille, et mes amis. A toutes les familles LOUKDACHE et ALLOUCHE. A tous ceux qui ont contribué de près ou de loin dans ce projet, je vous dis merci.
Fahd LOUKDACHE
Résumé
La technologie de fibre optique représente un grand saut dans le monde de trans-missions haut débit de données. Cette technologie qui attire une grande communauté de chercheurs a été renforcée par le multiplexage de longueur d’onde dans le but de multiplier l’efficacité du service offert.
Les réseaux à commutation optique de rafales OBS "optical burst switching" ont eu leur part de bénéfice de la technologie WDM "Wavelength-division multiplexing" du fait que les données des utilisateurs sont transférés depuis la source vers la destination sur des longueurs d’onde multipléxées. Cette transmission s’effectue en tout optique sans subir de conversion électronique ou passer par des supports de stockage.
Les réseaux OBS ont été proposés dans le but de rassembler les avantages des tech-nologies OPS "optical packet switching" et OCS "optical circuit switching" tout en surmontant leurs limites technologiques. La séparation du plan de contrôle de celui des données représente un point très fort dans ce type de réseaux. Toutefois, les pertes de données représentent l’inconvénient majeur et le centre d’attraction des nouvelles recherches dans le monde des réseaux OBS.
Plusieurs mécanismes et techniques ont été proposés afin de réduire les pertes et améliorer la qualité de service des réseaux OBS. Dans cette thèse, nous étudions l’ar-chitecture et le fonctionnement de ces réseaux et nous nous intéressons au processus d’assemblage des rafales et son impact sur les pertes. A cet effet, nous proposons le mécanisme de construction intitulé "GHL" (Abréviation des initiales de noms des publicateurs) basé d’une part sur le multiplexage du trafic dans des rafales slottées, et d’une autre part sur la disponibilité des canaux de contrôle. Le GHL est comparé aux mécanismes hybride et MCD et les résultats des simulations réalisés avec OMNeT++ démontrent que le GHL offre une réduction importante des pertes et s’impose lors de tous les expériences réalisées.
L’autre partie du travail dans cette thèse consiste en une amélioration du dit mé-canisme GHL en lui rajoutant une étape intermédiaire de sélection des canaux de contrôle les moins congestionnés, le mécanisme final que nous nommons GHL+ rap-porte d’importantes améliorations en matière de réduction des pertes par rapport au GHL et se détermine comme un mécanisme solide de construction des rafales et réduction de congestions dans les canaux de contrôle.
Mots-Clés : OBS, paquet de contrôle, rafale, GHL+, congestion, canal de contrôle.
The fiber-optic technology represents the biggest leap in the world of high data rate transmissions. This technology attracts a large community of researchers was strengthened by the multiplexing WDM wavelength in order to increase the efficiency of the service offered.
Networks optical burst switching OBS –optical burst switching- have had their share of profit of WDM technology made that the user data are transferred from the source to the destination on WDM links. This transmission takes place without suffering any optical electronic conversion or through storage media.
The OBS networks have been proposed in order to gather the benefits of packet technology OPS -optical packet switching- and OCS -optical circuit switching- while overcoming their technological limits. The separation of data from that control plan represents a strong point in this type of network. However, data losses remain the major drawback and the center of attraction of new research into the world of OBS networks.
Several mechanisms and techniques have been proposed in order to reduce losses and improve the quality of service of OBS networks. In this thesis, we studied the architecture and operation of these networks and we are interested to gusts assembly and its various impacts on the degradation of service quality. To this end, we propose a new building mechanism based in part on a multiplexing traffic bursts in slots and on the other hand the availability of control channels we call GHL mechanism (Abbreviation initials of names of publications). The new GHL is compared to the hybrid and MCD mechanisms and results of simulations performed with OMNeT ++ demonstrated that GHL offers a significant reduction of losses and wins in all results.
The second major part of the work in this thesis consists in improving the said GHL mechanism in him adding an intermediate step of selecting the least congested control channels, the final mechanism we call GHL + reported significant improvements in the reduction of losses relative to GHL and is determined as a strong mechanism construction gusts and reduction of congestion in control channels.
Keywords : OBS, control paquet, burst, GHL+, congestion, control channel.
Table des matières
Remerciements i
Dédicaces iii
Résumé iv
Abstract v
Table des figures 1
Liste des tableaux 3
Introduction Générale 4
1 Evolution des réseaux à commutation optique 7
1.1 Introduction . . . 8
1.2 Evolution des réseaux optiques vers OBS . . . 8
1.3 Architecture du réseau OBS . . . 10
1.4 Réservation et libération de longueur d’onde . . . 15
1.5 Ordonnancement des rafales . . . 19
1.6 Contention dans les réseaux OBS . . . 20
1.7 Conclusion . . . 22
2 Mécanisme de construction des rafales : GHL 23 2.1 Introduction . . . 24
2.2 Impact du plan de contrôle sur les pertes . . . 25
2.3 GHL : Mécanisme de construction des rafales . . . 39
2.4 Simulations et analyse des résultats . . . 50
2.5 Conclusion . . . 55
3 Mécanisme de réduction de congestion : GHL+ 57 3.1 Introduction . . . 58
3.2 Calcul et sélection des canaux . . . 59 vi
3.3 Algorithme GHL+ . . . 61 3.4 Simulations et analyse des résultats . . . 65 3.5 Conclusion . . . 68
Conclusion Générale 69
Bibliographie 71
Annexe A : Le simulateur OMNeT++ 78
Table des figures
1.1 Assemblage et désassemblage des rafales . . . 9
1.2 Commutation des rafales au noeud interne . . . 10
1.3 Réseau OBS . . . 10
1.4 Transmission des rafales après l’expiration de l’OT . . . 11
1.5 Architecture du nœud périphérique d’OBS . . . 12
1.6 a) Assemblage des rafales b) Désassemblage des rafales . . . 13
1.7 Architecture d’un core node . . . 14
1.8 Protocole JIT . . . 17
1.9 Protocole JET . . . 18
1.10 Echec de la réservation du chemin de la rafale . . . 20
2.1 Réseau OBS sous OMNeT++ . . . 27
2.2 Edge node sous OMNeT++ . . . 28
2.3 Core node sous OMNeT++ . . . 30
2.4 Journal d’événements de simulation d’un réseau OBS . . . 31
2.5 Nœud périphérique en simulation sous OMNeT++ . . . 32
2.6 Nœud interne en simulation sous OMNeT++ . . . 33
2.7 Offset-time implémenté . . . 34
2.8 Fenêtre de contrôle "Teknev" . . . 35
2.9 Exploration graphique des données sous OMNeT++ . . . 36
2.10 Exploration de données non permise sous OMNeT++ . . . 37
2.11 Impact du nombre de canaux de contrôle sur les pertes des rafales . . 38
2.12 Impact du nombre de canaux de contrôle sur les pertes des paquets de contrôle . . . 39
2.13 Rafale divisé en n slots . . . 40
2.14 Echec de réservation de longueur d’onde . . . 50
2.15 Taux de perte des rafales en fonction de la charge du réseau . . . 52
2.16 Taux de perte des paquets de contrôles en fonction de la charge du réseau . . . 52
2.17 Impact de la charge du réseau sur le débit de rafales . . . 53
2.18 Impact de la charge du réseau sur le débit de paquet de contrôle . . 53 1
2.19 Impact de la charge sur la taille moyenne des rafales . . . 54
2.20 Impact de la charge sur la durrée de construction des rafales . . . 55
3.1 Calcul et sélection d’un canal de contrôle . . . 62
3.2 Taux de perte des rafales en fonction de la charge du réseau . . . 66
3.3 Taux de perte des rafales en fonction de la charge du réseau . . . 66
3.4 Impact de la charge du réseau sur le débit de rafales . . . 67
3.5 Impact de la charge du réseau sur le débit de paquet de contrôle . . . 67
6 Lancement d’OMNeT++ . . . 80
7 Architecture modulaire du simulateur OMNeT++ . . . 81
8 Fichier NED en mode graphique . . . 82
9 Fichier NED en mode texte . . . 82
Liste des tableaux
1.1 Protocoles JIT et JET . . . 19
2.1 Trafics en forme de slots . . . 47
2.2 Représentation des rafales en slots . . . 47
2.3 Multiplexage des trafics dans les rafales . . . 47
2.4 Multiplexage final des trafics arrivés . . . 48
3.1 Variable de calcul de charges des canaux de contrôle . . . 60
La technologie optique a été élaborée pour donner solution au besoin en bande passante. Cette technologie adoptée par plusieurs modèles de réseau optique demeure la plus favorable en termes de transport haut débit des données.
L’apparition du multiplexage de longueur d’onde WDM "Wavelength-division multi-plexing" a résolu le problème de transport de données. La technologie WDM repose sur le multiplexage de longueur d’onde dans la même fibre optique. Une fibre est capable de transporter 768 longueurs d’onde dont chacune détient une capacité de bande passante de plus de 10 Gbps. Un système à 16 canaux de 10Gbps (soit 160 Gbit/s) par exemple permet l’acheminement de 2 000 000 conversations téléphoniques simultanément sur une seule paire de fibre optique.
Le développement des réseaux WDM a commencé avec les modèles de réseaux optiques OCS "Optical circuit switching"et OPS "Optical paquet switching". Malheureusement, à cause des limites de la technologie optique courante telles que l’absence des mémoires de stockage, un modèle intermédiaire de transport optique à commutation de rafales OBS est proposé pour corriger les limitations dans le développement des réseaux WDM.
L’apparition des réseaux OBS a tout de suite attiré l’attention des chercheurs dans le domaine du transport optique, ce qui explique l’explosion des propositions au sujet des réseaux OBS.
Les réseaux à commutation optique de rafales sont caractérisés par un plan de sépa-ration du traitement des données et celui de leurs paquets de contrôle. Un paquet de contrôle est envoyé dans un premier temps sur un canal de contrôle pour réserver les ressources de sa rafale, celle-ci le suit sur un canal de données après l’expiration du délai OT "offset-time". Cette séparation fournie une gestion flexible des réseaux et une transmission de haut débit améliorée.
Une nouvelle variation des modèles OBS est les réseaux optiques à commutation de rafales slottées. Dans ce type de réseau, les trafics arrivés aux noeuds périphériques seront rassemblés dans des slots de rafales de même taille. Ce modèle permet d’offrir plus de flexibilité pour la transmission du trafic, une meilleure utilisation de la bande passante et un taux de perte moins élevé.
Pour plus de flexibilité et afin de maximiser le trafic des utilisateurs sur une même rafale, un plan de multiplexage des trafics utilisateurs dans les rafales slotées à été
5 implémenté afin de remplacer la partie d’assemblage du mécanisme MCD proposé dans [49] basée sur un assemblage hybride. Nous nommerons dans ce travail ce nouvel mécanisme de construction de rafales le "GHL".
Dans les réseaux OBS, plusieurs mécanismes de construction des rafales peuvent être implémentés. On distingue des mécanismes basés sur la taille, d’autre basés sur le temps et des mécanismes hybrides basé sur la taille et le temps.
Dans cette thèse, le mécanisme GHL proposé a été comparé aux mécanismes de construction de rafale hybride et MCD. Les résultats obtenus durant les simulations démontrent que le GHL offre un meilleur debit de rafales et paquets de contrôle et une réduction remarquable du taux de perte.
Dans une deuxième partie de notre travail nous rajoutons au GHL une technique basée sur le calcul et la sélection des canaux les moins congestionnés dédiés au transport des paquets de contrôle. Le mécanisme GHL amélioré intitulé GHL+ offre à la fois les avantages du GHL en matière d’exploitation de la bande passante et réduit les congestions dans les canaux de contrôle.
Plus précisément :
Le Chapitre "1" présente l’évolution des technologies optiques, les réseaux optiques actuels et la nouvelle génération des réseaux optiques. Nous présentons l’architecture d’un réseau à commutation optique de rafale et celle de ces différents composants. Les mécanismes d’assemblage des rafales sont présentés dans ce chapitre ainsi que d’autres mécanismes tels que l’ordonnancement, la signalisation et la résolution de contention.
Le Chapitre "2" aborde l’objet de la problématique des mécanismes d’assemblage et leur influence sur les pertes. Nous commençons par étudier l’impact du choix du nombre de canaux de contrôles et canaux de données sur le taux de perte des rafales et paquets de contrôles. Nous présentons la technique d’assemblage du trafic dans les rafales slotées afin d’introduire le mécanisme GHL. Les études comparatives sont faites à la base du nouveau mécanisme proposé et les mécanismes de construction de rafale hybride et MCD.
Le Chapitre "3" présente la nouvelle fonctionnalité rajouté au mécanisme GHL proposé dans le deuxième chapitre. Le nouvel successeur du GHL est basé sur un algorithme de calcul et sélection des canaux de contrôle les moins congestionnés. A la base des résultats comparatives entre le GHL et le GHL+, ce dernier mécanisme minimise le taux de pertes et réduit la congestion des canaux de contrôle dans un réseau OBS.
Nous concluons notre travail en comparant les résultats obtenus des différents mécanismes proposés et proposons les perspectives des travaux futurs.
C h a p i t r e 1
Evolution des réseaux à
commutation optique
Sommaire
1.1 Introduction . . . 8
1.2 Evolution des réseaux optiques vers OBS . . . 8
1.3 Architecture du réseau OBS . . . 10
1.4 Réservation et libération de longueur d’onde . . . 15
1.5 Ordonnancement des rafales . . . 19
1.6 Contention dans les réseaux OBS . . . 20
1.7 Conclusion . . . 22
1.1
Introduction
De nos jours, plus de huit pour cent de la population mondiale accède quotidien-nement à l’internet. Le besoin de plus en plus croissant d’internet dans le commerce mondial et les entreprises impose le développement de nouvelles architectures et protocoles réseaux.
Les réseaux optiques représentent un potentiel d’échange incroyable grâce à leur tech-nologie de multiplexage de longueur d’onde WDM "wavelength-division multiplexing", cette technologie permet d’utiliser, sur une même fibre optique, plusieurs canaux de transmission différenciés les uns des autres par leurs longueurs d’onde.
Dans ce cadre, plusieurs réseaux optiques ont été adoptés tels que des réseaux à commutation de circuit optique OCS "optical circuit switching" ou ceux à commu-tation de paquets optique OPS "optical paquet switching". Cependant, à cause de leur mauvaise exploitation de la bande passante et leur immaturité matérielle, la migration vers un réseau tout-optique devient indispensable.
Le réseau à commutation optique de rafale (OBS) [6] devient désormais une technolo-gie de transmission de hauts débits de données qui peut répondre à l’exigence des applications nécessitant de grande bandes passantes.
Dans les domaines des réseaux et télécommunications, les réseaux OBS montrent clairement leurs avantages et leur capacité de faire face aux grands flux de trafics grâce à l’utilisation de la technologie WDM. Toutefois, le conception d’un réseau OBS reste encore loin de la perfection face à des problèmes de perte.
Dans ce chapitre, nous donnons une vision globale sur la naissance des réseaux à commutation optique de rafales, leur architecture et celle de leurs composantes ainsi que leurs mécanismes de fonctionnement à savoir le processus d’assemblage des rafales, la signalisation et la réservation des ressources. D’autres aperçus sur les réseaux OBS peuvent être trouvés dans [36] , [13] et [10] .
1.2
Evolution des réseaux optiques vers OBS
La naissance des réseaux à commutation optique de rafale OBS "Optical Burst Switching" est le résultat de faiblesse des commutations OCS et OPS [44] à supporter des réseaux de grande taille et à nécessiter la mise en place des équipements de stockage pour résoudre les problèmes de perte de données [35]. L’adoption d’un réseau tout-optique répond désormais aux exigences non résolues par OCS et OPS du faite que le traitement de la partie données est séparée de celui de la partie contrôle. Cette séparation permet de profiter à la fois, de la transparence du plan de données et de la capacité du traitement électronique du plan de contrôle.
1.2. EVOLUTION DES RÉSEAUX OPTIQUES VERS OBS 9 Dans les réseaux OBS, de gros paquets de données (appelés rafales ou bursts) sont assemblés moyennant un algorithme d’assemblage spécifique aux nœuds périphériques source "ingress edge node" et désassemblés au niveau des nœuds périphériques de destination "egress edge node" (Figure 1.1 [70]).
Figure 1.1 – Assemblage et désassemblage des rafales
Avant la transmission d’une rafale, un paquet de contrôle est envoyé pour lui réser-ver son chemin de transmission, celle-ci est envoyée dans le réseau après l’expiration du délai OT "offset-time" sans subir aucune conversion aux nœuds internes du réseau OBS "core node". Pendant son passage de réservation, le paquet de contrôle subit des conversions O/E/O "optoélectroniques" à chaque nœud interne du réseau par une unité de contrôle (Figure 1.2 [49]).
Figure 1.2 – Commutation des rafales au noeud interne
1.3
Architecture du réseau OBS
Un réseau OBS (Figure 1.3 [75]) est composé de nœuds périphériques et de nœuds internes connectés par des fibres optiques. Chaque lien de fibre optique est capable d’assurer de multiples transmissions grâce aux canaux de longueur d’onde en utilisant la technologie WDM.
1.3. ARCHITECTURE DU RÉSEAU OBS 11 Les nœuds périphériques "edge node" du réseau OBS sont responsables de l’as-semblage des paquets en rafales avant de les transmettre sur des longueurs d’ondes dédiées. Les nœuds internes ou de cœur "core node" sont principalement responsables du traitement des paquets de contrôle et la commutation des rafales depuis des ports d’entrées vers des ports de sorties. Les paquets de contrôle sont reçus en premier pour installer une connexion en réservant des bandes passantes et en configurant les matrices de commutation optique. Les rafales suivent ensuite leurs paquets de contrôle après l’expiration de l’OT "Offset-time" (Figure 1.4).
Figure 1.4 – Transmission des rafales après l’expiration de l’OT
Le faite de séparer un paquet de contrôle de sa rafale permet d’offrir une gestion flexible du réseau OBS. De plus, la nature dynamique des réseaux OBS permet une haute adaptabilité et extensibilité de transmissions.
Les nœuds périphériques "Edge node"
Les nœuds périphériques (Figure 1.5 [8]) se divisent en des nœuds périphériques d’entrée et des nœuds périphériques de sortie. Selon le mécanisme d’assemblage im-plémenté, les paquets reçus sont assemblés au niveau de nœuds périphériques d’entrée et désassemblés aux nœuds périphériques de sortie.
Figure 1.5 – Architecture du nœud périphérique d’OBS
Grâce à la technologie de transport WDM, on peut trouver par exemple sur une même fibre optique de différents protocoles transmis en même temps (voix, vidéo, données dans des trames IP, ...). Apres l’assemblage d’une rafale (Figure 1.6 [33]), un paquet de contrôle correspondant est généré et envoyé dans le réseau afin de réserver les ressources nécessaires pour l’acheminement de sa rafale. Le délai de décalage OT "offset-time" [45] est très important et doit être suffisant pour qu’un paquet de contrôle puisse avoir le temps nécessaire de conversion optoélectronique O/E/O et le temps de traitement à chaque nœud de cœur du réseau OBS [48]. A l’arrivée de la rafale au nœud périphérique de sortie, celle-ci sera désassemblée en paquets qui la composent pour faire servir les clients de destination.
1.3. ARCHITECTURE DU RÉSEAU OBS 13
Figure 1.6 – a) Assemblage des rafales b) Désassemblage des rafales
Le fonctionnement d’un nœud périphérique "edge node" se resume dans l’execution tâches successives suivantes :
• Réception et classement des paquets en fonction de leur destination dans un même assembleur.
• Assemblage des paquets pour former les rafales. La plupart des techniques d’assemblage des rafales utilisées sont basées sur le temps lorsque l’offest-time est définit d’une manière statique. Cette technique permet d’avoir des espaces de temps successives et uniformes entre les rafales. La technique d’assemblage peut être basée sur le seuil d’assemblage dans lequel est définit un nombre maximum des paquets pour former une rafale. Cette technique permet d’avoir des tailles fixes des rafales dans des intervalle de temps non périodiques. Le principal problème dans l’assemblage des rafales est comment choisir les va-leurs des paramètres (délai et taille) appropriés tout en réduisant la probabilité de perte dans le réseau OBS.
• Mise des rafales dans des files d’attentes. À ce moment, le paquet de contrôle relatif à chaque rafale généré est prêt à être envoyé dans le réseau.
• Choix d’une file d’attente à servir en fonction d’un algorithme d’ordonnance-ment.
• Transmission des paquets de contrôle BCP "burst control paquet" sur des canaux de contrôle disponibles.
Les nœuds internes "Core node"
Les nœuds internes (Figure 1.7 [8]) sont principalement responsables du traitement des paquets de contrôles reçus et la commutation des rafales depuis un port d’entrée vers un port de sortie. Ce traitement consiste en une conversion optoélectronique pour l’extraction de l’information de routage des rafales. Afin de compenser l’insuffi-sance de l’OT, des lignes de retard FDL peuvent être implémentées au niveau de ces nœuds afin d’éviter les contentions en retardant les rafales pour des courts délais. A l’arrivée d’une rafale au nœud interne, celle-ci sera commutée en tout-optique selon la configuration établie à la base des informations de routage.
1.4. RÉSERVATION ET LIBÉRATION DE LONGUEUR D’ONDE 15 Le fonctionnement d’un nœud interne "core node" se résume dans l’exécution des tâches successives suivantes :
• Reception puis conversion des paquets de contrôle depuis l’optique vers l’élec-tronique.
• Extraction de l’information de routage de la rafale correspondante.
• Configuration du brasseur optique (matrice de commutation).
• Reconversion du paquet de contrôle BCP depuis l’électronique vers l’optique puis l’envoyer au prochain nœud.
• Routage de la rafale depuis un port d’entrée vers un port de sortie par le brasseur optique.
Au niveau des nœuds de cœur d’un réseau OBS peuvent être mises en place des lignes de retardement ou FDLs "fiber delay link" pour faire retarder les rafales lorsqu’une contention apparait entre elles . Toutefois, ce mécanisme reste très cher à mettre en place même pour des retardements courts délais.
Les liens optiques
Dans un réseau OBS, chaque lien se compose de plusieurs longueurs d’onde qui relient les nœuds entre eux grâce à la technologie de multiplexage de longueur d’onde WDM. La capacité de bande passante de chaque longueur d’onde est mesurée en Gbps, ce qui explique la force de l’utilisation de la fibre optique en matière de transport haut débit de données.
1.4
Réservation et libération de longueur d’onde
La réservation de longueur d’onde est une technique qui permet de définir quand et comment une longueur d’onde sera réservée et allouée. Deux types de réservations des ressources pour les rafales sont à savoir, la réservation immédiate et la réservation retardée.
Dans la première réservation, les nœuds de coeur préparent les ressources néces-saires pour l’acheminement des rafales dès l’arrivée de leurs paquets de contrôle. Cette technique permet de gagner en temps de réalisation, en contrepartie, elle génère une sous utilisation des canaux de données. Dans le cas d’une réservation retardée, chaque nœud interne prend en considération une date d’arrivée de la rafale. Cette technique permet de maximiser l’utilisation des canaux de données mais reste très complexe à implémenter.
La libération des ressources est la technique qui vient après la réservation de celles-ci. Deux types de libérations des ressources sont à savoir, la libération implicite et la libération explicite. Dans la technique de libération implicite, les ressources allouées à une rafale sont libérées au moment de passage de la rafale. Cette technique présente beaucoup d’avantages du moment qu’elle permet une utilisation optimale des res-sources. Dans la technique de libération explicite, les ressources allouées aux rafales ne sont libérées qu’après la réception d’un message d’ acquittement indiquant la fin de la réservation. Cette dernière technique est très désavantageuse car elle mène à une mauvaise gestion de la bande passante. La plupart des conceptions de réseaux OBS proposées optent pour des protocoles de signalisation sans accusé de réception , par exemple JET "Just-Enough-Time" dans [13] ou JIT "Just-In-Time" dans [51]. Avant l’envoie d’une rafale, un nœud périphérique envoie un paquet de contrôle contenant les informations de routage de celle-ci. Le paquet de contrôle est transmis sur un canal séparé de celui dédié à l’envoi de sa rafale. Après l’expiration de l’offset-time, la rafale est directement envoyée sur un canal de données sans aucun accusé de réception [63].
Protocole de reservation JIT
Dans le protocole de reservation des ressources JIT [69], celles-ci sont réservées juste après le passage du paquet de contrôle (Figure 1.8 [49]).
1.4. RÉSERVATION ET LIBÉRATION DE LONGUEUR D’ONDE 17
Figure 1.8 – Protocole JIT
L’avantage avec JIT se voit dans l’élimination du stockage des rafales dans des lignes de retardement FDLs "Fiber Delay Line" en définissant un offset-lime qui prend en paramètre le temps de traitement et de configuration des paquets de contrôle à chaque nœud interne. En utilisant le protocole JIT, chaque paquet de contrôle doit parcourir les nœuds depuis la destination vers la source afin de libérer les ressources après le passage de la rafale [28]. Le protocole JIT emploie une méthode de libéra-tion explicite, c’est-à-dire qu’un paquet de contrôle doit parcourir les nœuds de la destination vers la source pour libérer les ressources après le passage de la rafale. L’inconvénient avec ce protocole de réservation apparait lorsqu’aucune ressource n’est disponible, dans ce cas le paquet de contrôle et sa rafale seront directement rejetés, ce qui par conséquence génère les pertes de données.
Protocole de reservation JET
Le protocole de signalisation JET [31] permet d’installer les chemins de transmis-sion dans lequel chaque paquet de contrôle porte l’information sur l’offset-time et la taille de sa rafale, c’est un protocole qui repose sur la réservation tardive, c’est-à-dire que la réservation des ressources commencera dès l’arrivée de la rafale (Figure 1.9 [30]). Le protocole JET est destiné à faire des réservations unidirectionnelles dont l’offset-time doit être choisit de tel sorte à ce qu’aucun mécanisme de retardement tels que les lignes de retardement FDLs ne soit obligatoire au niveau des nœuds internes.
Figure 1.9 – Protocole JET
Le paquet de contrôle est suivit de sa rafale après l’offset-time qui représente la somme des délais de traitement d’un paquet de contrôle à chaque nœud de cœur, cet offset-time devient de plus en plus réduit à chaque passage du paquet de contrôle. Généralement l’OT nécessaire pour le protocole JET dépend du nombre de sauts K de la source à la destination (nombre de nœuds parcourus), du temps de traitement du paquet de contrôle Ttraitement ainsi que du temps de configuration du commutateur
Tconf iguration [59] et peut être formulé ainsi :
OT= K*(Ttraitement + Tconf iguration)
DR = f(OT)
Le protocole JET permet d’éviter le problème du délai optique, mais à la ressem-blance avec le protocole précédent, lorsqu’aucun lien n’est disponible, la rafale ainsi que son paquet de contrôle seront immédiatement rejetés. A partir des simulations comparatives entre les protocoles de réservation, plusieurs auteurs confirment que les protocoles qui utilisent la réservation retardée permettent de bénéficier d’un faible taux de perte dans les réseaux OBS.
JIT vs JET
Le tableau suivant présente une vue générale sur les caractéristiques principales des protocoles de signalisation JIT et JET. Un protocole de signalisation peut initialiser la réservation d’une manière réversible ou irréversible entre la source et la destination. Dans le cas du protocole de signalisation JET, la réservation implicite implique que l’initialisation ne peut s’effectuer que par la source. On remarque qu’il y a une relation
1.5. ORDONNANCEMENT DES RAFALES 19 réfléchie entre le délai et le taux de perte. Les deux protocoles JIT et JET ont un faible délai de bout en bout, cependant ils présentent un taux de perte non négligeable. On ne peut que constater qu’aucun protocole n’est parfait pour assurer un faible délai de bout en bout tout en ayant un faible taux de perte.
Protocole de réservation Direction Réservation Libération Délai Pertes
JET 1 sens Implicite Implicite Petit Elevés
JIT 1 sens Explicite Explicite Petit Elevés
Table 1.1 – Protocoles JIT et JET
1.5
Ordonnancement des rafales
L’ordonnancement est un mécanisme qui se déclenche au niveau des nœuds de cœur d’un réseau OBS. Le but principal de l’ordonnancement est de transmettre les rafales sur les chemins optimaux et de réduire leur taux de perte dans les ca-naux de données lorsqu’une transmission de deux ou plusieurs rafales est prévue. L’ordonnancement repose sur la sélection des ressources afin d’offrir les longueurs d’ondes aux rafales. Lorsque le paquet de contrôle arrive au nœud de cœur, un algorithme d’ordonnancement détermine la longueur d’onde qui sera allouée à sa rafale de données. Lorsqu’aucune longueur d’onde ne peut être allouée, l’algorithme d’ordonnancement procédera au rejet de la rafale. L’implémentation d’un algorithme d’ordonnancement doit prendre en considération un ensemble de paramètres tels que la gestion et la sélection des ressources et les délais de réservations pour optimiser le temps d’ordonnancement. L’ordonnancement permet de minimiser la période du non utilisation d’une longueur d’onde après la transmission d’une rafale tout en multipliant le nombre de rafales transmises.
Plusieurs stratégies d’ordonnancement [68] [72] [27] ont été proposées pour les réseaux OBS. Dans l’algorithme d’ordonnancement LAUC "Latest Available Unscheduled Channel" ou "horizon", les paquets de contrôle contiennent l’information sur l’ offset-time et la longueur de la rafale, alors l’ordonnanceur peut prévenir le moment de disponibilité ou non disponibilité de chaque ressource pour un prochain ordonnance-ment. En effet, lorsqu’un paquet de contrôle arrive au nœud de cœur du réseau OBS, une longueur d’onde est directement programmée à être allouée à la prochaine rafale prévue ; c’est à dire que l’algorithme choisit la ressource récemment disponible au moment où la rafale correspondante arrive. Le schéma LAUC ou Horizon est pratique et permet une gestion anticipative des ressources en minimisant l’intervalle gaspillé entre le moment de réservation et l’arrivée de la rafale. Dans [68] est proposé un mé-canisme de remplissage des vides entre les réservations successives appelé LAUC-Void
Filling "LAUC-FV" dans lequel, ces vides sont utilisés pour ordonnancer une nouvelle rafale et par conséquence améliorer l’exploitation des longueurs d’onde.
1.6
Contention dans les réseaux OBS
Malgré les services avancés offerts par les réseaux OBS tels que l’exploitation de la bande passante et la transmission haute débit de données, les réseaux OBS demeurent vulnérables aux contentions. Une contention de longueur d’onde se manifeste lorsque deux ou plusieurs rafales prennent le même port de sortie sur la même longueur d’onde au même moment, c’est-à-dire que l’attribution d’un canal ne se fait pas d’une unique manière ce qui produit des éventuelles collisions. Afin de faire face à ce problème, les nœuds de cœur peuvent implémenter de différentes techniques pour éviter les contentions [5] :
1. domaine temporel : en utilisant les lignes de retardements FDLs :
Les lignes de retard FDLs peuvent avoir plusieurs rôles dans les commutateurs optiques [23]. En utilisant les lignes de retard, la rafale susceptible d’être en contention est mise en mémoire tampon pendant un court délai. Au niveau de chaque nœud interne, des FDLs peuvent être utilisées pour retarder une rafale lorsque son paquet de contrôle ne peut pas réserver la totalité de la longueur d’onde avant la transmission de celle-ci (Figure 1.10 [49]). Tel qu’il est représenté dans [40], l’implémentation des FDLs consiste à raccorder au même nœud interne les deux extrémités de la ligne de retard.
1.6. CONTENTION DANS LES RÉSEAUX OBS 21 Lorsqu’une contention se manifeste entre deux rafales, l’une sera retardée par les FDLs tandis que l’autre sera transmise vers la destination. L’inconvénient avec ce mécanisme réside dans le cas où le nombre de rafale à retarder devient très grand, à ce moment les FDLs ne sont plus pratiques.
2. domaine spectral : la résolution de contention peut être réglée en minimisant le gaspillage optique des canaux WDM moyennant la conversion de longueur d’onde. Au moment de la contention entre deux rafales, l’une des deux rafales se voit attribuer une longueur d’onde différente de celle qui lui a été attribuée au départ [43]. La capacité de conversion de longueurs d’onde d’un nœud OBS peut être complète ou partielle [18]. Dans le premier cas, il y a un convertisseur équipé pour chaque longueur d’onde sur un nœud OBS tandis que, dans le deuxième cas, le nombre de convertisseurs est moindre que la totalité des longueurs d’onde. Selon les expériences faites dans [23], lorsque la charge est élevée, la conversion de longueur d’onde peut donner de meilleurs résultats en termes de réduction de pertes en la comparant à d’autre mécanisme de résolution de contention.
3. domaine spatial : en utilisant le mécanisme de routage par déflexion. Son im-plémentation consiste en un algorithme qui choisit un canal pour router une rafale en contention. La décision est prise lors de chaque saut entre les nœuds de cœur du réseau OBS contrairement au choix des voies alternatives complètes entre la source et la destination. L’inconvénient avec cette technique survient dans le cas où la rafale prend un chemin plus long, provoquant par conséquence une augmentation du délai de bout en bout [39]. Dans [73] est démontré que le routage par déflection offre une amélioration des performances lorsque le nombre de longueurs d’onde est petit et la charge du trafic est limitée. [34] propose un routage par déflection qui adopte deux fonctionnalités pour le contrôle, d’une part pour empêcher la déflection d’une rafale à son nœud source, et d’une autre par pour décider si la rafale doit être retransmise depuis son nœud source. Les mécanismes basés sur le routage par déflexion peuvent être trouvés dans [18].
1.7
Conclusion
Dans ce chapitre, nous avons présenté un aperçu sur l’évolution des réseaux optiques. Malgré les avantages des réseaux à commutation de circuit optique "OCS" et à commutation de paquet optique "OPS", la commutation optique de rafale OBS est indispensable du fait qu’elle combine leurs avantages tout en surmontant leurs limites technologiques. Nous avons aussi donné un aperçu sur l’architecture d’un réseau "OBS", les éléments qui le composent ainsi que leurs fonctionnalités, à savoir, l’assemblage des rafales aux nœuds périphériques, la réservation des ressources pour les rafales et les mécanismes de résolution de contentions dans un réseau "OBS".
C h a p i t r e 2
Mécanisme de construction des
rafales : GHL
Sommaire
2.1 Introduction . . . 24 2.2 Impact du plan de contrôle sur les pertes . . . 25 2.3 GHL : Mécanisme de construction des rafales . . . 39 2.4 Simulations et analyse des résultats . . . 50 2.5 Conclusion . . . 55
2.1
Introduction
Les réseaux à commutation optique de rafale OBS sont capables de supporter les grandes demandes en besoin de bande passante grâce à la technologie de multiplexage de longueur d’onde WDM. Toutefois, la présence des pertes dont souffrent ces réseaux dégrade leurs performances. La réduction du taux de perte est un enjeu important dans la conception des réseaux OBS. Plusieurs techniques comme la déflexion ou la segmentation ont été proposées pour faire face, mais, ces techniques restent faibles devant de grandes charges de trafics et désavantageuses en terme de qualité de service. Dans la littérature sur les réseaux OBS, il existe deux modèles d’évaluation de la "QdS" qualité de Service, un modèle relatif [21] [19] et un modèle absolu [42]. Les tech-niques principales utilisées dans le modèle relatif sont : l’offset-time, la segmentation, l’ordonnancement des paquets de contrôle, la différentiation proportionnelle de la QdS, l’allocation des tampons et l’ordonnancement des rafales. Dans un modèle absolu, les performances d’une classe de trafic de priorité élevée sont garanties quantitativement en utilisant des seuils prédéfinis qui définissent une performance pire-cas pour chaque métrique de performance considérée. Par exemple, un mécanisme de provisionement de la QdS qui garantit que le taux de perte d’une classe de trafic donnée ne dépasse jamais 0.1 peut être classé comme étant un mécanisme de QdS absolu. En effet, avec le modèle absolu, les utilisateurs obtiennent des garanties sur les performances de leur trafic dans le cas des applications sensibles aux pertes et aux délais. Il est à noter que la métrique principale de QdS à l’intérieur du réseau OBS est la probabilité de perte des rafales puisque les rafales sont envoyées dans le réseau OBS sans passer par des mécanismes de stockage, notamment en l’absence des lignes de retardement (FDLs). Les études réalisées dans [67], [15], [24], [71] démontrent que le mécanisme d’assem-blage ainsi que la période d’assemd’assem-blage influencent le taux de perte dans un réseau OBS. Le mécanisme MCD proposé dans [49] rajoute au mécanisme traditionnel hybride de construction des rafales une condition de vérification de la disponibilité d’un canal de contrôle avant l’expiration du temps de construction alloué à une rafale. Les résultats de simulations comparatives entre le MCD et le mécanisme hybride démontrent une légère réduction du taux de perte du fait que le MCD et le mécanisme hybride traditionnel rassemble le trafic dans les rafales de la même manière.
Pour une meilleure flexibilité et exploitation de la bande passante, [57] propose une technique de multiplexage du trafic dans des rafales slotées qui permet de rappor-ter une gestion importante de données et augmenrappor-ter la qualité de service dans un réseau OBS. Dans ce cadre, nous proposons dans ce chapitre d’améliorer la tech-nique d’assemblage des rafales hybride proposée dans le MCD par une techtech-nique de multiplexage du trafic dans des rafales slotées et examiner les résultats obtenus avec ce nouveau mécanisme ‘GHL’ en le comparant aux mécanismes d’assemblage hybride et MCD. Dans un premier temps, nous commençons par l’étude de l’impact du nombre de canaux de contrôle et canaux de données afin de définir un bon choix de ces paramètres d’initialisation (*.ini du simulateur OMNeT++ [52] [11] [3] [55]),
2.2. IMPACT DU PLAN DE CONTRÔLE SUR LES PERTES 25 ensuite nous présentons la technique de multiplexage du trafic dans les rafales slotées 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 lonlon-gueurs 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 Les résultats observés (Figure 2.12) sont semblables à ceux des pertes des rafales. Le choix du nombre de canaux de contrôle impact le taux de services des paquets de contrôle. Un bon choix du nombre de canaux de contrôle est très important surtout lorsqu’il s’agit de charges très élevées pour gérer les congestions.
Figure 2.12 – Impact du nombre de canaux de contrôle sur les pertes des paquets de contrôle
2.3
GHL : Mécanisme de construction des rafales
Le mécanisme d’assemblage de rafales est considéré comme l’un des principaux fac-teurs qui permet de déterminer les performances des réseaux optiques à commutation de rafales [59]. Une rafale peut être construite moyennant plusieurs mécanismes. Cer-tains sont basés sur la taille ou sur le temps, d’autres sont basés sur la taille et le temps (mécanismes hybrides). Dans le mécanisme hybride, une taille minimale et un délai maximal d’assemblage sont fixés pour en décider de la fin de construction d’une rafale. Lorsque l’un des deux paramètres est atteint, la rafale est directement envoyée dans le réseau selon un mécanisme d’ordonnancement et après l’expiration de l’offset-time [44]. La taille des rafales demeure un argument très important qui conduit à minimiser ou maximiser les contentions dans un réseau OBS. Une taille maximale des rafales peut affecter les performances du réseau. En effet, plus la taille maximale d’une rafale est grande, plus le nombre de segments TCP contenus dans celle-ci est élevé. Lorsqu’une rafale contient des segments arrivant de plusieurs sources TCP ; la perte de cette rafale va affecter grandement le débit TCP généré, et par conséquence les performances du réseau. L’effet de la variation de la taille dans [50] a montré que l’augmentation de la taille des rafales peut impacter positivement le débit TCP généré. Les simulations
faites dans ce travail se sont basées sur deux valeurs de probabilité de perte de rafales :
• augmentation de la taille maximale de rafale a pour effet l’augmentation du délai de bout-en-bout des paquets. Les résultats montrent que le débit TCP n’en est pas affecté, vu qu’il n’y a pas de pertes de rafales (Tous les paquets émis sont reçus).
• la perte des paquets a pour effet la réduction du débit TCP total. Pour une faible probabilité de perte de paquets, l’augmentation de la taille maximale de rafale accroît considérablement le débit TCP. Cependant, pour une probabilité de perte élevée, l’augmentation de la taille maximale des rafales n’a pas de grands effets sur l’augmentation du débit TCP.
Les études réalisées dans [49] démontrent que le mécanisme MCD proposé a rap-porté une réduction de perte par rapport au mécanisme hybride dans le réseau OBS. Toutefois, la partie assemblage dans ce mécanisme reste traditionnelle et similaire à celle du mécanisme hybride. La réduction de perte récupérée n’est due qu’au rajout de la phase de vérification de disponibilité d’un canal de contrôle avant l’expiration du temps maximale d’assemblage ou l’atteinte de la taille maximale d’une rafale. Dans un réseau OBS, il est important dans un mécanisme d’assemblage de trouver une formule optimale pour réduire le nombre de rafales utilisées tout en maximisant le trafic dans celles-ci, c’est à dire qu’il faut trouver une solution de limitation de la quantité des rafales et répondre aux besoins de demandes d’utilisateurs en bande passante qui sont très supérieures à la capacité des rafales.
Une nouvelle variation des réseaux OBS [58] est représentée par des rafales slottées dont la plus petite unité de transport des données est l’intervalle de temps d’une rafale appelée un slot de celle-ci.
2.3. GHL : MÉCANISME DE CONSTRUCTION DES RAFALES 41 Le multiplexage de trafic dans une rafale pourrait être vu comme un classement des blocs de trafic utilisateur dans les slots de rafale disponibles. Les études réalisées dans [60] démontrent qu’il y’a une relation entre le mécanisme de construction des rafales et la qualité de service des réseaux OBS. En effet, le mécanisme d’assemblage des rafales peut causer des sanctions de délai sur les flux TCP. Les segments TCP reçus au niveau du nœud périphérique d’entrée doivent attendre l’expiration du temps d’agrégation de rafale avant leurs transmissions. Ce délai rajouté peut causer une diminution du débit TCP généré.
Les réseaux OBS à rafales slottées opèrent de la même manière que les OBS tradition-nels. Le plan de contrôle et celui des données sont séparés, les paquets de contrôle sont envoyés sur des canaux de contrôle dédiés pour effectuer les réservations des ressource de leurs rafales correspondantes, après l’expiration de l’Offset-time, les rafales sont transmise à leur tour sans subir de conversion ou traitement depuis le nœud source au nœud de destination. Les études réalisées dans [57] démontrent que ce modèle de réseau OBS peut offrir plus de flexibilité de transmission et une meilleure exploitation de la bande passante d’une rafale. Plusieurs algorithmes d’assemblage des rafales sont proposés dans [41] [61]. Selon les auteurs de [22], les mécanismes d’assemblage peuvent être classées en :
• mécanisme basé sur le temps : cette stratégie définit un seuil de temps pour la composition de la rafale. Le nœud périphérique assemble tous les paquets reçus pendant une période d’assemblage fixe, ayant la même destination, dans une même rafale. La construction de la rafale se termine à la fin de cette période fixe. Ce mécanisme est utile pour le trafic à temps réel exigeant une qualité de service en termes de délais [26].
• mécanisme basé sur la taille : ce mécanisme utilise des seuils de taille d’une rafale en prenant en considération la quantité de données ou le nombre de paquets dans la rafale [66].
• mécanisme hybride : ce mécanisme profite des avantages des deux stratégies précédentes, à savoir, le seuil du temps et le seuil de la taille pour en décider de la fin de construction d’une rafale [12] [74].
