Zusammenfassung

  • RFC 1070 kapselte vollständige OSI-Netzschicht-PDUs in IP-Datagramme. So ließ sich OSI-Routing zwischen entfernten Implementierungen erproben, ohne die vorhandenen Internet-Gateways mit unreifer Software zu verändern.
  • EON baute über dieser Reichweite eine eigene logische Nachbarschaft auf. NSAP-Zuordnung, core.EON, lokaler SNAcP-Cache, ES/IS-Rolle und Protokollaustausch belegten jeweils einen anderen Zustand und konnten vorübergehend auseinanderfallen.

Die RFC 1070 vom Februar 1989 versprach keinen produktionsreifen Dienst. Ihre Warnung nennt die Verfahren ausschließlich für Versuche in begrenztem Maßstab geeignet. Der Entwicklungsstand der OSI-Netzschicht reichte von Norm bis Vorentwurf. Gerade deshalb brauchten Protokolle und Implementierungen eine große, vielfältige, veränderliche Topologie. Sie dafür in bestehende IP-Gateways einzubauen, hätte den laufenden Verkehr zum Träger des Versuchsrisikos gemacht.

Die Autoren nutzten stattdessen die Verbindung, ohne die Gateways zu verändern. Ein komplettes PDU der verbindungslosen OSI-Netzschicht wurde in ein IP-Datagramm gelegt. Innerhalb eines Standorts sollte OSI direkt über lokale Netze laufen. Musste der Weg ein IP-Gateway queren, behandelte die Implementierung das Internet als ein Subnetz beziehungsweise als eine Verbindung. EON hieß das darüber gebaute Experimental OSI-based Network.

Erreichbarkeit blieb eine Aussage der unteren Schicht

Bei direktem EON trug das Datenfeld eines IP-Datagramms das gesamte ISO-gram; der Protokollwert war 80. Vorzugsweise sollte OSI CLNL fragmentieren, damit seine Fragmentierungslogik getestet wurde. IP-Fragmentierung ließ sich trotzdem nicht ausschließen. Das Ziel musste daher auch unten wieder zusammensetzen.

Schon daraus entstehen mehrere Prüfpunkte. Ein angekommenes IP-Fragment ist noch kein zusammengesetztes OSI-PDU. Ein PDU ist noch keine angenommene Konfigurationsnachricht. Und eine Nachricht ist noch keine gelernte Route. Ähnlich konnten an einem teilnehmenden Standort viele Rechner per IP erreichbar sein, obwohl nur ein konfigurierter Teil sich für den Versuch als direkt am IP subnet angeschlossen betrachtete.

Das Adressformat machte die Zustellung berechenbar. Es folgte der RFC 1069 und bettete die vier Oktette der Internet-Adresse gegen Ende des NSAP ein. Daraus ließ sich die SNPA-Adresse des Subnetzzugangs ableiten. Die IANA vergab die Routing-Domain, die lokale Area blieb zunächst null.

Die Abbildung beantwortete, an welche Internet-Adresse das äußere Paket gehen sollte. Sie beantwortete nicht, ob dort ein ES, ein IS oder beides arbeitete. Diese Rolle durfte sich bei gleichbleibender physischer Verbindung ändern. RFC 1070 wollte weder IP-Routingalgorithmen für ISO-grams benutzen noch ein großes Betriebsnetz schaffen. Das OSI-Routing sollte Gegenstand des Versuchs bleiben.

SNAcP setzte ein Broadcast-Netz aus Einzelpaketen zusammen

ES-IS und IS-IS erwarteten Gruppenziele für alle Endsysteme und alle Zwischensysteme. Das unterlegte Internet bot dem Versuch diese Bedeutung nicht unmittelbar. Zwischen OSI CLNL und IP trat daher ein SubNetwork Access Protocol, SNAcP.

Jede Instanz speicherte Internet-Adressen, die sie als in einem ISO-8473-Hop erreichbar ansah. Bei einem einzelnen Ziel versandte sie ein Exemplar. Für alle ES, alle IS oder Broadcast erzeugte sie je Cache-Eintrag eine Kopie. Ein kleiner Header bezeichnete Version und Adresssemantik und enthielt eine Fletcher-Prüfsumme. Auf der Eingangsseite hing die Annahme von all-ES und all-IS an der lokalen Rollenfestlegung.

Das vermeintlich gemeinsame Medium bestand also aus privaten Ansichten. Der Sender definierte mit seinem Cache die Empfängermenge. Jeder Empfänger deutete mit seiner Rolle die Gruppensemantik. Erfolgreiche IP-Zustellung bewies weder einen vollständigen Cache noch die Aktualität der Rollen in anderen Systemen.

