Zusammenfassung

  • Segals Vorschlag vom August 1984 sollte TCP/IP auf wichtigen Nicht-Unix-Systemen wie dem zentralen IBM-VM-Rechner und einer VAX unter VMS erproben. Der Pilot untersuchte die Koexistenz offener und proprietärer Computerwelten.
  • Als erster TCP/IP-Koordinator machte Segal ab 1985 aus dem Versuch einen laufenden Dienst. Eine zeitgenössische Bestandsaufnahme zählte im März 1988 bereits 355 Hosts, obwohl externe TCP/IP-Verbindungen ausdrücklich untersagt waren.
  • Erst die koordinierte Umstellung auf offiziell zugewiesene IP-Adressen im Januar 1989 bereitete den ersten externen Internetverbindungen den Weg. Technische Einführung, betriebliche Zuständigkeit und Grenzöffnung waren getrennte Entscheidungen.

Eine betriebsfähige Insel

Die Zahl 355 stammt aus einem Bericht, der im Frühjahr 1988 für die Vorbereitung des LEP-Betriebs entstand. Er führt IBM, Norsk Data, Apollo, VAX, PC, Sun, Cray und Macintosh auf. TCP/IP wurde intensiv eingesetzt, nicht nur beobachtet: für Remote Login, Dateiübertragung und auf RPC beruhende Anwendungen.

Eine derart breite Installation wirkt wie das Ende einer Einführungsgeschichte. Tatsächlich war sie nur innerhalb des CERN-Geländes vollständig. Die zuständige Kommunikationspolitik verbot jede externe TCP/IP-Verbindung. Hunderte Rechner konnten dieselbe Protokollfamilie sprechen, ohne im globalen Internet erreichbar zu sein.

Damit liefert der Fall einen selten klaren Unterschied: Reichweite innerhalb einer Verwaltungsdomäne ist nicht dasselbe wie die Erlaubnis, ihre Grenze zu überschreiten.

Der Pilot begann bei den schwierigen Systemen

Segal kam 1971 ans CERN. Datenkommunikation bestand aus Herstellerlösungen, hauseigenen Netzen und noch unvollständigen offenen Standards. Während eines Aufenthalts in Palo Alto 1977 lernte er ARPANET und Unix kennen. Am CERN musste jedoch nicht eine grüne Wiese vernetzt werden, sondern ein Bestand, dessen Großrechner und Spezialanlagen weiter gebraucht wurden.

1983 richtete das CERN eine Data-Communications-Gruppe mit dem Auftrag ein, die Netze zu vereinheitlichen. In der Praxis blieben die Aufgaben verteilt. Die neue Gruppe konzentrierte sich auf einen standortweiten Backbone und ISO-Standards, mit DECnet als wichtiger Ausnahme. IBM-Netze, E-Mail, News, Unix und Workstations lagen bei anderen Gruppen. TCP/IP wuchs genau an dieser organisatorischen Nahtstelle.

Im August 1984 schlug Segal vor, TCP/IP auf wichtigen Nicht-Unix-Rechnern zu installieren und auszuwerten. Der zentrale IBM-VM-Mainframe und ein VAX-VMS-System gehörten ausdrücklich dazu. Nicht die Kommunikation zweier ähnlicher Workstations sollte überzeugen, sondern eine gemeinsame Schicht zwischen neuen offenen Systemen und unverzichtbaren proprietären Plattformen.

Der Versuch wurde genehmigt. Segals spätere Darstellung nennt zwei Ergebnisse: TCP/IP galt als besonders aussichtsreiche Lösung, und Berkeley Sockets wurden als Programmierschnittstelle empfohlen. Letzteres übersetzte Netzkompatibilität in Anwendungsentwicklung. Eine gemeinsame API verringerte den Aufwand für jeden weiteren Dienst.

Koordination hieß, verteilte Zustände zusammenzuhalten

Anfang 1985 ernannte eine formelle Vereinbarung zwischen Software und Data Communications Segal zum ersten TCP/IP-Koordinator des CERN. Die Funktion sollte einen laufenden Betrieb ermöglichen, verlieh aber keine Entscheidungsgewalt über die Außengrenze.

Der Bericht von 1988 beschreibt statisches Routing und eine zentrale Host-Tabelle. Der Koordinator pflegte die maßgebliche Fassung von Namen, Adressen und Routen und verteilte Änderungen an Systemverantwortliche, die lokale Kopien betrieben. Die technische Wahrheit lag also an mehreren Orten und musste regelmäßig abgeglichen werden.

Ein Protokoll lässt sich einmal installieren; eine solche Ordnung muss ständig erneuert werden. Neue Hosts, geänderte Adressen und fehlerhafte Tabellen konnten den Dienst unterbrechen, obwohl die Software korrekt war. Segals Rolle machte Wartung zu einem benannten Bestandteil der Architektur.

