Mon blog

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 RFC 5714 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 (RFC 4090) 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 RFC 5714 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. RFC 5715).

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 RFC 5286, 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 RFC 5715 qui liste les possibilités.