Les travaux précédents se sont focalisés sur la réduction du temps d’exécution de ces étapes de convergence [FFEB05, RMD05]. Par exemple, plusieurs études se sont intéressées au problème de la détection de pannes étudiée au Chap. 2 [GRcF03]. La configuration du protocole de détection de pannes Hello avec une fréquence élevée amène une instabilité dans le routage et une fréquence lente augmente l’interruption de service. Ce problème de stabilité oblige les opérateurs à utiliser une période d’envoi des messages Hello supérieure à une seconde au dépend d’un rétablissement rapide du service.
Les autres étapes de la convergence ont aussi été l’objet d’amélioration notamment l’étape de calcul de route, et de nombreuse techniques de Fast ReRoute [SB10] ont été proposées afin d’outrepasser les délais tF + tSP + tU en pré-calculant à l’avance certains chemins de secours. L’étape de diffusion des LSA, bien que négligeable dans le processus de convergence a été l’objet d’amélioration [PE05, RBGK03, SWL+03, Nar00], notamment afin d’optimiser et de restreindre sa diffusion. Cependant c’est l’étape de calcul des plus courts chemins qui a été la plus étudiée [NST01, XN98, ZXW07, JXLP09]. Cette étape, la deuxième la plus longue après la détection de panne, nécessite une puissance de calcul importante, et est d’autant plus importante que la topologie est grande. Plusieurs travaux proposent une amélioration avec des algorithmes de calcul de route incrémental [NST01, FMSN94] ne nécessitant que de recalculer la portion affectée par la panne afin de réduire le temps de calcul des plus courts chemins. Un calcul parallèle dynamique des plus courts chemins est proposé dans [ZXW07] pour affecter le calcul partiel des plus courts chemins au routeur concerné sur différents processeurs. Xiao et al. [XN98] propose de diviser la topologie du réseau en aires indépendantes pour des processeurs différents selon la LSDB de chaque nœuds, afin d’accélérer le calcul de route dans des regroupements de routeurs. Enfin, l’utilisation de routeurs distribués exécutant plusieurs instances de calcul des plus courts chemins
est proposé dans [JXLP09] afin d’accélérer l’étape de calcul. Néanmoins, ces améliorations, bien que permettant de réduire le temps de rétablissement d’un chemin, ne permettent pas de rendre une panne imperceptible par le trafic, laissant le champ libre des approches différentes.
L’approche complémentaire qui a suscité le plus d’engouement ces dernières années est celle du IP Fast ReRoute (IP FRR) [FB05] où les routeurs, au plus près de la panne, utilisent des routes pré-calculées afin de rétablir les flux de trafic rapidement, sans en informer tout le réseau et attendre la reconvergence totale du protocole IGP. IP FRR1 fait référence à un ensemble de propositions dont le but est de fournir un reroutage rapide en n’utilisant seulement les technologies de base du routage IP. Comme étudié par la suite dans le Chap. 4, des initiatives similaires ont également été proposées pour la technologie MPLS sous le nom de MPLS FRR2. L’idée à l’origine de IP FRR est que, lorsqu’une panne apparaît, les chemins des routeurs de la zone autour de la panne sont fortement perturbés mais les routeurs plus éloignés possède des routes toujours valides. Il est donc nécessaire de mettre en place des mécanismes permettant de les utiliser afin de continuer à transférer les paquets jusqu’à leur destination en attendant la mise à jour complète des tables de routage du réseau. Cela permet d’outrepasser les délais
tF + tSP + tU en fournissant un chemin temporaire utilisant les tables de routage disponibles (i.e. obsolète depuis la panne), en attendant les nouveaux chemins définitifs qui seront déployés à la fin du processus de convergence.
Une des premières techniques proposée pour rétablir rapidement un chemin est l’utilisation de plusieurs chemins avec des coûts identiques (ECMP3). Dans le cas d’une panne, il reste toujours l’autre plus court chemin de même poids afin de continuer à transférer le trafic. Une alternative est l’utilisation de Loop Free Alternate (LFA) [AZ08] où le routeur directement lié à l’équipement en panne, transfert le trafic vers un de ses voisins directs qui possède un chemin sans panne pour la destination du trafic. Lorsqu’un chemin LFA4 n’est pas disponible sur les voisin direct, le routeur recherche un routeur dans un périmètre élargi à plusieurs sauts si celui-ci possède un chemin sans panne. Ce mécanisme appelé réparation multi-saut [SB10] est décliné suivant plusieurs techniques. L’utilisation d’une adresse spéciale mentionnant le routeur à éviter est appelée Not-via address [SBP11, ESRC09]. Il est aussi possible d’utiliser la technique du U turn alternate [Atl06] qui utilise un voisin considérant ce routeur en question comme prochain saut principal pour la destination du paquet et qui possède également un LFA pour la destination de ce paquet, qui ne passe pas ce routeur. Une autre proposition de IP FRR est la possibilité pour un routeur d’inférer une possible panne sur un lien en recevant un paquet sur une interface inhabituelle [NLY+07, WN07] et de transférer le paquet vers un chemin évitant ce lien possiblement en panne. Le papier « Relaxed multiple routing configurations for IP fast reroute »[CHK+08] propose l’utilisation par les routeurs de plusieurs configuration de routage, en maintenant une FIB pour chaque cas de panne. Lorsqu’un routeur détecte une panne, il marque le paquet qui aurait autre fois été transféré vers le routeur en panne, pour que chaque routeur puisse utiliser la configuration de routage correspondant à la panne sur le routeur en question. Enfin Xi et Chao [BFPS07] propose l’utilisation de tunnel IP (IP-in-IP ou GRE5) pour joindre un routeur possédant un chemin sans panne jusqu’à la destination, pour ensuite utiliser le routage IP classique de ce routeur jusqu’à la destination.
Il est important de noter que les chemins temporaires empruntés grâce au IP FRR ne sont pas définitifs et qu’en parallèle, le processus de convergence s’exécute et viens remplacer les chemins temporaires lorsqu’il est achevé. Néanmoins, les techniques de routage rapides introduisent quand même une interruption de service puisqu’elle met un certain temps à se mettre en place, même si celui-ci est beaucoup plus court que la convergence OSPF. Le temps de détection qui a le plus d’incidence n’est pas traité par cette technique, et les chemins temporaires ne sont pas optimaux et peuvent introduire des boucles de routage et de la congestion dans certain cas.
Une autre approche connexe à notre proposition est l’utilisation du risque de pannes dans le routage. Afin de minimiser l’incidence d’une panne sur le trafic, la prise en compte du risque
1. IP Fast ReRoute 2. MPLS Fast ReRoute
3. Equal-cost multi-path routing 4. Loop Free Alternate
de pannes dans le routage a été étudiée au travers plusieurs initiatives. Des études ont proposé la prise en compte du risque de pannes dans le routage. Pour commencer, des propositions de routage basées sur la disponibilité du chemin [ZZZ+07, LQL08, MFH08] ont été utilisées afin de s’assurer de respecter un certain SLA. De même le risque de pannes a déjà été utilisé afin de minimiser le nombre de pannes potentielles touchant un chemin [LY07, YVJ05]. Mais le risque de pannes ici utilisé est un risque statique, c’est-à-dire qui ne varie pas dans le temps et qui provient de statistiques de fiabilité à long terme qui ne correspondent en rien au risque de pannes envisagé dans cette thèse par le module RAM. De manière similaire, dans [XTMM10], des statistiques longs termes sont utilisées afin de choisir le meilleur chemin capable de satisfaire une disponibilité précise. Ce chapitre propose une approche assez différente puisque notre risque de pannes est une donnée dynamique calculée en temps réel en observant l’état de santé des éléments de réseau.
3.5 Description de la proposition
Un des avantages majeurs de la restauration IP est son coté dynamique qui permet d’adapter de manière sur-mesure la configuration du réseau à la situation de la panne en cours. Mais le désavantage est le côté réactif. Les systèmes de gestion des pannes, notamment dans les télécommunications, traitent les incidents de manière réactive car c’est la façon la plus simple de régler le problème. Mais une approche réactive par essence implique une réaction après l’occurrence de la panne et ne permet donc pas de supprimer toutes les conséquences d’une panne sur le trafic. En effet, la restauration IP amène à des pertes de paquets tant que le processus de convergence d’OSPF n’est pas achevé. Les dispositifs d’IP FRR permettent de réduire ce délai mais pas de le supprimer et peuvent induire des boucles de routage et des topologies sous-optimales.
Nous avons exploré une nouvelle approche complémentaire, en ajoutant un mécanisme pré- ventif aux mécanismes de résilience actuels. Cette approche proactive évalue le risque de panne en temps réel afin de créer une fenêtre de temps dans laquelle des actions préventives peuvent être prises. En l’occurrence, il s’agit d’adapter le comportement du routage afin d’éviter l’impact néfaste de la panne imminente en forçant le trafic à contourner la future panne. Si l’on consi- dère que les réseaux des opérateurs sont dimensionnés et configurés pour supporter au moins une panne de façon transparente pour le trafic [FT02, NSB+03, NBTD07, RCT+11] une telle approche proactive semble tout à fait envisageable. La stratégie proposée est le changement temporaire de la métrique des liens ayant un fort risque de panne avec une valeur dissuadante pour le trafic (i.e. bien plus grande que les autres métriques).
3.5.1 Aperçu général du principe de re-routage proactif
En collectant une information de risque de panne temps réel du RAM, il est possible pour un agent autonome tel que le RM_DE, de prendre en compte ce risque dans le routage. Nous proposons donc au travers d’un module de Risk-Aware Routing (RAR) au sein des RM_DE (voir Fig. 3.1) d’utiliser le temps précieux précédant une panne pour préventivement obliger le trafic à éviter les éléments de réseaux risqués. Cela permet d’atténuer les effets d’une panne sur le trafic de l’utilisateur. Dans les réseaux avec un protocole IGP tel que IS-IS ou OSPF, cela se traduit par l’ajustement des métriques des liens de manière à dissuader les flux d’utiliser les liens risqués [RNP+11, VC10, CPP+10, KAB+11] (i.e. avec une valeur de métriques très grande et égale à RiskyMetric(linki) définit à la Sec. 3.5.2).
Les avantages de cette méthode sont multiples. Premièrement, si le lien fait partie du seul chemin vers une destination, il est toujours disponible. Cela permet notamment de limiter l’inci- dence des fausses prédictions par rapport à une stratégie ou le lien serait désactivé complètement. Lorsqu’une prédiction de panne se vérifie, le trafic à préventivement été envoyé sur un autre chemin, la panne ne perturbe donc pas le trafic (sauf pour les rares cas où le lien risqué faisait partie du seul chemin disponible, mais il est alors impossible de faire quelque chose dans ce cas extrême). Dans ce cas, le dispositif RAR permet de supprimer complètement l’interruption de service et ainsi d’assurer une meilleure QoS pour l’utilisateur.
Figure 3.1: Architecture fonctionnelle du mécanisme RAR.
Si la panne n’est pas anticipée, la panne est gérée par le processus de convergence du protocole IGP ; l’indisponibilité est donc celle de la restauration IP. S’il y a une fausse prédiction de panne, le trafic est inutilement rerouté. Mais les réseaux sont actuellement configurés pour supporter un tel reroutage, notamment dans le cas d’une panne [FT02, NSB+03, NBTD07, RCT+11], les conséquences sont donc minimes sauf dans le cas d’un trop grand nombres de faux positifs. C’est pourquoi la Sec. 3.9.2 s’attache à évaluer l’impact des faux positifs, notamment sur la congestion que peuvent impliquer les nombreux reroutages. De plus, alors qu’un reroutage avant une panne ne fait qu’anticiper la situation du routage après la panne, un reroutage suite à une fausse prédiction créé deux changements de routage inutile. Or (Cf Chap. 2) les opérateurs sont très attachés à maintenir la stabilité dans leur routage. Avec un nombre de faux positifs raisonnable, cela ne devrait pas modifier sensiblement la donne néanmoins il convient d’étudier l’incidence des fausses prédictions sur la stabilité du routage pour en être certain (Cf Sec. 3.8 et 3.9.2).
Un des avantages importants du mécanisme RAR est qu’aucun processus de standardisation n’est nécessaire et que la compatibilité avec les protocoles actuellement déployés est totale. Il suffit de modifier localement sur le bon routeur le poids d’un lien et d’exploiter les capacités de diffusion de la topologie de routage d’OSPF (et d’IS-IS) pour propager le nouveau schéma de routage augmenté de la prise en compte du risque à tout le réseau et ses flux.
Ensuite, il est essentiel de ne pas bousculer les pratiques actuelles utilisées par les opérateurs en configurant les métriques des liens comme précédemment, afin d’optimiser la bande passante, le délai, l’équilibrage de charge, etc. L’intervention préventive reste restreinte à une courte pé- riode de temps pendant laquelle un important risque de panne est détecté, et ne concerne que le poids des liens risqués.
Bien qu’il soit possible de choisir un ensemble plus complexe de niveaux de risque afin d’utiliser ce risque directement comme métrique, cela aurait limité la stratégie d’ingénierie de l’opérateur à n’optimiser que l’exposition au risque. Au contraire, notre approche composite permet de combiner des métriques définies par l’opérateur la plupart du temps et les métriques utilisant le risque de panne seulement lors de l’anticipation d’une panne. Cette méthode consiste à garder un poids faible pour les liens sûrs et à augmenter de manière significative le poids des liens risqués afin d’orienter le trafic loin d’eux, vers des chemins de coût faible. Dans ce but, le coût des liens risqués doit être assigné avec plusieurs contraintes.
3.5.2 Considérations protocolaires
Premièrement, les protocoles IGP ont des limitations intrinsèques et il est nécessaire de les prendre en compte. Dans le cas d’OSPF, les 16 bits définissant la métrique ne permettent pas d’utiliser une valeur positive supérieur à 216− 2, car la valeur maximum est réservée pour la représentation de l’infini. Soit MaxP ossibleCost cette valeur.
Deuxièmement, une métrique de lien risqué doit être suffisamment grande pour obliger tous les flux de trafic à préférer n’importe quel chemin sûr à la place d’un lien risqué. Cette contrainte implique d’avoir une valeur de métrique de risque toujours plus grande que le plus court chemin entre les deux extrémités du lien (à l’exception du lien risqué). Mais dans le cas où seul des che- mins risqués seraient possibles, il est nécessaire de pouvoir privilégier le chemin avec un nombre
minimum de liens risqués. En d’autres termes, les différentes métriques de liens risqués doivent être le plus proche possible afin de maximiser le nombre de détections de risques simultanés possibles. Soit ∆CostR la différence maximum entre deux métriques risquées et Min(CostR) la valeur de la plus petite métrique risquée, le nombre maximum de prédictions de panne simulta- nées possibles tout en conservant la relation d’ordre est Min(CostR)/∆CostR.
Le résultat de ces contraintes est que la base commune pour tous les liens doit être supé- rieure au plus long chemin initial du réseau sans boucle. Mais puisque l’accès à cette donnée est un problème difficile, il est préférable d’utiliser MaxP ossibleCost pour deux raisons. Premiè- rement, c’est la valeur autorisée ayant la plus forte probabilité d’être supérieure au plus long chemin. Deuxièmement, cette valeur ne cause pas vraiment de limitation en terme de prédictions simultanées. En effet, le champ intra-area supporte jusqu’à 28 métriques risqués ce qui est bien assez.
La quatrième contrainte concerne l’arbitrage entre deux chemins égaux contenant le même nombre de liens risqués. Avec l’utilisation d’une même valeur pour tous les liens risqués, il est impossible de choisir entre ces deux chemins. Mais puisque la métrique initiale reflète le choix de l’opérateur, il est préférable d’ajouter la valeur de la métrique initiale à la base commune afin de rendre l’arbitrage possible. En conséquence, la métrique d’un lien risqué i (RiskyMetric(linki)) correspond à MaxP ossibleCost − MaxInitialCost + InitialCost(linki) avec MaxInitialCost la métrique la plus grande dans la configuration initiale du réseau et InitialCost(linki) la valeur de la métrique du lien i configurée par l’opérateur.
Une fois que la métrique de risque a été calculée, le processus autonome en charge de modifier la métrique des liens OSPF de la configuration initiale vers la valeur de risque doit s’assurer de le faire d’une manière douce et itérative telle que décrite dans [FB07] afin d’éviter les boucles de routage pendant le processus de convergence.
3.5.3 Illustration par l’exemple
L’exemple décrit dans cette section permet de visualiser le comportement du mécanisme RAR de manière illustrative. Pour cette exemple, on considère la configuration définie par la Fig. 3.2 comme étant la situation stationnaire. Le réseau est composé et huit routeurs utilisant un protocole de routage de type IGP tel qu’OSPF. Pour notre exemple, ce réseau transporte trois flux de trafic, en utilisant les métriques de routage affichées à la Fig. 3.2.
Figure 3.2: Configuration initiale du réseau.
3.5.3.1 Cas d’une panne sans le mécanisme RAR
Afin de visualiser les effets du dispositif RAR par rapport au fonctionnement standard d’OSPF nous commençons par illustrer les effets d’une panne sans notre mécanisme proac- tif. La Fig. 3.3 montre l’apparition d’une panne sur le routeur R1. Ce routeur faisant partie du chemin emprunté par le flux 1, ce flux est interrompu, car les données envoyées vers R1 sont
perdues. Le protocole Hello permet de détecter la panne et d’initier le processus de convergence afin de rétablir le flux du trafic 1.
Figure 3.3: Panne avec l’utilisation d’un protocole de routage IGP.
Figure 3.4: Situation après la convergence du protocole IGP.
Après plusieurs secondes d’interruption de service, le processus de convergence se termine et permet aux routeurs d’avoir une vision correcte du réseau permettant de rétablir le flux 1. La Fig. 3.4 montre l’état du réseau une fois le flux 1 rétabli en utilisant les routeurs R4 et R7 pour contourner la panne. Les autres flux n’étant pas impactés par la panne, leur routage n’est pas modifié.
3.5.3.2 Cas d’une panne avec le mécanisme RAR
Avec le dispositif RAR, la situation peut être bien différente. Les équipements du réseau sont équipés de modules de prédiction de pannes RAM qui observent l’état du réseau en continue. À partir de la configuration initiale de la Fig. 3.2, la détection d’un risque de panne sur le routeur R1 aboutie à la situation représentée par la Fig. 3.5. Le module RAR présent dans le RM_DE du routeur R1 modifie les métriques de toutes ses interfaces réseaux pour atteindre une valeur suffisamment grande pour obliger le trafic passant par R1 à utiliser un chemin alternatif. Le flux 1 est donc préventivement router vers les routeurs R4 et R7. En conséquence plus aucune donnée n’est commutée par le routeur R1 dont l’état laisse penser qu’une panne est imminente.
Figure 3.5: Situation lors d’une panne avec le méca- nisme RAR.
Figure 3.6: Situation après la convergence du protocole IGP.
Quelques secondes plus tard, lorsque la panne apparait, celle-ci n’impact pas les flux de données puisqu’aucun flux n’utilise le routeur R1. La convergence du protocole de routage IGP permet de supprimer le routeur R1 de la topologie mais ne modifie pas le routage des flux. En
effet, le mécanisme RAR permet d’anticiper le routage qui sera effectif après le processus de