Wo das Netz aufhörte: Die IMP-Grenze und die Neuverteilung technischer Verantwortung

Zusammenfassung

• Der IMP war weder bloß eine Leitung noch ein früher IP-Router. Er war ein funktionsreicher, von BBN im Auftrag von ARPA gebauter Paketvermittler, der Paketierung, Prüfsummen, Weiterleitung, Wiederzusammensetzung, Messung, Tracing und Teile der Flusskontrolle übernahm. Gleichzeitig machten schon die ersten RFCs deutlich, dass Host-Software und die Zusammenarbeit der Hosts für vollständige Kommunikation unverzichtbar blieben.
• Die spätere Internetarchitektur war keine einfache Fortsetzung dieses Modells. NCP setzte auf ein einziges zuverlässiges ARPANET und konnte keine eigenständigen Netze adressieren. Offenes Internetworking, Quell-Reübertragung und schließlich das Ende-zu-Ende-Argument verschoben deshalb die Prüfung vollständiger Korrektheit zu den Endsystemen, ohne die gemeinsame Infrastruktur abzuschaffen.

Im Herbst 1969 war die wichtigste Grenze des entstehenden ARPANET keine Landesgrenze, keine Unternehmensgrenze und noch nicht einmal eine Protokollgrenze im späteren Sinn. Sie verlief durch einen Kabelanschluss.

Auf der einen Seite stand ein Rechner der Universität oder eines Forschungszentrums. Auf der anderen stand ein Interface Message Processor, kurz IMP: ein aus einem Honeywell-516-System entwickelter Rechner, dessen Hardware und Software aus einem ARPA-Auftrag an Bolt Beranek and Newman hervorgingen. Dazwischen lag eine Schnittstelle, die nicht nur elektrische Signale trennte. Sie verteilte Verantwortung.

Die erste Generation von ARPANET war deshalb bereits institutionell und technisch modular, aber anders modular als das spätere Internet. BBN lieferte ein Paketvermittlungs-Subnetz. Die angeschlossenen Forschungsgruppen mussten ihre Hosts befähigen, dieses Subnetz zu benutzen und untereinander Protokolle zu vereinbaren. Der Netzunterbau erledigte erstaunlich viel. Er zerlegte Nachrichten, transportierte Pakete durch das IMP-Netz, prüfte Übertragungen, setzte Nachrichten am Ziel wieder zusammen, unterstützte Messung und Tracing und begrenzte bestimmte Formen des Datenflusses. Er war keine neutrale Röhre.

Und doch konnte er nicht bestimmen, was eine Anwendung bedeutete, wie zwei entfernte Programme miteinander umgehen sollten oder ob die Kommunikation für den jeweiligen Zweck tatsächlich korrekt abgeschlossen war. Schon die frühen Arbeitsnotizen des Netzes zeigen daher etwas, das in rückblickenden Erzählungen leicht verloren geht: Die Grenze zwischen Netz und Host war nicht bloß eine Aufteilung von Rechenaufwand. Sie war eine Grenze des Wissens.

Genau diese Grenze sollte einige Jahre später entscheidend werden. NCP, die frühe Host-Kommunikationsarchitektur des ARPANET, konnte sich auf die Eigenschaften eines einzigen Netzes verlassen. Als jedoch Paketfunk-, Satelliten- und andere Netze miteinander verbunden werden sollten, wurde diese Annahme zur Begrenzung. Ein Netz konnte nicht mehr selbstverständlich garantieren, was nur die Gesamtheit einer Kommunikation über mehrere unabhängig entworfene Netze betraf.

Die Reaktion darauf war nicht die Abschaffung leistungsfähiger Infrastruktur. Sie war eine neue Platzierungsregel für Verantwortung: unabhängige Netze sollten eigenständig bleiben; Gateways sollten möglichst wenig verbindungsspezifischen Zustand tragen; Zustellung konnte nach dem Best-Effort-Prinzip erfolgen; verlorene Information sollte von der Quelle erneut gesendet werden können.

Später formulierte das Ende-zu-Ende-Argument den allgemeineren Test: Funktionen, deren vollständige Korrektheit Wissen der Anwendung benötigt, können auf einer niedrigeren Schicht höchstens teilweise oder als Leistungsoptimierung realisiert werden. Für Vollständigkeit müssen die Endpunkte beteiligt sein.

Diese Entwicklung lässt sich leicht zu einer Legende vom „dummen Netz“ vereinfachen. Historisch wäre das falsch. Der IMP war gerade deshalb wichtig, weil er technische Arbeit zentralisierte, die ansonsten jeder Host selbst hätte lösen müssen. Die spätere Internetarchitektur behielt ebenfalls Routing, Weiterleitung, Messung, Betriebszustand und Sicherheitsmechanismen im Netz. Was sich änderte, war nicht die Existenz von Infrastruktur, sondern der Anspruch, welche Art von Korrektheit diese Infrastruktur verbindlich herstellen könne.

Ein Subnetz, damit nicht jeder Rechner das Netz neu erfinden musste

Die Entscheidung, für ARPANET dedizierte Paketvermittlungsrechner einzusetzen, löste ein sehr praktisches Problem. Die angeschlossenen Standorte betrieben unterschiedliche Großrechner, unterschiedliche Betriebssysteme und unterschiedliche lokale Entwicklungspraktiken. Hätte jeder Host zugleich die gesamte Fernnetzlogik implementieren müssen, wären Interoperabilität, Fehlerdiagnose und Betrieb von den Eigenheiten jedes einzelnen Systems abhängig geworden.

