• Aucun résultat trouvé

Panne de liens

Dans le document Optimisation dynamique de réseaux IP/MPLS (Page 77-84)

4.4 Résultats

4.4.3 Panne de liens

50 % 60 % 70 %

Day 01 Day 02 Day 03 Day 04 Day 05 Day 06 Day 07 0

1 2 3 4 5 6 7 8 9 10

Figure 4.10 – Taux de congestion réseau optimisé sur la 4ème semaine du réseau ABI-LENE.

Les temps d’exécution restent inférieurs à 0.07 secondes, ce qui est clairement com-patible avec un fonctionnement en ligne. Le nombre total de modifications reste aussi assez limité pour l’intégralité de la semaine. Pour γ = 0.25, des modifications ont été appliquées à seulement 17 instants pour l’ensemble de la semaine (qui se compose de 2000 instants d’exécution de l’algorithme), et seulement 27 poids ont été modifiés pour toute la semaine.

4.4.3 Panne de liens

Dans cette partie, nous étudions les résultats obtenus avec l’algorithme proposé lors-qu’une panne de lien apparaît sur le réseau. Plus précisément, nous comparons le taux de congestion réseau obtenu avec les poids unitaires avec ceux fournis par l’algorithme en ligne, lorsqu’un lien tombe en panne à un instant arbitraire Tdown, avant de réap-paraître à l’instant Tup > Tdown. Nous utilisons le même protocole de simulation que

4.4 RÉSULTATS 61

dans la section 4.4.1. Le même lien est rompu pour les différentes configurations : il s’agit du lien ayant le taux d’utilisation le plus important à l’instant de la panne. Trois exemples de résultats sont présentés sur les Figures4.11,4.12et4.13, tous obtenus avec Tdown= 97ème minute, Tup= 157ème minute et γ = 0.25. Les mêmes types de résultats sont obtenus pour les autres topologies.

Comme indiqué dans la section4.3.1, le problème d’estimation de la matrice de trafic peut devenir insoluble si un lien tombe en panne ou réapparaît pendant la période de mesure. Dans ces deux cas, l’algorithme reste en sommeil jusqu’à ce que la prochaine mesure SNMP "valide" (sans modification de topologie) soit disponible. Pour les Tdown= 97ème minute et Tup= 157ème minute, cela signifie que l’algorithme ne propose pas de modifications à la 100ème minute et à la 160ème minute.

Les taux de congestion réseau obtenus sont la plupart du temps inférieurs à ceux de la configuration statique unitaire. Nous observons qu’après chaque événement, des mo-difications sont appliquées, réduisant le taux de congestion réseau d’une façon efficace. Nous remarquons aussi que pour chaque événement, le taux de congestion réseau aug-mente moins avec l’algorithme en ligne, tout en conservant un nombre de modifications limité. Il semble qu’une bonne répartition des trafics (comme opéré avec l’algorithme) avant une panne de lien permette de réduire l’impact de l’événement sur la congestion du réseau.

Max Congestion Metric changes

Time (min)

ABOVENET-Failure

Distinct metric changes UnitMetrics Lower Bound Estimated Matrix Optim

40 % 50 % 60 % 70 % 80 % 90 % 100 % 110 % 120 % 0 50 100 150 200 250 0 1 2 3 4 5 6 7 8 9 10

Figure 4.11 – Taux de congestion pour la topologie ABOVENET en cas de panne de lien.

62 OPTIMISATION DYNAMIQUE DES RÉSEAUX OSPF

Max Congestion Metric changes

Time (min)

BHVAC-Failure

Distinct metric changes UnitMetrics Lower Bound Estimated Matrix Optim

40 % 60 % 80 % 100 % 120 % 140 % 160 % 0 50 100 150 200 250 0 1 2 3 4 5 6 7 8 9 10

Figure 4.12 – Taux de congestion pour la topologie BHVAC en cas de panne de lien.

Max Congestion Metric changes

Time (min)

EON-Failure

Distinct metric changes UnitMetrics Lower Bound Estimated Matrix Optim

20 % 30 % 40 % 50 % 60 % 70 % 80 % 90 % 100 % 110 % 120 % 0 50 100 150 200 250 0 1 2 3 4 5 6 7 8 9 10

4.5 CONCLUSION 63

4.5 Conclusion

