Résumé

  • La RFC 3477 associait un Router ID stable à un Interface ID local afin que RSVP-TE puisse désigner et enregistrer un lien point à point non numéroté.
  • Les deux extrémités pouvaient choisir des valeurs sans rapport entre elles ; l’ERO, la résolution IF_ID, le RRO et la réalité du transfert restaient des preuves distinctes.

« Non numéroté » ne signifiait pas « sans identité ». Le lien décrit par la RFC 3477 disposait même de deux noms. Chacun venait du routeur de commutation par étiquettes placé à une extrémité, et aucun n’avait vocation à devenir le numéro universel du câble.

Chaque LSR attribuait une valeur non nulle sur 32 bits, unique dans son propre périmètre. Le texte précisait qu’aucune relation préalable ne devait exister entre les deux valeurs. Depuis A, le nombre choisi par A était local et celui de B distant. Depuis B, les adjectifs s’inversaient. Le point de vue faisait donc partie de la donnée.

Cette architecture évitait une fausse centralisation. Un identifiant local est simple à administrer, mais il devient ambigu dès qu’on le détache de l’autorité qui l’a produit. La RFC 3477 lui ajoutait un Router ID stable, normalement une adresse de bouclage qui demeure joignable tant qu’un chemin quelconque vers le LSR subsiste. La référence exploitable était le couple Router ID–Interface ID.

Deux routeurs pouvaient employer le même nombre pour des liens différents sans collision, car leurs Router ID différaient. Inversement, un même lien pouvait porter deux nombres différents sans incohérence. La portée n’était pas une faiblesse à nettoyer dans une base de données ; elle était la condition qui permettait aux décisions locales de coexister.

Il fallait néanmoins échanger ces décisions. La configuration, LMP, RSVP ou CR-LDP pour une forwarding adjacency, ainsi que les extensions IS-IS ou OSPF pouvaient transmettre les correspondances. Quand un IGP soutenait l’ingénierie de trafic, ses modules et RSVP devaient s’accorder sur les valeurs. Le protocole transportait un nom dont la fiabilité dépendait encore d’une table de correspondance datée.

La première utilisation concernait l’intention de route. La RFC ajoutait à l’Explicit Route Object un sous-objet Unnumbered Interface ID de type 4 et de longueur 12. Il contenait le Router ID et l’Interface ID attribué par ce routeur. Dans l’ERO, ce couple disait quel lien devait servir à l’étape suivante. Il ne constatait pas que le passage avait eu lieu.

La résolution constituait une deuxième preuve. En choisissant un lien sortant non numéroté, le nœud plaçait son Router ID et son identifiant local dans IF_ID RSVP_HOP. Le destinataire devait connaître les identifiants attribués par ses voisins et rechercher la correspondance. En l’absence de résultat, le texte recommandait IF_ID ERROR_SPEC, code 24, valeur 16 : « Unknown Interface Index ».

Cette erreur borne correctement ce qui est connu. Elle établit qu’un récepteur n’a pas résolu un couple donné avec l’état qu’il possédait alors. Elle ne démontre ni l’inexistence de la fibre, ni une tromperie du voisin, ni l’impossibilité d’un autre chemin. Pour comprendre la panne, il faut conserver la source de la correspondance, sa date, la direction du message et l’état des protocoles concernés.

Le Record Route Object reprenait le même format de type 4 et de longueur 12, mais pour un autre acte. L’ERO formulait une route voulue ; le RRO accumulait une trace dans l’état de signalisation RSVP. L’identité du format ne rendait pas les deux affirmations équivalentes.

Les bits de protection rendaient la différence encore plus nette. Un bit signalait qu’une protection locale était disponible ; un autre qu’elle était effectivement utilisée, généralement à la suite d’une défaillance. Une capacité de réparation et une réparation active ne sont pas le même événement. Les résumer sous le seul mot « protégé » détruit la chronologie.

Le cas des forwarding adjacencies étendait le principe au-delà d’un port physique. Un LSP annoncé comme lien non numéroté recevait lui aussi une identité à chaque extrémité. L’objet LSP_TUNNEL_INTERFACE_ID, classe 193 et C-Type 1, pouvait porter l’identité avant dans Path et l’identité inverse dans Resv. Même un lien construit par signalisation conservait deux autorités de nommage.

Les RFC ultérieures sur GMPLS, OSPF, IS-IS et les faisceaux de liens replacèrent ce mécanisme dans une architecture plus vaste. La RFC 6107 mit ensuite à jour la RFC 3477 pour les Path Keys. Ces textes décrivent une évolution ; ils ne prouvent pas les capacités ni le déploiement d’un équipement de janvier 2003.

La méthode des couches de réalité de Heng Lu donne la bonne discipline de lecture. Le Router ID donne une portée, pas une preuve de joignabilité présente. L’ERO décrit une intention, pas un passage. Le RRO est un reçu de signalisation, pas une mesure indépendante de la fibre. Une étiquette allouée n’est pas encore un transfert de paquets.

Une enquête doit donc garder le message RSVP brut, la session, l’émetteur, la direction et l’horodatage. Elle conserve l’ordre de l’ERO, le couple IF_ID, la source de la table voisine, le résultat de la recherche, les états Path et Resv, les opérations d’étiquette, l’ordre du RRO et ses bits. Les inventaires, adjacences, tables de transfert, alarmes et compteurs de trafic ne rejoignent cette chaîne qu’avec leurs propres preuves.

La règle essentielle est de ne jamais isoler l’Interface ID du routeur qui l’a attribué. Il ne faut pas davantage fusionner les deux valeurs d’extrémité en un numéro canonique inventé. Leur différence raconte l’autorité réelle : chaque LSR nommait ce qu’il administrait localement.

La RFC 3477 marque ainsi un épisode important de l’histoire de l’Internet. Elle n’a pas exigé qu’une infrastructure distribuée adopte une seule nomenclature mondiale. Elle a rendu deux vérités locales compatibles sans en effacer l’origine. Le lien était « non numéroté » au niveau IP, mais son identité n’était ni vide ni unique : elle était correctement située.

Sources