Ein separates Subnetz bot einen anderen Weg. Die Hosts sollten über standardisierte Schnittstellen an spezialisierte Paketvermittler angeschlossen werden. Diese IMPs konnten untereinander eine gemeinsame Transportinfrastruktur bilden, während die Host-Gruppen sich auf die Software oberhalb dieser Schnittstelle konzentrierten.

RFC 1 ist gerade deshalb bemerkenswert, weil die organisatorische Aufteilung darin so offen ausgesprochen wird. ARPA-Network-Software existiere teils in den IMPs und teils in den Hosts. BBN spezifizierte die IMP-Software; die Host-Gruppen mussten sich darüber verständigen, welche Host-Software erforderlich war. Das ist keine spätere Interpretation einer undokumentierten Arbeitsteilung. Es ist eine zeitgenössische Beschreibung der entstehenden Architektur.

Die Grenze war zugleich institutionell. ARPA konnte einen Auftrag vergeben. BBN konnte Hardware und Software liefern, testen und betreiben. Die Standorte erhielten damit einen konkreten technischen Gegenpart, gegen dessen Schnittstelle sie entwickeln mussten. Doch aus dieser Beschaffungsmacht folgte nicht automatisch die Kompetenz, Host-Protokolle, Anwendungen oder die Architektur künftiger unabhängiger Netze zu bestimmen.

Diese Unterscheidung ist wichtiger, als sie zunächst klingt.

Beschaffungsmacht beantwortet die Frage, wer bezahlt, auswählt und vertragliche Anforderungen durchsetzt. Gelieferte Implementierung beantwortet die Frage, wer tatsächlich funktionierende Hardware und Software bereitstellt. Schnittstellenautorität beantwortet die Frage, welche Anforderungen ein angeschlossener Teilnehmer erfüllen muss, um mit dieser Implementierung kommunizieren zu können. Architekturmandat wäre etwas Größeres: die dauerhafte Befugnis, auch jenseits der gelieferten Funktion darüber zu entscheiden, wie andere Systeme aufgebaut sein müssen.

Für BBN sind die ersten drei Formen von Autorität gut belegbar. Für die vierte fehlt eine solche Grundlage.

Die Unterscheidung schwächt die Bedeutung des Vertrags nicht. Sie macht sie präziser.

Der Auftrag von ARPA war die Bedingung dafür, dass das Subnetz gebaut wurde. Die Lieferung des ersten IMP an UCLA im September 1969 setzte einen Termin, gegen den andere Teams arbeiten mussten. Steve Crockers späterer Rückblick beschreibt, wie die Host-Seite ihre Interfaces und Software vorbereiten musste, obwohl manche Details unter erheblichem Zeitdruck entwickelt wurden. Frank Hearts Erinnerungen zeigen zudem, dass Zuverlässigkeit keine abstrakte Eigenschaft eines Architekturdiagramms war. Debugging, Neustart, Reloading und die Möglichkeit, Leitungen umzuschalten, waren konkrete Betriebsprobleme.

Die betriebsfähige Implementierung hatte hier eine sehr wörtliche Bedeutung: Eine Architektur existiert operativ erst, wenn Geräte geliefert, Leitungen verbunden, Software ausgeführt und Fehler beseitigt werden können.

Der IMP war kein leerer Transportkanal

Wer den späteren Erfolg eines schlanken IP-Layers kennt, kann den frühen IMP leicht unterschätzen. Seine Funktionen waren jedoch erheblich.

RFC 1 beschreibt Nachrichten mit einer Länge von bis zu 8.080 Bit. Der IMP zerlegte sie in Pakete von höchstens 1.010 Bit, fügte Mechanismen zur Fehlerkontrolle hinzu, transportierte die Pakete über das Subnetz und setzte sie am Ziel-IMP wieder zu einer Nachricht zusammen. Eine 24-Bit-Zyklische Prüfsumme gehörte zur Übertragungssicherung. Logische Links strukturierten den Datenverkehr. Trace-Funktionen halfen bei der Beobachtung. Request-for-Next-Message, RFNM, bildete einen Mechanismus zur Flusskontrolle.

Damit übernahm die gemeinsame Infrastruktur eine Reihe von Aufgaben, die in anderen Architekturen teilweise den Endsystemen zufallen könnten.

Das war kein Designfehler. In einem Netz aus heterogenen, teuren und schwer programmierbaren Rechnern war es ökonomisch und betrieblich attraktiv, gemeinsame Probleme einmal im Subnetz zu lösen. Eine stabile Paketvermittlung reduzierte die Zahl der Implementierungen, die jedes Host-Team selbst entwickeln musste. Gemeinsame Mechanismen ließen sich zentral testen. Fehlerbilder konnten systematischer beobachtet werden. Ein spezialisiertes Subnetz konnte sogar eine gewisse Unabhängigkeit von den Eigenheiten der angeschlossenen Großrechner schaffen.

Die frühe ARPANET-Architektur demonstriert damit einen immer wiederkehrenden Vorteil gemeinsamer Infrastruktur: Sie kann Komplexität von vielen Teilnehmern aufnehmen und als gemeinschaftliche Dienstleistung zurückgeben.

Der Preis dafür ist, dass die gemeinsame Schicht Zustände und Annahmen tragen muss.

