Résumé

  • Dans l’expérience décrite par RFC 1477, l’arrêt d’une passerelle puis la modification d’une politique de transit ont chacun déclenché la dépose d’un chemin et son remplacement, sans interrompre la session Telnet observée.
  • Cette preuve concernait un prototype simplifié : politique source et passerelles multiples entre deux domaines n’étaient pas implémentées, les correspondances adresse-domaine étaient préconfigurées et les mesures de performance n’étaient pas publiées.

Une continuité observée, pas une promesse générale

L’expérience centrale de RFC 1477 repose sur quatre domaines administratifs disposés en anneau. Le premier héberge la source, le dernier la destination, et deux domaines intermédiaires offrent deux parcours possibles. Lorsqu’une session Telnet est lancée, l’agent de chemin du domaine source demande une route de politique à son serveur de routes, puis établit le chemin correspondant.

Les expérimentateurs arrêtent ensuite les processus IDPR d’une passerelle située sur le parcours actif. Ses voisines détectent la rupture, annoncent le changement de connectivité et détruisent les segments encore présents de l’ancien chemin. L’agent de chemin obtient une nouvelle route par l’autre domaine de transit. La session Telnet reste intacte.

Le deuxième scénario part d’un réseau rétabli. Cette fois, la politique du domaine de transit actif est reconfigurée afin d’exclure le trafic allant de la source à la destination. L’information de routage change, le chemin devenu inadmissible est démonté, un autre est établi par le premier domaine de transit. La session reste, là encore, intacte.

Le résultat a une qualité rare : plusieurs états intermédiaires étaient visibles. Le prototype suivait les changements de voisinage, les politiques de transit, l’envoi et la réception d’informations d’état de liens, la route produite, les messages de contrôle et l’état du chemin. La continuité de l’application n’était donc pas le seul voyant disponible.

Mais elle demeure la continuité d’une session dans deux scénarios rapportés. Le texte ne fournit ni distribution du temps de convergence, ni nombre de paquets perdus, ni répétitions statistiques. L’observation est solide à condition de ne pas lui demander d’être universelle.

Le prototype avait son propre cahier des absences

Avant de raconter les essais, RFC 1477 précise que le prototype couvrait la plupart des fonctions d’IDPR, et non leur totalité. Pour obtenir rapidement un logiciel opérationnel, l’équipe a laissé de côté la prise en charge des politiques source et celle de plusieurs passerelles de politique reliant deux domaines.

Une politique source ne se confond pas avec une politique de transit. La seconde exprime les conditions posées par un domaine traversé pour l’usage de ses ressources. La première porte les exigences de service ou de parcours du domaine d’origine. Le test a démontré une réaction à la reconfiguration d’une politique de transit. Il n’a pas secrètement exécuté la logique source absente.

L’absence de passerelles multiples ferme une autre branche. Deux routes autour d’un anneau peuvent être comparées tout en ne traitant jamais le cas de plusieurs points de passage entre les mêmes domaines. Sélection, agrégation d’état, redondance locale et réparation partielle restent alors hors du logiciel éprouvé.

Cette réduction était raisonnable. Une spécification initiale plus petite peut produire du retour d’expérience au lieu d’attendre une complétude abstraite. Le mérite historique de l’équipe est d’avoir inscrit la réduction dans le document. Le contresens ultérieur serait d’accorder aux fonctions retranchées le bénéfice des essais menés sur le noyau restant.

Trois bancs d’essai, puis un anneau simple

Le développement du prototype UNIX commence à l’été 1990. Les essais du logiciel achevé débutent en février 1991. À USC, des stations SPARC1+ sont reliées par Ethernet dans un laboratoire reconfigurable. SAIC relie des Sun3 à Sparta et MITRE, par une liaison SLIP à 9,6 kb/s sur Alternet et par un parcours X.25 dans le banc DCA EDN. BBN relie des SPARC1+ de BBN et d’ISI au moyen de DARTnet et de TWBnet.

Ce sont de vrais systèmes et de vraies liaisons de l’époque. Ils donnent au travail davantage de réalité qu’une simple simulation. Pourtant, le principal scénario reste volontairement lisible : quatre domaines en anneau, deux domaines de transit, et au départ aucune restriction d’accès dans leurs politiques.

