Proposition pour un routage sensible au risque de pannes

Proposition pour un routage sensible au risque de pannes

 La restauration IP

Le contexte de ce chapitre est similaire au chapitre précédent. Dans les réseaux IP, le routage intra omaine est effectué à l’aide des protocoles IGP tel qu’OSPF et IS S . Avec OSPF, chaque routeur d’une aire de routage découvre et construit une vue complète de la topologie du réseau. Chaque routeur OSPF doit signaler sa connectivité par l’intermédiaire de LSA1. Afin de réduire le nombre de messages échangés, plusieurs LSA sont regroupés au sein d’un mme paquet.

Ces LSA sont diffusés aux autres routeurs du réseau, afin qu’ils puissent construire une vue complète de la topologie. L’ensemble des LSA qui forment le graphe de la topologie est stocké dans une LSDB2. Basé sur cette topologie, chaque routeur calcule un arbre de plus court chemin dont il est la racine en utilisant un algorithme à état de liens tel que l’algorithme de Dijkstra. Il applique ensuite le résultat pour construire sa table de commutation (FIB3).

Lors d’un changement de topologie, typiquement une panne, le processus de convergence est déclenché. Ce processus décrit à la Sec. 2.2.1 nécessite une période tC pour rétablir les flux de trafic impactés par une panne. Cette convergence se fait en quatre étapes [PIM11] :– l’étape de détection de panne avec tD le temps de cette détection;– l’étape de diffusion des LSA d’une durée tF ;– le calcul des plus courts chemins dont la durée est notée tSP ; 1. Link State Advertisements 2. Link State DataBase 3. Forwarding Information Base 3.3.

Problématique 97– et l’écriture du nouveau routage dans les tables de routage et de commutation qui dure tU secondes. En conséquence, on obtient une durée de convergence tC = TD + TF + TSP + TU (voir Eq. (3.2)) durant laquelle la topologie de routage n’est pas cohérente. En l’état actuel, la durée d’indisponibilité des flux touchés par une panne due au processus de convergence est de l’ordre de plusieurs secondes, ce qui n’est pas acceptable pour les trafics premium tel que la VoIP, la vidéo, les services de télétravail interactifs, etc. 

La gestion des pannes dans les réseaux IP est effectuée au travers du processus de restauration IP. Une reconvergence complète du réseau est déclenchée suite à la détection d’une panne afin de mettre à jour les routeurs avec des chemins valides. Malheureusement, lors d’une panne dans le réseau, le protocole IGP prend du temps pour détecter la panne et rétablir une vue cohérente de la nouvelle topologie du réseau. Durant cette transition, le trafic transféré vers les équipements en panne sera perdu.

De plus, des boucles de routage peuvent apparaître et engendrer de la congestion. Ces pertes engendrent une interruption de service de plusieurs secondes, ce qui n’est pas acceptable pour le trafic sensible à la QoS (VoIP, Vidéo, etc.). Des techniques ont été proposées afin de réduire le délai de convergence (Cf Sec. 3.4), notamment pour accélérer l’étape de détection de panne traitée au Chap. 2. Néanmoins, le délai de convergence reste impactant pour les trafics nécessitant une QoS garantie. La nature réactive du dispositif de restauration permet d’adapter le routage du réseau à une panne de manière optimale, contrairement aux mécanismes de protection, comme peut le propo ser le protocole GMPLS (voir Sec. 4.2.3.1).

La simplicité d’utilisation et la nature relativement autonome du protocole IP sans connexion [RNP+11] en font un candidat crédible par rapport à GMPLS dans bien des cas. Il est donc important d’améliorer ses défauts, notamment sa gestion des pannes dont la nature réactive oblige à conserver une interruption de service pendant le processus de reconvergence, ce qui pénalise le trafic des utilisateurs. 

Amélioration du délai de restauration IP

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é alculant à 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 ds, 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