Die IMPs mussten wissen, wie Pakete transportiert wurden. Sie mussten Ressourcen verwalten. Sie mussten erkennen, wann eine Nachricht weitergegeben werden konnte. Sie mussten mit Übertragungsfehlern umgehen. Sie mussten über logische Links und Puffer verfügen. Sie mussten bei Störungen diagnostizierbar bleiben.

Das Netz war also nicht „zustandslos“. Und es wäre historisch ebenfalls falsch, den IMP einfach als frühen Router zu bezeichnen. Er war ein Paketvermittler eines ARPANET-Subnetzes vor IP, mit Mechanismen, die deutlich über das hinausgingen, was ein späterer IP-Router für einzelne Datagramme garantierte.

Die interessante Frage lautet deshalb nicht, ob Infrastruktur Funktionen übernehmen darf. Die interessante Frage lautet, welche Funktionen sie vollständig richtig ausführen kann.

Die ersten RFCs zeigen, wo das Wissen fehlte

Gerade weil der IMP viel übernahm, sind die Stellen wichtig, an denen die frühen RFCs seine Grenzen offenlegen.

RFC 1 beschreibt etwa, dass die Konstruktion logischer Links bestimmte Überlastungssituationen begrenzen konnte, der Ziel-IMP aber nicht unbegrenzt Kapazität für alle Links gleichzeitig bereithielt. Das System war deshalb auf Kooperation der Hosts angewiesen.

RFC 2 zeigt auf der Host-Seite weiteren Zustand: Links mussten verwaltet, Prüfungen vorgenommen, Quittungen verarbeitet und Informationen über entfernte Hosts berücksichtigt werden. RFC 7 dokumentiert Host-IMP-Interface-Verarbeitung, Multiplexing und Pufferverwaltung. Selbst bei einem funktionsreichen Subnetz existierte also kein Punkt, an dem das Netz allein vollständiges Wissen über den Kommunikationsvorgang besaß.

Das ist ein wichtiger Unterschied zwischen lokaler Zuverlässigkeit und vollständiger Korrektheit.

Ein IMP konnte feststellen, ob ein Paket auf einer Leitung beschädigt worden war. Er konnte kontrollieren, ob eine Nachricht nach seinen Regeln übertragen und wieder zusammengesetzt wurde. Er konnte Datenfluss begrenzen. Er konnte Zustände melden.

Aber er konnte nicht aus eigener Kenntnis entscheiden, ob ein entferntes Programm die Daten semantisch richtig verarbeitet hatte. Er konnte nicht wissen, ob eine Anwendung eine Transaktion vollständig abgeschlossen hatte. Er konnte nicht garantieren, dass die Bedeutung einer Nachricht auf beiden Seiten identisch verstanden wurde.

Vollständige Korrektheit hängt häufig von Wissen ab, das nur die Endsysteme besitzen.

Das Ende-zu-Ende-Argument sollte diese Einsicht später theoretisch verallgemeinern. Doch man sollte es nicht rückwärts in das Jahr 1969 projizieren. Die Entwickler des frühen ARPANET arbeiteten nicht einfach nach einer bereits ausformulierten Ende-zu-Ende-Doktrin. Im Gegenteil: Die IMPs übernahmen erhebliche Zuverlässigkeitsfunktionen.

Die historische Linie ist subtiler. Der frühe Betrieb produzierte eine funktionale Grenze. Später, unter veränderten Anforderungen, wurde aus der Beobachtung solcher Grenzen eine explizitere Architekturregel.

Zuverlässigkeit war ein Betriebsprodukt, kein Etikett

Ein Netz kann auf Papier zuverlässig sein und im Betrieb dennoch unbrauchbar werden. Hearts Rückblick ist deshalb relevant, weil er zeigt, wie stark die Zuverlässigkeit des IMP mit ganz gewöhnlichen technischen Vorkehrungen verbunden war.

Rechner mussten neu geladen werden können. Fehler mussten diagnostiziert werden. Leitungen mussten sich im Problemfall anders verschalten lassen. Betriebspersonal brauchte Möglichkeiten, Fehlerquellen zu isolieren. Software musste mit realer Hardware und realen Übertragungswegen umgehen.

Diese Details sind für die Architekturgeschichte wichtig, weil sie zwei verschiedene Formen von Zuverlässigkeit sichtbar machen.

Die erste ist lokale infrastrukturelle Zuverlässigkeit: Kann der Paketvermittler seine Aufgabe trotz Bitfehlern, Leitungsproblemen, Neustarts und Ressourcengrenzen erfüllen?

Die zweite ist Ende-zu-Ende-Korrektheit: Hat die Kommunikation aus Sicht der beteiligten Anwendungen tatsächlich das richtige Ergebnis geliefert?

Die erste kann eine gemeinsame Netzschicht sehr weitgehend verbessern. Die zweite kann sie oft nur vorbereiten.

Diese Unterscheidung erklärt, weshalb es falsch wäre, aus dem späteren Ende-zu-Ende-Prinzip zu schließen, die frühen Investitionen in zuverlässige IMPs seien überflüssig gewesen. Eine niedrigere Schicht kann Fehlerwahrscheinlichkeiten drastisch verringern und damit die Leistung des Gesamtsystems verbessern. Sie kann Wiederholungen vermeiden, Diagnose erleichtern und die normale Kommunikation beschleunigen.

Sie kann trotzdem nicht die letzte Prüfung ersetzen, wenn diese Wissen benötigt, das außerhalb ihrer Sicht liegt.