Außerhalb des Standorts galt weiterhin eine andere Ordnung. In Europa unterstützten Regierungen, Fernmeldeverwaltungen und Industrie ISO-orientierte Standards und etablierte proprietäre Netze. Die politische Auseinandersetzung um Internetprotokolle war real. Interne Beweise ersetzten keine institutionelle Entscheidung über externe Abhängigkeiten.

LEP machte den Pilotversuch unverzichtbar

Im November 1985 entschied sich die Leitung des 27 Kilometer langen LEP-Beschleunigers für TCP/IP im Kontrollsystem. Die spätere Wahl Unix-basierter Systeme verstärkte diese Richtung. Segal bewertete beide Entscheidungen als wesentlich für den Erfolg von LEP.

Ein kritischer Großkunde verändert die Ökonomie eines Piloten. Solange nur Entwickler testen, kann Betreuung improvisiert bleiben. Wenn eine Forschungsanlage von der Verbindung abhängt, werden Verfügbarkeit, Zuständigkeit und Personal zu Betriebsfragen.

Zwischen 1985 und 1988 wuchs TCP/IP mit wenigen Beteiligten. 1988 übernahm Data Communications schließlich den Support. Aus einer knapp ausgestatteten Aktivität der Softwaregruppe wurde ein organisierter Dienst. Die Institution akzeptierte damit nicht nur die Technik, sondern auch ihre dauerhaften Kosten.

Die Außengrenze blieb bis dahin geschlossen. Die Schritte „funktioniert“, „wird gebraucht“ und „wird offiziell getragen“ führten nicht automatisch zu „darf extern kommunizieren“.

Der Adresswechsel als institutioneller Schnitt

In einem geschlossenen Netz müssen Adressen nur intern eindeutig sein. Für das Internet müssen sie in einen weltweit anerkannten Adress- und Routingraum passen.

Im Januar 1989 stellte CERN alle IP-Adressen in einem koordinierten „Big Bang“ auf offiziell zugewiesene Werte um. Danach folgten die ersten externen Internetverbindungen.

Die Umstellung war gerade deshalb aufwendig, weil der Pilot erfolgreich gewesen war. Nun mussten nicht wenige Testrechner, sondern Hunderte Systeme, Anwendungen, Tabellen und lokale Administratoren gleichzeitig wechseln. Eine provisorische Konvention wird mit jedem neuen Nutzer schwerer reversibel.

Die neuen Adressen waren daher keine kosmetische Bereinigung. Sie markierten den Übergang von lokaler Eindeutigkeit zu globaler Anerkennung. Erst als Support, Adressierung und Außenpolitik zusammenpassten, bekam eine externe Leitung ihren vollen Sinn.

Die Infrastruktur war nicht das World Wide Web

Tim Berners-Lee schrieb im März 1989 seinen ersten Vorschlag für das World Wide Web. Bis Ende 1990 liefen am CERN der erste Webserver und Browser. Die zeitliche Nähe verführt dazu, Internetöffnung und Web-Erfindung als einen Vorgang zu erzählen.

Segal half, das technische Umfeld zu schaffen. Laut Internet Hall of Fame führte er Entwickler in IP-Stack und Berkeley Sockets ein und verwies Berners-Lee auf RFCs sowie bestehende Protokolle wie FTP und NNTP. Das ist eine konkrete Beratung und Vorbereitung, aber keine Miterfindung des Web.

Segal setzte selbst eine saubere Grenze. Die Vermutung, ein früherer Internetanschluss hätte ein früheres Web ermöglicht, bezeichnete er als Spekulation. Sicher sei, dass das Internet eine Gelegenheit bot.

Diese Vorsicht verteilt Anerkennung genauer. Eine heterogene Organisation internetfähig zu machen und ein neues Informationssystem darauf zu entwerfen, sind verbundene, aber eigenständige Leistungen.

Was der Pilot der Entscheidung lieferte

1989 verfügte das CERN über mehr als eine technische Demonstration. Es hatte Anwendungen, Erfahrung auf zahlreichen Plattformen, eine gemeinsame API, einen Koordinator, ausgebildete Administratoren, einen kritischen Nutzer und eine formelle Supportstruktur.

Der interne Erfolg verringerte das Risiko der Öffnung. Er zwang sie aber nicht herbei. Offizielle Adressen, externe Sicherheit, wechselseitige Erreichbarkeit und institutionelle Verantwortung mussten weiterhin ausdrücklich akzeptiert werden.

Segals Beitrag lag in dieser langen Zwischenphase. Er hielt die Technik nicht nur am Leben, sondern verwandelte sie in überprüfbare Betriebserfahrung. Als die Grenze 1989 geöffnet wurde, traf die Entscheidung auf ein vorbereitetes Netz statt auf ein Versprechen.

Quellen