Malgré l’existence d’un ensemble complet de dispositifs de résilience au sein du protocole GMPLS, l’utilisation à bon escient du mécanisme adapté est un problème en soi. Le choix de la stratégie à adopter est un problème pour de nombreux opérateurs auxquels la communauté scientifique a tenté de répondre [CLSS02]. Ce n’est pas un problème simple puisque chaque technique possède des avantages et des inconvénients. La protection permet une interruption minimum mais est très coûteuse alors que la restauration est peu onéreuse mais engendre une indisponibilité importante.
Des propositions ont été faites afin d’améliorer l’efficacité des mécanismes de résilience, soit en améliorant le coût des dispositifs de protection, soit d’une manière plus commune, en diminuant le temps de rétablissement du service avec le mécanisme peu coûteux de la restauration.
La protection a pour principal inconvénient de nécessiter la réservation des ressources pour les LSP de protection, ce qui est très coûteux en CAPEX comme en OPEX. Pour réduire ce défaut, le concept de préemption permet à plusieurs LSP de réserver une même ressource, un ordre de priorité permettant d’arbitrer l’utilisation de la ressource lorsque plusieurs LSP veulent l’utiliser en même temps. Cette possibilité augmente le temps de rétablissement d’un service
car il est désormais nécessaire de signaler le choix d’utilisation de la ressource partagée, mais cela reste plus performant que la restauration et permet de diminuer les coûts. Néanmoins, l’utilisation de cette option est complexe. Il est difficile pour un opérateur de maîtriser entiè- rement son comportement et d’en prévoir les conséquences. En réponse, de nombreux travaux [Gro04, LGS02, CTS03, GAVC05, SFT+06] ont proposé des approches pour partager efficace- ment les ressources de protection et ainsi de faire baisser le coût de cette technique. Mais la restauration reste toujours plus intéressante en terme de coût et possède une nature dynamique qui la rend plus robuste aux multiples pannes.
L’autre alternative est l’amélioration des performances de la restauration. Cette option a été de loin la plus étudiée. Comme vu aux Sec. 2.4 et 3.4, de nombreuses propositions ont été faites pour réduire les différente étapes de la convergence des protocoles IGP [FFEB05] afin de rendre viable l’utilisation de la restauration pour les réseaux à haute disponibilité [SRM02, PIKF04]. De plus, en ce qui concerne l’utilisation de la technologie de commutation de paquets, il existe de manière similaire à la restauration IP, des mécanismes permettant d’outrepasser le délai de convergence par des décisions locales mettant en place des chemins temporaires [TWFV06]. Le MPLS Fast ReRoute (MPLS FRR) [RI07, PSA05, VPD04] comme le IP FRR possède les techniques de Loop Free Alternate (LFA), de U turn alternate, de Not-via address et de tunneling. De nombreux travaux ont proposé des modalités d’amélioration de la mise en œuvre du MPLS FRR [RI07, WWM+10] mais cette solution ne permet pas d’assurer une disponibilité comparable à la protection et génère des topologies non optimales avec des chemins plus longs, des délais d’acheminement plus longs et de possibles boucles de routage.
En dépit des évolutions améliorant les deux catégories de mécanismes de résilience, et au regard de la nature statique des stratégies de gestion des pannes actuelles, le choix de confi- guration est toujours un compromis entre vitesse et consommation de ressources. En réponse, nous proposons une approche d’autoréparation complètement différente qui utilise l’estimation en temps réel du risque de pannes pour alterner dynamiquement entre la protection et la res- tauration afin de minimiser les coûts consacrés à la gestion des pannes tout en maintenant une disponibilité importante.
4.5 Description de la proposition
Le principal défaut des dispositifs de résilience de GMPLS est leur nature statique alors que la probabilité de panne évolue dans le temps. Avec des modules RAM capables de détecter en temps réel lorsque le risque de panne devient important, il devient possible d’envisager d’utiliser cette information pour modifier dynamiquement la gestion des pannes. Une telle intervention nécessite qu’elle soit effectuée en quelques secondes maximum ce que n’est pas capable de réa- liser un opérateur humain. C’est pourquoi le principe de réseau autonome est le candidat idéal pour implémenter une telle fonctionnalité au sein des équipements réseaux. L’utilisation d’une information de risques fourni par le RAM permet au réseau d’adapter de manière extrêmement rapide son mécanisme de gestion des pannes au risque de pannes en temps réel et ainsi d’obtenir une meilleure efficacité. Notre proposition a pour but de fournir une protection minimum lorsque le risque de panne est faible afin de limiter le coût de la gestion des pannes, et une protection maximum lorsqu’un risque de panne est détecté, afin de minimiser le délai de rétablissement du LSP. Le mécanisme ALR1 repose sur l’utilisation de la restauration en temps normal, et de l’établissement de LSP de protection temporaire lorsqu’un élément du LSP est concerné par une prédiction de panne [VNC12, WTVL13, PKM+09, PKA+10, VCL+11]. On obtient donc pour un coût proche de la restauration, de meilleures performances en termes de disponibilité.
4.5.1 Aperçu général du principe de résilience dynamique
L’objectif du dispositif ALR est d’améliorer les performances de la résilience de GMPLS en introduisant la prédiction de pannes au sein des équipements de réseau. Le mécanisme joue sur l’augmentation temporaire du niveau de protection d’un LSP possédant un routeur risqué afin
d’être prêt si une panne devait effectivement apparaître [VNC12, WTVL13, PKM+09, PKA+10, VCL+11]. Le reste du temps, quand le risque de panne est faible, le LSP peut rester moins protégé ce qui permet à l’opérateur d’avoir plus de ressources disponibles.
L’objectif de cette proposition n’est pas d’assurer une disponibilité semblable à la protection, mais d’exploiter au mieux les informations sur les pannes possibles dans le réseau afin d’améliorer la disponibilité fournit par la restauration. Ainsi, lors d’une prédiction de panne, la rapidité d’exécution des machines permet au couple RAM et au module FMF du R&S_DE de déclencher la modification du mécanisme de résilience des LSP concernés par la panne, afin, le cas échéant, d’être capable de rétablir le LSP dans un délai minimum. De plus, cette méthode permet les performances de disponibilité de la protection avec l’avantage de la restauration puisque l’on connaît à l’avance les éléments concernés par la future panne. Ainsi il est possible d’adapter le chemin du LSP de protection de façon optimale pour n’exclure que les éléments risqués.
Si par contre la prédiction devait s’avérer être fausse, le trafic ne serait pas impacté, mais les ressources réservées pendant le temps de la prédiction ∆tp auraient été inutilement consommées, créant un coût supplémentaire. Néanmoins, cette surconsommation limitée au temps ∆tp reste négligeable comme en atteste les résultats obtenus. (Cf les sections suivantes). Enfin, si une panne n’est pas précédée par une prédiction, c’est le dispositif de restauration qui est utilisé pour rétablir les services perturbés. Cela permet d’obtenir un meilleur ratio coût/disponibilité que les mécanismes de protection et de restauration du protocole GMPLS en exploitant les indicateurs de l’état de santé du réseau, ainsi que la rapidité d’exécution (supérieure à celle d’un être humain) que permet l’autoréparation.
Afin de réaliser ce changement dynamique, le module FMF du R&S_DE (voir Fig. 4.2), suite à la réception d’une information de risques de panne en provenance du RAM, doit prendre le contrôle des éléments en charge du protocole GMPLS (i.e. OSPT-TE et RSVP-TE) sur le Ingress router de chaque LSP concerné par la panne afin de modifier le mécanisme de résilience associé à chaque LSP. Pour ce faire, il est nécessaire de prendre en compte les spécificités et outils du protocole GMPLS tel que le MBB et le XRO1.
Figure 4.2: Architecture fonctionnelle du mécanisme ALR.
4.5.2 Considérations protocolaires
Le dispositif ALR doit composer avec les spécificités du protocole GMPLS, pour en décrire le fonctionnement. Ceci est illustré au travers de l’exemple des Fig. 4.4, 4.5 et 4.6 de la section suivante.
Afin de changer le niveau de protection, deux procédures distinctes sont nécessaires. La première a pour rôle de mettre à jour le chemin principal (working) avec les nouvelles caracté- ristiques du mécanisme de résilience. La seconde a pour rôle la configuration et la mise en place éventuelle des ressources dédiées au chemin de sauvegarde.
En effet, la protection et la restauration GMPLS concernent trois objets décrits dans la RFC4872 [LRP07] : les objets Session, Association et Protection. L’objet « session »contient des paramètres pour identifier un LSP tel qu’un Tunnel ID, un LSP ID ainsi que la source
et la destination du tunnel. Un tunnel protégé est composé de deux LSP possédant le même Tunnel ID. Le LSP ID permet de différencier les deux LSP du tunnel que sont le LSP working et le LSP protection. L’objet « association »contient un paramètre important, l’Association ID qui référence le LSP associé, c’est-à-dire le LSP working lors du basculement sur le LSP de protection et vice-versa. Enfin, l’objet « protection »représenté à la Fig. 4.3 contient les détails du schéma de résilience :
– 0x00 pour non protégé ; – 0x01 pour reroutage complet ;
– 0x02 pour reroutage avec trafic externe ; – 0x04 pour la protection 1 :N (N>=1) ;
– 0x08 pour la protection 1+1 unidirectionnelle ; – 0x10 pour la protection 1+1 bidirectionnelle.
Figure 4.3: Objet protection de RSVP.
Les autres paramètres importants comprennent un bit (P) qui précise si le LSP est un LSP de protection, un bit (O) qui renseigne si le LSP est actuellement en train de transporter du trafic et un bit (S) qui indique si la protection est cross-connectée.
La mise à jour dynamique du mécanisme de résilience utilisé nécessite de modifier ces trois objets sur le LSP principal et dans le même temps de créer le nouveau LSP de sauvegarde et les ressources qui lui sont associées.
Mais, la mise à jour dynamique de la protection d’un LSP n’est pas nativement supportée par le protocole GMPLS. Il est donc nécessaire de combiner cela avec un second mécanisme nommé Make-Before-Break (MBB). Le MBB défini dans la RFC3209 [ABG+01] permet de cloner un LSP avant de supprimer les ressources de celui-ci. Ce dispositif utilise l’option Shared Explicit qui rend possible l’utilisation par le nouveau LSP des mêmes ressources que le précédant LSP sur les segments qui sont partagés. En effet, le nouveau LSP principal doit avoir un chemin identique à l’ancien LSP. Sans l’option Shared Explicit, il est fort possible que l’établissement du nouveau LSP principal ne soit pas possible par manque de bande passante. Avec cette option, le nouveau LSP peut utiliser les ressources de l’ancien LSP. Une fois le nouveau LSP établi avec les bons paramètres de gestion des pannes, le trafic peut être basculé d’un LSP à l’autre, sans perturbation du service.
De plus, un objet particulier appelé Exclude Route Object (XRO), définit dans la RFC4874 [LFC07], permet de spécifier des routeurs à exclure de la route d’un LSP. Cet objet est utilisé pour la création du LSP de protection afin de ne pas utiliser les routeurs avec un risque de panne. En combinant les trois composants que sont les objets du mécanisme de résilience, le MBB avec l’option Shared Explicit et le XRO, il est possible d’implémenter un mécanisme de résilience adaptatif entièrement compatible avec les spécifications de GMPLS.
4.5.2.1 Extension protocolaire pour une meilleure intégration au protocole de ges-
tion des pannes de GMPLS
Même si le changement du dispositif de résilience est possible par l’intermédiaire du MBB, cela pourrait être fait de manière beaucoup plus efficace. En effet, cette modification ne change pas fondamentalement les caractéristiques du LSP principale. Une simple mise à jour de ce LSP avec les nouvelles caractéristiques de la résilience serait préférable à l’établissement complet d’un nouveau LSP principal comme c’est le cas avec le MBB. Les étapes de signalisation du nouveau LSP de protection restent néanmoins obligatoires.
Une autre amélioration possible est l’intégration du mécanisme de changement de niveau de protection au sein du contrôleur GMPLS. En effet, il serait possible d’utiliser le mécanisme
de notification (message notify) pour transporter l’information de risque de panne jusqu’au routeur d’entrée du LSP. Pour cela, il serait nécessaire d’ajouter des nouveaux Error_Code dans l’objet ERROR_SPEC du message notify afin de signifier lorsqu’un risque de panne est détecté, ou lorsqu’un élément redevient non risqué. Suite à la réception du message notify, le routeur d’entrée du LSP pourrait alors automatiquement déclencher le changement du dispositif de résilience. Mais ce type de fonctionnement peut ne pas être désiré par tous les opérateurs et ce sur tous les LSP, il est donc nécessaire de rajouter une option pour activer ou non ce type de fonctionnement sur un LSP. Une option possible serait l’utilisation des bits de poids fort du champ LSP Protection Type de l’objet protection [LRP07] qui sont actuellement non utilisés et qui permettrait de spécifier si un changement de mécanisme de résilience doit être initié lorsqu’une information de risque de panne est reçu par l’intermédiaire d’un message notify. Néanmoins, les mécanismes de MBB permettent une première implémentation du dispositif ALR sans extension protocolaire, ce qui est un avantage pour la promotion de ce nouveau mécanisme d’autoréparation proactif.
4.5.3 Illustration par l’exemple
L’exemple décrit ci-dessous permet de visualiser le comportement du mécanisme de manière pratique. La Fig. 4.4 illustre la situation normale où un LSP est établi pour transporter du trafic entre deux routeurs. Aucun des routeurs composant le chemin du LSP principale étant risqué, aucun LSP de protection n’est configuré ; c’est donc la restauration qui fait office de mécanisme de résilience associé.
Figure 4.4: Configuration initiale du mécanisme ALR.
Dans un deuxième temps (voir Fig. 4.5), le système de refroidissement du routeur situé au milieu du LSP tombe en panne. Cela se traduit rapidement par une augmentation de la tempé- rature qui est observée par le module de prédiction de pannes du RAM. Lorsque la température devient trop importante, le RAM de l’équipement concerné diffuse une information de risque de panne aux éléments concernés et notamment au module FMF du R&S_DE en charge du contrôle de GMPLS. Une fois l’information de risque de panne reçue, le nœud source du LSP est piloté afin de déclencher le changement du dispositif de résilience pour utiliser la protection. Afin d’établir un LSP de protection, le routeur de bordure calcule le nouveau chemin pour la protection avec un XRO contenant le routeur risqué. Il doit aussi re-signaler un nouveau LSP principal qui utilise les même ressources que le précédant LSP en faisant usage de l’option Sha- red Explicit du MBB. Enfin, une fois le nouveau LSP principal associé au LSP de protection, le trafic peut alors utiliser le nouveau tunnel de manière transparente pour l’utilisateur. L’ancien LSP principal peut alors être supprimé pour aboutir à la configuration de la Fig. 4.5 où le trafic est maintenant protégé par un LSP dédié.
Figure 4.5: Modification du mécanisme de résilience de la restauration vers la protection. Ainsi, lorsque la panne apparaît, comme l’illustre la Fig. 4.6, le trafic est orienté de ma- nière extrêmement rapide sur le LSP de protection afin de minimiser l’interruption du service. L’utilisation de la protection aura permis une interruption de service beaucoup plus faible que
Figure 4.6: Incidence d’une panne sur le mécanisme ALR.
si la restauration avait dû s’appliquer. Mais la majorité du temps, lorsqu’aucun risque de panne n’est détecté, les LSP sont configurés pour utiliser la restauration comme l’illustre la Fig. 4.4, ce qui permet une consommation des ressources beaucoup moins importante qu’avec l’utilisation de la protection de manière systématique.
4.5.4 Algorithme
L’Algorithme 3 résume le déroulement du dispositif ALR suite à l’envoi d’une information de risque de panne par le RAM au module FMF. Cette information de risque de panne peut concerner trois types d’équipements, le routeur (noté n ∈ N où N est l’ensemble des routeurs du réseau), un lien du routeur (noté link) ou l’interface à laquelle est rattachée ce lien sur le routeur (noté IF).
algorithme 3 Adaptation du mécanisme de résilience de GMPLS.
1: for each router niin N do
2: if ni.new_risk > ni.old_risk then 3: forAll lspjin ni.lsp do
4: if not lspj.isprotected() OR ( lspj.isprotected() AND niin lspj.Protection_Path ) then 5: create new Working LSP with SharedExplicit option (Make-BeFore-Break)
6: create new Protection Path by adding ni to XRO
7: execute Associate (new Working LSP, new Protection Path) 8: execute Switch traffic From lspj.working to new Working LSP 9: delete lspj.old_working_LSP 10: if lspj.old_Protection_Path.exist() then 11: delete lspj.old_Protection_Path 12: end if 13: end if 14: end for
15: else if ni.new_risk <ni.old_risk then 16: forAll lspjin ni.lsp do
17: if not lspj.working_LSP.contain_risky_element() then
18: create new Working LSP with SharedExplicit option (Make-BeFore-Break) 19: execute ConfigureRecoveryLevel(new Working LSP, Restoration)
20: execute Switch traffic From lspj.working to new Working LSP 21: delete lspj.Protection_Path
22: delete lspj.old_working_LSP
23: else
24: create new Working LSP with SharedExplicit option (Make-BeFore-Break) 25: create new Protection Path by removing nito XRO
26: execute Associate (new Working LSP, new Protection Path) 27: execute Switch traffic From lspj.working to new Working LSP 28: delete lspj.old_working_LSP
29: delete lspj.old_Protection_Path 30: end if
31: end for
32: else if ni.new_risk = normal then 33: foreach linkk in ni.links do
34: if (linkk.new_risk > linkk.old_risk) OR (linkk.If.new_risk > linkk.If.old_risk) then 35: forAll lspj in linkk.lsp do
36: if not lspj.isprotected() OR ( lspj.isprotected() AND linkkin lspj.Protection_Path ) then 37: create new Working LSP with SharedExplicit option (Make-BeFore-Break)
38: create new Protection Path by adding linkk to XRO 39: execute Associate (new Working LSP, new Protection Path) 40: execute Switch traffic From lspj.working to new Working LSP
41: delete lspj.old_working_LSP 42: if lspj.old_Protection_Path.exist() then 43: delete lspj.old_Protection_Path 44: end if 45: end if 46: end for
47: else if (linkk.new_risk < linkk.old_risk) OR (linkk.If.new_risk < linkk.If.old_risk) then 48: forAll lspj in linkk.lsp do
49: if not lspj.working_LSP.contain_risky_element() then
50: create new Working LSP with SharedExplicit option (Make-BeFore-Break) 51: execute ConfigureRecoveryLevel(new Working LSP, Restoration)
52: execute Switch traffic From lspj.working to new Working LSP 53: delete lspj.Protection_Path
54: delete lspj.old_working_LSP
55: else
56: create new Working LSP with SharedExplicit option (Make-BeFore-Break) 57: create new Protection Path by removing linkkfrom XRO
58: execute Associate (new Working LSP, new Protection Path) 59: execute Switch traffic From lspj.working to new Working LSP
60: delete lspj.old_working_LSP 61: delete lspj.old_Protection_Path 62: end if 63: end for 64: end if 65: end for 66: end if 67: end for
4.6 Modélisation analytique
Cette section définit le modèle analytique permettant de comparer les performances de notre mécanisme adaptatif de résilience avec les mécanismes classiques de restauration (R) et de protection 1 :1 (P). Les deux critères principaux de notre comparaison sont l’indisponibilité de service et la consommation de ressources réseaux. Pour cela, notre modèle analytique prend en compte la probabilité de panne d’un élément de réseau (MTBF, MTTR), mais pour des raisons de simplicité, nous ne considérons dans cette thèse, que les pannes de routeurs. Le modèle reste néanmoins facilement transposable à l’ajout des pannes de lien ou de carte de ligne. De plus, les performances de la prédiction de pannes sont aussi pris en compte via les paramètres Recall,
P recision et ∆tp.
4.6.1 Définitions et notations
Le réseau est représenté par un graphe orienté G=(N,E) où N est l’ensemble des nœuds (routeurs) du réseau et E l’ensemble des liens orientés. Le trafic est représenté par l’ensemble