Der spätere Aufsatz von Saltzer, Reed und Clark machte genau daraus einen Platzierungstest: Eine Funktion, deren vollständige und korrekte Implementierung Anwendungswissen benötigt, muss unter Beteiligung der Endpunkte realisiert werden. Eine Implementierung in niedrigeren Schichten kann weiterhin sinnvoll sein — aber dann als Optimierung, nicht als alleiniger Beweis der Korrektheit.

Die historische Bedeutung des IMP liegt deshalb nicht darin, dass er „zu viel“ tat. Sie liegt darin, dass seine Leistungsfähigkeit die Grenze zwischen nützlicher Infrastrukturarbeit und vollständiger Kommunikationsgarantie besonders deutlich sichtbar machte.

NCP funktionierte, solange das Netz eine gemeinsame Welt war

Innerhalb des frühen ARPANET war eine weitere Annahme plausibel: Es gab ein Netz, und dieses Netz konnte einen zuverlässigen Dienst zwischen angeschlossenen Hosts bereitstellen.

NCP baute auf dieser Umwelt auf. Ein Ziel wurde im Zusammenhang mit dem ARPANET und seinem IMP-Adressraum gedacht. Die Host-Kommunikation konnte Eigenschaften des zugrunde liegenden Netzes voraussetzen.

Das Problem entstand nicht, weil diese Annahme in ihrer ursprünglichen Umgebung offensichtlich unsinnig gewesen wäre. Sie entstand, weil die Umwelt größer wurde.

Paketfunknetze, Satellitennetze und andere paketvermittelte Systeme mussten nicht nach derselben internen Architektur arbeiten wie ARPANET. Sie konnten unterschiedliche Paketgrößen, Fehlereigenschaften, Verzögerungen, Verwaltungsmodelle und Betriebsbedingungen besitzen. Ein Protokoll, das ein einziges zuverlässiges Netz voraussetzt, lässt sich nicht einfach unverändert auf eine Welt aus unabhängigen Netzen ausdehnen.

Damit änderte sich die Architekturfrage.

Im ARPANET konnte man fragen: Welche Zuverlässigkeitsfunktionen gehören in das gemeinsame Paketvermittlungs-Subnetz?

Beim Internetworking musste man zusätzlich fragen: Welche Funktion kann überhaupt als gemeinsame Annahme gelten, wenn jedes beteiligte Netz intern anders arbeitet?

Das ist eine härtere Bedingung.

Eine gemeinsame Schicht, die zu viele Annahmen über ihre Umgebung verlangt, funktioniert nur, solange alle Teilnehmer diese Annahmen erfüllen. Je heterogener das System wird, desto teurer wird eine dicke gemeinsame Semantik.

Offene Architektur bedeutete daher nicht, dass die unabhängigen Netze ihre internen Eigenschaften aufgeben sollten. Im Gegenteil: Ein wesentliches Ziel bestand darin, dass jedes Netz eigenständig bleiben konnte.

Damit wurde der verbindende Mechanismus absichtlich enger.

Vom zuverlässigen Netz zum bestmöglichen verbindenden Dienst

Die später beschriebene Open-Architecture-Idee setzte mehrere Grundregeln.

Einzelne Netze sollten für sich stehen können. Sie mussten intern nicht umgebaut werden, nur um Teil des Verbunds zu werden. Kommunikation sollte auf Best-Effort-Basis möglich sein. Wenn Pakete verloren gingen, sollte die Wiederherstellung durch erneute Übertragung von der Quelle erfolgen können. Die verbindenden Gateways sollten möglichst einfach bleiben und nicht für jede einzelne Verbindung umfangreichen Zustand halten müssen.

Diese Entscheidungen waren keine philosophische Vorliebe für Einfachheit. Sie waren Antworten auf das Skalierungsproblem heterogener Netze.

Wenn ein Gateway wissen muss, welche Anwendung hinter jeder Verbindung steht, welche Semantik sie erwartet und welche Wiederherstellungsregeln für sie gelten, wird das Gateway Teil des Zustands jeder Anwendung. Seine Ausfälle werden schwieriger. Ein alternatives Netz kann ihn schwerer ersetzen. Neue Anwendungen müssen sich an die Annahmen der Vermittlungsinfrastruktur anpassen.

Ein schmalerer Gateway kann dagegen Netzgrenzen überbrücken, ohne zum Besitzer der gesamten Kommunikationssemantik zu werden.

RFC 675, die Spezifikation des Internet Transmission Control Program von Dezember 1974, gehört in diese spätere Phase. Sie darf nicht als Beschreibung des ursprünglichen ARPANET-IMP-Dienstes gelesen werden. Ihr Wert für diese Geschichte liegt gerade im Kontrast: Das Problem war nun nicht mehr nur Kommunikation über ein paketvermitteltes Subnetz, sondern Kommunikation über miteinander verbundene, eigenständige Netze.

Der Wandel war deshalb ein Wandel der Zuständigkeitsgeometrie.

Beim IMP-Modell ließ sich Zuverlässigkeit in erheblichem Umfang innerhalb eines einzelnen gemeinsamen Netzes konzentrieren. Beim Internetworking musste ein Endsystem damit rechnen, dass der Gesamtpfad aus mehreren Netzen bestand, deren interne Mechanismen nicht unter einer einzigen Kontrolle standen.

Eine Eigenschaft, die ein Netz lokal garantiert, ist nicht automatisch eine Eigenschaft des gesamten Verbunds.