L’idée clé de l’approche proposée consiste à dévier du trafic des liens les plus conges-tionnés. Pour évaluer dans quelle mesure une déviation peut être intéressante, nous avons besoin d’information sur les trafics. Cette information est obtenue via une estimation simple de la matrice de trafic courante, à partir de mesures données par le protocole SNMP. L’optimisation robuste est utilisée pour compenser les erreurs d’estimation du trafic. Les résultats obtenus avec l’algorithme glouton proposé, sur des trafics simulés et des trafics réels montrent qu’une réduction importante du taux de congestion réseau peut être obtenue par rapport à une configuration statique des poids, même si les trafics subissent d’importantes variations temporelles. Pour les trafics sur le réseau ABILENE, le taux maximum de congestion réseau peut être réduit à environ 45% avec l’algorithme en ligne , là où il atteint 55% avec la configuration unitaire des poids. Cela montre aussi que l’algorithme dynamique fournit une configuration plus robuste, en apportant la pos-sibilité de réagir aux variations de trafic. Les temps d’exécution sont compatibles avec un fonctionnement en ligne, tant que l’on ne considère pas des topologies de tailles très importantes. Une autre conclusion intéressante est que, en répartissant mieux les trafics entre les liens du réseau, l’algorithme en ligne proposé aide à réduire l’impact des pannes sur le taux de congestion au moment où l’événement arrive. Une perspective future in-téressante consisterait à tester l’implémentation de l’algorithme sur un vrai réseau pour démontrer son utilité et sa faisabilité réelle.

5

Optimisation du placement des LSP dans les

réseaux MPLS

5.1 Introduction

Dans ce chapitre, nous nous intéressons à l’optimisation des cœurs de réseau reposant sur la technologie MPLS. Comme évoqué dans le chapitre1, la technologie MPLS a des avantages certains en termes d’ingénierie de trafic par rapport à des protocoles de routage classiques comme OSPF. En particulier, elle permet de gérer finement l’utilisation des ressources disponibles en assignant un chemin explicite à chacun des LSP, qui sont alors appelés ER-LSP (Explicitly Routed LSP). Un exemple de placement explicite de LSP est présenté sur la Figure5.1, où 3 LSP ayant la même source et la même destination transitent par des chemins distincts. Avec l’utilisation de LSP explicitement routés, il devient possible d’envisager adapter les chemins utilisés en fonction des conditions de trafic pour optimiser dynamiquement l’utilisation des ressources. C’est cette possibilité que nous exploiterons dans ce chapitre.

Chaque LSP devant être routé sur un et un seul chemin, le problème du placement optimal des LSP est un problème de routage mono-chemin qui peut se formuler avec des variables de décision binaires. Il est de tradition en optimisation de réseaux de chercher à minimiser le taux de congestion du réseau, c’est-à-dire le taux maximal d’utilisation des liens du réseau. Dans ce cas, le placement optimal des LSP peut s’écrire comme un problème linéaire en nombres entiers. D’autres critères de performance peuvent cepen-dant être pertinents, et notamment ceux représentant la qualité de service des flux dans

66 OPTIMISATION DU PLACEMENT DES LSP DANS LES RÉSEAUX MPLS LER LER LER LSR LSR LSR LSR LSR LSP1 LSP2 LSP3

Figure 5.1 – Exemple de placement de 3 LSP dans un réseau MPLS.

le réseau. On peut ainsi chercher à minimiser le délai moyen des paquets dans le réseau. C’est par exemple le choix qui a été fait dans [52] où les auteurs cherchent à minimiser la violation d’une contrainte sur le délai des paquets, en supposant que certains trafics sont prioritaires, les autres se partageant le reste de la bande passante en fonction de priorités relatives. Le délai moyen des paquets s’exprimant à l’aide de formules de files d’attente qui sont non linéaires, le problème d’optimisation à résoudre devient alors un problème non linéaire en variables binaires.

Pour prendre en compte ce type de critère, nous étudions dans ce chapitre le pro-blème du placement optimal des LSP en supposant une fonction objectif additive et non linéaire. Ce problème appartient à la classe des problèmes mathématiques non li-néaires mettant en jeu des variables entières (binaires, dans notre cas), problèmes qui sont connus pour être très difficiles à résoudre, aussi bien d’un point de vue théorique que pratique. Même les cas les plus simples avec des variables binaires, une fonction coût quadratique et des contraintes d’égalité sont connus pour être NP-difficiles [27]. En pratique, on doit donc souvent se contenter d’une résolution approchée.

Plusieurs approches ont été proposées pour la résolution approchée des problèmes d’optimisation non linéaires en nombres entiers. Certaines transforment le problème dis-cret en un problème continu (voir par exemple [90]). Malgré leurs qualités, ces techniques rencontrent des difficultés de mise à l’échelle vis-à-vis de la taille des problèmes consi-dérés. Une alternative récente est la technique nommée Global Smoothing Algorithm [82], qui semble être plus tolérante aux des problèmes de passage à l’échelle, tout en fournissant des approximations intéressantes (voir Section5.4.1 pour les détails).

Dans le document Optimisation dynamique de réseaux IP/MPLS (Page 77-84)