Résumé

  • RFC 2333 présentait NHRP comme un mécanisme de résolution utilisant une décision de routage déjà prise, non comme un protocole de routage ou un test de bout en bout.
  • L’intérêt d’un raccourci dépendait de la topologie, du coût d’établissement, des besoins de l’application, de la participation NHRP et de la sécurité contre les boucles.
  • Un accusé d’enregistrement, une réponse faisant autorité ou une entrée de cache décrivaient un état de contrôle borné par sa source, sa politique et sa durée de conservation.
  • Sur ATM, obtenir une adresse restait distinct de l’établissement d’un circuit virtuel ; le transfert IP, le chemin retour, le service distant et l’application restaient à vérifier.
  • La preuve opérationnelle devait progresser par étapes : route, décision d’usage, résolution, connexion, paquets, service, résultat.

Un raccourci ne commence pas par un circuit

Le point de départ de RFC 2333 était une inefficacité du modèle classique.

Plusieurs sous-réseaux IP logiques pouvaient partager le même support ATM ou un autre réseau NBMA. Pourtant, deux stations appartenant à des LIS différents devaient normalement passer par un routeur IP, même si le support sous-jacent rendait possible une connexion directe. NHRP devait permettre à une source de découvrir l’adresse NBMA d’une destination ou de la sortie appropriée et d’éviter certains sauts intermédiaires.

Cette description pouvait donner l’impression que la résolution créait le raccourci. Le texte séparait les opérations.

Le routage IP déterminait d’abord le chemin. NHRP répondait ensuite à une question d’adressage à l’intérieur du domaine NBMA logique. Sur un support orienté connexion, la source pouvait encore devoir établir une connexion avec les caractéristiques souhaitées. Ce n’est qu’après cette étape que des paquets pouvaient éprouver le chemin.

La première preuve était donc une indication de lieu. Elle n’était pas encore un événement de transport.

L’applicabilité était un calcul d’utilité

RFC 2333 ne recommandait pas un raccourci pour chaque flux.

Une opération brève, sans exigence particulière de qualité de service, pouvait se terminer avant que le coût du raccourci soit amorti. Ce coût pouvait représenter du temps, de la signalisation, de la mémoire, des circuits commutés ou une charge supplémentaire pour les interfaces. Le routage saut par saut pouvait alors être le meilleur choix.

La question n’était plus seulement « local ou distant ». Dans un grand réseau commuté, deux points distants du point de vue IP pouvaient se joindre directement au niveau NBMA. Il fallait décider entre un chemin IP ordinaire et un raccourci, en fonction des besoins de l’application et de la politique.

Reconnaître que les conditions favorisaient NHRP donnait une justification à une tentative. Cela ne prouvait ni l’émission d’une requête, ni la réception d’une réponse, ni la création d’un chemin.

Le document proposait même de limiter les initiateurs : l’hôte d’origine, le premier routeur dont le prochain saut était joignable par l’interface NBMA, ou un routeur de politique obligatoire. Ce choix évitait que plusieurs points du chemin construisent chacun leur propre raccourci.

La route restait l’autorité de départ

NHRP n’était pas un protocole de routage.

Quand il utilisait un algorithme dynamique, le serveur choisi et l’adresse de sortie renvoyée reflétaient la décision du routage de couche réseau. Une sortie pouvait être désirable parce qu’elle réduisait le nombre de sauts du chemin initial, sans pour autant optimiser toutes les dimensions du service.

Une réponse NHRP ne prouvait pas que la sortie était la moins chère, la moins congestionnée ou la plus fiable. Elle n’authentifiait pas non plus la logique qui avait conduit à cette route.

Surtout, l’adresse résolue restait liée à une époque de routage. Si les métriques changeaient rapidement, des raccourcis pouvaient vivre très peu de temps. Dans certains usages entre routeurs, la perte d’informations nécessaires à la suppression des boucles pouvait même produire des boucles persistantes.

NHRP pouvait concrétiser une décision de routage ; il ne pouvait pas la figer.

Le cas routeur-routeur imposait une limite

Les communications hôte-hôte, hôte-routeur et routeur-hôte entraient dans le cadre général. Le cas routeur-routeur exigeait davantage de prudence.

RFC 2333 identifiait un cas plus sûr : la destination était directement adjacente à l’interface non-NBMA du routeur de sortie et cette relation était considérée comme stable. Une requête dont le bit Q indiquait un demandeur routeur pouvait alors recevoir une réponse.

Si la destination n’était pas directement adjacente, une réponse négative était un comportement prudent. Les paquets continuaient par le chemin routé.

Le NAK ne signifiait donc pas nécessairement perte de connectivité. Il refusait une optimisation dont la sécurité topologique n’était pas suffisamment établie.

