Zusammenfassung

  • RFC 891 nutzte einen HELLO-Austausch zugleich für die Laufzeitmetrik einer Route und für den zugehörigen Uhrenoffset, ließ aber beide Ergebnisse durch unterschiedliche Prüfungen gehen.
  • Der Pfad mit der geringsten akzeptierten Verzögerung beförderte die Zeitinformation; den Master bestimmte die Konfiguration CLOCK-HID, nicht die Metrik.
  • Gleiche Paketlängen, Haltezustand, gültiges Datum und lokale Nachführlogik trennten Nachrichteneingang, Routenwechsel und Uhrenkorrektur.

Die Host Table aus RFC 891 war weder nur eine Routingtabelle noch nur ein Zeitmessspeicher. In einer Zeile standen Ausgangsprozess, Umlaufverzögerung, Uhrenoffset, Aktualisierungszeit und ein Lebenszähler. Damit bewahrte sie zwei Geschichten derselben Verbindung.

Diese Verdichtung passte zu DCN: ein lokales Netz mit höchstens 256 Hosts und Gateways, häufig PDP-11- oder LSI-11-Fuzzballs, verbunden über Punkt-zu-Punkt- und Mehrpunktstrecken. Jeder Rechner konnte Pakete vermitteln, Netze koppeln und Dienste anbieten. Einen gesonderten lokalen Routingchef gab es nicht.

Ein physischer Rechner durfte mehrere virtuelle Hosts beherbergen. Für fremde Netze existierte neben der Host Table eine Net Table. Sie ordnete Netze ihren Gateways zu und blieb normalerweise Konfigurationsbestand; nur Routingprozesse wie GGP oder EGP änderten sie dynamisch.

Die Umlaufmessung brauchte keine geeichten Uhren

HELLOs im selben Netz liefen unter IP-Protokollnummer 63 und enthielten Verzögerung und Offset aus der Host Table. Das heutige IANA-Register der Protokollnummern führt 63 weiterhin als „any local network“. Es belegt die Nummernvergabe, nicht gegenwärtige DCN-Nutzung.

Für die Messung verband der Host Zustand aus einem empfangenen HELLO mit dem nächsten gesendeten. Die Methode war weder auf bereits synchrone Uhren noch auf gleichmäßige Sendeabstände angewiesen. Auch verlorene oder reflektierte HELLOs machten das Prinzip nicht unbrauchbar.

Nach Format- und Prüfsummenprüfung folgten engere Bedingungen. Eine genaue Offsetberechnung setzte voraus, dass das zuletzt gesendete und empfangene HELLO gleich lang waren. Bei ungleicher Länge durfte die Route dennoch erneuert werden, während der Offset unverändert blieb.

Die gemeinsame Nachricht bildete also keinen gemeinsamen Commit. Jeder lokale Regelkreis entschied selbst, welchen Teil der Beobachtung er übernehmen konnte.

Eine kurze Strecke war noch keine Autorität

Für einen Zielhost addierte der Empfänger die Umlaufzeit zum Nachbarn und dessen beworbene Zielverzögerung. Ein Kandidat ersetzte den aktuellen Ausgang nur, wenn er ihn um eine konfigurierte Schwelle schlug. Das beschriebene System nannte ungefähr 100 Millisekunden Schwelle, 120 Sekunden Haltezeit und 30 Sekunden maximalen Pfadwert. Das sind Implementierungswerte, keine zeitlosen Vorgaben.

Mit der angenommenen Route speicherte der Host auch deren Offset. Daher trug der beste akzeptierte Weg die Zeitbeobachtung. Er bestimmte aber nicht, wessen Uhr maßgeblich war. Die Master-ID stand in CLOCK-HID.

Der schnellste Nachbar konnte eine wertvolle Route liefern, ohne Zeitgeber zu werden. Selbst ein Offset des konfigurierten Masters benötigte ein gültiges Datum und die Zustimmung des lokalen Uhrenverfahrens. Erreichbarkeit, Identität und Wirkung blieben getrennte Kontrollflächen.

Die Eingangsleitung veränderte die Rückmeldung

Eine gelernte Route unverändert über ihre Herkunftsleitung zurückzumelden, konnte eine Schleife erzeugen. RFC 891 setzte dort MAXDELAY ein. RFC 2453 beschreibt später die verwandten Probleme mit Split Horizon, Poisoned Reverse, ausgelösten Aktualisierungen und Zählen bis Unendlich.

Das ist ein Vergleich und keine belegte direkte Abstammung zu RIP. Sicher ist: Eine Metrik ohne Herkunft kann fremde Auskunft in scheinbar eigene Erkenntnis verwandeln.

Lebenszähler und Haltezeit bewahrten ebenfalls Vergangenheit. Nach dem Verschwinden eines Nachbarn wurde der Tabellenplatz nicht sofort zu einem geschichtslosen Neuanfang. Pfadfrische, Offsetfrische und Uhrenzustand hatten unterschiedliche Laufzeiten.

Ein Uhrsprung entzog der Messung ihre Grundlage

RFC 891 unterschied physische, scheinbare und tatsächlich ausgegebene Uhr. Kleine Abweichungen wurden schrittweise durch Übertragung eines Teils von CLK.DELTA abgebaut. Die vorgeschlagenen Parameter hielten die maximale Nachführung unter ungefähr zwei Millisekunden pro Sekunde.

Eine große Abweichung konnte die scheinbare Uhr springen lassen. Danach begann eine Haltephase, in der Zeitstempel für Messungen ungültig waren. Der Rechner erkannte damit an, dass ein Umlauf über eine lokale Zeitlücke keine gewöhnliche Probe darstellt.

Weil die scheinbare Uhr um Mitternacht UT umlief, brauchte sie wenigstens täglich ein gültiges Datum samt Uhrzeit vom Master. Eine vorhandene Route zu CLOCK-HID lieferte diese Gültigkeit nicht automatisch.

RFC 778 hatte zuvor einen DCNET-Uhrdienst mit Zeitstempeln über ICMP und GGP beschrieben. RFC 891 machte aus solcher Messung fortlaufenden, verteilten Tabellenzustand für Route und Zeit.

Hellospeak war Einfluss, nicht Gleichheit

RFC 1059 nannte das Fuzzball-Protokoll später „Hellospeak“. Sie erklärte ausdrücklich, die Einbettung von Zeitsynchronisation ins Routing habe NTP stark beeinflusst, und bezeichnete die Konstruktion zugleich als ungeeignet außerhalb ihrer lokalen Umgebung.

Der frühe NTP-Entwurf in RFC 958 setzte auf UDP, Hierarchie und Nachrichtenformate, legte aber keine Synchronisations- und Filteralgorithmen, Peer-Erkennung oder Authentisierung fest. RFC 1305 dokumentierte später Auswahl und Filterung mehrerer Server, Fehlergrenzen und eine von Fuzzball-Arbeiten abgeleitete logische Uhr.

Die Quellen belegen Einfluss, nicht Protokollidentität. NTP machte Zeit zu einem eigenen Auswahl- und Korrektursystem für einen größeren Geltungsbereich, den Hellospeak nicht beanspruchte.

Quellen und Grenzen

Die Darstellung stützt sich auf RFC 778, RFC 891, RFC 958, RFC 1059, RFC 1305, RFC 2453 und das IANA-Register. Sie belegt weder heutigen DCN-Betrieb noch einheitliche Parameter, Master-Authentisierung, symmetrische Laufzeit, direkte Abstammung zu RIP oder die Garantie, dass die kleinste Umlaufzeit den kleinsten Uhrenfehler ergibt.