Résumé

  • Le head-end demande la protection et conserve les contraintes FAST_REROUTE inchangées. Le PLR calcule ou choisit un secours admissible et l’active localement ; le point de fusion rejoint le LSP protégé.
  • Un détour un-à-un possède un état de secours par LSP. Un bypass de facility peut servir plusieurs LSP admissibles, généralement par empilement d’étiquettes, au prix de dépendances communes de capacité et de destin.
  • Le RFC 8796 introduit une signalisation FRR résumée destinée à réduire les échanges et la pression d’échelle. Le RFC 9705 ajoute une gestion indépendante des rafraîchissements. Ces mises à jour ne prouvent pas que toutes les implémentations les prennent en charge.

Autorité et séquence

Le RFC 4090 concerne les LSP RSVP-TE explicitement routés, et non les LSP unicast IGP modifiés dynamiquement. Le LER head-end insère l’objet FAST_REROUTE ; les LSR en aval ne doivent pas le modifier. L’objet porte notamment les priorités d’établissement et de maintien, la bande passante demandée ou estimée, la limite de sauts, la méthode de protection et les filtres d’attributs de lien ou d’affinité. Le head-end peut demander la protection locale, l’enregistrement des labels, la protection de nœud et celle de la bande passante.

La priorité d’établissement détermine si une session peut obtenir des ressources en préemptant une autre ; la priorité de maintien détermine si sa propre réservation peut être préemptée. Une demande de bande passante indisponible peut produire un PathErr, sauf si des réservations admissibles de priorité inférieure peuvent être préemptées. Il s’agit de règles d’autorité sur les ressources, non d’une preuve qu’un secours existe.

Le PLR est l’acteur local. Lorsqu’il détecte la panne d’un lien ou d’un nœud protégé, il redirige les données et le contrôle vers le secours sélectionné. La détection est une entrée, pas une autorité de réparation : elle ne permet pas d’inventer un nouveau chemin. Le PLR reste dans les contraintes demandées et dans l’état de transmission disponible. L’indication local-protection-available exige un chemin de secours disponible et l’état de transmission nécessaire, conformément à l’erratum vérifié 4203. Lorsque la protection agit, le PLR marque local-protection-in-use et devrait notifier le head-end par un PathErr.

Le point de fusion a une fonction distincte : il retire, si nécessaire, le contexte du bypass et ramène le trafic sur le LSP protégé. Dans un bypass de facility, le PLR applique le label du LSP protégé puis pousse celui du tunnel de bypass ; le point de fusion retire ce contexte. Ni le PLR ni le point de fusion ne deviennent le head-end. La réoptimisation globale reste une fonction du head-end.

Détour ou bypass partagé

Le détour un-à-un est propre à un LSP. Il permet des contraintes précises, mais les tunnels, labels, messages et réservations augmentent avec le nombre de LSP. Le bypass de facility protège plusieurs LSP qui partagent une facility protégée et un point de fusion. Il peut réduire l’état répété, mais sa capacité, sa compatibilité et son état commun touchent un ensemble plus vaste. Analyse : il échange un coût par LSP contre une dépendance partagée ; une panne du bypass ou un état obsolète peut donc élargir l’impact potentiel. Bande passante, protection de lien ou de nœud, affinité et limite de sauts déterminent l’éligibilité sans la garantir.

Le RFC 8796 met à jour le bypass de facility avec une signalisation FRR résumée, destinée à diminuer les échanges PLR/point de fusion ainsi que la pression de contrôle lorsque beaucoup de LSP partagent un bypass. Le RFC 9705 met à jour la protection de facility afin que la maintenance d’état et le nettoyage d’état obsolète ne dépendent plus nécessairement de courts délais de rafraîchissement ; il ajoute des procédures explicites de capacité, d’adjacence et de suppression. La prise en charge réelle et l’interopérabilité restent inconnues.

Retour, coûts et limites

Le RFC 4090 distingue le retour global, où le head-end réoptimise les LSP TE avec une vue plus large, du retour local facultatif au PLR. Il recommande le mode global et note que le retour local peut ajouter des interruptions lorsque les ressources fluctuent. Le PathErr informe le head-end ; il ne transforme pas le chemin local temporaire en nouvelle conception de bout en bout.

Analyse : les services sensibles à la latence ou aux pertes peuvent bénéficier d’une continuité locale, et l’exploitant peut éviter d’attendre la propagation et le calcul à l’échelle du réseau. En contrepartie, il faut de la capacité réservée ou préemptible, des labels et états de signalisation, du nettoyage et des tests. Sans réparation préétablie, l’attente de la convergence du head-end ou du routage peut prolonger l’exposition et les pertes. À l’inverse, un état obsolète ou une réservation épuisée peut détourner rapidement le trafic vers une protection qui ne respecte plus l’hypothèse initiale.

Les faits sont ceux des RFC cités et des errata vérifiés ; les implications de direction sont une analyse. Il n’y a aucune allégation. Restent inconnus : fournisseurs, déploiements, marges de capacité, qualité de détection, temps mesurés, résultats clients, pannes simultanées, instabilité et interopérabilité multiversion. L’objectif normatif de redirection un-à-un est de l’ordre de dizaines de millisecondes ; ce n’est pas une mesure universelle.

Fixtures de vérification

  1. Autorité : établir un LSP RSVP-TE explicitement routé avec FAST_REROUTE, enregistrement des labels, protection de nœud, bande passante, priorités, limite de sauts et filtres d’affinité. Vérifier que seul le head-end insère l’objet et qu’il reste inchangé.
  2. Disponibilité : inspecter le PLR avant panne. Vérifier que local-protection-available n’est indiqué que si le secours admissible et l’état de transmission existent ; tester l’erratum 4203.
  3. Panne : retirer un lien puis un nœud. Capturer les opérations de labels du PLR, local-protection-in-use, la redirection et le PathErr vers le head-end.
  4. Méthode : comparer détour un-à-un et bypass de facility ; vérifier au PLR l’empilement label du LSP protégé + label du bypass, puis son retrait au point de fusion.
  5. Ressources : imposer une demande de bande passante avec priorités concurrentes d’établissement et de maintien ; vérifier préemption, PathErr, protection de lien, de nœud et échec d’affinité.
  6. Cycle de vie : tester retours global et local, instabilité répétée, signalisation résumée RFC 8796 et procédures RFC 9705 uniquement si l’implémentation revendique ces fonctions.

Sources