Cette nuance protège une règle plus générale : l’échec d’un raccourci et l’échec du service IP ne sont pas le même événement.

Enregistrer une adresse ne réveillait pas l’hôte

RFC 2332 définissait l’enregistrement d’un client auprès d’un Next Hop Server.

Le serveur vérifiait la requête, appliquait sa politique et décidait s’il pouvait servir l’adresse. Il pouvait répondre négativement en cas d’interdiction administrative, de ressources insuffisantes, de mauvais serveur ou de conflit d’unicité.

Un accusé positif avait donc une signification précise : le NHS avait accepté les informations de correspondance dans son service.

Il ne vérifiait pas la disponibilité de l’interface à l’instant suivant. Il ne testait pas l’application. Il ne garantissait pas la synchronisation immédiate de tous les autres serveurs. Il ne construisait pas une connexion de données.

L’enregistrement devait en outre être renouvelé avant l’expiration de son Holding Time. Cette règle reconnaissait que la valeur perdait son autorité avec le temps. Un état que le protocole oblige à rafraîchir ne peut honnêtement être lu comme une identité permanente ou une présence continue.

L’autorité d’une réponse avait un domaine

Une requête de résolution suivait la direction fournie par le routage. Le serveur responsable de la destination pouvait renvoyer une information faisant autorité. Un serveur de transit pouvait, si les règles l’autorisaient, répondre à partir d’une information non autoritative déjà mise en cache.

Cette différence permettait au client d’évaluer la provenance.

Mais même la meilleure provenance NHRP ne transformait pas la réponse en preuve de toutes les couches. Elle attestait une correspondance entre une adresse de protocole et une adresse NBMA dans le cadre du service NHRP. Elle ne déclarait pas que la signalisation ATM accepterait un SVC, que la bande passante souhaitée serait disponible, que les filtres permettraient le trafic ou que la route retour serait correcte.

Le terme « autoritatif » ne voulait pas dire « omniscient ». Il désignait l’autorité de répondre pour cette correspondance.

Un cache mélangeait plusieurs histoires

Les entrées NHRP ne provenaient pas toutes du même événement.

Un NHS pouvait apprendre une correspondance par enregistrement, par échange de résolution, par table préconfigurée, par ARP ou par un autre mécanisme. Un client pouvait conserver une réponse, une configuration manuelle ou un état acquis hors du protocole.

L’affichage d'une simple présence effaçait ces histoires.

RFC 2677 exposait justement le type du cache, son origine, la validité du Holding Time, le temps restant et d’autres attributs. Une entrée apprise devait disparaître lorsque son compteur atteignait zéro. Une entrée administrative pouvait ne pas avoir de durée définie parce qu’elle venait d’une configuration persistante.

Deux lignes présentant la même paire d’adresses pouvaient donc soutenir des décisions différentes. Une réponse autoritative fraîche, une copie synchronisée et une valeur saisie manuellement ne comportaient ni la même fraîcheur ni la même chaîne de responsabilité.

Un cache était un ensemble de déclarations temporaires, pas un capteur de paquets.

Synchroniser n’observait pas le trafic

SCSP et son usage distribué pour NHRP répondaient à un problème réel : plusieurs serveurs d’un même groupe devaient disposer d’informations suffisamment cohérentes pour offrir un service stable.

La synchronisation pouvait diffuser des correspondances enregistrées et réduire les divergences entre NHS. Elle ne produisait aucune observation nouvelle de la destination.

Si une source tardait à renouveler une information, plusieurs serveurs pouvaient reproduire le même état devenu ancien. Leur accord prouvait la réussite de la réplication. Il ne prouvait pas que le système externe répondait encore.

RFC 2332 prévoyait des messages Purge pour invalider des informations et des erreurs pour les boucles, adresses injoignables, réponses invalides, échecs d’authentification ou dépassements de sauts. Le protocole traitait la révision comme une fonction normale, non comme une exception honteuse.

Pendant la résolution, le réseau pouvait continuer

Lorsqu’un paquet déclenchait une résolution, la source pouvait le abandonner, le conserver ou l’envoyer par le chemin routé. RFC 2332 recommandait ce troisième comportement par défaut afin que les données puissent circuler en attendant un meilleur chemin.

La même logique apparaissait lorsqu’un routeur intermédiaire ne comprenait pas NHRP. La requête pouvait être silencieusement perdue, rendant le raccourci impossible, tandis que le routage ordinaire maintenait la connectivité.

Cette architecture séparait optimisation et continuité.

Une absence de raccourci ne prouvait pas une panne. Une réponse de résolution ne prouvait pas la continuité. Pour comprendre le résultat, il fallait observer la connexion NBMA, les paquets, le retour et le service.