Résumé
- RFC 1992 admettait des bases de cartes incomplètes, différentes et parfois périmées : le fournisseur contrôlait la diffusion, le destinataire la conservation, et l’abstraction le niveau de détail.
- Un utilisateur ou son agent pouvait payer le coût d’un chemin soumis à des contraintes ; un chemin calculé par un seul dispositif évitait une boucle due à des décisions saut par saut incompatibles, sans certifier la carte ni le service.
Le réseau mondial que Nimrod cherchait à desservir n’avait pas de point de vue unique. Ce n’était pas une panne transitoire à réparer par davantage de synchronisation. C’était une propriété attendue d’un système trop vaste pour que chaque équipement stocke tout, trop hétérogène pour que chaque demande exige le même détail et trop politique pour que chaque fournisseur publie tout ce qu’il savait.
RFC 1992 transforme cette absence d’omniscience en choix d’architecture. Une carte Nimrod représente la connectivité par des nœuds et des adjacences orientées. Une même zone physique peut apparaître comme un seul nœud dans une carte et comme une structure interne détaillée dans une autre. Le représentant d’un nœud peut même répondre différemment à deux requêtes, notamment pour des raisons de sécurité. Le document en tire la conséquence sans détour : la cohérence des cartes entre routeurs n’est pas requise.
Réduire la carte, accepter ce qu’elle perd
La première économie vient du regroupement. Hôtes, routeurs, réseaux ou groupes déjà formés peuvent devenir des clusters à plusieurs niveaux. Le sommet de la hiérarchie contient l’ensemble, mais aucun algorithme unique n’est imposé à tous les étages. La frontière logique n’est pas tenue de suivre une frontière matérielle.
La seconde économie vient de l’abstraction. Elle ne supprime plus des entités ; elle raccourcit leur description. Les exemples de RFC 1992 sont révélateurs : éliminer un service offert par une petite fraction du cluster, ou remplacer des valeurs multiples par une moyenne. La carte devient plus légère précisément parce qu’elle renonce à certaines différences. Une route ordinaire peut s’en satisfaire ; un flux qui dépend du service rare effacé ne le peut pas.
La troisième économie concerne la circulation de l’information. Un cluster décide quelle partie publier et à quels destinataires. Ceux-ci choisissent à leur tour ce qu’ils conservent. Un fournisseur peut réserver un plan interne, répondre seulement sur une portion ou adapter la réponse à un demandeur. Un petit routeur peut rejeter des données pour préserver mémoire et calcul. Le silence du premier est un pouvoir de divulgation ; le tri du second est une contrainte ou une politique de stockage. Les effets se ressemblent dans la base locale, pas les responsables.
Enfin, le cache remplace une acquisition future par un souvenir. Nimrod l’encourage pour économiser délai et ressources, mais avertit que l’information vieillie peut produire des routes médiocres. L’architecture reconnaît donc une dette temporelle : plus la réutilisation est longue, plus il faut justifier la durée d’utilité supposée.
La complexité suit la demande spéciale
Le calcul d’une route respectant plusieurs contraintes est présenté comme généralement NP-complet. Nimrod n’en fait pas une taxe obligatoire pour tous. Seules les entités qui veulent une route particulière—débit garanti, délai, fournisseur choisi, restrictions d’usage—supportent l’acquisition d’information et le calcul correspondants.
Le sujet du calcul peut être l’utilisateur, mais RFC 1992 envisage surtout un dispositif agissant pour lui. Deux lieux peuvent utiliser des algorithmes différents sans coordination mondiale. Cette autonomie autorise l’expérimentation et le déploiement incrémental : une nouvelle méthode de sélection n’attend pas la mise à niveau de tous les routeurs.
Il serait pourtant faux d’y voir une égalité automatique. Celui qui obtient une carte plus riche ou finance un calcul plus coûteux possède davantage d’options. Une information non divulguée ne réapparaît pas par puissance de calcul. Le déplacement de la charge vers la demande explique qui paie ; il ne prouve ni accès équitable, ni politique impartiale, ni route optimale.
La boucle disparaît pour une raison précise
Dans un routage saut par saut, deux routeurs qui raisonnent à partir d’états incompatibles peuvent se renvoyer le trafic. Nimrod propose une autre composition. Un seul dispositif calcule le chemin à partir de l’ensemble d’information qu’il détient. Le paquet et les routeurs transportent ensuite le résultat de ce choix, au lieu de recommencer un choix autonome à chaque saut. Les cartes peuvent rester différentes sans que leurs divergences soient combinées dans la même chaîne de décisions.
Les modes de transmission ne placent pas tous l’état au même endroit. En mode flux, un identifiant de chemin renvoie à un état installé à l’avance dans les routeurs intermédiaires ; la demande de mise en place peut aussi annoncer des ressources souhaitées. Les modes CSC et CSS ordonnent des spécifications de connectivité. Le mode datagramme s’appuie sur un état préétabli pour offrir un chemin strictement sans boucle sans reproduire la route source d’IPv4.
Dire que Nimrod n’est que du « source routing » efface ces différences. Le point commun est une route choisie en amont par une instance, non l’inscription obligatoire de chaque routeur physique dans chaque paquet.
La garantie reste circonscrite. Un calcul unique supprime la boucle née de plusieurs croyances de prochain saut. Il ne démontre pas que la croyance unique est vraie. Le lien peut avoir disparu, le cache peut être ancien, l’état de flux peut manquer, l’abstraction peut avoir masqué une contrainte et le fournisseur peut ne pas tenir le service annoncé. Ne pas tourner en rond n’est ni arriver, ni arriver au bon prix, ni recevoir la qualité promise.
Une provenance authentique n’est pas une vérité
La section consacrée à la confiance refuse une autre fusion. Une carte externe devrait correspondre aux capacités réelles du nœud, mais l’exemple du RFC montre une publicité laissant croire à une confidentialité que la topologie physique ne garantit pas. Et même une information authentifiée, provenant d’un acteur digne de confiance, peut contenir une erreur honnête.
Il faut donc distinguer l’identité de l’émetteur, l’intégrité du message, la fidélité de la description, sa fraîcheur et l’exécution. RFC 1992 ne traite pas les questions de sécurité. Il ne fournit ni mécanisme universel d’authentification, ni preuve d’autorisation, ni garantie de confidentialité. Une confirmation de mise en place de chemin n’est pas davantage une mesure continue du débit ou du délai.
Le statut historique ferme la dernière extrapolation
RFC 1992 est un document Informational. Il expose les concepts et renvoie les protocoles et bases distribuées à d’autres textes. RFC 1752 rapporte que l’IESG considérait Nimrod comme un projet de recherche trop avancé pour devenir candidat IPng, tout en jugeant ses exigences instructives. RFC 1753 refusait déjà de présumer une adoption large avant déploiement et essais pratiques. RFC 2102 précisait ensuite que la génération de route unicast restait laissée à l’agent et que, pour le multicast, génération et transmission demeuraient non spécifiées.
Cette incomplétude documentaire fait partie de l’histoire. Elle empêche de convertir une idée architecturale en inventaire de produits ou en preuve d’usage. La « décision future localisée » décrite par Lu Heng aide à lire l’autonomie des algorithmes ; la primauté du code en fonctionnement interdit de confondre publication et adoption. Sa distinction entre couche symbolique et couche exécutable rappelle enfin qu’une carte est une déclaration, qu’un état de chemin est une action et qu’un service observé est encore autre chose.
L’intuition durable de Nimrod tient en une phrase : la sécurité contre une certaine boucle n’exigeait pas une connaissance universelle, mais une responsabilité claire du calcul. RFC 1992 a montré comment sacrifier de l’information sans sacrifier cette propriété. Il n’a jamais promis que la carte restante serait suffisante pour toutes les autres vérités.
Sources
- RFC 1992 : The Nimrod Routing Architecture
- RFC 1752 : recommandation pour IPng
- RFC 1753 : exigences IPng de Nimrod
- RFC 2102 : support multicast pour Nimrod
- RFC 2103 : support de la mobilité pour Nimrod
- Lu Heng, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Lu Heng, Running-Code Primacy
- Lu Heng, On Reality Layers
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