Auch ICMP wurde erst durch lokale Regeln topologisch. Destination unreachable, parameter problem oder time exceeded konnten einen Cache-Eintrag unbrauchbar machen, source quench vorübergehend. Netzwerkmanagement zu informieren konnte eine Konsolenmeldung, einen Zähler, ein Protokoll oder ausdrücklich gar nichts bedeuten. Beim simulierten Broadcast ließ SNAcP unbrauchbare Adressen aus; beim Einzelversand meldete es einen Fehler nach oben. Eine Beobachtung des Trägers veränderte den Versuch nur über diese Übersetzung.

Die Startdatei beschrieb keine Routerklasse

Ein frisches System brauchte erste Ansprechpartner, bevor die Routingprotokolle weitere lernen konnten. Die IANA sollte deshalb core.EON für direktes IP und core.EON-UDP für die UDP-Variante bereitstellen. Die Einträge waren SNPAs, die andere Kernsysteme als einen logischen ISO-Hop entfernt behandeln sollten.

Daneben gab es hosts.EON und hosts.EON-UDP. Sie halfen Anwendungen und Menschen, beteiligte Endsysteme zu finden, wurden aber von OSI CLNL nicht benutzt. Auch ein Core-Eintrag bestimmte keine Rolle: Er durfte zu einem ES, IS oder zu beiden gehören. Ein neuer Kernteilnehmer konnte vor der Verteilung seines Eintrags beginnen, blieb jedoch den Peers unbekannt, die beim Start nur die alte Datei lasen und deshalb keine ESH- oder ISH-Nachrichten an ihn richteten.

Die hypothetische Universität Fordor liefert die Probe. 192.5.2.1 ist zunächst IS und Kernsystem, 192.5.2.2 ein ES. Beide tauschen ihre Rollen, ohne ihre Internet-Verbindung zu ändern. Solange core.EON den alten Stand enthält, senden andere Systeme ihre Konfiguration weiterhin an .1. Dieser Rechner antwortet jetzt als ES; den neuen IS .2 fragen sie nicht an. Im EON-Bild wirkt .2 unerreichbar, obwohl IP es erreicht.

Beim Start kann .2 selbst OSI-Konfigurationsnachrichten versenden. Andere IS antworten und ergänzen ihre Caches; damit entstehen die logischen Verbindungen. Die Reparatur betrifft keine physische Strecke. Sie schließt die Lücke zwischen Startwissen, aktueller Rolle und dynamisch gelernter Topologie.

EON-UDP war ein paralleler Versuch

Manche Implementierer konnten UDP, aber nicht unmittelbar IP ansprechen. EON-UDP legte das OSI-NPDU auf Port 147 und setzte SNAcP zwischen UDP und ISO 8473. Die übrige Konstruktion ähnelte EON. Direkte Interoperabilität bestand dennoch nicht. Ein Übergang wäre denkbar gewesen, doch seine Technik und sein Routing blieben außerhalb des Memos. Getrennte Core- und Hostdateien entsprachen zwei Versuchen für unterschiedliche Zugriffsbedingungen.

Die Schichtgrenze unterscheidet RFC 1070 auch von verwandten Entwürfen. RFC 1006 stellte OSI-Transportdienst über TCP für Sitzung und höhere Schichten bereit. RFC 1070 führte OSI-Netz- und Transportschichten über ein IP-Internet. RFC 1069 nutzte Internet-Routing und -Adressierung in einem CLNP-Gateway; RFC 1070 wollte dort OSI-Routing und -Adressierung benutzen und beobachten.

Quellen und Grenzen

RFC 1070 belegt einen Vorschlag und ein hypothetisches Beispiel, keinen breiten Einsatz. Die Fordor-Rollenänderung war kein gemeldeter Vorfall. RFC 994 und RFC 995 liefern den damaligen CLNP- und ES-IS-Kontext, aber keinen Nachweis für eine konkrete EON-Implementierung. Eine direkte Abstammung heutiger Overlay-Netze lässt sich daraus ebenfalls nicht ableiten.

Der haltbare Befund ist kleiner: Ein Netz kann die Verbindung eines anderen liefern, ohne dessen Mitgliedschaft oder Routingwahrheit zu besitzen. Adresse, Startliste, Cache, Rolle und gelerntes Ergebnis müssen deshalb als getrennte Belege gelesen werden.