Zusammenfassung

  • Im Versuch aus RFC 1477 lösten ein abgeschaltetes Policy Gateway und eine geänderte Transit Policy jeweils den Abbau des alten und den Aufbau eines alternativen Pfads aus; die beobachtete Telnet-Sitzung blieb erhalten.
  • Der Beleg gilt für einen eingeschränkten Prototyp: Quellrichtlinien und mehrere Gateways zwischen zwei Domänen waren nicht implementiert, Zuordnungen wurden lokal vorkonfiguriert, und die als ermutigend bezeichneten Leistungswerte wurden nicht veröffentlicht.

Zwei Eingriffe in denselben Verkehr

Vier administrative Domänen bilden im Hauptversuch von RFC 1477 einen Ring. S enthält den Quellhost, D den Zielhost. T1 und T2 können den Verkehr auf zwei Seiten des Rings weiterleiten. Beginnt eine Telnet-Sitzung, fordert der Path Agent in S beim Route Server eine Policy Route an und richtet den gelieferten Pfad ein.

Für den ersten Eingriff werden die IDPR-Prozesse eines Policy Gateways auf dem aktiven Weg durch T1 beendet. Die benachbarten Gateways erkennen die Unterbrechung, verteilen die neue Konnektivitätsinformation und bauen ihre verbliebenen Pfadteile ab. S erhält eine neue Route durch T2. Laut Bericht bleibt die Telnet-Sitzung währenddessen intakt.

Nach der Wiederherstellung folgt kein weiterer Geräteausfall, sondern eine Regeländerung. T2 wird so konfiguriert, dass Verkehr von S nach D nicht mehr passieren darf. Die neue Transit Policy wird verteilt, der unzulässige Pfad entfernt und ein Ersatz durch T1 aufgebaut. Auch diesmal bleibt die Sitzung bestehen.

Die Aussage stützt sich nicht nur auf das Endgerät. Der Prototyp war umfangreich instrumentiert. Er machte Änderungen der Gateway-Nachbarschaft und Transitregeln, Versand und Empfang von Link-State-Informationen, erzeugte Routen, Pfadkontrollnachrichten sowie Aufbau und Abbau eines Pfads sichtbar.

Damit entsteht eine nachvollziehbare Ereigniskette. Es entsteht aber keine Statistik über Paketverlust, Konvergenzzeiten oder wiederholte Versuche. Die konkrete Sitzung überstand die beschriebenen Änderungen. Das ist kein Verfügbarkeitsversprechen für jede Anwendung und Topologie.

Der bewusste Schnitt vor der Implementierung

RFC 1477 hält fest, dass der Prototyp den Großteil der IDPR-Funktionalität erfasste, nicht alles. Um schnell zu lauffähiger Software zu kommen, ließ das Team Quellrichtlinien und mehrere Policy Gateways zwischen zwei Domänen bewusst weg.

Eine Transit Policy beschreibt Bedingungen, unter denen eine durchquerte Domäne ihre Ressourcen zur Verfügung stellt. Eine Source Policy beschreibt Anforderungen und Präferenzen des Ursprungs. Die Änderung der T2-Regel prüfte den ersten Mechanismus. Sie konnte den zweiten nicht prüfen, weil dessen Unterstützung fehlte.

Auch zwei alternative Transitdomänen sind nicht dasselbe wie mehrere Gateways an derselben Domänengrenze. Dort entstehen lokale Auswahl, Redundanz, Zustandsabgleich und partielle Reparatur. Der Ring zeigte einen großräumigen Wechsel von T1 zu T2, nicht die ausdrücklich ausgelassene Mehrfach-Gateway-Logik.

Der Schnitt war eine legitime Entwicklungsstrategie. Ein kleiner ausführbarer Kern liefert früher Rückmeldung. Beweiskräftig bleibt er, wenn seine Auslassungen nicht nachträglich mit dem Erfolg des Kerns gefüllt werden.

Reale Netze, kontrollierte Frage

Die Prototyparbeit begann im Sommer 1990, die Versuche mit der fertigen Fassung im Februar 1991. USC betrieb SPARC1+-Rechner in einem frei konfigurierbaren Ethernet-Labor. SAIC verband Sun3-Systeme in Sparta und MITRE über Alternet mit einer 9,6-kb/s-SLIP-Leitung sowie über einen X.25-Pfad im DCA-EDN-Testnetz. BBN verband SPARC1+ bei BBN und ISI über DARTnet und TWBnet.

Das waren zeitgenössische Maschinen und Verbindungen, keine reine Simulation. Dennoch blieb das Hauptszenario einfach. Vier Domänen, zwei Transitmöglichkeiten, zunächst keine Zugangsbeschränkungen in den Transitregeln.

