Zusammenfassung

  • Demand RIP ersetzte periodische WAN-Aussendungen auf X.25 und ISDN durch ausgelöste, bestätigte Übertragungen. Dadurch konnten ruhende Verbindungen schließen, während ausgelöst gelernte Routen normalerweise dauerhaft blieben.
  • Scheiterte ein echter Verbindungsaufbau, konnte der Circuit Manager den nächsten Hop als nicht erreichbar melden; erst dann folgten Alterung, Hold-down und Entfernung. Ein ACK belegte Nachrichtenempfang, nicht die Wahrheit der Route oder den Erfolg des Nutzverkehrs.
  • RFC 1581 meldete genau eine fertige Implementierung, die auf zwei WAN-Arten gegen sich selbst getestet worden war. RFC 1264 verlangte für Interoperabilität eigenständige Implementierungen und weitergehende Tests.

Das regelmäßige Lebenszeichen hielt die Rechnung am Laufen

RFC 1582 erschien laut offiziellem Eintrag im Februar 1994. Auf verbindungsorientierten öffentlichen Datennetzen ließ sich ein virtueller Kanal bei Bedarf aufbauen und nach Ende des Verkehrs wieder lösen. Nutzdaten konnten kurz und selten sein.

Gewöhnliches RIP wiederholte seine Tabelle trotzdem periodisch. Was auf einem LAN eine Aussendung an das gemeinsame Medium war, wurde auf dem WAN zu einzelnen Nachrichten an alle bekannten Ziele. Der RFC rechnete für N Router mit N × (N - 1) Updates pro Periode über N × (N - 1) / 2 Verbindungen. Gleichzeitig konnte die Schnittstelle weniger Kanäle als Nachbarn besitzen; beim ISDN-Basisanschluss des Beispiels waren es zwei gleichzeitige Rufe.

Ein längeres Intervall sparte Gebühren und verzögerte Änderungen. Das normale Intervall hielt Kanäle und Warteschlangen beschäftigt. Demand RIP änderte deshalb nicht nur die Frequenz, sondern den Anlass: Anfrage, Änderung der Routingdatenbank oder eine vom Circuit Manager gemeldete Rückkehr von down zu up.

Stille ließ die letzte Aussage nicht mehr altern

Der begleitende RFC 1581 ist eine Informational-Analyse; der RFC-Editor-Eintrag hält diesen Status fest. Auf dem WAN sollten Updates nur ereignisgesteuert erscheinen und bis zum ACK wiederholt werden. Empfangene Angaben liefen im Normalbetrieb nicht aus.

RFC 1582 unterschied dafür zwei Datenbankklassen. LAN-Routen aus periodischen Antworten waren temporär und verfielen ohne Auffrischung. Routen aus ausgelösten WAN-Antworten waren normalerweise dauerhaft.

Dauerhaft bedeutete nicht ewig wahr. Der Router behielt den zuletzt akzeptierten Zustand, bis ein ausdrücklich anerkanntes Gegenereignis eintraf: eine als unerreichbar markierte Route, ihr Fehlen in einer vollständigen Antwort, ein Interface-Ausfall, zu viele unbestätigte Übertragungen oder ein erfolgloser Versuch des Circuit Managers, für realen Verkehr einen Kanal aufzubauen.

„Kein Update gehört“ war folglich etwas anderes als „Verbindung versucht und gescheitert“. Ersteres war beabsichtigte Ruhe, kein positiver Messwert. Letzteres konnte den Rückzug starten. Der Auslöser wanderte vom periodischen Timer zu benannten Ereignissen.

Der Circuit Manager bekam Wirkung auf den Routingzustand

RFC 1582 ordnete den Circuit Manager unter IP, IPX und deren Routingprozessen an. Er übersetzte die logische Next-Hop-Adresse in eine physische X.25- oder ISDN-Adresse, öffnete bei Datenbedarf einen virtuellen Kanal und schloss ihn nach Leerlauf.

Schlug ein Verbindungsaufbau im normalen Betrieb fehl, sendete er circuit down. Die dauerhaften Routen über diesen Nachbarn wurden temporär, alterten, erschienen während des Hold-down als unerreichbar und konnten danach verschwinden. Kam der Kanal rechtzeitig zurück, ließen sie sich wieder dauerhaft setzen; waren sie abgelaufen, musste ein vollständiger Austausch die Datenbanken neu füllen.

circuit up bestätigte ebenfalls nur einen begrenzten Sachverhalt: Der Manager konnte wieder Kontakt herstellen. Es bestätigte nicht alle alten Routen. Deshalb folgte die vollständige Synchronisierung. Verbindung, Routenbestand, Forwarding-Auswahl, Paketdurchgang und Anwendungsergebnis waren getrennte Belege.

Wie der Manager die Verbindung reparierte, blieb außerhalb der Spezifikation. Kanalengpass, falsche Adresszuordnung, entfernte Ablehnung oder physischer Defekt konnten dasselbe Signal erzeugen. Es rechtfertigte eine sichere Routingreaktion, aber keine vollständige Ursachenbehauptung.

