Zusammenfassung

  • Plutarch wollte das bestehende Internet nicht ablösen. Das global routbare IPv4-Netz blieb unverändert, wurde aber als ein Kontext beschrieben, neben dem andere Kommunikationsordnungen schrittweise bestehen konnten.
  • Namen und Adressen galten innerhalb eines Kontextes. Beim Übergang musste eine interstitielle Funktion Bedeutung neu binden und Unterschiede bei Routing und Transport übersetzen.
  • Der Aufsatz war ein Forschungsentwurf. Sicherheit, Audit, Capability-Verwaltung, skalierbare Suche, Fehleranzeige und Auswahlregeln für Kontextketten blieben offen.

Der gemeinsame Nenner war nicht länger die ganze Welt

Das Internet verdankt einen großen Teil seines Erfolgs einer homogenen Mitte. Anwendungen mussten die jeweilige Leitungstechnik nicht kennen, Netze mussten nicht jede Anwendung verstehen. Ein einfaches Datagrammmodell und ein gemeinsamer Adressraum bildeten den schmalen Übergang.

Die Autoren von Plutarch würdigten genau diese Leistung. Sie erklärten weder IP noch die end-to-end geprägte Architektur zum Irrtum. Ihr Einwand setzte später an: Aus einem erfolgreichen gemeinsamen Nenner war die Vorstellung geworden, auch Sensoren, Mobilnetze, Overlays und private Technologien müssten ihre Besonderheiten darin verstecken.

Plutarch behandelte das IPv4-Internet deshalb als Kontext. Innerhalb dieses Kontextes durfte alles bleiben wie es war. Neue Kontexte konnten oberhalb als Overlay, daneben mit anderen Protokollen, unterhalb als private Link-Technik oder an den Rändern entstehen.

Das Internet blieb groß und nützlich. Es war nur nicht mehr die Definition dessen, was als Netz gelten durfte.

Kontext bedeutete einen Geltungsbereich für Bindungen

Ein Kontext war im Papier ein in bestimmter Hinsicht homogener Bereich und zugleich ein Satz von Bindungen, in dem Namen aufgelöst werden konnten. Die Gemeinsamkeit konnte sich auf Adressen, Paketformate, Transport, Namensdienste, Linkeigenschaften oder Verwaltung beziehen.

Ein Endpunkt konnte mehreren Kontexten angehören. Mitgliedschaft konnte wechseln. Kontexte konnten getrennt, gleich oder ineinander verschachtelt sein. Eine lokale Ethernet-Umgebung lag etwa innerhalb eines IP-LANs, dieses wiederum innerhalb des Internets. Einen einzigen globalen Wurzelkontext gab es nicht.

Damit verlor der Name den Anschein, seine Bedeutung überall mitzubringen. Ein Sensorbezeichner oder eine lokale Adresse verwies nur unter den Bindungen des eigenen Kontextes eindeutig auf ein Objekt. Beim Grenzübertritt musste der Referent im Zielkontext neu gebunden werden.

Diese Neubindung war eine Behauptung: Dieser fremde Name und dieses lokale Ziel sollen als Entsprechung gelten. Plutarch zeigte, wo diese Behauptung technisch getroffen wurde.

Die interstitielle Funktion trug die Übersetzung

Die Grenze hieß interstitial function, kurz IF. Sie hatte logisch je eine Schnittstelle zu den beiden benachbarten Kontexten und einen Mechanismus, der Daten und Funktionalität von einer Seite auf die andere abbildete. Mehrere IFs konnten eine Kontextkette bilden.

NAT, Signalisierungs-Gateways und BGP-Router dienten als vorhandene Beispiele. Darüber hinaus dachten die Autoren an Brücken zwischen unterschiedlichen Transporten, Video-Transcoding oder das Ergänzen von Vorwärtsfehlerkorrektur. Eine IF konnte also Darstellung, Zustand, Zuverlässigkeit und Zeitverhalten verändern.

Vier Felder machten die Aufgabe greifbar. Adressierung brauchte gepflegte Zuordnungen. Namensauflösung musste zwischen mehreren Namenssystemen vermitteln. Routing durfte die Dynamik eines OSPF/BGP-Bereichs nicht gedankenlos in ein drahtloses On-Demand-Netz kippen. Transportoptimierung sollte dort stattfinden, wo die Eigenschaften des Kontextes sie rechtfertigten.

Ein Nachweis musste deshalb Eingang, Ausgang, Äquivalenzregel, Konfigurationsrecht, gespeicherten Zustand und verlorene Eigenschaften enthalten. Erreichbarkeit bestätigte nur, dass irgendeine Übersetzung stattgefunden hatte.