Je mehr Netze beteiligt sind, desto wichtiger wird deshalb die Fähigkeit der Endpunkte, den Erfolg selbst zu überprüfen und sich von Fehlern selbst zu erholen.

Ende-zu-Ende war eine Platzierungsregel, kein Verbotskatalog

Das Ende-zu-Ende-Argument wird häufig verkürzt zu der Formel, Funktionen sollten „an den Rand“. Das unterschlägt den analytischen Kern.

Saltzer, Reed und Clark unterscheiden nicht einfach zwischen guten Endpunkten und schlechtem Netz. Ihr Test richtet sich auf Vollständigkeit.

Wenn eine Funktion nur mit Wissen der Anwendung vollständig und korrekt ausgeführt werden kann, kann ihre Implementierung in einer niedrigeren Schicht die Endsystemprüfung nicht ersetzen. Die niedrigere Schicht kann dieselbe Funktion trotzdem teilweise ausführen, wenn dadurch Effizienz oder Zuverlässigkeit verbessert werden.

Ein klassisches Muster ist Fehlerkontrolle. Eine Übertragungsschicht kann Übertragungsfehler erkennen und korrigieren. Doch eine Anwendung, die sicherstellen muss, dass ein gesamter Datensatz korrekt geschrieben wurde, kann sich nicht allein darauf verlassen. Fehler können an anderen Stellen auftreten. Die Anwendung benötigt eine Prüfung, die ihrem eigenen Verständnis des Ergebnisses entspricht.

Damit wird die Architekturfrage ökonomisch.

Eine Funktion im gemeinsamen Netz wird einmal implementiert und kann allen Teilnehmern zugutekommen. Das senkt Duplikation.

Aber sie belastet auch alle Teilnehmer mit ihrer Komplexität, ihrem Zustand, ihren Fehlern und ihren Annahmen.

Eine Funktion am Endpunkt wird möglicherweise mehrfach implementiert. Dafür können verschiedene Anwendungen unterschiedliche Anforderungen haben, ohne die gemeinsame Infrastruktur ändern zu müssen.

Die effiziente Architektur liegt deshalb selten an einem dogmatischen Extrem.

Ein gemeinsamer Mechanismus gehört in den Kern, wenn er tatsächlich eine gemeinsame Invariante schützt oder die gemeinsame Übertragung so stark verbessert, dass seine Kosten gerechtfertigt sind.

Eine anwendungsspezifische Prüfung gehört an den Rand, wenn nur die Anwendung selbst entscheiden kann, ob ihr Ziel erreicht wurde.

Manchmal gehört dieselbe Funktion auf beide Ebenen: unten als Optimierung, oben als endgültige Prüfung.

RFC 3439 verbindet diese Tradition später mit einer breiteren Einfachheitsargumentation für IP. Auch dort bedeutet ein minimalistischer Kern nicht, dass der Kern keinerlei Zustand oder Intelligenz besitzen darf. Routingzustand bleibt unvermeidlich. Weiterleitung bleibt unverzichtbar. Messung und Betrieb bleiben nötig.

Die Disziplin richtet sich gegen unnötige gemeinsame Abhängigkeiten.

Wer implementiert, besitzt nicht automatisch die Zukunft

An dieser Stelle wird die institutionelle Dimension der IMP-Geschichte sichtbar.

BBN besaß reale Macht.

Es gewann den Auftrag. Es entwickelte den IMP. Es implementierte Software. Seine technische Arbeit prägte die Schnittstelle, gegen die Hosts programmiert werden mussten. Ein schlecht funktionierender IMP hätte den Netzbetrieb beeinträchtigt. BBNs Entscheidungen über Zuverlässigkeit, Debugging oder Paketverarbeitung waren deshalb keine unverbindlichen Vorschläge.

Doch diese Autorität war funktionsgebunden.

Die Host-Gruppen mussten weiterhin eigene Software entwickeln. Sie mussten untereinander Protokolle vereinbaren. Die Bedeutung von Anwendungen blieb außerhalb des IMP. Und als später mehrere unabhängige Netze verbunden werden sollten, war die Architektur nicht durch die bloße Tatsache festgeschrieben, dass BBN zuvor eine zentrale Implementierungsrolle besessen hatte.

Daraus folgt eine begrenzte institutionelle Lehre.

Technische Autorität sollte zunächst dort vermutet werden, wo eine konkrete Funktion implementiert, betrieben und über eine definierte Schnittstelle angeboten wird. Ein Betreiber darf Anforderungen definieren, die nötig sind, damit diese Funktion funktioniert. Ein Auftraggeber darf die Leistung verlangen, für die er bezahlt.

Daraus folgt aber nicht automatisch ein allgemeines Recht, angrenzende Schichten oder künftige Systeme zu beherrschen.

Operativ lässt sich die Grenze so formulieren: Gemeinsame Architektur entsteht nicht allein aus Erklärung oder institutioneller Stellung. Sie wird durch spezifizierte Schnittstellen, implementierte Mechanismen und tatsächliche Nutzung real.

Diese Perspektive passt besonders gut zur IMP-Geschichte, solange man sie nicht überdehnt. Der historische Beleg zeigt keine ausformulierte politische Theorie der ARPANET-Teilnehmer. Er zeigt etwas Konkreteres: Funktion, Implementierung und Verantwortung waren verteilt. Die BBN-Implementierung war real und zentral, aber nicht identisch mit der Gesamtheit der Host- oder Anwendungsarchitektur. Die spätere Weiterentwicklung konnte deshalb andere Grenzen ziehen.

