Le choix du nombre de canaux de contrôle impact le taux de services des paquets de contrôle. Un bon choix du nombre de canaux de contrôle est très important surtout lorsqu’il s’agit de charges très élevées pour gérer les congestions.
Figure 2.12 – Impact du nombre de canaux de contrôle sur les pertes des paquets de contrôle
2.3
GHL : Mécanisme de construction des rafales
Le mécanisme d’assemblage de rafales est considéré comme l’un des principaux fac- teurs qui permet de déterminer les performances des réseaux optiques à commutation de rafales [59]. Une rafale peut être construite moyennant plusieurs mécanismes. Cer- tains sont basés sur la taille ou sur le temps, d’autres sont basés sur la taille et le temps (mécanismes hybrides). Dans le mécanisme hybride, une taille minimale et un délai maximal d’assemblage sont fixés pour en décider de la fin de construction d’une rafale. Lorsque l’un des deux paramètres est atteint, la rafale est directement envoyée dans le réseau selon un mécanisme d’ordonnancement et après l’expiration de l’offset-time [44]. La taille des rafales demeure un argument très important qui conduit à minimiser ou maximiser les contentions dans un réseau OBS. Une taille maximale des rafales peut affecter les performances du réseau. En effet, plus la taille maximale d’une rafale est grande, plus le nombre de segments TCP contenus dans celle-ci est élevé. Lorsqu’une rafale contient des segments arrivant de plusieurs sources TCP ; la perte de cette rafale va affecter grandement le débit TCP généré, et par conséquence les performances du réseau. L’effet de la variation de la taille dans [50] a montré que l’augmentation de la taille des rafales peut impacter positivement le débit TCP généré. Les simulations
faites dans ce travail se sont basées sur deux valeurs de probabilité de perte de rafales :
• augmentation de la taille maximale de rafale a pour effet l’augmentation du délai de bout-en-bout des paquets. Les résultats montrent que le débit TCP n’en est pas affecté, vu qu’il n’y a pas de pertes de rafales (Tous les paquets émis sont reçus).
• la perte des paquets a pour effet la réduction du débit TCP total. Pour une faible probabilité de perte de paquets, l’augmentation de la taille maximale de rafale accroît considérablement le débit TCP. Cependant, pour une probabilité de perte élevée, l’augmentation de la taille maximale des rafales n’a pas de grands effets sur l’augmentation du débit TCP.
Les études réalisées dans [49] démontrent que le mécanisme MCD proposé a rap- porté une réduction de perte par rapport au mécanisme hybride dans le réseau OBS. Toutefois, la partie assemblage dans ce mécanisme reste traditionnelle et similaire à celle du mécanisme hybride. La réduction de perte récupérée n’est due qu’au rajout de la phase de vérification de disponibilité d’un canal de contrôle avant l’expiration du temps maximale d’assemblage ou l’atteinte de la taille maximale d’une rafale. Dans un réseau OBS, il est important dans un mécanisme d’assemblage de trouver une formule optimale pour réduire le nombre de rafales utilisées tout en maximisant le trafic dans celles-ci, c’est à dire qu’il faut trouver une solution de limitation de la quantité des rafales et répondre aux besoins de demandes d’utilisateurs en bande passante qui sont très supérieures à la capacité des rafales.
Une nouvelle variation des réseaux OBS [58] est représentée par des rafales slottées dont la plus petite unité de transport des données est l’intervalle de temps d’une rafale appelée un slot de celle-ci.
2.3. GHL : MÉCANISME DE CONSTRUCTION DES RAFALES 41 Le multiplexage de trafic dans une rafale pourrait être vu comme un classement des blocs de trafic utilisateur dans les slots de rafale disponibles. Les études réalisées dans [60] démontrent qu’il y’a une relation entre le mécanisme de construction des rafales et la qualité de service des réseaux OBS. En effet, le mécanisme d’assemblage des rafales peut causer des sanctions de délai sur les flux TCP. Les segments TCP reçus au niveau du nœud périphérique d’entrée doivent attendre l’expiration du temps d’agrégation de rafale avant leurs transmissions. Ce délai rajouté peut causer une diminution du débit TCP généré.
Les réseaux OBS à rafales slottées opèrent de la même manière que les OBS tradition- nels. Le plan de contrôle et celui des données sont séparés, les paquets de contrôle sont envoyés sur des canaux de contrôle dédiés pour effectuer les réservations des ressource de leurs rafales correspondantes, après l’expiration de l’Offset-time, les rafales sont transmise à leur tour sans subir de conversion ou traitement depuis le nœud source au nœud de destination. Les études réalisées dans [57] démontrent que ce modèle de réseau OBS peut offrir plus de flexibilité de transmission et une meilleure exploitation de la bande passante d’une rafale. Plusieurs algorithmes d’assemblage des rafales sont proposés dans [41] [61]. Selon les auteurs de [22], les mécanismes d’assemblage peuvent être classées en :
• mécanisme basé sur le temps : cette stratégie définit un seuil de temps pour la composition de la rafale. Le nœud périphérique assemble tous les paquets reçus pendant une période d’assemblage fixe, ayant la même destination, dans une même rafale. La construction de la rafale se termine à la fin de cette période fixe. Ce mécanisme est utile pour le trafic à temps réel exigeant une qualité de service en termes de délais [26].
• mécanisme basé sur la taille : ce mécanisme utilise des seuils de taille d’une rafale en prenant en considération la quantité de données ou le nombre de paquets dans la rafale [66].
• mécanisme hybride : ce mécanisme profite des avantages des deux stratégies précédentes, à savoir, le seuil du temps et le seuil de la taille pour en décider de la fin de construction d’une rafale [12] [74].
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 utilisa- teurs 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 43
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
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 est : z(X) = Pn
i=1xipi. De même, la somme des blocs des trafics multiplexés est :
w(X)=Pn
i=1xiwi. 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
maximum de la fonction objectif z(X), sous la contrainte : w(X)=Pn
i=1xiwi 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=1wi > 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 dispo- nible, la rafale ne sera envoyée que lorsqu’elle multipléxe les trafics utilisateurs dans le maximum de slots disponibles.
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 S1 S2 S3 S4 S5 S6 T1 D D D ND ND ND T2 ND ND D D D ND T3 D D ND ND ND ND T4 ND ND ND D D D T5 D D ND ND ND 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 S1 S2 S3 S4 S5 S6 R1 D D D ND ND D
R2 D D D D D D
R3 ND ND D D D D R4 D D D D ND 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 S1 S2 S3 S4 S5 S6 R1 T1 ND ND D R2 T3 T2 D R3 ND ND D T4 R4 T5 D D ND ND
C’est à dire que : Trafics T1 T2 T3 T4 T5 R1 X R2 X X R3 X R4 X
2.3. GHL : MÉCANISME DE CONSTRUCTION DES RAFALES 49 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.