Modifications appliquées

6 Cout M/M/1 Nombre de LSP modifies Temps (min) Routage Statique Optim hors ligne Routage dynamique BR LSP modifies

Figure 5.7 – Optimisation en ligne sur topologie METRO avec fonction coût de type M/M/1.

5.6.2 Modifications appliquées

Les nombres de modifications appliquées pour chaque simulation sont exposés dans les Tables5.8 et5.9. La première colonne présente le nombre d’instants où une reconfi-guration a été proposée et appliqué par l’algorithme dynamique. Nous présentons trois valeurs pour appréhender correctement le nombre de LSP modifiés sur chaque simula-tion :

— Cumul total : la somme totale des LSP modifiées au cours d’une simulation. Autrement dit le nombre total cumulé de LSP dont la route a été touchée au cours d’une simulation de 250 minutes, il est donc possible d’y retrouver plusieurs fois un même LSP.

— 1ère reconfiguration : le nombre de LSP distincts qui ont été modifiés lors de la toute première reconfiguration proposée par l’algorithme (la plupart du temps dès la première exécution à t=5 minutes).

— Cumul restant : la somme du nombre de LSP modifiés après la 1ère reconfigu-ration (on peut à nouveau y retrouver plusieurs fois un même LSP).

90 OPTIMISATION DU PLACEMENT DES LSP DANS LES RÉSEAUX MPLS

On remarque que le nombre d’instants de modifications reste modéré, et ce pour les deux fonctions coût : sur l’intégralité des simulations, au maximum 5 reconfigurations distinctes auront été nécessaires pour des simulations de 250 minutes.

Le nombre cumulé de LSP re-routés est plus ou moins proportionnel à la taille du scénario considéré. On remarque qu’une portion importante des modifications appliquées le sont dès la première reconfiguration : cela s’explique par le fait que l’on démarre avec une configuration statique de type OSPF qui n’est absolument pas optimisée. La première reconfiguration procède donc à un replacement général et poussé des LSP.

Les modifications appliquées après la première reconfiguration (« cumul restant ») sont en nombre bien moins important, ce qui indique que l’algorithme tente de se limi-ter aux reconfigurations minimales permettant de suivre efficacement les variations de trafic. Malgré tout, certaines valeurs restent parfois élevées (ABOVENET, ARPANET et EON pour la fonction coût quadratique). Cela nous laisse penser qu’un travail sup-plémentaire pourrait s’avérer nécessaire pour restreindre plus intelligemment le nombre de modifications proposées.

Topologie ^{Instants de Nombre de LSP modifiés}

modifications Cumul Total 1ère reconfiguration Cumul restant

ABOVENET 5 92 43 49 ARPANET 3 112 46 66 BHVAC 2 52 21 31 EON 4 62 14 48 METRO 5 18 4 14 PACBELL 4 54 28 26 NSF 2 4 2 2 VNSL 2 8 5 3

Table 5.8 – Modifications appliquées avec la fonction Quadratique.

5.6.3 Temps d’exécution

Les temps d’exécution sont faibles, et sont impactés positivement par la restriction aux gains supérieurs à G_Seuil : on constate alors une valeur maximale (tous scénarios confondus) de 3 secondes pour l’exécution de l’algorithme. Ces temps sont très clairement compatibles avec une utilisation en ligne.

5.7 CONCLUSION 91

Topologie ^{Instants de Nombre de LSP modifiés}

modifications Cumul Total 1ère reconfiguration Cumul restant

ABOVENET 2 40 31 9 ARPANET 5 124 60 64 BHVAC 3 36 12 24 EON 2 41 21 20 METRO 2 35 29 6 PACBELL 2 35 29 6 NSF 2 4 2 2 VNSL 2 7 5 2

Table 5.9 – Modifications appliquées avec la fonction M/M/1.

5.7 Conclusion

Les résultats numériques obtenus avec l’algorithme de meilleure réponse que nous proposons sont intéressants : l’erreur relative à la solution optimale reste relativement modeste (équivalente aux autres techniques testées), tout en proposant des temps d’exé-cution substantiellement inférieurs aux autres. Ces résultats nous font penser que cet algorithme devrait être considéré pour les systèmes de grande échelle, là où les autres techniques peuvent potentiellement rencontrer leurs limites, et là où les temps d’exécu-tions sont primordiaux. L’optimisation dynamique du placement est typiquement un cas où les temps d’exécutions sont importants, et les simulations effectuées en ce sens nous révèlent que l’algorithme proposé semble conserver un bon comportement dans ce type de situation. La restriction du nombre de modifications proposée par l’algorithme est une piste d’amélioration éventuelle de l’algorithme proposé pour le schéma d’optimisation dynamique.

6

Réseau overlay auto-guérissant et

auto-optimisant

6.1 Introduction

Nous avons présenté dans les chapitres précédents des méthodes d’optimisation pour la reconfiguration dynamique du routage IP/MPLS, permettant d’adapter en temps réel les routes utilisées par les flux aux conditions de trafic dans le réseau. Ces méthodes peuvent être utilisées par les opérateurs de réseaux pour optimiser la performance des flux dans leurs infrastructures. Nous présentons dans ce chapitre une solution logicielle permettant le déploiement d’un réseau overlay auto-guérissant et auto-optimisant entre différents sites. La solution, directement utilisable par un fournisseur de service, est conçue pour ne nécessiter aucun changement des applications. En mesurant régulière-ment la qualité des liens Internet entre les sites distants, elle permet de détecter rapi-dement la panne d’une route IP et de basculer le trafic sur un chemin de secours. Elle permet également de découvrir dynamiquement les chemins dans le réseau overlay qui optimisent une métrique de routage spécifique à l’application.

Cette solution logicielle a été développée dans la cadre du projet européen Pana-cea¹. Ce projet regroupe des partenaires industriels et académiques collaborant pour concevoir une solution de gestion autonomique et proactive des services informatiques déployés dans le cloud afin d’en améliorer notablement la disponibilité et les perfor-mances. La solution visée est proactive dans le sens où elle mesure en permanence un

94 RÉSEAU OVERLAY AUTO-GUÉRISSANT ET AUTO-OPTIMISANT

certain nombre de paramètres et peut, en utilisant des techniques avancées d’apprentis-sage, prédire le temps restant avant l’interruption ou une dégradation non acceptable du service fourni. La solution visée est également autonomique dans le sens où les ser-vices déployés avec elle auront la capacité de s’auto-réparer, de s’auto-configurer et de s’auto-optimiser. Le réseau overlay présenté dans ce chapitre est un des composants in-novants de cette solution et doit permettre de protéger les communications inter-clouds des dysfonctionnements de l’Internet.

Nous commençons par expliquer les motivations de ce travail en présentant des ré-sultats expérimentaux illustrant quelques limites du routage Internet au paragraphe6.2. Nous décrivons ensuite au paragraphe 6.3les objectifs du système proposé et analysons les similarités et différences avec quelques solutions existantes. Le paragraphe 6.4 pré-sente l’architecture du système et ses composants. Nous présentons en détail les choix techniques pour l’acheminement des paquets (paragraphe6.5), pour la mesure de la qua-lité des chemins Internet entre les nœuds de l’overlay (paragraphe6.6) et pour découvrir les chemins optimaux dans l’overlay avec un minimum de mesures (paragraphe6.7). Le paragraphe6.8présente les plateformes de test et de validation. Enfin, le paragraphe6.9 est consacré aux résultats expérimentaux.