Die gefährliche Verwechslung von Betriebsabhängigkeit und Architekturmandat

In modernen Infrastrukturen lässt sich dieselbe Verwechslung leicht beobachten.

Ein Vermittler beginnt als nützlicher Dienst. Er übernimmt Wiederholungslogik, Sicherheitsprüfung, Identität, Sitzungszustand, Richtlinienauswertung oder Anwendungsmetadaten. Weil diese Zentralisierung zunächst Doppelarbeit reduziert, steigt seine Verbreitung.

Mit wachsender Verbreitung steigen jedoch die Wechselkosten.

Neue Anwendungen werden gegen den Vermittler gebaut. Datenformate übernehmen seine Annahmen. Fehlerbehandlung setzt seine Verfügbarkeit voraus. Identität existiert nur noch in seinen Begriffen. Richtlinien werden nicht mehr an den Endpunkten geprüft, sondern durch einen zentralen Dienst entschieden.

Irgendwann kann aus einer operativen Abhängigkeit der Eindruck entstehen, der Vermittler besitze auch die legitime Autorität, die Regeln seiner Umgebung festzulegen.

Die IMP-Geschichte warnt nicht davor, Vermittler zu bauen. Sie bietet einen präziseren Test: Welche Verantwortung ist durch die angebotene Funktion tatsächlich gerechtfertigt?

Wenn ein Dienst Pakete weiterleitet, muss er Regeln für Paketweiterleitung besitzen.

Wenn er eine Sicherheitsprüfung als optionale Beschleunigung übernimmt, bedeutet das nicht automatisch, dass die Anwendung auf eigene Prüfung verzichten kann.

Wenn er Identität zwischenspeichert, bedeutet das nicht automatisch, dass er die alleinige Quelle der Identitätswahrheit sein muss.

Wenn er einen Standard implementiert, bedeutet das nicht automatisch, dass seine künftigen Änderungen ohne unabhängige Implementierung oder Adoption allgemein verbindlich werden.

Die Differenz zwischen Betriebsnutzen und Architekturmandat wird besonders wichtig, wenn ein System schwer ersetzbar wird.

Ein technischer Dienst kann unverzichtbar sein, weil er gut funktioniert.

Er kann aber auch unverzichtbar werden, weil zu viel anwendungsspezifischer Zustand in ihn verlagert wurde.

Nur der erste Fall ist ein eindeutiger Qualitätsgewinn.

Der Wert eines engen gemeinsamen Kerns

Die spätere Internetarchitektur wird gelegentlich so erzählt, als habe sie einfach entschieden, möglichst wenig zu zentralisieren.

Das ist zu grob.

Ein gemeinsamer Kern ist gerade deshalb wertvoll, weil er Dinge vereinheitlicht, die vereinheitlicht werden müssen.

Pakete benötigen Adressierungs- und Weiterleitungsregeln. Netzwerke müssen Pfade bestimmen. Geräte müssen Formate verstehen. Sicherheits- und Betriebsmechanismen benötigen gemeinsame Grundlagen. Ohne solche Invarianten gibt es keinen Verbund, sondern lediglich isolierte Systeme.

Die Herausforderung besteht darin, das Gemeinsame von dem lediglich Bequemen zu unterscheiden.

Der IMP machte zahlreiche gemeinsame Funktionen wirtschaftlich attraktiv, weil das ARPANET ein kontrollierteres Umfeld war. Das spätere Internetworking verschärfte den Test: Die gemeinsame Funktion musste nun über unterschiedliche Netze hinweg tragfähig sein.

Je heterogener die Teilnehmer werden, desto größer der Vorteil eines Minimums, das lokal implementierbar und unabhängig überprüfbar bleibt.

Diese Logik entspricht dem Prinzip einer minimalen Ausgangsspezifikation, wenn man es als Architekturdisziplin und nicht als nachträgliche politische Doktrin versteht: Der gemeinsame Layer sollte die Invarianten präzise definieren, die für die Interoperabilität wirklich notwendig sind. Alles andere sollte nicht ohne Not zu einer Voraussetzung für alle Teilnehmer werden.

Lokale zukünftige Entscheidungen ergeben sich dann aus der Struktur. Wer eine Erweiterung implementieren will, kann sie implementieren. Wer sie nicht benötigt, muss nicht zwangsläufig den gemeinsamen Kern verändern. Adoption wird durch funktionierende Implementierungen sichtbar, nicht allein durch Veröffentlichung.

Die IMP-Geschichte liefert dafür keinen direkten historischen Wortlaut. Sie liefert jedoch einen nützlichen Mechanismus: Wo Verantwortung über klar definierte Schnittstellen verteilt bleibt, können unterschiedliche Entwicklungsgemeinschaften eigenständig handeln. Wo dagegen immer mehr anwendungsspezifischer Zustand in eine gemeinsame Vermittlungsschicht gelangt, wird die Architektur zunehmend von der Weiterentwicklung dieser Vermittlungsschicht abhängig.

Eine Schnittstelle ist stärker als eine Zuständigkeitsbehauptung

Die Host-IMP-Schnittstelle war eine praktische Grenze. Wer einen Host anschließen wollte, musste sie implementieren. BBN musste seinerseits den IMP so liefern, dass diese Schnittstelle funktionierte.

Das erzeugte gegenseitige Disziplin.

