Nouveau mécanisme GHL+ d’assemblage des OBS Fahd LOUKDACHE

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.
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
Remerciements
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 recherche. 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’ Enseignement 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.
i
ii
Remerciements
J’aimerais remercier Madame Ghizlane ORHANOU, Professeur assistant à l’ Université Mohamed 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 soutenu et que je les remercie infiniment.
Dédicaces
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
iii
Résumé
La technologie de fibre optique représente un grand saut dans le monde de transmissions 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 technologies 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’architecture 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+ rapporte 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.
iv
Abstract
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.
v
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
1.1 Introduction . . . . . . . . . . . . . . . . . .
1.2 Evolution des réseaux optiques vers OBS . .
1.3 Architecture du réseau OBS . . . . . . . . .
1.4 Réservation et libération de longueur d’onde
1.5 Ordonnancement des rafales . . . . . . . . .
1.6 Contention dans les réseaux OBS . . . . . .
1.7 Conclusion . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
7
8
8
10
15
19
20
22
.
.
.
.
.
23
24
25
39
50
55
3 Mécanisme de réduction de congestion : GHL+
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Calcul et sélection des canaux . . . . . . . . . . . . . . . . . . . . . .
57
58
59
.
.
.
.
.
.
.
2 Mécanisme de construction des rafales : GHL
2.1 Introduction . . . . . . . . . . . . . . . . . . .
2.2 Impact du plan de contrôle sur les pertes . . .
2.3 GHL : Mécanisme de construction des rafales
2.4 Simulations et analyse des résultats . . . . . .
2.5 Conclusion . . . . . . . . . . . . . . . . . . . .
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATIÈRES
3.3
3.4
3.5
Algorithme GHL+ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulations et analyse des résultats . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
61
65
68
Conclusion Générale
69
Bibliographie
71
Annexe A : Le simulateur OMNeT++
78
Annexe B : Liste des publications
92
Table des figures
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
Assemblage et désassemblage des rafales . . . . . . . .
Commutation des rafales au noeud interne . . . . . . .
Réseau OBS . . . . . . . . . . . . . . . . . . . . . . . .
Transmission des rafales après l’expiration de l’OT . .
Architecture du nœud périphérique d’OBS . . . . . . .
a) Assemblage des rafales b) Désassemblage des rafales
Architecture d’un core node . . . . . . . . . . . . . . .
Protocole JIT . . . . . . . . . . . . . . . . . . . . . . .
Protocole JET . . . . . . . . . . . . . . . . . . . . . . .
Echec de la réservation du chemin de la rafale . . . . .
.
.
.
.
.
.
.
.
.
.
9
10
10
11
12
13
14
17
18
20
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
Réseau OBS sous OMNeT++ . . . . . . . . . . . . . . . . . . . . . .
Edge node sous OMNeT++ . . . . . . . . . . . . . . . . . . . . . . .
Core node sous OMNeT++ . . . . . . . . . . . . . . . . . . . . . . .
Journal d’événements de simulation d’un réseau OBS . . . . . . . . .
Nœud périphérique en simulation sous OMNeT++ . . . . . . . . . .
Nœud interne en simulation sous OMNeT++ . . . . . . . . . . . . .
Offset-time implémenté . . . . . . . . . . . . . . . . . . . . . . . . . .
Fenêtre de contrôle "Teknev" . . . . . . . . . . . . . . . . . . . . . . .
Exploration graphique des données sous OMNeT++ . . . . . . . . . .
Exploration de données non permise sous OMNeT++ . . . . . . . . .
Impact du nombre de canaux de contrôle sur les pertes des rafales . .
Impact du nombre de canaux de contrôle sur les pertes des paquets de
contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rafale divisé en n slots . . . . . . . . . . . . . . . . . . . . . . . . . .
Echec de réservation de longueur d’onde . . . . . . . . . . . . . . . .
Taux de perte des rafales en fonction de la charge du réseau . . . . .
Taux de perte des paquets de contrôles en fonction de la charge du
réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impact de la charge du réseau sur le débit de rafales . . . . . . . . .
Impact de la charge du réseau sur le débit de paquet de contrôle . .
27
28
30
31
32
33
34
35
36
37
38
2.13
2.14
2.15
2.16
2.17
2.18
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
40
50
52
52
53
53
2
TABLE DES FIGURES
2.19 Impact de la charge sur la taille moyenne des rafales . . . . . . . . .
2.20 Impact de la charge sur la durrée de construction des rafales . . . . .
54
55
3.1
3.2
3.3
3.4
3.5
6
7
8
9
10
62
66
66
67
67
80
81
82
82
83
Calcul et sélection d’un canal de contrôle . . . . . . . . . . . . .
Taux de perte des rafales en fonction de la charge du réseau . .
Taux de perte des rafales en fonction de la charge du réseau . .
Impact de la charge du réseau sur le débit de rafales . . . . . . .
Impact de la charge du réseau sur le débit de paquet de contrôle
Lancement d’OMNeT++ . . . . . . . . . . . . . . . . . . . . . .
Architecture modulaire du simulateur OMNeT++ . . . . . . . .
Fichier NED en mode graphique . . . . . . . . . . . . . . . . . .
Fichier NED en mode texte . . . . . . . . . . . . . . . . . . . .
Exemple de fichier ini . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Liste des tableaux
1.1
Protocoles JIT et JET . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.1
2.2
2.3
2.4
Trafics en forme de slots . . . . . . . .
Représentation des rafales en slots . . .
Multiplexage des trafics dans les rafales
Multiplexage final des trafics arrivés . .
.
.
.
.
47
47
47
48
3.1
Variable de calcul de charges des canaux de contrôle . . . . . . . . . .
60
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Introduction Générale
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 multiplexing" 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éparation 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é
4
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.
6
INTRODUCTION GENERALE
Chapitre 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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
8 CHAPITRE 1. EVOLUTION DES RÉSEAUX À COMMUTATION OPTIQUE
1.1
Introduction
De nos jours, plus de huit pour cent de la population mondiale accède quotidiennement à 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 technologie 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 à commutation 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 technologie 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éserver 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]).
10 CHAPITRE 1. EVOLUTION DES RÉSEAUX À COMMUTATION OPTIQUE
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.
Figure 1.3 – Réseau OBS
1.3. ARCHITECTURE DU RÉSEAU OBS
11
Les nœuds périphériques "edge node" du réseau OBS sont responsables de l’assemblage 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 implé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.
12 CHAPITRE 1. EVOLUTION DES RÉSEAUX À COMMUTATION OPTIQUE
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 valeurs des paramètres (délai et taille) appropriés tout en réduisant la probabilité
de perte dans le réseau OBS.
14 CHAPITRE 1. EVOLUTION DES RÉSEAUX À COMMUTATION OPTIQUE
• 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’ordonnancement.
• 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’insuffisance 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.
Figure 1.7 – Architecture d’un core node
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’électronique.
• 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.
16 CHAPITRE 1. EVOLUTION DES RÉSEAUX À COMMUTATION OPTIQUE
Dans la première réservation, les nœuds de coeur préparent les ressources nécessaires 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 ressources. 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ération 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 transmission 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.
18 CHAPITRE 1. EVOLUTION DES RÉSEAUX À COMMUTATION OPTIQUE
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 ressemblance 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
19
1.5. ORDONNANCEMENT DES RAFALES
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
JET
JIT
Direction
1 sens
1 sens
Réservation
Implicite
Explicite
Libération
Implicite
Explicite
Délai
Petit
Petit
Pertes
Elevés
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 canaux 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’ offsettime 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 ordonnancement. 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
20 CHAPITRE 1. EVOLUTION DES RÉSEAUX À COMMUTATION OPTIQUE
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.
Figure 1.10 – Echec de la réservation du chemin de la rafale
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 implé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].
22 CHAPITRE 1. EVOLUTION DES RÉSEAUX À COMMUTATION OPTIQUE
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".
Chapitre 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
23
24
2.1
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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 techniques 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’assemblage ainsi que la période d’assemblage 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 rapporter une gestion importante de données et augmenter la qualité de service dans un
réseau OBS. Dans ce cadre, nous proposons dans ce chapitre d’améliorer la technique d’assemblage des rafales hybride proposée dans le MCD par une technique
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
26
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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 interconnecté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
28
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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émentation 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.
30
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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 longueur 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’estimer 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.
32
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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 transmission 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 maniè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 "omnetpp.ini" ont été prédéfinis.
34
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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 simulation, 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).
36
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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 protocole JET est utilisé pour la signalisation ;
38
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
• 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.
Figure 2.11 – Impact du nombre de canaux de contrôle sur les pertes des rafales
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 facteurs qui permet de déterminer les performances des réseaux optiques à commutation
de rafales [59]. Une rafale peut être construite moyennant plusieurs mécanismes. Certains 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
40
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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 rapporté 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.
Figure 2.13 – Rafale divisé en n slots
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 traditionnels. 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].
42
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
Le choix d’un algorithme d’assemblage de rafale convenable permet de réduire
le taux de contentions dans les nœuds internes et conduit à une augmentation de
performances en termes du taux de pertes et qualité de service. Au niveau de chaque
nœud périphérique d’entrée, l’assemblage des trafics utilisateurs se fait en fonction de
leurs destinations. La taille maximal/minimal de la rafale une fois atteinte, celle-ci
sera prête à être envoyée dans le réseau. Lorsque la taille d’une rafale est très grande,
moins de rafales seront générées dans le réseau et par conséquence il y’aura moins de
contentions, mais en contre partie, la moyenne du nombre de paquets perdus sera plus
élevée à chaque contention car le nombre de paquets contenus dans chaque rafale sera
très élevé. D’une autre part, quand la taille d’une rafale est très petite, ceci augmente
le nombre de rafales dans le réseau et augmente par conséquence la probabilité de
contention, mais en revanche la moyenne du nombre de paquets perdus sera assez
petite. Les auteurs de [54] suggère un programme d’agrégation de trafics utilisateurs
qui ont la même nécessité en qualité de service dans une même rafale, alors que [9]
détecte que lorsque les classes de trafics sont dans une même rafale, celle ci est mieux
exécutée.
Un autre défit dans l’algorithme d’agrégation est de maximiser les trafics des utilisateurs dans une rafale. [54] présente un algorithme qui définit un seuil maximal de
rafales, une fois franchis, celle ci sera envoyée dans le réseau.
L’assemblage des rafales dans le MCD est similaire à celui du mécanisme traditionnel
hybride du fait qu’il génère des rafales de tailles différentes. Nous rappelons qu’au
moment d’une contention entre deux ou plusieurs rafales de grande taille, les pertes
de données sont très considérables. Dans le cas contraire, lorsque les rafales sont de
petites tailles, trop de paquet de contrôle se génèrent et par conséquence le phénomène
de congestion apparaît dans les canaux de contrôle.
2.3. GHL : MÉCANISME DE CONSTRUCTION DES RAFALES
Algorithm 2 MCD
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
}
if (burst Length == Min Burst Length) then
{
if (K>0) then
{
K= K-l
Send BCP
Send Burst after offset Time
Reset Timer
}
Event : OT Expires
K= K+l
}
Event : Timer Expires
{
Send BCP
Send Burst after offset time
Reset Timer
}
43
44
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
Dans ce cadre, nous proposons d’améliorer le mécanisme d’assemblage MCD, nous
modifions la formule d’assemblage en une plus optimale pour avoir un minimum de
rafales générées tout en garantissant une exploitation maximale de la bande passante.
Dans un réseau optique à commutation de rafales slottées, lorsqu’un trafic utilisateur
arrive au nœud périphérique, il sera reparti sous forme de slots de données. Deux
paramètres importants sont à considérer dans un tel type de réseau OBS, d’une part,
le nombre de slots occupés par un trafic utilisateur car il représente la quantité de
bande passante exigée, et d’ autre part, la position du trafic dans la rafale qui dépend
de sa destination [15].
Considérons que T trafic utilisateurs arrivent au nœud périphérique ou R rafales sont
prêtes à les rassembler et que chaque rafale est divisée en S slots. L’objectif est de
remplir les rafales dont la capacité de charge est limitée par les blocs de trafic arrivés
aux nœuds périphériques. Pour un problème pareil, l’utilisation d’un algorithme de
recherche de solution optimale et des méthodes approximatives peut rapporter une
réponse à notre problématique.
Les méthodes d’optimisation combinatoire selon [37] sont divisées en deux types :
• méthodes de résolution exactes tels que la méthode (Branch and Bound) [17]
qui peuvent garantir de trouver une solution optimale pour une instante de
taille finie dans un temps limité et de trouver son optimalité. Toutefois, ces
méthodes ne sont efficaces que pour les instances de problème de petite taille.
• méthodes de résolution approchées [25] qui peuvent être utilisées pour des
problèmes d’optimisation particuliers (heuristique) ou à plusieurs problèmes
d’optimisation (Méta-Heuristique) afin de trouver des solutions avec un temps
de calcule raisonnable.
Dans un réseau OBS à rafale slotées, les blocs de trafic seront mis dans un ensemble
de rafales. Cependant, l’objectif de notre travail est de minimiser le nombre de rafales
utilisées. Pour un problème pareil, des algorithmes d’optimisation peuvent donner
des solutions exactes mais avec un temps d’exécution inacceptable. Une méthode de
résolution approchée sera dans ce cas avantageuse à utiliser.
On considère dans notre cas qu’une rafale ne peut pas dépasser sa capacité de
multiplexage d’un ou plusieurs trafics entrant ayant chacun une taille et un nombre
de slots. Les trafics mis dans une rafale doivent maximiser la valeur totale des
slots disponibles, sans dépasser la capacité maximale de trafics que peut rassembler
une rafale. Afin de modéliser ce mécanisme d’assemblage, les données du problème
peuvent être reformulées en termes mathématiques. On considère que les trafics
sont numérotés par l’indice i allant de 1 à n. Les nombres wi et pi représentent
respectivement l’ensemble des blocs de trafic à multiplexer et le nombre de slots
disponibles pour le trafic numéro i. La capacité d’une rafale sera notée W.
2.3. GHL : MÉCANISME DE CONSTRUCTION DES RAFALES
45
Il existe de multiples façons pour le multiplexage du trafic dans une rafale. Au départ,
il faut indiquer pour chaque trafic s’il peut être multiplexé ou non. En utilisant une
représentation binaire, l’état de l’i-ème trafic vaudra xi =1 s’il est mis dans la rafale,
ou xi =0 s’il est laissé toujours en attente. Une façon de multiplexer les trafics dans
une rafale est donc décrite par le vecteur contenu X=(x1 , x2 , ... , xn ) ; et la taille des
trafics associé, ainsi que le nombre de slots associés à ce multiplexage, peuvent alors
être exprimés comme fonction du vecteur contenu.
Pour un contenu X donné, le nombre de slots total consommés dans une rafale
P
est : z(X) = ni=1 xi pi . De même, la somme des blocs des trafics multiplexés est :
Pn
w(X)= i=1 xi wi . Le problème peut alors être reformulé comme la recherche d’un
vecteur contenu X=(x1 , x2 , ... , xn ) (les composantes valant 0 ou 1), réalisant le
P
maximum de la fonction objectif z(X), sous la contrainte : w(X)= ni=1 xi wi tel que la
somme des tailles des trafics multiplexés ne dépasse pas la capacité d’une rafale, c’està-dire que w(X) < W. Afin d’éviter les cas singuliers, nous rajoutons les contraintes
suivantes :
Pn
i=1 wi > W : on ne peut pas multiplexer tous les trafics dans une rafale ;
wi ≤ W, ∀i ∈ {1, . . . , n} : aucun trafic n’est de taille plus que celle d’une rafale ;
pi > 0, ∀i ∈ {1, . . . , n} : tout trafic a un nombre de bloc de slot dont on retrouve au
moins un disponible ;
wi > 0, ∀i ∈ {1, . . . , n} : tout trafic a une certaine taille et consomme les slots d’une
rafale.
Pour un tel problème d’optimisation nous cherchons non seulement à trouver la
solution mais la meilleure solution de multiplexage parmi plusieurs combinaisons
possible. Un tel problème peut se résoudre avec l’utilisation d’une méthode approchée
tel que l’algorithme Avide ou Glouton. A chaque phase, on cherche à choisir un
optimum local qui convergera vers une solution optimale globale, c’est à dire que
l’algorithme Avide ne voit pas très loin, il regarde l’état actuel, lorsqu’il a une certaine
configuration, si celle-ci qui peut lui donner une solution optimal, Avide la prend
et la considère comme la solution optimale. Selon l’algorithme d’Avide, si cette
solution est localement intéressante donc forcément elle sera globalement intéressante.
L’algorithme Avide ne remet jamais en cause une décision prise auparavant, c’est-àdire que lorsqu’un trafic ne peut pas être multipléxé dans une rafale, l’algorithme
n’essaie pas d’enlever un autre trafic déjà multipléxé dans la rafale pour y mettre un
autre trafic à sa place.
Nous avons vue dans la section précédente que le choix du nombre de canaux
de contrôle influence le taux de perte, nous partons aussi du fait qu’un bon nombre
de canaux de données réduit le nombre de rafales en contention. Lorsque le nombre
minimal de slots disponibles est consommé, le mécanisme GHL vérifie la disponibilité
d’un canal de contrôle [46]. Dans le cas affirmatif, la rafale sera prête à être envoyer
après l’expiration de l’offset-time. Dans le cas où aucun canal de contrôle n’est disponible, la rafale ne sera envoyée que lorsqu’elle multipléxe les trafics utilisateurs dans
le maximum de slots disponibles.
46
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
Algorithm 3 Assemblage MCD vs Assemblage GHL
Assemblage MCD
Start Timer ;
BEGIN
while (burst Length < Max Burst Length) do
{
Add IP packet to burst
Update burst Length
}
END
Assemblage GHL
BEGIN
return (pi / wi) for each traffic i,
Sort all traffic in descending order of value (pi / wi),
Select one by one traffic in the sort order
while (burst Length < Max Burst Length) do
{
Add the selected traffic in the slot of burst.
Update burst Length
}
END
2.3. GHL : MÉCANISME DE CONSTRUCTION DES RAFALES
47
Considérons par exemple que T trafics utilisateurs arrivent au nœud périphérique
où R rafales sont prêtes à les rassembler et que chaque rafale est divisée en S slots. T
peut être formé en S slots successifs. L’ensemble de T trafics arrivés est présenté par
une matrice TxS slots. Le Tableau 2.1 illustre l’ensemble de 5 trafics formés de slots ‘
D’ sur une bande de 6 slots.
Trafics
T1
T2
T3
T4
T5
S1
D
ND
D
ND
D
S2
D
ND
D
ND
D
S3
D
D
ND
ND
ND
S4
ND
D
ND
D
ND
S5
ND
D
ND
D
ND
S6
ND
ND
ND
D
ND
Table 2.1 – Trafics en forme de slots
D’une autre part, l’ensemble de R rafales est présenté par une matrice de RxT
slots. Le Tableau 2.2 illustre l’ensemble de 4 rafales divisées en 6 slots, les slots
disponibles sont représenté par ‘D’ et ‘ND’ pour les slots non disponible.
Trafics
R1
R2
R3
R4
S1
D
D
ND
D
S2
D
D
ND
D
S3
D
D
D
D
S4
ND
D
D
D
S5
ND
D
D
ND
S6
D
D
D
ND
Table 2.2 – Représentation des rafales en slots
La matrice résultante représente le multiplexage des trafics dans les slots de rafales
disponibles Tableaux 2.3 et 2.4. Par exemple, le trafic T3 arrivé est multiplexé dans
la rafale R2.
Trafics
R1
R2
R3
R4
S1
S2
T1
S3
ND
D
D
T3
ND
T5
S4
ND
T2
D
S5
ND
T4
ND
S6
D
D
ND
Table 2.3 – Multiplexage des trafics dans les rafales
48
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
C’est à dire que :
Trafics
R1
R2
R3
R4
T1
X
T2
T3
X
X
T4
T5
X
X
Table 2.4 – Multiplexage final des trafics arrivés
2.3. GHL : MÉCANISME DE CONSTRUCTION DES RAFALES
Algorithm 4 Algorithm GHL
Event : IP packet Arrives
if (timer not running) then
{
Start Timer
Return value (pi / wi) for each traffic i
Sort all traffic in descending order of value (pi / wi)
Select one by one traffic in the sort order
}
while (burst Length < Max Burst Length) do
{
Add the selected traffic in the slot of burst
Update burst Length
}
if (burst Length == Max Burst Length) then
{
Send BCP
Send Burst after offset Time
Reset Timer.
}
if (burst Length == Min slot of Burst Length) then
{
if (K>0) then
{
K= K-l
Send BCP
Send Burst after offset Time
Reset Timer. }
Event : OT Expires
K= K+l
}
Event : Timer Expires
Send BCP
Send Burst after offset time.
Reset Timer.
49
50
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
2.4
Simulations et analyse des résultats
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 proportion 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.
52
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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
Figure 2.18 – Impact de la charge du réseau sur le débit de paquet de contrôle
54
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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.
Figure 2.19 – Impact de la charge sur la taille moyenne des rafales
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 disponibilité 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
56
CHAPITRE 2. MÉCANISME DE CONSTRUCTION DES RAFALES : GHL
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.
Chapitre 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
57
58 CHAPITRE 3. MÉCANISME DE RÉDUCTION DE CONGESTION : GHL+
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.
3.2. CALCUL ET SÉLECTION DES CANAUX
3.2
59
Calcul et sélection des canaux
Dans le cadre de l’extension du mécanisme GHL, nous proposons de lui rajouter
la fonctionnalité de sélection du canal de contrôle le moins congestionné avant la
transmission d’un paquet de contrôle. Dans sa nouvelle partie de traitement, le GHL+
opère comme n’importe quel type d’algorithme de routage adaptatif [14] visant à
satisfaire à chaque instant un ou plusieurs critères d’optimalités relativement à charge
du réseau. Le GHL+ se base d’une part sur une méthode de calcul statique des
canaux de contrôle effectuée au niveau des nœuds de cœur, et d’autre part, entre
chaque nœud périphérique et nœud interne, les informations de congestion reçues
sont utilisées pour faire la sélection dynamique d’un canal de contrôle non concerné
par la congestion.
Traitement aux nœuds internes
Au niveau des nœuds de cœur, une table C(i,j) représentant le statut de charge
des canaux de contrôle est conservée. Un seuil de congestion SM AX est fixé comme
paramètre d’initialisation pour les canaux de contrôle pour déterminer la congestion
ou non d’un canal. Le seuil de congestion SM AX est un paramètre très important et
décisif du faite qu’il détermine le seuil maximal de la charge d’un canal de contrôle.
Au moment où ce seuil est franchi, le lien sera considéré en congestion. [60] trouve que
pour de meilleures décisions, le choix de la valeur d’un seuil maximal de congestion
doit prendre en considération le niveau du trafic qui va être généré dans le réseau.
Lorsque la valeur SM AX est petite, une meilleure sélection du chemin se fera lorsqu’il
y’aura moins de paquets de contrôle générés, autrement dit lorsque le trafic dans le
réseau est faible. Néanmoins, lorsque la charge du trafic dans le réseau est grande,
une petite valeur de SM AX est non rentable, car elle va livrer des informations non
adaptées.
En revanche, une grande valeur SM AX va fournir une meilleure sélection du chemin
lorsque la charge du trafic dans le réseau est très grande. Toutefois, lorsque la charge
du trafic dans le réseau est faible et la valeur de SM AX est grande, tous les paquets
de contrôle seront envoyés sur le canal primaire considéré non congestionné et tous
les autres canaux de contrôles seront considérés en congestion, produisant dans ce
cas la congestion du canal primaire.
La charge d’un lien S(i,j) reliant le nœud "i" au nœud "j" est égale à la durée d’arrivée
de tous les paquets de contrôle à travers un lien donné.
On considère que Ts représente la durée pendant laquelle tous les paquets de contrôle
sont routés avec succès dans le temps "T" et que Td représente la durée pendant
laquelle tous les paquets de contrôle ont été supprimés durant "T", alors la charge du
lien S(i,j) est représentée par :
60 CHAPITRE 3. MÉCANISME DE RÉDUCTION DE CONGESTION : GHL+
S(i,j) = (Ts + Td ) / T
Après chaque intervalle de temps ‘T’, C(i,j) est mise à jour.
Algorithm 5 Calcul des status des liens
if (S(i,j) ≥SM AX ) then
{
C(i,j) =1
}
else
{
C(i,j) =0
}
A chaque intervalle ‘T’, les nœuds de cœur envoient les valeurs de la table C(i,j)
au nœuds périphériques sous forme de paquets de statuts. Ces paquets contiennent
des informations concernant l’état des canaux de contrôle par rapport à la congestion.
Traitement aux nœuds périphériques
Lorsque le mécanisme d’assemblage s’achève, un paquet de contrôle est généré et
prêt à être émis dans le réseau pour réserver les ressources de sa rafale. A ce stade,
le nœud périphérique source doit déterminer si le paquet de contrôle en question
sera envoyé sur le canal de contrôle primaire par défault ou sur le canal de contrôle
secondaire. Pour une période donnée T, un seul canal sera utilisé par le paquet de
contrôle.
Les informations locales sont mises à jour avant l’envoie d’un paquet de contrôle pour
faire la sélection du chemin le moins congestionné. Les variables contenues dans le
Tableau 3.1 sont utilisées pour le calcul de charges des canaux de contrôle.
Statut de charge et Chemin
CCp(s,d)
CCs(s,d)
W p(s,d)
W s(s,d)
Signification
le statut de charge du chemin primaire
le statut de charge du chemin secondaire
le chemin primaire entre la source s et la destination d
le chemin secondaire entre la source s et la destination d
Table 3.1 – Variable de calcul de charges des canaux de contrôle
61
3.3. ALGORITHME GHL+
Au niveau d’un nœud périphérique, le calcul du statut de la charge du chemin
primaire (1) et du chemin secondaire (2) s’effectue comme suit :
P
CCp(s,d) = (i,j)∈ Wp(s,d) (C(i,j) ) (1)
P
CCs(s,d) = (i,j) ∈Ws(s,d) (C(i,j) ) (2)
Lorsqu’un nœud périphérique est prêt à envoyer un paquet de contrôle, il déterminera
un canal primaire ou secondaire sur lequel il sera envoyé.
3.3
Algorithme GHL+
Dans cette partie, nous proposons de renforcer le mécanisme GHL proposé dans
le chapitre précédent pour qu’en plus du taux de perte réduit rapporté, puisse réduire
le taux de perte des paquets de contrôle relatif aux canaux congestionnés.
Dans le mécanisme GHL, nous partons du principe que le bon choix du nombre des
canaux de contrôle est fait de sorte à réduire la contention dans les canaux de contrôle.
Lorsque le nombre de slots minimal est consommé, le GHL vérifie la disponibilité d’un
canal de contrôle pour l’envoie du paquet. Lorsqu’un paquet de contrôle est transmis
dans le réseau pour faire la réservation des ressources la rafale, le nombre de canaux
de contrôle est décrémenté jusqu’à la fin du traitement. Un paquet de contrôle sera
envoyé sans aucune vérification lorsque le temps alloué à la construction de la rafale
sera expiré. La rafale est envoyée après l’expiration de l’offset time qui la sépare de
son paquet de contrôle.
Le mécanisme GHL+ [47] rapporte une extension au GHL, il permettra d’envoyer les
paquets de contrôle sur les canaux les moins surchargés en se basant sur une technique
de calcul statique et sélection dynamique de chemins. Chaque nœud périphérique
calcule deux chemins par lesquels les paquets de contrôle seront routés et avant chaque
envoie, un seul canal de contrôle est sélectionné pour l’envoie d’un paquet de contrôle
Figure 3.1.
62 CHAPITRE 3. MÉCANISME DE RÉDUCTION DE CONGESTION : GHL+
Figure 3.1 – Calcul et sélection d’un canal de contrôle
Le calcul et la sélection du chemin se basent sur les informations transmises par les
nœuds internes du réseau. A chaque intervalle de temps T, des paquets qui contenant
l’information du niveau de congestion sont envoyés aux nœuds périphériques. Les
paquets d’information reçus serviront de calcul et la sélection du chemin le moins
congestionné. Dans le chapitre précédent nous avons démontré que le nouvel mécanisme GHL offre une meilleure réduction de pertes en le comparant avec le mécanisme
hybride de construction de rafales. Comme dans les contentions, le taux de perte
augmente proportionnellement à l’augmentation du niveau de congestions dans les
canaux de contrôle. Ce problème peut être causé par l’insuffisance des canaux de
contrôle et/ou la sélection des canaux de contrôle congestionnés.
Dans le nouvel mécanisme GHL+ proposé, le traitement est effectué au niveau des
nœuds internes du réseau en se basant sur un seuil maximal de congestion prédéfini
au départ Section 4.2.1). Ensuite, le GHL+ sélectionne dynamiquement et selon
l’algorithme implémenté, le canal de contrôle le moins congestionné pour l’envoie du
paquet de contrôle ; on considère que dans le cas où aucun canal de contrôle n’est
disponible pour l’envoie d’un paquet de contrôle, la rafale correspondante sera rejetée.
Les nouvelles simulations réalisées feront l’objet de comparaison entre les mécanismes
GHL et GHL+.
3.3. ALGORITHME GHL+
Algorithm 6 GHL+
Event : IP packet Arrives
if (timer not running) then
{
Start Timer ;
Return value (pi / wi) for each traffic i,
Sort all traffic in descending order of value (pi / wi),
Select one by one traffic in the sort order
}
while (burst Length < Max Burst Length) do
{
Add the selected traffic in the slot of burst.
Update burst Length
}
if (burst Length == Max Burst Length) then
{
End of the burst construction
if (CCp(s,d) >0) then
{
if (CCs(s,d) >0) then
{
if (CCp(s,d) > CCs(s,d) ) then
{
Send BCP on the secondary channel
}
else
{
Send BCP on the primary channel
}}}
else
{
Send BCP on the primary channel
}
if (burst Length == Min slot of Burst Length) then
{
if (K>0) then {
K= K-l
63
64 CHAPITRE 3. MÉCANISME DE RÉDUCTION DE CONGESTION : GHL+
End of the burst construction
if (CCp(s,d) >0) then
{
if (CCs(s,d) >0) then
{
if (CCp(s,d) > CCs(s,d) ) then
{
Send BCP on the secondary channel
}
else
{
Send BCP on the primary channel
}}}
else
{
Send BCP on the primary channel
}}
Event : OT Expires
K= K+l
}
Event : Timer Expires
End of the burst construction
if (CCp(s,d) >0) then
{
if (CCs(s,d) >0) then
{
if (CCp(s,d) > CCs(s,d) ) then
{
Send BCP on the secondary channel
}
else
{
Send BCP on the primary channel
}}}
else
{
Send BCP on the primary channel
}
3.4. SIMULATIONS ET ANALYSE DES RÉSULTATS
3.4
65
Simulations et analyse des résultats
Les simulations ont été réalisées avec les hypothèses suivantes :
Les simulations ont été conduites avec les hypothèses suivantes :
• La taille des paquets TCP : 1000B ;
• La taille maximale des rafales : 18000B ;
• La taille minimale des rafales : 6000B ;
• Le temps maximal d’assemblage est fixé à 0.1 ms ;
• L’intervalle de temps après lequel la charge du réseau est recalculée est fixé à
10-3s ;
• Le seuil de congestion SM AX est fixé à 0.5 ;
• 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 ;
Le taux de perte des rafales et des paquets de contrôles en fonction de la charge
du réseau OBS pour chaque couple (source, destination) est présenté par les Figures
3.2 et 3.3 successivement. Pour de faibles charges, on remarque que les taux de perte
sont très faibles, mais pour les charges de trafic élevées, le taux de perte des paquets
de contrôle augmente du faite que la disponibilité des canaux de contrôle devient un
problème majeur quelque soit le mécanisme de réduction de perte implémenté.
L’augmentation des pertes des rafales dépend naturellement des pertes de leurs
paquets de contrôle, mais le résultat obtenu démontre que le GHL+ offre un taux
de perte réduit en le comparant au mécanisme GHL, cette réduction est relative
essentiellement au traitement de congestion à l’entrée des canaux de contrôle.
66 CHAPITRE 3. MÉCANISME DE RÉDUCTION DE CONGESTION : GHL+
Figure 3.2 – Taux de perte des rafales en fonction de la charge du réseau
Figure 3.3 – Taux de perte des rafales en fonction de la charge du réseau
Les Figures 3.4 et 3.5 présentent le débit de rafales et celui des paquets de
contrôles respectivement. Nous rappelons que le débit représente le nombre de rafales
ou paquets de contrôle envoyés chaque seconde. A partir des résultats de simulations,
nous remarquons que pour de faible charges ( entre 100 et 500 ) l’apport du GHL+
n’est presque pas existant car la congestion dans les canaux de contrôle ne se génère
pas, mais pour de grandes charges ( entre 500 et 1500 ), trop de paquets de contrôle
seront générés créant par conséquence des congestions dans les canaux de contrôle,
entre cet intervalle de charge, nous remarquons l’apport du GHL+ en matière de
traitement des congestions dans les canaux de contrôle, toutefois, pour des charges
3.4. SIMULATIONS ET ANALYSE DES RÉSULTATS
67
très élevés (au delà de 1500 connexions) les résultats recherchés ne sont plus garantis
pour les deux mécanismes et le problème de disponibilité et congestion des canaux de
contrôle réapparaissent à nouveau et entraine des utilisations non proportionnelles
entre les canaux de contrôle et ceux de données.
Figure 3.4 – Impact de la charge du réseau sur le débit de rafales
Figure 3.5 – Impact de la charge du réseau sur le débit de paquet de contrôle
68 CHAPITRE 3. MÉCANISME DE RÉDUCTION DE CONGESTION : GHL+
3.5
Conclusion
Dans ce chapitre, nous avons proposé une amélioration de la fonctionnalité d’attribution des canaux de contrôle aux paquets d’information de routage du mécanisme
GHL présenté dans le chapitre précédent. Cette amélioration porte sur deux étapes
indispensables de calcul et sélection des canaux de contrôle les moins congestionnés.
Par le biais des simulations réalisées, nous avons pu constater que la congestion dans
les canaux de contrôle peut condamner le traitement des paquets et par conséquence
générer des échecs de réservation et augmenter le taux de perte dans un réseau
OBS. Le mécanisme GHL+ réduit considérablement le taux de pertes des paquets de
contrôle et permet d’offrir des débits de rafales et paquets de contrôle améliorés tout
en réduisant les congestions dans les canaux de contrôle.
Conclusion Générale
Dans cette thèse, nous avons présenté l’évolution de la technologie de commutation
optique dans laquelle la fibre optique s’impose comme un équipement prometteur et
capable de supporter le transport d’un grand débit de données. Toutefois, à cause
des exigences infinies des utilisateurs en demande de bande passante, les nouvelles
architectures et protocoles réseaux se retrouvent forcés de migrer vers des réseaux
tout optique pour dépasser les contraintes matérielles.
La présentation des techniques de commutation optique a eu sa place dans ce travail,
dans ce cadre, trois techniques de commutations ont été comparées. La commutation
optique de circuit OCS est désavantageuse en exploitation de la bande passante
malgré sa mise en place qui ne nécessite aucune contrainte technologique compliquée.
La commutation optique de paquet quant à elle dépende du matériel qui fournit le
temps de compensation des traitements des entêtes de paquets, les lignes de retardement FDLs sont nécessaires pour camoufler un tel handicap mais restent très cher
même pour des petits retardements.
La technologie de commutation optique de rafales reste la plus sollicitée du faite
qu’elle rassemble les avantages des deux technologies OCS et OPS tout en surmontant
leurs inconvénients.
Toutefois, l’exploitation idéale des services de la technologie OBS passera par la
minimisation des pertes qui représentent la cause principale de la dégradation de
qualité de service. Ces pertes sont généralement liées aux contentions et congestions
qui peuvent survenir à l’entrée des noeuds internes ou dans les canaux de transports.
Les mécanismes traditionnels de réduction de contentions tels que le routage par
déflexion et la segmentation ont été présentés pour introduire le mécanisme de réduction de perte proposé intitulé "GHL" que nous proposons dans cette thèse. Le GHL
est un mécanisme de construction basé sur un multiplexage de trafics en forme de
slots dans les rafales ; il permet d’une part de minimiser le débit des rafales en se
basant sur un algorithme qui maximise la consommation des slots ; et d’une autre
part rajoute la condition de disponibilité d’un canal de contrôle pour en décider
de la fin de construction d’une rafale fournie par le mécanisme MCD. L’impact du
nouvel mécanisme sur les pertes à été comparé à ceux des mécanismes de construction
hybride et MCD.
Par le biais des simulations réalisées sous OMNET++, le "GHL" s’impose en offrant
69
70
CONCLUSION GENERALE
moins de pertes et en améliorant la qualité de service désirée par un tel réseau optique.
Dans le mécanisme GHL, lorsque le mécanisme d’assemblage s’achève, un paquet de
contrôle généré est envoyé sur un canal dédié. Un canal de contrôle en congestion peut
impacter le traitement des paquets de contrôles et par la suite, l’ensemble des tâches
suivantes tels que la réservation des ressources seront annulés. L’amélioration du
fonctionnement du mécanisme GHL repose sur le choix du canal le moins congestionné
au moment de l’envoie du paquet de contrôle.
Le "GHL" amélioré intitulé "GHL+" permet en plus de ses valeurs ajoutées, de faire
une sélection du chemin le moins congestionné au lieu de faire router un paquet de
contrôle sur n’importe quel chemin disponible. L’ajout d’une telle tâches rapporte
moins de pertes et plus de granularité en le comparant au "GHL" lors des simulations
réalisées.
Dans un futur travail, nous allons essayer de rajouter une nouvelle extension de
réservation des canaux de données les moins congestionnés au "GHL+". Au lieu du
calcul statique, basé sur le seuil de congestion définit comme hypothèse de simulation,
le calcul sera réalisé dynamiquement et dépendra de la charge du réseau, le test sera
réalisé sur des topologies de différentes tailles avec des exigences plus complexes que
celle simulées dans ce travail. Au moment de la congestion, le paquet de contrôle
et sa rafale sont automatiquement rejetés, une deuxième partie du prochain travail
consistera à implémenter une architecture qui repose sur des rafales de dépannage.
L’objectif est de permettre de sauvegarder les données perdues dans le cas de la non
disponibilité des ressources sans passer par l’utilisation des FDL.
Bibliographie
[1] https ://omnetpp.org/doc/omnetpp/api/files.html.
[2] An overview of the OMNeT++ simulation environment. Proceedings of the 1st
international conference on Simulation tools and techniques for communications,
networks and systems & workshops, 2008.
[3] Azadeh Abdolrazaghi. Unifying wireless sensor network simulators. Master’s
thesis, Stockholm, 2009.
[4] Shakeel Ahamad. Design and implementation of optical burst switching (obs).
Technische Universitt Hamburg-Harburg Communication Networks, 2006.
[5] Javier Aracil, Nail Akar, Steinar Bjornstad, Maurizio Casoni, K Christodoulopoulos, Davide Careglio, J Fdez-Palacios, C Gauger, O GonzáLez De Dios,
Guoqiang Hu, et al. Research in optical burst switching within the e-Photon/ONe
network of excellence, volume 4. Elsevier, 2007.
[6] AM Balamurugan and A Sivasubramanian. Optical burst switching issues and
its features. International journal of Emerging Trends & Technology in computer
science, 2(3) :306–315, 2013.
[7] Neil Barakat and Thomas E Darcie. The control-plane stability constraint in
optical burst switching networks. Communications Letters, IEEE, 11(3) :267–269,
2007.
[8] Alvaro L Barradas and Maria do Carmo R Medeiros. An intrinsic te approach for
end-to-end qos provisioning in obs networks using static load-balanced routing
strategies. Futur Internet, 2(4) :559–586, 2010.
[9] Balagangadhar G Bathula and Vinod M Vokkarane. Qos-based manycasting over
optical burst-switched (obs) networks. Networking, IEEE/ACM Transactions,
18(1) :271–283, 2010.
[10] Tzvetelina Lina Battestilli. Optical Burst Switching : a Survey. Citeseer, 2002.
71
72
BIBLIOGRAPHIE
[11] Sastel luccia Bilge Cetin. Simulateur : OMNET++. 2005.
[12] Franco Callegati, Aldo Campi, Giorgio Corazza, Dimitra Simeonidou, Georgios
Zervas, Yixuan Qin, and Reza Nejabati. Sip-empowered optical networks for
future it services and applications. Communications Magazine, IEEE, 47(5) :48–
54, 2009.
[13] Pushpendra Kumar Chandra, Ashok Kumar Turuk, and Bibhudatta Sahoo.
Survey on optical burst switching in wivelength division multiplexing networks.
In Industrial and Information Systems (ICIIS), 2009 International Conference
on, pages 83–88. IEEE, 2009.
[14] Jean-Pierre Chanet. Algorithme de routage coopératif à qualité de service pour
des réseaux ad hoc agri-environnementaux. PhD thesis, Université Blaise PascalClermont-Ferrand II, 2007.
[15] A. Detti and M. Listanti. Impact of segments agregation on transmission
control protocol reno flows in optical burst switching networks. proceedings of :
INFOCOM, 2002.
[16] Hassen DKHIL. Greedy perimeter stateless routing sur omnet++. PhD thesis,
Master’s thesis, Ecole nationale supérieur d’informatique, Tunisie, 2009.
[17] M Douiri, Souad Elbernoussi, and Halima Lakhbab. Méthodes de résolution
exactes heuristiques et métaheuristiques. Master’s thesis, Université Mohamed
V, Faculté des sciences de Rabat, 2009.
[18] Rudra Dutta, Ahmed E Kamal, and George N Rouskas. Traffic grooming for
optical networks : foundations, techniques and frontiers. Springer Science &
Business Media, 2008.
[19] Farid Farahmand and Jason P Jue. Analysis and implementation of lookahead window contention resolution with quality of service support in optical
burst-switched networks. Selected Areas in Communications, IEEE Journal,
24(12) :81–93, 2006.
[20] Farid Farahmand, Qiong Zhang, and Jason P Jue. A feedback-based contention
avoidance mechanism for optical burst switching networks. Proc. 3rd International
Workshop on Optical Burst Switching, 2004.
[21] Amit Kumar Garg and RS Kaler. Performance analysis of an integrated scheme
in optical burst switching high-speed networks, volume 6. Chinese Optical Society,
2008.
[22] Chr Gauger et al. Novel network architecture for optical burst transport. PIKPraxis der Informationsverarbeitung und Kommunikation, 32(1) :57–63, 2009.
BIBLIOGRAPHIE
73
[23] J. Scharf Gauger, C. M. and M. Kohn. Comparison of contention resolution
strategies in obs network scenarios. proceedings of : Transparent Optical Networks,
1 :18–21, 2004.
[24] R.K. ; Sivalingam K.M. ; Cankaya H.C. Gowda, S. ; Shenai. Performance evaluation of traffic connection protocol over optical burst-switched (obs) wdm
networks. IEEE Communications, 2 :1433–1437, 2003.
[25] Jin-Kao Hao, Philippe Galinier, and Michel Habib. Métaheuristiques pour
l’optimisation combinatoire et l’affectation sous contraintes. Revue d’intelligence
artificielle, 13(2) :283–324, 1999.
[26] J. Choi J. Choi and M. Kang. Dimensioning burst assembly process in optical
burst switching networks. IEICE Transactions on Communications, 2005.
[27] C. Qiao J. Li and Y. Chen. Recent progress in the scheduling algorithms in
opticalburst-switched networks. Journal of Optical Networking, 3 :229–241, 2004.
[28] J.P Jue and V. M. Vokkarane. Optical burst switched networks. Springer, 2004.
[29] Jaegwan Kim, Jinseek Choi, and Minho Kang. Offset-time based scheduling
algorithm for burst control packet in optical burst switching networks, pages
827–834. Information Networking. Networking Technologies for Broadband and
Mobile Networks, 2004.
[30] Miloš Kozák. Efficient Control, Routing, and Wavelength Assignment in Loss-Less
Optical Burst Switching Networks. PhD thesis, 2010.
[31] Cedric F Lam. Passive optical networks : principles and practice. Academic
Press, 2011.
[32] Heykel Limaiem. Maximisation du débit dans les réseaux obs. Master’s thesis,
Université du Québec à Montréal, 2010.
[33] Kawale S. M. Overview on optical burst switching by using scheduling algorithms.
International Journal of Engineering Research Technology, 2(5), 2013.
[34] G. Mohan M. Motani M. H. Phung, K. C. Chua and T. C. Wong. An absolute
quality of service framework for loss guarantees in optical burst-switched networks.
IEEE Transactions on Communications, 55(6) :1191–1201, 2007.
[35] D. K. Hunter M. J. O’Mahony, D. Simeonidou and A. Tzanakaki. The application of optical packet switching in future communication networks. IEEE
Communications Magazine, 39(3)(128-135), 2001.
[36] M. Maier. Optical switching networks. Cambridge University Press, 2008.
74
BIBLIOGRAPHIE
[37] Catherine Mancel. modélisation et résolution de problèmes d’optimisation combinatoire issus d’applications spatiales. PhD thesis, INSA de Toulouse, 2004.
[38] Won-Seok Park, Minsu Shin, and Song Chong. Performance enhancement in obs
network with flow control and edge delay method. Global Telecommunications
Conference, 2006. GLOBECOM’06. IEEE, pages 1–6, 2006.
[39] Pablo Pavon-Marino and Ferrante Neri. On the myths of optical burst switching.
Communications, IEEE Transactions on IEEE, 59(9) :2574–2584, 2011.
[40] Jumpot Phuritatkul, Yusheng Ji, and Yongbing Zhang. Blocking probability of
a preemption-based bandwidth-allocation scheme for service differentiation in
obs networks. Lightwave Technology, Journal of IEEE, 24(8) :2986–2993, 2006.
[41] Yvan Pointurier, Maïté Brandt-Pearce, Suresh Subramaniam, and Bo Xu. Crosslayer adaptive routing and wavelength assignment in all-optical networks. Selected
Areas in Communications, IEEE Journal, 26(6) :32–44, 2008.
[42] J. P. Jue Q. Zhang, V. M. Vokkarane and B. Chen. Absolute qos differentiation in optical burst-switched networks. IEEE Journal on Selected Areas in
Communications, 22(9) :1781–1795, 2004.
[43] Rajiv Ramaswami, Kumar Sivarajan, and Galen Sasaki. Optical Networks : A
practical perspective. Morgan Kaufmann, 2009.
[44] Rajiv Ramaswami, Kumar Sivarajan, and Galen Sasaki. Optical networks : a
practical perspective. Morgan Kaufmann, 2009.
[45] J. S. Choi S. Kim and M. Kang. Providing absolute differentiated services
for optical burst switching networks : loss differentiation. . IEEE ProceedingsCommunications, 152(4) :439–446, 2005.
[46] Fahd LOUKDACHE Said EL HAJJI and Abdellatif EL GHAZI. New mechanism
of burst construction to reduce losses in obs networks. International Journal of
Software Engineering and Its Applications, 8(10) :73–82, 2014.
[47] Fahd LOUKDACHE Said EL HAJJI and Abdellatif EL GHAZI. Ghl algorithm
extension based on a new technique of reducing congestion in obs networks.
International Journal of Software Engineering and Its Applications, 9(9) :189–
196, 2015.
[48] Fahd LOUKDACHE Said EL HAJJI, Salah-eddine KRIT. Modeling an obs
network in omnet + + and the impact of processing speed of control packets in
such network. Proceedings of the World Congress on Engineering, 2 :958–961,
2013.
BIBLIOGRAPHIE
75
[49] Tindo Sanghapi and Judith Noël. Nouvelle approche de réduction des pertes
dans les réseaux obs. Master’s thesis, Université du Québec à Montréal, 2009.
[50] Basem Shihada, Qiong Zhang, Pin-Han Ho, and Jason P Jue. A novel implementation of Transmission Control Protocol Vegas for optical burst switched
networks, volume 7. Elsevier, 2010.
[51] Daniel Stevenson, Mark Cassada, and Pronita Mehrotra. Optical burst switch network system and method with just-in-time signaling. US Patent App. 10/849,204,
2004.
[52] Andreas Timm-Giel, Ken Murray, Markus Becker, Ciaran Lynch, Carmelita
Görg, and Dirk Pesch. Comparative simulations of wsn. ICT-MobileSummit,
2008.
[53] Jonathan S Turner. Terabit burst switching. Technical report, DTIC Document,
2003.
[54] K. Haridoss V. M.Vokkarane and J. P.Jue. Threshold-based burst assembly
policies for qos support in optical burst-switched networks. proceedings of : SPIE
OptiComm, pages 125–136, 2002.
[55] A Varga. OMNeT++, Discrete Event Simulation System Version 4.0. User
Manual, 2009.
[56] Sanjeev Verma, Hemant Chaskar, and Rayadurgam Ravikanth. Optical burst
switching : A viable solution for terabit ip backbone. Network, IEEE, 14(6) :48–53,
2000.
[57] Viêt Minh Nhat Vo. Techniques cognitives pour la modélisation et l’optimisation
du groupage de trafics dans les réseaux de commutation de rafales. PhD thesis,
Université du Québec à Montréal, 2006.
[58] Viet Minh Nhat Vo. Learning model for reducing the delay in traffic grooming
optimization. Intelligent Information and Database Systems, pages 308–318,
2010.
[59] V. M. Vokkarane. Design and Analysis of Achitectures and Protocols for Optical
Burst-Switched Networks. PhD thesis, The University of Texas, 2004.
[60] V.M. Vokkarane et al. Generalized burst assembly and scheduling techniques for
qos support in optical burst-switched networks. GlobeCom, 2002.
[61] V.M. Vokkarane et al. Threshold-Based Burst Assembly Policies for QoS Support
in Optical Burst-Switched Networks. The Convergence of Information Technologies and Communications, 2002.
76
BIBLIOGRAPHIE
[62] Sajjad Waheed. Comparing optical packet switching and optical burst switching.
Daffodil international university journal of science and technology, 6(2) :22–32,
2011.
[63] Y. Wang and B. Ramamurthy. A control packet queuing optical burst switching
protocol for supporting quality of service. The Third International Workshop on
Optical Burst Switching, 2004.
[64] Jolyon White, Moshe Zukerman, and Hai Le Vu. A framework for optical burst
switching network design. IEEE Communications Letters, 6(6), 2002.
[65] Y. Jiang X. Guan, I. L.-J. Thng and H. Li. Providing absolute quality of
service through virtual channel reservation in optical burst switching networks.
Computer Communications, 28(9) :967–986, 2005.
[66] Y. Chen X. Yu and C. Qiao. A study of traffic statistics of assembled burst
traffic in optical burst switched networks. Proceedings of Optical Networking
and Communications Conference, 2002.
[67] Y. Liu X. Yu, C. Qiao and D. Towsley. Performance evaluation of transmission
control protocol implementations in obs networks. Technique report, 2003.
[68] Yijun Xiong, Marc Vandenhoute, and Hakki C Cankaya. Control architecture in
optical burst-switched wivelength division multiplexing networks. Selected Areas
in Communications, IEEE Journal on, 18(10) :1838–1851, 2000.
[69] D. Xu Y. Chen, H. Wu and C. Qiao. Performance analysis of optical burst switched node with deftection routing. International Conference on Communications
(ICC), 2 :1355–1359, 2003.
[70] Abdlatiff Yahaya and Mohamed. A review of routing strategies for optical
burst switched networks. International Journal of Communication Systems,
26(3) :315–336, 2013.
[71] X. Yu and C. Qiao. Transmission control protocol performance over obs networks
with multiple flows input. proceedings of : Broadband Communications, 2006.
[72] Chi Yuan, Zhengbin Li, and Anshi Xu. Dual-fiber-link OBS for metropolitan
area networks : modelling, analysis and performance evaluation. IEEE, 2008.
[73] Andrew Zalesky, Hai L Vu, Zvi Rosberg, Eric WM Wong, and Moshe Zukerman.
Stabilizing deflection routing in optical burst switched networks. Selected Areas
in Communications, IEEE Journal on, 25(6) :3–19, 2007.
[74] Zhenghao Zhang, Lin Liu, and Yuanyuan Yang. Slotted optical burst switching
(sobs) networks. Computer Communications, 30(18) :3471–3479, 2007.
BIBLIOGRAPHIE
77
[75] Jun Zhou, Jian Wu, and Jintong Lin. Novel acknowledgement-based assembly
and scheduling mechanisms in optical burst switching grid networks. Optical
Engineering, 46(6) :065003–065003, 2007.
Annexe A :
Le simulateur OMNeT++
Introduction :
La demande croissante en test des nouvelles architectures et protocoles réseaux
avant leur déploiement a conduit à la prolifération des simulateurs. Les simulateurs
se divisent en deux classes, des logiciels libres et gratuits ainsi que des simulateurs
payants. NS2 est un simulateur de réseaux construis autour du langage de programmation Tcl. La mise en œuvre de ce simulateur se fait à travers une étape de
programmation de la topologie du réseau et le comportement de ses composants,
l’étape suivante consiste en la simulation et l’interprétation des résultats. NS2 est un
programme complexe écrit en C++ et doté d’une interface Tcl.
Le simulateur OMNeT++ s’impose comme le plus favorisé parmi toutes les solutions
open source du fait qu’il présente des avantages en termes d’architecture modulaire
qui permet l’intégration de nouveaux modèles et pour son utilisation du langage C++
pour le développement du noyau.
OMNeT++ IDE est basé sur la plateforme Eclipse, il permet d’offrir des outils de
création et configuration des modèles de réseaux (fichier NED et INI) et des outils pour
l’exécution de programmes et analyse des résultats de simulation. La comparaison
entre les deux simulateurs open source OMNeT++ et NS2 [16] est rassemblée dans
le tableau ci-dessous :
78
79
Simulateur
Flexibilité
OMNeT++
OMNeT++ est un simulateur
flexible et générique, il peut simuler n’importe quel type de réseau. Par exemple, il peut être utilisé pour simuler les files d’attente,
les systèmes multiprocesseurs, les
architectures de matérielles (routeurs, les commutateurs optiques,
les serveurs etc.). Plusieurs modèlent sont utilisables pour les différents domaines (INET Fw, Mobility Fw, OverSim, NesCT, MACSimulator, etc.)
NS2
NS-2 a été conçu comme un
(TCP/IP) simulateur de réseau, et
il est difficile de simuler les choses
autre que paquet-commutant les
réseaux et les protocoles.
NS-2 ne fournit que le Random
Waypoint Mobility Model et le
OMNeT++ fournit plusieurs
Trajectory Based Mobility Model,
modes de mobilités comme le
ce qui rend difficile de présenter
Random Waypoint Mobility MoMobilité
une mobilité linéaire.
del, le Linear Mobility Model, le
Constant Speed Mobility Model,
le Basic Mobility Model, etc.
Le OMNeT++ noyau de simulaDans les NS-2, la limite entre le
tion est une bibliothèque de classe,
coeur de la simulation et les moc’est à dire, les modèles dans OMdèles sont barbouillés d’encre, sans
NET++ sont indépendants du
La gestion de moun clair API.
noyau de simulation. Les cherdèle
cheurs ont écrit leurs composants
(les modules simples) contre noyau
de simulation API du simulateur.
Dans NS-2, les modèles sont plats,
la création d’un sous réseau ou
l’exécution d’un protocole complexe (composition de plusieurs
La structure hiérarchique dans unités indépendantes) n’est pas
Support
pour OMNET++ facilite la complexité possible.
Les
Modèles des méthodes.
Hiérarchiques
OMNeT++ peut montrer les
Support de tra- transmissions de paquets pendant Pas de traçage.
une simulation.
çage
La documentation est très bonne
et contient tous ce qu’on a besoin pour la simulation (défini- Bonne documentation.
Documentation
tions, méthodes, modules, implémentations, etc).
80
ANNEXE A
Après une comparaison approfondie entre les deux simulateurs, nous constatons
que NS2 ne peut pas supporter plusieurs noeuds dans la simulation ce qui dessert nos
besoins d’implémentation. C’est pour cette raison que nous optons pour le simulateur
OMNet++.
Le choix du simulateur OMNeT++ :
Avant le déploiement d’un réseau, une simulation doit être réalisée auparavant
pour tester les performances avant la mise en place. En utilisant un tel simulateur,
nous nous retrouvent dans un monde totalement, paramétrable, flexible, et modulaire
dans la modélisation de plusieurs domaines dont on peut distinguer :
• la modélisation de réseaux optique
• la modélisation de protocole de communication
• l’évaluation des performances de système software complexe
Figure 6 – Lancement d’OMNeT++
81
Présentation d’ OMNet :
L’environnement OMNet++ de simulation est utilisé pour tester les performances
des réseaux de communication et d’autres systèmes distribués. Il dispose d’une architecture très variée qui répond à plusieurs domaines d’applications telles que la
modélisation des protocoles de communication ou celle des systèmes répartis.
Le simulateur OMNet++ dispose des outils de création et configuration des modèles
de réseaux comme les fichiers NED et d’autres outils pour l’exécution du programme
et la récolte des résultats de simulation.
Description architecturale d’OMNet++ :
Les modèles OMNeT++ sont représentés par un ensemble de modules (Figure 6). Les
modules simples sont codés en langage C++ en utilisant la librairie de simulations
d’OMNeT++.
Figure 7 – Architecture modulaire du simulateur OMNeT++
Les modules contiennent des algorithmes relatifs au modèle implémenté. Le
groupement des modules simples consiste en des modules composés et qui peuvent
communiquer grâce à des connexions entre les modules à travers des ports.
Au niveau plus avancé, le module système est crée par l’utilisateur. C’est un module
qui ne se connecte qu’avec avec ses composants internes qui sont, les modules simples
et composés.
Les modules peuvent s’attribuer des paramètres assignés aux modules dans le fichiers
de configuration omnetpp.ini . Ces paramètres sont utiles pour la personnalisation
du comportement des modules simples, le paramétrage de la topologie du modèle ou
l’initialisation des hypotheses des simulations.
Les principaux fichiers d’OMNeT++ :
Les différents fichiers sont :
• Fichier .NED : Utilise le langage NED pour décrire le réseau. Il peut être définit
de deux manières : graphiquement ou textuellement. En mode texte, le simulateur offre la possibilité de décrire les paramètres et les ports du module. Dans
82
ANNEXE A
le cas d’erreurs, un point rouge est signalé à gauche du code. Un exemple de fichier Ned en mode « Source » et « Graphique » sont représentés dans la figure y.
Figure 8 – Fichier NED en mode graphique
Figure 9 – Fichier NED en mode texte
83
• Fichier . ini : Est lié au fichier NED et permet à l’utilisateur de paramétrer
les hypotheses de simulation des différents modules ainsi que la topologie du
réseau. Voici un exemple présenté ci-dessous :
Figure 10 – Exemple de fichier ini
• Le fichier .msg : les modules communiquent en passant des messages qui sont
déclarés dans un fichier d’extension .msg où l’on peut ajouter des champs de
données. OMNeT++ traduira les définitions de messages en classes C++.
84
ANNEXE A
Dispatcher.cc
# include
# include
# include
# include
# include
# include
# include
# include
< fstream >
" AnsyncSlottedDispatcher . h "
" IPControlInfo . h "
" Burst . h "
" BurstControlPacket . h "
" BurstSchedulerAccess . h "
" OffsetTableAccess . h "
" WDMTableAccess . h "
Define_Module ( AnsyncSlottedDispatcher );
void AnsyncSlottedDispatcher :: initialize ()
{
bsc = BurstSchedulerAccess (). get ();
oft = OffsetTableAccess (). get ();
wdm = WDMTableAccess (). get ();
timeslot = par ( " timeslot " );
}
void AnsyncSlottedDispatcher :: handleSendingBurst ( cMessage * msg )
{
BurstControlPacket * bcp = new BurstControlPacket ( bcpName , 2);
Address src = ctrl - > getSrcAddr ();
Address dest = ctrl - > getDestAddr ();
if ( burstlength > fixedTimeslot )
{
sendtime = fixedSlottail - burstlength ;
if ( sendtime < slothead )
{
sendtime = slottail - burstlength ;
if ( sendtime > fixedSlothead )
{
sendtime = fixedSlothead ;
bursttail = sendtime + burstlength - fixedSlottail ;
}
else
{
bursthead = fixedSlothead - sendtime ;
bursttail = maxBursttail ;
} }
else {
85
bursthead = fixedSlothead - sendtime ;
}
while ( sendtime < simTime () + offset )
sendtime += timeslot ;
int channel = bsc - > schedule ( bcp , 0);
while ( channel < 0)
{
sendtime += timeslot ;
bcp - > setBurstArrivalTime ( sendtime );
channel = bsc - > schedule ( bcp , 0);
}
bcp - > setBurstChannel ( channel );
send ( bcp , " bcpg$o " );
}
void AnsyncSlottedDispatcher :: handleReceivedBurst ( cMessage * msg )
{
Burst * bst = check_and_cast < Burst * >( msg );
sendDelayed ( msg , txFinishTime , " out " );
}
Horizon.cc (LAUC)
# include
# include
# include
# include
# include
" HorizonScheduler . h "
" Burst . h "
" BurstControlPacket . h "
" ConnectionEvent_m . h "
" WDMTableAccess . h "
Define_Module ( HorizonScheduler );
void HorizonScheduler :: initialize ()
{
wdm = WDMTableAccess (). get ();
droppable = par ( " droppable " );
waveConversion = par ( " waveConversion " );
cModule * parent = getParentModule ();
int size = parent - > gateSize ( " burstg$o " );
for ( int i = 0 , prev = -1; i < size ; i ++)
}
cGate * g = parent - > gate ( " burstg$o " , i ) - > getNextGate ();
int id = g - > getOwnerModule () - > getId ();
86
ANNEXE A
if ( id != prev )
}
prev = id ;
ScheduleTable table ;
scheduleTables . push_back ( table );
}
Schedule * sch = new Schedule ;
sch - > horizon = 0;
sch - > tail = 0;
sch - > burst = NULL ;
scheduleTables . back (). push_back ( sch );
}
updateDisplayString ();
}}
void HorizonScheduler :: finish ()
{
ScheduleTables :: iterator it = scheduleTables . begin ();
while ( it != scheduleTables . end ())
{
ScheduleTable :: iterator jt = it - > begin ();
while ( jt != it - > end ())
{
delete * jt ;
jt ++;
}
it ++;
}
}
void HorizonScheduler :: printSchedule ( int port )
{
for ( unsigned int i = 0; i < scheduleTables [ port ]. size (); i ++)
{
char str [48];
ev << str ;
}
ev << endl ;
}
ScheduleResult HorizonScheduler :: trySchedule ( cMessage * msg ,
int port , int channel = -1)
{
BurstControlPacket * bcp = check_and_cast < BurstControlPacket * >
( msg );
Schedule * sch = channel < 0 ? scheduleTables [ port ][0] :
87
scheduleTables [ port ][ channel ];
}}
Burstassembly.cc
# include " PacketClassifier . h "
# include " Ghlp . h "
# include " PacketClassifier . h "
# include " Burst . h "
# include " IPControlInfo . h "
Define_Module ( Ghlp );
int Ghlp :: counter ;
Ghlp :: Ghlp ()
{
queue = NULL ;
timeoutEvent = NULL ;
}
Ghlp ::~ Ghlp ()
{
while (! queue - > empty ())
delete queue - > pop ();
delete queue ;
cancelAndDelete ( timeoutEvent );
}
void Ghlp :: initialize ()
{
queue = new cPacketQueue ( " queue " );
maxByteBurstlength = par ( " maxBurstlength " );
timeout = par ( " timeout " );
minSlotBurstlenght = par ( " minBurstlength " );
timeoutEvent = new cMessage ( " BurstAssembleTimeout " );
counter = 0;
}
void Ghlp :: handleMessage ( cMessage * msg )
{
if (! msg - > isSelfMessage ())
handlePacket ( msg );
else if ( msg == timeoutEvent )
handleTimeout ();
else
{
delete msg ;
}
88
ANNEXE A
}}
void Ghlp :: handleTimeout ()
{
ev << " Queue ␣ was ␣ timeout . " << endl ;
assembleBurst ();
}
void Ghlp :: assembleBurst ()
{
char msgName [32];
Burst * bst = new Burst ( msgName );
cPacket * pkt = queue - > get (0);
if ( pkt == NULL )
IPControlInfo * bstCtrl = new IPControlInfo ();
IPControlInfo * pktCtrl = ( IPControlInfo *) pkt - > getControlInfo ();
if ( channel > 0)
{
numDataChannels = numDataChannels -1;
bstCtrl - > setSrcAddr ( pktCtrl - > getSrcAddr ());
}
bstCtrl - > setDestAddr ( pktCtrl - > getDestAddr ());
bst - > setControlInfo ( bstCtrl );
ev << " Queue ␣ assemble ␣ burst ␣ ( " << msgName << " :
␣ ␣ ␣ ␣ " << queue - > info () << " ) " << endl ;
bst - > setPacketQueue ( queue );
queue = new cPacketQueue ( " queue " );
send ( bst , " out " );
}
PacketClassifier.cc
# include " BurstControlPacket . h "
# include " CoreRoutingTableAccess . h "
# include " BurstSchedulerAccess . h "
# include " OpticalSwitchFabricAccess . h "
# include " WDMTableAccess . h "
# include " PacketClassifier . h "
# include " IPControlInfo . h "
Define_Module ( PacketClassifier );
void PacketClassifier :: handleMessage ( cMessage * msg )
{
send ( msg , " out " , getQueueIndex ( msg ));
}
89
void PacketClassifier :: install ( int slot , NsObject * p )
{
if ( slot >= nslot_ ) alloc ( slot );
slot_ [ slot ] = p ;
if ( slot >= maxslot_ ) maxslot_ = slot ;
}
int PacketClassifier :: getQueueIndex ( cMessage * msg )
{
int i =0;
cPacket * slot_ = check_and_cast < cPacket * >( msg )
IPControlInfo * ctrl = ( IPControlInfo *) pkt - > getControlInfo ();
IPAddress destAddr = ctrl - > getDestAddr ();
while ( nslot_ <= slot ) nslot_ < <= 1;
slot_ = new NsObject *[ nslot_ ];
memset ( slot_ , 0 , nslot_ * sizeof ( NsObject *));
std :: vector < IPAddress >:: iterator it = destAddresses . begin ();
for ( int n = nslot_ ; it != destAddresses . end (); n ++ , it ++)
if (* it == destAddr ) slot_ [ i ] = pkt [ i ];
return i ;
destAddresses . push_back ( destAddr );
if (( int ) destAddresses . size () > gate ( " out " ) - > getVectorSize ())
return destAddresses . size () - 1;
}
ControlUnit.cc
# include " ControlUnit . h "
# include " Burst . h "
# include " BurstControlPacket . h "
# include " CoreRoutingTableAccess . h "
# include " BurstSchedulerAccess . h "
# include " OpticalSwitchFabricAccess . h "
# include " WDMTableAccess . h "
Define_Module ( ControlUnit );
void ControlUnit :: initialize ()
{
crt = CoreRoutingTableAccess (). get ();
scd = BurstSchedulerAccess (). get ();
osf = OpticalSwitchFabricAccess (). get ();
wdm = WDMTableAccess (). get ();
processDelay = bcpProcessDelay + ( oeConvertDelay * 2);
failedCounter = 0;
}
90
ANNEXE A
void ControlUnit :: handleMessage ( cMessage * msg )
{
if ( msg - > isSelfMessage ())
handleSelfEvent ( msg );
else
handleBurstControlPacket ( msg );
}
void ControlUnit :: handleBurstControlPacket ( cMessage * msg )
{
printBCP ( msg );
BurstControlPacket * bcp = check_and_cast < BurstControlPacket * >( m
int inPort = bcp - > getBurstPort ();
int inChannel = bcp - > getBurstChannel ();
int outPort = crt - > getSendPort ( bcp - > getDestAddress ());
int outChannel = scd - > schedule ( bcp , outPort );
if ( outChannel < 0)
{
failedCounter ++;
ev << bcp << " ␣ schedule ␣ failed . " << endl ;
delete msg ;
}
}
else
{
ev << bcp << " ␣ schedule ␣ success . " << endl ;
int inGateIndex = wdm - > getGateIndex ( inPort , inChannel );
int outGateIndex = wdm - > getGateIndex ( outPort , outChannel );
ConnectionEvent * connect = new ConnectionEvent ( msgName );
connect - > setIn ( inGateIndex );
connect - > setOut ( outGateIndex );
scheduleAt ( bcp - > getBurstArrivalTime () - guardtime , connect );
bcp - > setBurstPort ( crt - > getReceivePort ( bcp - > getDestAddress ()));
bcp - > setBurstChannel ( outChannel );
sendDelayed ( bcp , processDelay , " bcpg$o " , outPort );
}
void ControlUnit :: printBCP ( cMessage * msg )
{
BurstControlPacket * bcp = check_and_cast < BurstControlPacket * >( m
ev << bcp - > getName ()
<< " ␣ | ␣ Src : ␣ " << bcp - > getSrcAddress (). str (). c_str ()
<< " ␣ Dest : ␣ " << bcp - > getDestAddress (). str (). c_str ()
<< " ␣ BurstArrivalTime : ␣ " << bcp - > getBurstArrivalTime ()
<< " ␣ Burstlength : ␣ " << bcp - > getBurstlength ()
91
<<
<<
<<
<<
}
" ␣ BurstPort : ␣ " <<
" ␣ BurstChannel : ␣ "
" ␣ Bursthead : ␣ " <<
" ␣ Bursttail : ␣ " <<
bcp - > getBurstPort ()
<< bcp - > getBurstChannel ()
bcp - > getBursthead ()
bcp - > getBursttail () << endl ;
Annexe B :
Liste de publications
Publications dans les journaux :
– Fahd Loukdache, Said El Hajji and Abdellatif El Ghazi, "GHL Algorithm
Extension Based on a New Technique of Reducing Congestion in OBS Networks", International Journal of Software Engineering and Its Applications
Vol. 9, No. 9 (2015), pp. 189-196 (Indexé par Scopus).
– Fahd Loukdache, Said El Hajji and Abdellatif El Ghazi, "New Mechanism
of Burst Construction to Reduce Losses in OBS Networks", International
Journal of Software Engineering and Its Applications Vol. 8, No. 10 (2014),
pp. 73-82 (Indexé par Scopus).
Articles : conférences et congrès internationaux
– Fahd Loukdache, Salah Eddin KRIT, Said El Hajji and Abdellatif El
Ghazi, "Modeling an OBS Network in OMNeT + + and the Impact of
Processing Speed of Control Packets in Such Network", Lecture Notes
in Engineering and Computer Science, pp 958-961, WCE Londres 2013.
(Indexé par Scopus).
– Fahd Loukdache, Salah Eddin KRIT, Said El Hajji and Abdellatif El
Ghazi, "Modeling an OBS Network in OMNeT + + and the Impact
of Data Channels in such Network", Lecture Notes in Engineering and
Computer Science, pp 1045-1047 WCE Londre 2012.
92
93