Le dispositif remplace également un composant prévu par l’architecture. Les serveurs de correspondance ne sont pas utilisés ; chaque passerelle reçoit une table configurée d’adresses et de domaines. Le substitut fournit une réponse correcte au calculateur de route. Il ne teste ni la diffusion ni la mise à jour d’un service de correspondance, encore moins ses conflits et ses données périmées.

Un banc d’essai peut neutraliser une dépendance pour observer ce qui vient après elle. Il ne transforme pas cette neutralisation en validation de la dépendance.

La totalité des fonctions de quel objet ?

RFC 1477 qualifie les expériences de simples, puis conclut qu’elles ont testé les grandes fonctions du prototype. L’énoncé est cohérent. Le logiciel a surveillé la connectivité, distribué de l’information, fabriqué une route, établi un chemin, détecté une panne, retiré le chemin affecté et construit son remplaçant. Il a aussi réagi à une politique de transit devenue incompatible.

Le complément « du prototype » interdit cependant une extension silencieuse. L’architecture de RFC 1478 et le protocole détaillé dans RFC 1479 couvrent un espace plus vaste. Une fonction décrite dans l’architecture n’acquiert pas une trace d’exécution parce que le prototype porte le même nom.

La distinction protège également le résultat. Dire que cette session Telnet est restée intacte est vérifiable dans le périmètre du rapport. Dire que le mécanisme garantissait toute application contre toute interruption ajouterait des essais qui n’ont pas été décrits.

Des mesures encourageantes, sans tableau

Les équipes d’USC et de SAIC ont évalué le traitement nécessaire à l’établissement d’un chemin et au transfert des messages. Elles ont comparé le transfert IDPR encapsulé dans IP au transfert IP ordinaire, ainsi que l’absence de calcul d’intégrité ou d’authentification à l’emploi de RSA/MD4.

Le rapport juge les mesures encourageantes. Il ne les reproduit pas. Il indique à qui les demander et avertit qu’elles ne doivent pas être extrapolées aveuglément à d’autres implémentations, le prototype ayant reçu peu d’efforts d’optimisation.

Il est donc possible d’établir qu’une campagne de mesures a eu lieu, d’en nommer les variables et de conserver l’appréciation des auteurs. Il est impossible d’en déduire un débit, un délai ou un coût processeur. Un adjectif ne remplace pas une série numérique.

gated ouvrait la prochaine étape

En 1992, SRI rejoint SAIC et BBN pour intégrer IDPR au processus de routage UNIX gated. RFC 1477 affirme que cette version disposait de toutes les fonctions IDPR, d’une interface de configuration et d’une meilleure efficacité liée au processus unique. Elle était librement accessible aux utilisateurs d’UNIX.

Cette disponibilité supprimait un obstacle à l’expérimentation. Elle ne recensait pas les installations. Le document explique que l’objectif suivant était d’acquérir de l’expérience dans des réseaux opérationnels, avec de vraies contraintes d’usage et de service. Au moment de la publication, un déploiement pilote et une démonstration étaient en cours dans certains sites.

Disponible, installé, activé, traversé par du trafic, exploité durablement et largement adopté sont des états distincts. « En cours » décrit l’ouverture d’un pilote, pas son bilan.

La frontière documentaire est tout aussi nette. La notice RFC Editor de RFC 1477 classe le mémo comme Informational malgré « Proposed Standard » dans son titre. Les notices de RFC 1478 et de RFC 1479 fixent l’identité des deux autres textes. RFC 2026 fournit le vocabulaire du processus de normalisation. Aucun statut de document ne remplace un reçu d’exploitation.

Une réussite qui gagne à rester limitée

RFC 1102 avait posé le problème de la construction progressive des routes de politique. RFC 1104 distinguait information de routage, traitement des paquets, allocation de ressources et comptabilité. La contribution propre de RFC 1477 est différente : elle permet de lire côte à côte le logiciel exécuté, les fonctions exclues, les artifices du test et les observations obtenues.

Les textes de Heng Lu sur la primauté du code exécuté, la spécification initiale minimale et l’adoption volontaire et les couches de réalité offrent ici une discipline de lecture : l’exécution l’emporte sur l’intention, mais seulement pour ce qui a été exécuté.

Conserver la liste des absences n’abaisse pas le prototype. Cela empêche qu’une exagération ultérieure rende son véritable résultat suspect. Une session a résisté à deux changements provoqués ; c’est déjà une pièce importante de l’histoire technique.

Sources