Das ACK bestätigte Zustellung, nicht Erreichbarkeit

Ohne die nächste periodische Runde konnte eine verlorene Änderung bestehen bleiben. Ein freier virtueller Kanal konnte fehlen, die Sendequeue voll sein, ein Ruf verdrängt oder ein Frame beschädigt werden. RFC 1582 führte deshalb Request, Response, Acknowledgement und Retransmission ein.

Große Antworten wurden fragmentiert. Jedes Fragment erhielt ein eigenes ACK; die Empfängerseite änderte die Datenbank erst nach vollständigem Eingang. Lief das Reassembly-Zeitfenster aus, verwarf sie den unvollständigen Satz und forderte alles neu an. Eine neue Sequenz ersetzte die Reste der vorherigen.

Das waren präzise Quittungen. ACK belegte den Eingang einer Antwort oder eines Fragments. Vollständiges Reassembly belegte einen anwendbaren Satz. Die Sequenz trennte Versionen. Keine Quittung bewies, dass das angekündigte Netz tatsächlich erreichbar war, die Route in der FIB stand, ein Nutzerpaket ankam oder ein Dienst funktionierte.

Auch die Peerliste hatte einen engen Zweck. Sie legte Sendeziele und zugelassene Quellen fest; fremde Updates waren zu verwerfen. RIP-2 konnte authentisieren. Ein berechtigter Absender konnte trotzdem falschen oder veralteten Zustand übertragen. Identität und Betriebsergebnis blieben getrennt.

Leitungsersparnis erzeugte Zustandsschuld

Dauerhafte Routen konnten sich nicht durch Vergessen korrigieren. RFC 1582 verlangte alle Alternativen oder eine begrenzte Auswahl samt Erinnerung daran, dass weitere verworfen worden waren. Bevor die letzten Optionen ausfielen, sollte der Router fehlende Informationen neu anfordern.

Weniger Anrufe bedeuteten deshalb mehr langlebigen Zustand. Dieser brauchte exakten Rückzug, zuverlässige Änderungslieferung, vollständige Fragmente, Schichtkoordination und Neustartgrenzen. Die sichtbare Leitungsausgabe sank, während die unsichtbare Konsistenzpflicht stieg.

Der RFC legte zudem eine Implementierungsannahme offen. Im beschriebenen Produkt waren Circuit Manager und Routinganwendung eng gekoppelt. Auf Unix konnte der Manager im Kernel und der Routingprozess separat laufen; anderswo auf einer eigenen Karte. Hatten beide unabhängige Lebenszyklen, waren Keepalive und Resynchronisierung Pflicht. Ein lebender Teil bewies nicht, dass der andere denselben Zustandsstand besaß.

Ein Selbsttest blieb ein Selbsttest

RFC 1581 berichtete von einer vermutlich einzigen fertigen Implementierung. Spider Systems unterstützte IP RIP-1, IPX RIP und IPX SAP, damals jedoch noch nicht RIP-2. Das neue Verfahren lief gegen sich selbst auf X.25 und ISDN und neben gewöhnlichen LAN-Implementierungen auf Ethernet. Zwei Novell-spezifische Arbeiten waren noch in Entwicklung.

Damit gab es laufenden Code und zwei WAN-Umgebungen. Nicht belegt war eine zweite unabhängige Interpretation von Fragmenten, Timern, Neustarts und up/down-Signalen.

RFC 1264 und sein offizieller Datensatz erklärten die Differenz. Routingprotokolle sind verteilte Echtzeitalgorithmen; eine Implementierung in einer Umgebung garantiert keine andere Umgebung mit mehreren Herstellern. Unabhängige Implementierungen, vollständige Funktionsprüfungen und demonstrierte Sicherheitsmechanismen waren eigenständige Nachweise.

„Implementiert“ darf nicht zu „interoperabel“ werden. Ebenso wenig ist der Selbsttest wertlos. Sein sauber erklärter Umfang macht ihn historisch brauchbar.

Die spätere Fassung änderte den Transport, nicht die Grenze

Im Januar 1997 folgte RFC 2091, wie sein Eintrag zeigt. Gegenüber RFC 1582 übertrug er nach dem Vollabgleich nur Änderungen, verringerte Speicher und Verkehr und beseitigte die frühere Grenze von 255 Fragmenten, indem er dieses Fragmentmodell nicht nutzte.

Die zentrale Annahme blieb bestehen. Ausgelöst gelernte WAN-Routen waren normalerweise dauerhaft. Der Circuit Manager meldete weiter down und up. Requests und Responses brauchten ACK und Wiederholung. Zu lange ausbleibende Bestätigungen konnten den Next Hop unerreichbar machen. Wiederanlauf und Rückkehr verlangten Flush und Vollabgleich.

Eine spätere Veröffentlichung ist kein Einsatznachweis. Sie zeigt eine geänderte Umsetzung derselben Verantwortung. Wo Stille normal ist, müssen gehaltener Zustand, widerrufender Befund, Nachrichtenlieferung, Weiterleitung und Dienstergebnis getrennt bleiben.

Quellen