IP a une propriété
très utile : la route entre deux points n'est pas fixée à l'avance et
peut être modifiée même en cours de conversation. Cela permet aux
réseaux IP de continuer à fonctionner même lorsque des coupures
surviennent, s'il existe un chemin alternatif. Par contre, trouver ce
chemin alternatif et l'utiliser prend du temps et ce délai peut être
fatal à certaines applications plus ou moins
temps-réel. D'où la nécessité de développer une
méthodologie et des mécanismes pour un reroutage
rapide. Ce est consacré à décrire le
cadre général de ce reroutage rapide.
De tels mécanismes existent déjà pour certains protocoles de
couche 2, comme SONET,
ou de couche « 2,5 » comme MPLS. Mais le but du
travail sur le reroutage rapide IP est d'avoir une solution générale
pour tous les réseaux IP.
Donc, après une section 1 de terminologie, commençons par décrire
le problème (section 2). Lorsqu'un lien physique tombe en panne, même
si des liens alternatifs sont disponibles, il s'écoule une période non
nulle pendant laquelle les paquets ne peuvent plus être transmis. Ces
paquets sont alors souvent jetés par les routeurs. Traditionnellement,
dans un réseau IP, les
durées de ces périodes atteignaient facilement plusieurs
secondes. Pour certains applications (par exemple
SMTP) ce n'est pas un problème. Mais certains
services récents ont davantage de mal à tolérer ces courtes
coupures. Calculer de nouvelles routes, dans un environnement
distribué comme l'Internet, ne peut pas être
« temps-réel ». Mais il existe une autre solution : calculer
à l'avance les routes de secours ce qui
permettrait de remplacer la route passant par le lien en panne en un
temps bien plus court. C'est l'approche utilisée par le mécanisme
Fast Reroute de MPLS () et le but du projet IP Fast Reroute
est de spécifier des mécanismes analogues dans un environnement
purement IP.
Ces mécanismes sont loin d'être complètement définis, notre se contenant de définir un cadre général pour leur
élaboration. D'autre part, le projet se limite pour l'instant aux
IGP à état des liaisons
(section 3), une extension aux autres IGP ou bien aux protocoles
de routage externes comme BGP étant possible
dans le futur.
La section 4 du RFC analyse le problème. D'où vient le délai avant
que la route alternative soit utilisable ? Il y a plusieurs sources de
retard :
- Le temps de détection de la panne. Lorsque celle-ci peut être
détectée physiquement (câble Ethernet
débranché, avec perte du signal de lien), ce temps est parfois de
quelques milli-secondes. Mais, lorsque la détection se fait par
l'absence, pendant une certaine période, d'un message (par exemple le
paquet Hello d'OSPF),
alors, des durées de plusieurs dizaines de secondes sont
possibles.
- Le temps pour le routeur de se
reconfigurer.
- Le temps pour le routeur de passer l'information à ses voisins
(de dix à cent milli-secondes par saut entre deux routeurs).
- Le temps de recalculer les tables de routage (quelques
milli-secondes avec un algorithme comme celui de Dijkstra).
- Le temps de recharger les nouvelles tables, par exemple en
reconfigurant les ASIC. Il peut atteindre des
centaines de milli-secondes.
Toutes ces opérations n'étant pas instantanées et devant être
effectuées par plusieurs routeurs, le réseau sera dans un état
incohérent pendant un moment et on verra des micro-boucles temporaires
se former
(une micro-boucle est le ping-pong entre deux routeurs, chacun croyant
que l'autre est la meilleure route, cf. ).
Quels sont les mécanismes disponibles pour faire mieux ? La section
5 les expose. Pour la détection de la panne (section 5.1), l'aide du
matériel est bien pratique : si la
fibre est coupée, la disparition de la lumière
indique le problème immédiatement. Mais il existe aussi des protocoles
indépendants du protocole de routage, et dédiés à la détection de
pannes, comme BFD.
Pour réparer la panne, l'idée de base est de pré-calculer les
chemins alternatifs, ce qui permettra de les installer rapidement
(section 5.2). La plupart des pannes devraient pouvoir être réparées
avec les techniques du , qui ne nécessitent pas de
marquage spécial des paquets IP. Pour les autres, des
techniques plus avancées sont nécessaires comme le calcul et le
stockage à l'avance de plusieurs FIB dans les
routeurs, combinés avec un mécanisme de signalisation permettant
d'indiquer que le paquet doit prendre la route de secours. Des
mécanismes reposant sur un routage explicite, par exemple avec des
tunnels, sont également possibles.
Au fait, j'ai utilisé des termes vagues comme « la
plupart ». Peut-on les quantifier ? La section 5.2.2 analyse le succès
de chaque mécanisme en fonction de la topologie.
Enfin, pour la prévention des micro-boucles, la section 5.3 renvoie
au qui liste les possibilités.