Résumé

  • RFC 3469 découpait la reprise MPLS en détection, temporisation, notification, opération de bascule et retour effectif du trafic.
  • Un chemin préparé pouvait partager la panne, manquer de ressources réservées, dégrader le service ou laisser le trafic sans seconde protection après la bascule.

Le mot « secours » rassure parce qu’il ressemble déjà à un résultat. En février 2003, RFC 3469 montrait au contraire qu’il ne décrivait qu’une possibilité. Une route pouvait être calculée, signalée et conservée avant l’incident sans être physiquement indépendante, suffisamment dimensionnée ni disponible au moment précis où le chemin actif tombait.

Ce RFC Informationnel n’était pas une norme de protocole ni un compte rendu de déploiement. Il proposait une taxonomie et des critères de comparaison. Les redémarrages restaient hors de son périmètre. Son apport fut de rendre observable l’espace situé entre une défaillance et une restauration durable.

Deux modèles ouvraient le raisonnement. Le reroutage créait une route ou un segment après détection de la panne. La commutation de protection utilisait un chemin établi à l’avance. Les deux pouvaient se succéder : une protection rapide ramenait la connectivité, puis la convergence et l’ingénierie installaient un chemin de travail plus satisfaisant.

Cette combinaison produisait un état semi-stable. Les paquets pouvaient circuler alors que la topologie n’était pas encore optimisée, que la route de reprise n’offrait qu’une capacité réduite ou que le service n’avait plus de protection contre une seconde panne. Une alarme verte ne signifiait donc pas que le système avait retrouvé sa situation de sûreté initiale.

RFC 3469 attribuait cinq temps au premier cycle. T1 mesurait le passage de l’altération à sa détection. T2 autorisait une attente configurable. T3 transportait l’indication de panne jusqu’au Path Switch LSR lorsqu’un autre équipement avait observé le défaut. T4 couvrait les actions de reprise et leur éventuelle coordination avec le Path Merge LSR. T5 commençait après la dernière action et ne se terminait que lorsque le trafic était de nouveau arrivé au point perturbé.

T5 empêchait de confondre une transaction de contrôle avec le service. Une entrée de commutation pouvait être installée alors que les paquets restaient en vol, perdaient leur ordre, remplissaient une file ou rencontraient un goulot d’étranglement. La dernière commande réussie n’était pas le dernier fait du cycle.

La remise en service du chemin préféré constituait un autre cycle. Il fallait constater la réparation, déclarer la panne effacée, attendre éventuellement que la route se stabilise, transmettre cette information, effectuer la réversion puis vérifier le trafic. Une réversion immédiate pouvait transformer une réparation intermittente en nouvelle interruption. Un basculement make-before-break réduisait le risque sans produire à lui seul une preuve d’usage.

Le reroutage dynamique ajoutait encore une horloge. Après convergence, un nouveau chemin de travail pouvait être créé, un hold-down borné pouvait éviter les oscillations, puis le trafic était déplacé. La première route de secours achetait du temps ; elle ne garantissait pas la destination finale de l’ingénierie.

Le document séparait création du chemin et allocation des ressources. Un chemin pouvait être préétabli, simplement préqualifié ou créé à la demande. La bande passante, les tampons et la capacité de traitement pouvaient être réservés avant l’incident ou seulement après. Un chemin équivalent maintenait les garanties du chemin de travail ; un chemin limité acceptait une prestation inférieure et ne devait pas devenir une résidence invisible.

Les modèles 1+1 et 1:1 rendaient le coût concret. En 1+1, le trafic était dupliqué en permanence et le point de fusion choisissait une copie. En 1:1, la route de secours pouvait transporter un trafic de moindre priorité, ensuite préempté par le flux protégé. Dans les variantes 1:n ou m:n, l’existence d’une ressource partagée ne disait pas quelle combinaison de pannes elle pourrait absorber.

Le lieu de réparation modifiait la preuve. Une réparation locale, proche du lien ou du voisin défaillant, réduisait la notification mais couvrait une zone étroite. Une réparation globale pouvait offrir une meilleure séparation au prix d’un signal plus long jusqu’au point de réparation. Un autre point de sortie pouvait restaurer le transfert sans recréer la route perdue. Un tunnel de contournement pouvait agréger de nombreuses protections tout en n’ayant assez de ressources que pour quelques-unes simultanément.

La granularité comptait aussi. Seule une portion du trafic pouvait être protégée. La réussite d’une classe premium ne disait rien du sort des autres paquets. La mention historique des bits EXP doit être lue avec la clarification Traffic Class de RFC 5462 ; le sujet durable est l’autorité qui sélectionne le trafic couvert.

Une panne dure, une dégradation et une indication de couche inférieure n’étaient pas le même événement. Une dégradation devait franchir un seuil configuré avant de déclencher la reprise. L’équipement détecteur pouvait ne pas posséder l’autorité de basculer et envoyer un FIS au point de réparation. Observation, déclaration, notification et commande restaient quatre reçus distincts.

Après la bascule, le mode réversible conservait un chemin préféré et y ramenait le trafic une fois sa stabilité établie. Pendant ce temps, le flux utilisant déjà sa protection pouvait ne plus avoir de secours, tandis que les ressources de l’ancien chemin restaient immobilisées. En mode non réversible, la route de reprise devenait route de travail, l’ancienne pouvait devenir protection, ou une nouvelle paire optimisée était construite.

Le RFC distinguait ainsi le temps de reprise du temps de restauration complète. Le premier additionnait détection, attente, notification, opération et retour du trafic. Le second durait jusqu’à ce que les liens utilisés soient réellement conçus pour la charge en situation de panne. Ils ne coïncidaient que si la première reprise était déjà équivalente et permanente.

La liste de comparaison empêchait de réduire le résultat à des millisecondes : vulnérabilité pendant l’établissement, capacité de secours, latence ajoutée, qualité de protection, réordonnancement, état à maintenir, pertes et couverture. La référence à une commutation proche de 50 ms, comparable à SONET, exprimait une ambition de conception, pas une mesure de service.

RFC 4090 apporta ensuite le fast reroute RSVP-TE. RFC 4426, 4427 et 4428 précisèrent fonctions, vocabulaire et analyse multicouche. RFC 5714 traita la réparation rapide IP. Cette filiation ne prouve ni adoption générale, ni diversité physique, ni continuité applicative.

La primauté du code en fonctionnement de Heng Lu impose alors une lecture stricte : « préétabli » et « récupéré » sont des états symboliques tant que tables, ressources et trafic ne concordent pas. La spécification initiale minimale explique l’usage de primitives composables plutôt qu’un algorithme souverain. Les couches de réalité séparent défaut, signal, décision, paquet et résultat utilisateur.

L’héritage de RFC 3469 tient dans cette discipline. Inventorier une route de secours n’est pas enregistrer une reprise. Il faut savoir qui a vu la panne, qui l’a déclarée, où le signal est arrivé, quelle autorité a déplacé le trafic, quelles ressources existaient, quelle qualité a survécu et quand une nouvelle protection est redevenue disponible.

Sources