BBN konnte nicht beliebig voraussetzen, was ein Host intern tat. Der Host konnte nicht beliebig voraussetzen, wie das IMP-Subnetz intern arbeitete. Jede Seite musste die vereinbarte Grenze bedienen.

Solche Schnittstellen sind institutionell interessant, weil sie Autorität in überprüfbare technische Anforderungen übersetzen.

Eine Organisation kann behaupten, für ein Gesamtsystem verantwortlich zu sein. Eine Schnittstelle zwingt zu einer konkreteren Frage: Welche Ein- und Ausgaben kontrolliert sie tatsächlich? Welche Eigenschaften garantiert sie? Welche bleiben dem Gegenüber überlassen?

Die besten technischen Grenzen reduzieren damit nicht nur Kopplung. Sie reduzieren interpretativen Spielraum.

Das ist eine wichtige Eigenschaft für langlebige Infrastruktur.

Eine dicke institutionelle Beschreibung kann eine Organisation für eine breite „Koordination“ zuständig erklären. Eine enge technische Schnittstelle dagegen zeigt, welche Funktion tatsächlich gemeinsam sein muss.

Natürlich löst auch eine Schnittstelle nicht jedes Machtproblem. Wer eine proprietäre, nicht ersetzbare Schnittstelle kontrolliert, kann erhebliche Abhängigkeit erzeugen.

Deshalb reicht Schnittstellenklarheit allein nicht aus.

Entscheidend wird zusätzlich, ob mehrere unabhängige Implementierungen möglich sind, ob Teilnehmer einen Vermittler ersetzen können und ob Zustände portabel oder unabhängig überprüfbar bleiben.

Die frühe IMP-Welt erfüllt diese späteren Kriterien nicht automatisch. Sie war ein konkretes ARPA-Projekt mit einem konkreten Auftragnehmer. Man darf ihre Struktur deshalb nicht nachträglich als fertiges Modell dezentraler Governance ausgeben.

Aber sie zeigt, warum die Trennung von Funktion und darüber hinausgehender Autorität analytisch produktiv ist.

Was der IMP nicht beweist

Gerade weil sich aus dieser Geschichte moderne Schlüsse ziehen lassen, ist Zurückhaltung nötig.

Erstens beweist die Existenz der IMP/Host-Grenze nicht, dass ARPANET bereits das spätere Ende-zu-Ende-Prinzip verwirklichte. Das tat es nicht. Die IMPs trugen erhebliche Zuverlässigkeits- und Flusskontrollfunktionen.

Zweitens beweist BBNs zentrale Rolle nicht, dass BBN „die Paketvermittlung erfand“. Die breitere Geschichte umfasst unter anderem Arbeiten von Donald Davies, Paul Baran, Leonard Kleinrock, Larry Roberts und zahlreiche Standortteams. Der hier betrachtete Gegenstand ist enger: die konkrete Verantwortungsverteilung rund um den ARPANET-IMP.

Drittens beweist die spätere Entwicklung hin zu einem schmaleren Internetworking-Kern nicht, dass Netzwerke ohne Management oder Zustand auskommen. Routing, Weiterleitung, Messung und andere Betriebsfunktionen bleiben unverzichtbar.

Viertens beweisen die erhaltenen RFCs keine vollständige Verfassung des ARPANET. Sie waren Arbeitsdokumente. Verträge, Gespräche, informelle Entscheidungen und lokale Implementierungsdetails sind nur unvollständig dokumentiert.

Fünftens darf spätere Literatur nicht als Beweis dafür benutzt werden, dass Teilnehmer von 1969 bereits bewusst nach Argumenten handelten, die erst später formalisiert wurden.

Die Quellen erlauben eine Funktionsgeschichte. Sie erlauben eine begrenzte institutionelle Schlussfolgerung. Sie erlauben keine einfache Heldenerzählung und keine rückwirkende Philosophie.

Die eigentliche Erfindung war eine verschiebbare Grenze

Der langfristige Wert der IMP-Geschichte liegt deshalb weniger in einem einzelnen Gerät als in der Veränderbarkeit seiner Verantwortungsgrenze.

1969 war es vernünftig, in einem dedizierten Subnetz erhebliche Übertragungsintelligenz zu konzentrieren. Diese Infrastruktur ermöglichte es heterogenen Hosts überhaupt erst, an einem gemeinsamen experimentellen Netz teilzunehmen.

Als die Architektur über ein einzelnes Netz hinauswuchs, wurde ein Teil dieser Annahmen unbrauchbar.

Die Lösung bestand nicht darin, den bisherigen Vermittler einfach größer zu machen, bis er jedes neue Netz kontrollierte.

Stattdessen wurde die gemeinsame Schicht neu definiert.

Unabhängige Netze sollten ihre Eigenständigkeit behalten. Gateways sollten verbinden, ohne alle Kommunikationszustände zu besitzen. Endpunkte sollten verlorene Daten erneut senden und die korrekte Ausführung der Funktionen prüfen, die nur sie vollständig verstehen konnten.

Damit änderte sich auch die institutionelle Topologie.

Wenn eine gemeinsame Schicht weniger anwendungsspezifischen Zustand besitzt, muss sie weniger Entscheidungen über Anwendungen treffen. Wenn Teilnehmer Schnittstellen unabhängig implementieren können, wird Implementierungsautorität eher ersetzbar. Wenn neue Funktionen durch tatsächliche Implementierung und Nutzung verbreitet werden, ist Veröffentlichung allein weniger mächtig.

