Résumé

  • Une annonce HELLO de la RFC 891 permettait de calculer un aller-retour pour le routage et de transporter un décalage d’horloge, mais les deux valeurs n’étaient pas admises selon les mêmes conditions.
  • Le meilleur chemin acheminait l’observation temporelle ; il n’élisait pas la source de temps. L’identité maîtresse venait du paramètre configuré CLOCK-HID.
  • La longueur égale des annonces, l’état de maintien, la validité de la date et la procédure de correction locale séparaient réception, changement de route et mise à l’heure.

Un système distribué devient difficile à lire lorsque le même nombre sert à deux décisions. La RFC 891 offre un cas plus subtil : elle ne réutilisait pas seulement un nombre, mais toute une conversation HELLO pour apprendre où envoyer les paquets et comment estimer l’écart entre horloges.

Le contexte comptait. DCN était un petit réseau local, limité à 256 hôtes et passerelles, souvent composés de PDP-11 ou de LSI-11 surnommés Fuzzballs. Chaque machine pouvait commuter des paquets, relier des réseaux et offrir des services. Aucune autorité locale distincte ne distribuait les routes.

Chaque hôte maintenait donc une Host Table. Pour une destination, la ligne conservait le processus de sortie, le délai aller-retour, le décalage d’horloge, l’instant de mise à jour et un compteur de survie. Une Net Table distincte indiquait les passerelles des réseaux étrangers et restait normalement sous contrôle de la configuration, sauf mise à jour par les processus GGP ou EGP.

Deux usages ne signifiaient pas une seule validation

Les voisins d’un même réseau échangeaient leurs entrées au moyen de HELLO sous le numéro de protocole Internet 63. Le registre IANA des numéros de protocole conserve aujourd’hui la mention « any local network » pour 63. Ce registre atteste l’attribution du numéro, pas l’exploitation actuelle du réseau DCN.

Le calcul de délai utilisait une annonce reçue puis l’annonce suivante émise. Il ne supposait ni des horloges déjà alignées, ni un rythme d’émission parfaitement régulier. Une perte ou un message réfléchi n’annulait pas le principe de mesure.

La précision du décalage exigeait cependant que la dernière annonce envoyée et la dernière annonce reçue aient la même longueur. Si cette condition manquait, le logiciel pouvait accepter la nouvelle route tout en conservant l’ancien décalage. La séparation est décisive : un paquet valide pour une boucle de contrôle ne l’était pas automatiquement pour l’autre.

Le format et la somme de contrôle formaient encore une barrière en amont. Ils détectaient une partie des erreurs, mais n’authentifiaient ni l’hôte, ni l’identité d’une horloge maîtresse.

Le délai répondait à « par où », pas à « qui commande »

Pour chaque destination annoncée, l’hôte ajoutait le délai vers son voisin au délai déclaré par celui-ci. Il changeait de sortie seulement si le candidat améliorait suffisamment la route en cours. L’implémentation décrite employait environ 100 millisecondes comme marge, un maintien de 120 secondes et une valeur maximale de chemin de 30 secondes. Ce sont des paramètres documentés, non des lois universelles.

Lorsqu’un chemin était retenu, son décalage associé entrait dans la table. On pourrait croire que la source la plus proche devenait ainsi la référence. La RFC dit autre chose. Le maître était nommé à l’avance par CLOCK-HID, un identifiant d’hôte configuré.

Le calcul de route déterminait donc le transport de l’information temporelle, non sa souveraineté. Une valeur provenant d’un autre identifiant pouvait renseigner la table sans régler l’horloge. Même la valeur du maître devait encore disposer d’une date valide et traverser la procédure locale de correction.

Le lien d’origine restait une partie de la preuve

Une route renvoyée vers le lien qui l’avait fournie pouvait entretenir une boucle. RFC 891 remplaçait alors son délai par MAXDELAY. La RFC 2453 fournit plus tard le vocabulaire familier de l’horizon partagé, de la route empoisonnée, des mises à jour déclenchées et du comptage jusqu’à l’infini.

Cette comparaison n’établit pas une filiation directe vers RIP. Elle montre pourquoi la provenance du chemin importe : supprimer le lien d’entrée et ne garder que la métrique transforme un témoignage reçu en fausse connaissance autonome.

Le compteur de maintien jouait le même rôle temporel. Une route qui cessait d’être entendue n’était pas immédiatement interchangeable avec une route neuve. L’absence, la réapparition et la validité du décalage suivaient des calendriers distincts.

Corriger l’horloge pouvait invalider la mesure

La RFC distinguait l’horloge physique, l’horloge apparente et l’horloge effectivement présentée. Les petites corrections étaient étalées : une fraction de l’écart accumulé était transférée progressivement, avec des paramètres suggérés limitant la dérive imposée à moins d’environ deux millisecondes par seconde.

Une grande correction provoquait au contraire un saut de l’horloge apparente. Le système entrait alors dans une période de maintien où ses horodatages de mesure n’étaient plus valides. Il ne suffisait pas d’avoir reçu une nouvelle heure ; il fallait reconnaître que le déplacement cassait la continuité nécessaire à l’aller-retour.

La représentation roulait à minuit UT, ce qui imposait au moins une mise à jour quotidienne valide de la date et de l’heure maîtresses. La présence d’une route vers le maître ne prouvait pas que ce contexte civil avait été reçu.

La RFC 778 avait auparavant décrit un service d’horloge DCNET utilisant des horodatages ICMP et GGP pour estimer délais aller simple et aller-retour. RFC 891 transforma cette mesure en état distribué entretenu dans la même table que les routes.

Une influence déclarée, et non une identité

La RFC 1059 appelle plus tard ce protocole « Hellospeak ». Elle affirme explicitement que son intégration du temps au routage a fortement influencé NTP, tout en jugeant le système impropre à un usage dépassant son environnement local.

Le projet NTP de la RFC 958 passa par UDP et posa une hiérarchie ainsi qu’un format de message, mais reconnaissait ne pas définir les algorithmes de synchronisation, de filtrage, de découverte des pairs ou d’authentification. La RFC 1305 documenta ensuite filtrage de plusieurs serveurs, sélection, bornes d’erreur et horloge logique dérivée des Fuzzballs.

Hellospeak n’était donc pas « déjà NTP ». Son héritage documenté est plus intéressant : une observation peut être transportée par la meilleure route sans que la route décide quelle source mérite autorité.

Sources et limites

Ce récit s’appuie sur les RFC 778, 891, 958, 1059, 1305 et 2453 ainsi que sur le registre IANA. Ces textes n’établissent ni un déploiement actuel de DCN, ni l’uniformité des paramètres, ni l’authentification du maître, ni la symétrie des délais, ni une filiation directe vers RIP, ni la garantie que le trajet le plus rapide produit la plus petite erreur d’horloge.