Zusammenfassung

  • Ginny Strazisar schrieb frühe BBN-Gateway-Software und installierte sie an heterogenen Grenzen; Code, PDP-11-Hardware, Treiber und Standortplanung mussten zusammenpassen, bevor die Drei-Netze-Übertragung gelingen konnte.
  • Die Quellen trennen installierte Standorte von tatsächlich genutzten Paketwegen und Forschungsprototypen vom Dauerbetrieb. Selbst der widersprüchlich überlieferte Demonstrationstag bleibt als Unsicherheit sichtbar.

In Oslo war der Softwarefehler zunächst ein fehlender Rechner. Ginny Strazisar war angereist, um nach einem TCP/IP-Treffen ihre Gateway-Software zu installieren. Die Hardware stand noch nicht bereit. Sie blieb einige Tage bei Paal Spilling, reiste durch Norwegen und kam zurück, als der PDP-11 die Software endlich aufnehmen konnte. In der Oral History des Computer History Museum klingt das wie eine freundliche Reiseerinnerung. Technisch beschreibt es den Augenblick, an dem eine Abstraktion von Lieferterminen abhängig wird.

Strazisar war im April 1975 zu Bolt Beranek and Newman gekommen. Bald arbeitete sie an den damals so genannten Gateways, also den Rechnern, die Netze verbanden. BBN betrieb bereits ein Gateway zwischen seinem experimentellen Resource Computer Network und ARPANET. Danach folgten Grenzen zwischen ARPANET und Packet Radio Network sowie zwischen ARPANET und Atlantic Satellite Network. Das Museum nennt Strazisar die Autorin der ersten Internetworking-Routersoftware für die neuen TCP/IP-Protokolle, noch bevor „Router“ die übliche Bezeichnung wurde.

Dieser Satz ist eine genaue Zuschreibung, keine Alleinerfinder-Erzählung. TCP, Funknetz, Satellitennetz und ARPANET hatten viele Urheber. Strazisar verantwortete die ausführbare Verbindung: Software, die auf einer Seite einen lokalen Mechanismus akzeptierte und auf der anderen Seite einen anderen bediente, ohne beide Netze gleich zu machen.

Die Unterschiede waren der Zweck des Vorhabens. Im Funknetz bewegten sich Endgeräte, Relais änderten den Weg, und das Testnetz war nicht ständig aktiv. ARPANET brachte eigene Schnittstellen mit. SATNET spannte sich über den Atlantik und setzte verteilte Stationen und Teams voraus. Geschwindigkeit, Verfügbarkeit und Fehlerbilder waren asymmetrisch. Das Gateway musste diese Asymmetrie tragen, nicht beseitigen.

Auch die Rechneranordnung war ortsabhängig. Beim Packet Radio Network liefen Stations- und Gateway-Code gemeinsam auf einem PDP-11. Die Gateways zwischen ARPANET und Satellitennetz waren eigenständige PDP-11-Systeme: eine Seite sprach mit ARPANET, die andere mit SATNET, dazwischen leitete die Software Datagramme weiter. Gemeinsam war die Funktion, nicht die Einbausituation.

Strazisars Erinnerung liefert eine materielle Zeitleiste: BBN im Sommer 1976, London im Dezember 1976, Norwegen im Sommer 1977. Hardware und Software lagen bei verschiedenen Verantwortlichen. In London war der PDP-11 vor ihrer Software-Installation angekommen. In Oslo störte eine Verzögerung die Reihenfolge. Ein Programmplan auf hoher Ebene zerfiel in konkrete Fragen: Ist die Maschine da? Ist die Schnittstelle verkabelt? Kann der Code geladen werden?

Auch die Versuche wurden schrittweise ausgeweitet. Eine Zeitschrift des Computer History Museum beschreibt Tests im Sommer 1976, die einen Funkhop von der Station entfernt blieben, in der Strazisars bidirektionales ARPANET-Gateway lief. Sie datiert eine zeremonielle Zwei-Netze-Übertragung auf den 27. August. Die nächste Stufe musste zeigen, dass die Verbindung nicht nur ein Sondertrick für dieses Paar war.

1977 sendete ein fahrender Funkwagen in Kalifornien Daten über die SRI-Infrastruktur, ARPANET und das Satellitennetz zu einem Server an der USC, nachdem der Pfad transatlantische Einrichtungen durchlaufen hatte. Drei physische Netztypen und mehrere Implementierungen bildeten eine Ende-zu-Ende-Verbindung.