Das bedeutet nicht, dass Infrastruktur politisch oder wirtschaftlich bedeutungslos wird. Im Gegenteil: Je zentraler ein Dienst für laufende Systeme ist, desto wichtiger wird die Frage, ob seine Macht aus notwendigen technischen Invarianten oder aus historisch gewachsener Abhängigkeit stammt.

Der IMP liefert hierfür keine fertige Antwort.

Er liefert die erste Hälfte eines Tests.

Welche Funktion kann ein gemeinsamer Vermittler nachweislich besser übernehmen?

Die spätere Internetarchitektur liefert die zweite.

Welche Funktion kann er trotz aller lokalen Zuverlässigkeit nicht vollständig korrekt machen, weil ihm das Wissen der Endpunkte fehlt?

Zwischen diesen beiden Fragen liegt ein großer Teil der Architekturökonomie des Internets.

Quellen und Grenzen der Belege

Die Evidenz besteht aus zeitgenössischen RFCs, späteren historischen Rückblicken, Oral-History-Material und nachträglicher Architekturinterpretation. Die frühen RFCs sind besonders wertvoll für die konkrete IMP/Host-Arbeitsteilung, dürfen aber nicht als vollständige institutionelle Verfassung des ARPANET gelesen werden. Spätere Rückblicke rekonstruieren Ziele und Erfahrungen, sind jedoch zeitlich von den Ereignissen entfernt.

Die Ende-zu-Ende-Literatur erklärt eine spätere Platzierungsregel und darf nicht als Beweis für die bewusste Doktrin sämtlicher Beteiligter von 1969 verwendet werden. Die Schlussfolgerung über die Begrenzung von Beschaffungs-, Implementierungs- und Schnittstellenautorität ist eine redaktionelle Ableitung aus dem dokumentierten Funktionszuschnitt, keine überlieferte Erklärung der damaligen Akteure. Diese Trennung verhindert, dass spätere Architekturinterpretation als zeitgenössischer Beleg erscheint.

1. RFC 1 — zeitgenössische Grundlage für die explizite Aufteilung zwischen BBNs IMP-Software und der Verantwortung der Host-Gruppen sowie für Paketierung, Prüfsumme, Links, Tracing, RFNM und notwendige Host-Kooperation. https://www.rfc-editor.org/rfc/rfc1.html

2. RFC 2 — zeitgenössische Grundlage für Host-seitigen Link-Zustand, Prüfungen, Quittungen und den Umgang mit Zuständen entfernter Hosts. https://www.rfc-editor.org/rfc/rfc2.html

3. RFC 7 — Grundlage für Host-IMP-Schnittstellenverarbeitung, Multiplexing, Pufferverwaltung und die auf den Hosts verbleibende Softwarearbeit. https://www.rfc-editor.org/rfc/rfc7.html

4. RFC 528 — späterer Beleg für Prüfsummenmechanismen in IMP-Software und für die fortgesetzte operative Bedeutung von Netzzuverlässigkeit. https://www.rfc-editor.org/rfc/rfc528.html

5. RFC 1000 — Steve Crockers späterer Rückblick auf die Arbeit der Host-Teams, die Host-IMP-Schnittstelle und den Liefertermin des ersten IMP im September 1969. https://www.rfc-editor.org/rfc/rfc1000.html

6. Computer History Museum — Material zum ARPANET-Auftrag von 1968 und zur Umwandlung des Honeywell 516 in den IMP. https://archive.computerhistory.org/resources/access/text/2012/11/102706168-05-01-acc.pdf

7. Computer History Museum — Frank Hearts Oral History zu Zuverlässigkeit, Debugging, Reloading, Leitungsumschaltung und der betrieblichen Entwicklung des IMP. https://archive.computerhistory.org/resources/access/text/2017/11/102702222-05-01-acc.pdf

8. Internet Society, Brief History of the Internet — Grundlage für die NCP-Annahme eines zuverlässigen ARPANET, die Open-Architecture-Grundsätze, einfache Gateways und Wiederübertragung von der Quelle. https://www.internetsociety.org/internet/history-internet/brief-history-internet/

9. Internet Society, Brief History of the Internet and Related Networks — Grundlage für den Übergang von ARPANET zu mehreren verbundenen Paketnetzen und die historische Einordnung des Internetworking. https://www.internetsociety.org/internet/history-internet/brief-history-internet-related-networks/

10. RFC 675 — Spezifikation des Internet Transmission Control Program von Dezember 1974 und Beleg für die spätere Internetworking-Phase. https://datatracker.ietf.org/doc/html/rfc675

11. David Clark, retrospektive Architekturanalyse — Grundlage für die spätere Analyse der DARPA-Internetprotokolle, des Datagramm-Modells und der Survivability-Ziele. https://groups.csail.mit.edu/ana/People/DDC/ebook-arch-V1.pdf

12. Saltzer, Reed und Clark, End-to-End Arguments in System Design — Grundlage für den Test, nach dem vollständige Korrektheit bei Funktionen mit Anwendungswissen die Beteiligung der Endpunkte verlangt, während niedrigere Schichten weiterhin Leistungsoptimierungen bereitstellen können. https://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf

13. RFC 3439 — Grundlage für spätere Argumente zu Einfachheit, einem minimalistischen IP-Layer und der Verteilung von Zustand zwischen Kern und Endpunkten. https://www.rfc-editor.org/rfc/rfc3439.html