Zusammenfassung

  • Das virtuelle lokale Netz von Cronus sollte IP eine gleichbleibende Schnittstelle bieten, während sich die physische Technik darunter austauschen ließ.
  • Die Schnittstelle musste dafür konkrete Leistungen erhalten: Einzel-, Rundruf- und Gruppenadressen, Gateways, Adressabbildungen und begrenzte Zusagen zur Datagrammzustellung.

Ein LAN wird teuer, langsam oder untauglich für die Umgebung. Dann will man es ersetzen. Die Rechnung wird unangenehm, wenn jede Anwendung die Eigenheiten der alten Leitung kennt. William I. MacGregor und Daniel C. Tappan schlugen in RFC 824 eine andere Aufteilung vor: Cronus-Software sollte sich an ein Virtual Local Network, kurz VLN, halten. Die VLN-Implementierung würde sich mit dem physischen Netz auseinandersetzen. Oben bliebe das Gesicht vertraut; unten konnte man die Schuhe wechseln.

Das Papier vom August 1982 entstand bei Bolt Beranek and Newman für ein verteiltes Betriebssystem. Seine Schichtzeichnung zeigt TCP und UDP über IP, darunter das VLN und schließlich das physische lokale Netz. Zwei Ziele stehen ausdrücklich im Text. Die Einrichtung sollte zu DARPA-IP und damit zu darauf aufbauenden Protokollen wie TCP passen. Und eine physische Netztechnik sollte sich durch eine andere ersetzen lassen, solange die Bedeutung der VLN-Schnittstelle gleich blieb. Wer oben programmierte, brauchte einen verlässlichen Vertrag; wer unten baute, musste ihn erfüllen.

Für einen Wechsel nannten die Autoren handfeste Gründe: Kosten, Leistung sowie mechanische und elektrische Belastbarkeit. Die konkrete Programmrepräsentation der Schnittstelle durfte je nach Rechner anders aussehen. Ihre Funktionen mussten übereinstimmen. Ein neues physisches LAN verlangte daher eine neue VLN-Implementierung auf jedem Cronus-Host. Der Aufwand verschwand nicht, er erhielt eine Adresse im System. Das war der Gewinn: Er musste nicht durch jede Anwendung wandern.

IP sollte oberhalb des VLN ohne Änderung oder Erweiterung funktionieren. Innerhalb eines Cronus-Clusters waren die Hosts an dasselbe physische lokale Netz angeschlossen. Für Ziele außerhalb des Clusters leitete das VLN Datagramme an ein Internet-Gateway; eingehende Datagramme gingen an den zuständigen Host. Das VLN wurde im Internet selbst als Netz mit einer Netznummer behandelt. Das physische Netz darunter konnte dieselbe oder eine andere Nummer haben. Eine stabile Oberfläche machte die Wahl des Ausgangs nicht überflüssig.

Besonders deutlich wird der Vertrag bei den Adressen. Ein Client konnte einen bestimmten Host, alle Hosts oder eine Multicast-Gruppe erreichen. Die lokale Adresstabelle des RFC reservierte 0 bis 1.023 für einzelne Hosts, 1.024 bis 65.534 für Multicast und 65.535 für Broadcast. Um den ganzen Bereich darzustellen, empfahlen die Autoren eine Klasse-A- oder Klasse-B-Netznummer. Diese Zahlen gehören zum historischen Cronus-Entwurf. Entscheidend war, dass alle drei Zustellarten an der Schnittstelle eindeutig blieben, auch wenn die Hardware dahinter wechselte.

Im Ethernet-Beispiel hielt jeder Host eine VPMap vor. Sie ordnete einer spezifischen 32-Bit-VLN-Adresse eine 48-Bit-Ethernet-Adresse zu. Wenn ein Rechner seine physische Adresse änderte, aber seine VLN-Adresse behielt, konnten gespeicherte Zuordnungen auf anderen Rechnern veralten. Das Papier bespricht deshalb auch das Zurücksetzen der Schnittstelle und den Wiederaufbau dynamischer Tabellen. Die Anwendung durfte den Umzug ignorieren. Der Zusteller brauchte die neue Anschrift. Sonst blieb die schöne Abstraktion mit einem Paket vor dem falschen Haus stehen.

Auch die Zustellung hatte präzise Grenzen. Ein Datagramm von höchstens 576 Oktetten sollte zwischen beliebigen zwei VLN-Clients übertragbar sein. Größere Datagramme konnten bei manchen Paaren funktionieren. Das VLN übernahm weder IP-Fragmentierung und -Zusammensetzung noch die Verarbeitung von IP-Optionen. Es garantierte keine zuverlässige Zustellung und verschickte keine negativen Bestätigungen für verworfene Pakete. Was ankam, musste jedoch den gesendeten Inhalt korrekt wiedergeben. Pro beabsichtigtem Empfänger sollte ein Datagramm einmal oder gar nicht ankommen.

Innerhalb des Clusters bildeten empfangene Datagramme eine Teilfolge der gesendeten: Lücken waren möglich, Vertauschungen der angekommenen Folge nicht vorgesehen.

RFC 824 ist deshalb mehr als eine hübsche Schichtgrafik. Der Text buchstabiert die Kosten des Austauschs aus: Adressen, Ausgang, Paketgröße und Zustellverhalten. Erst dieser genaue Vertrag erlaubte es der oberen Software, die neue Leitung nicht zu kennen. Die Freiheit zum Umbau war das Ergebnis von Pflichten, die eine Etage tiefer sehr genau beschrieben waren.