Auf Mapping Server verzichtete der Versuch ebenfalls. Stattdessen wurde in jedem Gateway eine Adress-Domänen-Tabelle vorkonfiguriert. Das lieferte der Routenberechnung die benötigte korrekte Zuordnung. Verteilung, Aktualisierung, Konflikte und veraltete Einträge eines Mapping-Dienstes wurden dadurch nicht erprobt.

Ein Test-Fixture kann eine Abhängigkeit zuverlässig ersetzen. Es ist kein Laufzeitnachweis für die ersetzte Komponente.

Was „alle Hauptfunktionen“ bezeichnete

RFC 1477 nennt die Versuche einfach und erklärt zugleich, sie hätten alle Hauptfunktionen des Prototyps erfasst. Der Prototyp beobachtete Konnektivität, verteilte Information, berechnete eine Route, richtete einen Pfad ein, erkannte einen Ausfall, entfernte alten Zustand und baute den Ersatz. Auf eine unzulässige Transitregel reagierte er ebenfalls.

Das Bezugswort bleibt Prototyp. Die Architektur in RFC 1478 und das Protokoll in RFC 1479 beschreiben mehr. Ein Architekturabschnitt hinterlässt keinen Ausführungsbeleg in einer Implementierung, die ihn ausgeschlossen hat.

Gerade die enge Formulierung schützt das Ergebnis. Der Bericht belegt die Reaktion der implementierten Mechanismen und die Kontinuität der beobachteten Sitzung. Eine pauschale Behauptung über sämtliche Funktionen wäre schwächer, weil ihr die Belege fehlen.

Ermutigung ohne Messreihe

Mitglieder von USC und SAIC maßen den Aufwand für Pfadaufbau und Nachrichtenweiterleitung. Sie verglichen IDPR-Weiterleitung mit IP-Kapselung gegen gewöhnliche IP-Weiterleitung sowie den Betrieb ohne Integritäts-/Authentisierungswert gegen RSA/MD4.

Die Messungen seien ermutigend gewesen, heißt es. Zahlen stehen nicht im RFC. Der Text nennt Ansprechpartner und warnt davor, die Werte blind auf andere Implementierungen zu übertragen, da für Optimierung wenig Zeit geblieben war.

Historisch belegt sind Messung, Vergleichsvariablen, Bewertung und Warnung. Latenz, Durchsatz oder CPU-Verhältnis lassen sich daraus nicht zurückgewinnen. Ein positives Adjektiv hat keine Maßeinheit.

Die gated-Fassung öffnete eine neue Beweisphase

1992 stieß SRI zu SAIC und BBN und integrierte IDPR in den UNIX-Routingprozess gated. RFC 1477 beschreibt diese Fassung als funktional vollständig, mit Konfigurationsoberfläche und wegen des Einzelprozesses effizienter als den Mehrprozess-Prototyp. Sie war frei verfügbar, sodass Besitzer eines UNIX-Systems ohne eigene Implementierung experimentieren konnten.

Verfügbarkeit beseitigte eine Zugangshürde. Sie erfasste keine Installationen. Als nächstes sollten Erfahrungen in Betriebsnetzen mit realen Nutzungsbeschränkungen und Diensterfordernissen gesammelt werden. Bei Veröffentlichung lief an ausgewählten Orten ein Pilot mit Demonstration.

Verfügbar, installiert, aktiviert, von Verkehr genutzt, dauerhaft betrieben und breit angenommen sind verschiedene Zustände. Ein laufender Pilot ist kein Abschlussbericht.

Auch der Dokumenttitel entscheidet nicht. Der RFC-Editor-Eintrag zu RFC 1477 führt das Memo als Informational, obwohl der Titel „Proposed Standard“ enthält. Die Einträge zu RFC 1478 und RFC 1479 sichern die Dokumentidentitäten; RFC 2026 erklärt die damalige Standardisierungssprache. Kein Statusfeld ist ein Betriebsbeleg.

Eine Leistung mit sichtbarer Kante

RFC 1102 behandelte die Konstruktion von Policy Routes. RFC 1104 trennte Routinginformation, Paketbehandlung, Ressourcenzuweisung und Abrechnung. RFC 1477 liefert eine andere historische Ebene: den Übergang von Architektur zu einem abgegrenzten ausführbaren und beobachteten Artefakt.

Heng Lus Texte über Running-Code-Primat, minimale Anfangsspezifikation und freiwillige Annahme sowie Realitätsebenen geben dafür eine klare Regel: Ausführung wiegt schwerer als Absicht, spricht aber nur für Ausgeführtes.

Die Auslassungsliste ist deshalb kein Makel, den man aus der Geschichte entfernen sollte. Sie ist der Rand des Belegs. Innerhalb dieses Randes bleibt die intakte Telnet-Sitzung eine bemerkenswerte Leistung.

Quellen