Die Überlieferung ist dennoch nicht glatt. Der Museumsbeitrag von 2017 nennt Mittwoch, den 22. November, als Versuchstag. Die Zeitschrift von 2002 beschriftet ihr Drei-Netze-Diagramm mit dem 27. November. Ebenso darf Installationsgeografie nicht mit Paketgeografie verwechselt werden. Strazisar installierte in Norwegen, doch Vint Cerf erinnerte sich im Gespräch daran, dass der Demonstrationsverkehr Norwegen nicht tatsächlich durchlief.

Das ist mehr als historische Genauigkeit. „Installiert“ belegt, dass Code und Maschine an einem Standort zusammenkamen. „Zugestellt“ belegt einen Pfad in einer bestimmten Konfiguration. Keiner der beiden Zustände beweist automatisch Ausweichwege, jede Schnittstelle oder Dauerbetrieb. Eine erfolgreiche Vorführung darf ungetestete Zustände nicht nachträglich beglaubigen.

Die Leistung war kollektiv. Das Museum nennt mehr als 35 Menschen und acht Institutionen. Bob Kahn und Vint Cerf werden für das TCP-Konzept, Jim Mathis und Dave Retz für den Client, Ray Tomlinson und Bill Plummer für den Server aufgeführt. Teams von SRI, Collins Radio, Linkabit, BBN, UCL und der norwegischen Forschungseinrichtung trugen Funk-, Satelliten- und Stationsarbeit. Virginia Strazisar steht bei den BBN-Gateways. Sie beherrschte nicht beide Netze; sie machte ihre Berührung funktionsfähig.

Nach dem Versuch wurde ausführbares Wissen zu dokumentiertem Wissen. RFC 823 verweist zunächst auf IEN 30, Gateway Routing: An Implementation Specification, anschließend auf Strazisars IEN 109, How to Build a Gateway. Besonders gewürdigt werden V. Strazisar, M. Brescia, E. Rosen und J. Haverty. Andere konnten nun nicht nur den Erfolg sehen, sondern die Implementierungsstruktur untersuchen.

IEN 30 macht seine Erkenntnisgrenzen deutlich. Der Routing-Algorithmus ist detailliert genug zur Implementierung und soll ausgefallene Komponenten umgehen. Trotzdem lasse sich nicht beweisen, dass Gateways immer korrekt weiterleiten oder bestimmte Ziele niemals auf unbestimmte Zeit unerreichbar bleiben. Verwundbarkeit zeigt sich womöglich erst im Experiment und Betrieb. Zudem können Routing-Informationen beschädigt, Hardware und Software fehlerhaft oder ein korrekter Algorithmus falsch programmiert sein.

RFC 823 dokumentiert später einen Wechsel des Betriebsregimes. Frühe Versionen nutzten BCPL und ELF, danach MOS für höhere Leistung. Ende 1981 begann eine neue Implementierung für eine operative Kommunikationsanlage statt nur für ein Forschungstestbett. MACRO-11 sparte Speicher, damit Puffer und Überwachungsmechanismen Platz fanden. Die Architektur blieb laut RFC dennoch grundsätzlich dieselbe.

Betriebsreife hieß, Grenzen messbar zu machen. Jede Schnittstelle erhielt eine begrenzte Ausgangswarteschlange, damit ein langsames Netz nicht alle Puffer verbrauchte. Passte ein Datagramm nicht hinein, wurde es verworfen und ein Überwachungsereignis erzeugt. Schnittstellen, Nachbarn, erreichbare Netze, Durchsatz und Verlustgründe wurden sichtbar. RFC 823 bezeichnet sich selbst als Momentaufnahme der aktuellen Implementierung, nicht als endgültige Spezifikation.

Eine heutige Interoperabilitätsbehauptung braucht dieselbe Beweiskette: Welcher Binärcode läuft? Auf welcher Hardware und mit welchem Treiber? Welche Schnittstelle wurde wirklich belastet? Welcher Zähler erklärt einen Verlust? Ein Diagramm belegt Absicht. Ein angekommenes Paket belegt einen Weg. Reproduzierbare Installation und beobachtetes Fehlverhalten belegen Betriebsfähigkeit.

Der Code reiste zuerst, weil Interoperabilität einen Ort besitzt. Sie steckt im Installationsmedium, in der Board-Revision, im lokalen Kabel, im Wartungsfenster und in Menschen, die den fernen Zustand deuten können. Das Protokoll ließ verschiedene Netze verschieden bleiben. Die Arbeit vor Ort ließ sie trotzdem miteinander sprechen.

Sources