Zusammenfassung

  • RFC 877 legte eine schmale gemeinsame Schnittstelle zwischen IP und X.25 fest: eine Protokollkennung, vollständige Paketfolgen je Datagramm und verhandelbare Parameter.
  • Der virtuelle Kanal wurde bei Bedarf geöffnet; die Leerlaufzeit bis zum Schließen hing von den lokalen Kosten ab. Für jede TCP-Verbindung wurde kein eigener X.25-Kanal angelegt.

Analyse

Für den Kanal lief eine eigene Kostenuhr

Im September 1983 beschrieb J. T. Korb mit RFC 877, wie IP-Datagramme über öffentliche Datennetze auf X.25-Basis übertragen werden konnten. Gleich zu Beginn nennt das Dokument CSNET, das VAN Gateway und weitere Organisationen als Anwender, die den Standard übernommen hatten. Das sind benannte Übernahmen, keine vollständige Liste aller Netze.

Zu verbinden waren zwei verschiedene Betriebsmodelle: IP sendet Datagramme, X.25 stellt virtuelle Kanäle im öffentlichen Datennetz bereit. RFC 877 machte aus dem Netzkanal keine Anwendungssitzung. Stattdessen definierte es eine kleine gemeinsame Schnittstelle und ließ wichtige Betriebsentscheidungen bei den angeschlossenen Standorten.

Ein Kennungsbyte und eine vollständige Paketfolge

Das erste Oktett im Call User Data-Feld des X.25-Verbindungsaufrufs diente der Protokollunterscheidung. Der Wert 0xCC stand für IP. Jedes Datagramm wurde danach als vollständige Folge von X.25-Paketen übertragen: Es begann an einer Paketgrenze; das More-Bit markierte die Fortsetzung, wenn mehrere Pakete nötig waren. Zusätzliche Header in den Datenpaketen sah der RFC nicht vor.

Auch die Größe war geregelt, aber verhandelbar. Ohne Vereinbarung über größere X.25-Pakete durfte ein IP-Datagramm höchstens 576 Oktette umfassen. Als Beispiel für eine ausgehandelte größere Größe nennt der RFC 1.024 Oktette. Paket- und Fenstergrößen konnten die Standorte vereinbaren; es gab kein weltweit einheitliches Profil.

TCP gab dem Kanal nicht seine Lebensdauer

Der virtuelle Kanal folgte einer anderen Uhr. Laut RFC 877 wurde er bei Bedarf geöffnet, sobald ein Datagramm an der Schnittstelle zur Übertragung eintraf. Nach einer Ruhezeit konnte er geschlossen werden; wie lang diese Zeit war, hing von den Kosten eines offenen Kanals ab. Bei erschöpfter Kanalzahl konnte auch die Schnittstelle einen Kanal schließen, und beide Standorte durften das ebenfalls.

Die Abgrenzung zu TCP ist ausdrücklich: Protokolle oberhalb von IP beeinflussen diesen Standard nicht. Insbesondere wird kein X.25-Kanal für jede TCP-Verbindung geöffnet. Eine langlebige TCP-Sitzung versprach daher keinen dauerhaft reservierten Kanal im öffentlichen Netz. Der Adapter verwaltete eine Netzressource; der TCP-Verbindungszustand lag auf einer anderen Ebene.

Die belegte Folge bleibt eng umrissen: Wird ein Kanal während der Übertragung eines Datagramms geschlossen oder zurückgesetzt, geht dieses Datagramm verloren. Der RFC nennt weder die Häufigkeit noch das spätere Anwendungsergebnis. Was ein höheres Protokoll daraus macht, lässt sich aus dieser Quelle nicht ablesen.

„Empfohlen“ heißt nicht überall implementiert

Der offizielle ARPA-Internet-Protokollbericht RFC 924 von 1984 führte „Internet Protocol on X.25 Networks“ als Recommended und verwies auf RFC 877. In diesem Bericht bedeutete Recommended, dass Hosts zur Implementierung ermutigt wurden; es belegte nicht, dass alle Hosts das Protokoll bereits nutzten. 1992 bezeichnete RFC 1356 die Methode als weit verbreitet und ersetzte die frühere Spezifikation, um Mehrdeutigkeiten sowie neue Anforderungen an Datagramm- und Paketgröße, Kanalverwaltung und Multiprotokollverbindungen zu behandeln.

Die drei Dokumente zeigen benannte frühe Anwender, eine offizielle Empfehlung und eine spätere Überarbeitung auf Erfahrungsbasis. Sie enthalten aber weder eine Standortliste noch Tarife oder einen bezifferten Leerlauf-Timer.

Note 64 als spätere Lesart

Heng Lus Note 64 schlägt ein Gestaltungsprinzip vor: Die gemeinsame Spezifikation soll nur die nötigen Regeln für Interoperabilität enthalten; weitere Entscheidungen sollen bei den Betreibern liegen. Als redaktionelle Lesart macht das die Architektur von RFC 877 sichtbar. 0xCC und Paketgrenzen waren gemeinsame Regeln; Leerlaufzeit und verhandelbare Funktionen erhielten keinen globalen Festwert.

Das ist eine rückblickende Einordnung. RFC 877 zitiert Note 64 nicht, und die Note belegt keine Absicht Korbs. Das Dokument selbst zeigt, dass IP über einen öffentlichen X.25-Dienst übertragen werden konnte, ohne Kosten und Lebensdauer jedes Kanals zu vereinheitlichen.

Quellen