Die Kette konnte Wahl ermöglichen oder Kontrolle verdecken

Eine Folge aus Kontexten und IFs ließ sich selbst wieder als Kontext abstrahieren. Eine einfache Anwendung musste dann nicht jedes Zwischennetz verstehen. Eine anspruchsvollere Anwendung konnte mehrere Ketten erhalten, ihre Eigenschaften vergleichen und wählen.

Damit wanderte Entscheidungsmacht zum Endpunkt. Zugleich konnte die Abstraktion wichtige Tatsachen verbergen. Ein automatischer Reparaturdienst mochte nach einem Ausfall auf eine Kette unter anderer Verwaltung wechseln. Ein Proxy konnte den Transport beenden und neu aufbauen. Ein Transcoder konnte Lesbarkeit erhalten und Qualität verringern.

Plutarch skizzierte verteilte Verwaltungsdienste und mehrere getrennt betriebene „Plutarchies“. Anfragen sollten Capabilities vorlegen. Wie diese Rechte ausgegeben und kontrolliert würden, legte die Architektur jedoch nicht fest.

Viele Kontexte verhinderten also nicht automatisch eine neue Zentrale. Die Zentrale konnte im Katalog, in der Capability-Vergabe oder in der einzigen verfügbaren IF entstehen.

Schrittweise Einführung ersetzte den globalen Umschalttag

Der Entwurf hob hervor, dass das bestehende Internet unverändert bleiben und ein Kontext nach dem anderen eingeführt werden konnte. Ein Betreiber musste keine weltweite Protokollmigration abwarten. Er konnte eine lokale Ordnung und ihre Grenzübersetzung vorführen.

Diese Reihenfolge passte Adoption an laufende Implementierungen an. Andere nahmen teil, wenn die Kombination funktionierte. Wer keinen Nutzen sah, musste seinen eigenen Kontext nicht aufgeben.

Doch schrittweise Einführung garantierte keine schrittweise Ablösung. Eine provisorische IF konnte immer mehr Bindungen, Sonderfälle und Zustand ansammeln. Sobald Anwendungen ihre Eigenheiten voraussetzten, wurde Austausch zur gemeinsamen Migration beider Seiten.

Die Brücke blieb nur dann freiwillig, wenn ihr Zustand exportierbar, ihr Vertrag dokumentiert und eine zweite Brücke tatsächlich einsetzbar war.

Das Papier markierte seine offenen Flanken

Die Autoren beschränkten sich ausdrücklich auf Inter-Networking. Ressourcenverteilung, Rechtzeitigkeit, Garantien, Sicherheit und Audit lösten sie nicht. Die Schnittstellen waren Strawmen, Leistungswerte gab es nicht, und Capability-Verwaltung war nicht spezifiziert.

Zu den Forschungsfragen gehörten skalierbares Routing zwischen Kontexten, IF-Entdeckung, Fehlermeldung, Politik der Kettenwahl, Programmierschnittstellen, Transportanpassung und Namenssuche. Die Erwartung weniger Kontexttypen und kurzer Ketten war keine Messung eines Produktivsystems.

Darum darf Plutarch nicht als vollendete dezentrale Internetarchitektur erscheinen. Der Beitrag lag darin, Heterogenität explizit zu modellieren und die noch ausstehenden Beweise sichtbar zu lassen. Ein Übersetzer wurde durch den Entwurf nicht vertrauenswürdig; er wurde auffindbar.

Ein fünfköpfiges Autorenkollektiv

Die Universität Cambridge führt Jon Crowcroft heute als Marconi Professor of Communications Systems und beschreibt mehr als vier Jahrzehnte Arbeit an Internet-Technologien. Seine Verbindung von Netzen und verteilten Systemen prägt die Fragestellung des Papiers.

Plutarch trägt dennoch fünf Namen: Crowcroft, Hand, Mortier, Roscoe und Warfield. Hinzu kommen Vorarbeiten zu kontextabhängiger Namensgebung, late binding und end-to-end-Entwurf. Crowcroft allein zum Erfinder aller Netzwerkpluralität zu erklären oder spätere Gateways pauschal aus Plutarch abzuleiten, wäre historisch unbelegt.

Der gemeinsame Beitrag war eine klare Umkehr: Nicht das heterogene Netz musste sich als Ausnahme rechtfertigen. Die Grenze musste erklären, wie sie Verschiedenes zusammenfügte.

Quellen