Zusammenfassung

  • RFC 1201 konnte ein Datagramm auf bis zu 120 ARCNET-Rahmen verteilen, mit höchstens 504 Oktetten Nutzdaten je langem Rahmen.
  • Die theoretischen 60.480 Oktette bestimmten kein Netz-MTU; die Höchstgröße musste konfigurierbar und zwischen den Stationen vereinbar sein.

Eine Obergrenze war noch kein Betriebswert

Ein langer ARCNET-Rahmen hatte eine feste Länge von 512 Oktetten. Für IP standen diese 512 jedoch nicht vollständig zur Verfügung: Hardwarekopf, Softwarekopf und Füllbytes beanspruchten Platz. Der Software standen höchstens 504 Oktette Clientdaten offen. Kurze Rahmen waren 256 Oktette lang. Für Clientdatenlängen von 250, 251 und 252 Oktetten definierte der Standard einen Ausnahme-Rahmen.

Die frühere RFC 1051 von 1988 legte eine erste Übertragung von IP und ARP über ARCNET fest. Wenn nicht alle Stationen erweiterte Rahmen beherrschten, empfahl sie ein IP-MTU von 253 Oktetten und IP-seitige Fragmentierung. Die im Februar 1991 veröffentlichte RFC 1201 ersetzte sie und verschob das Aufteilen in die ARCNET-Sicherungsschicht.

Ein Split-Flag kennzeichnete ein unfragmentiertes Paket, das erste Fragment oder eines der folgenden Fragmente. Eine gemeinsame Sequenznummer hielt die Teile zusammen. Bis zu 120 Fragmente konnten ein Paket bilden; so entstand die Zahl von 60.480 Oktetten. Der Text nannte diese Größe gleichwohl unpraktisch und verlangte, dass jede Implementierung die maximale Paketlänge konfigurierbar machte. Stationen eines ARCNET mussten sich auf einen passenden kleineren Wert verständigen. Empfohlen war die Unterstützung von Datagrammen bis mindestens 576 Oktette; 1.500 Oktette wurden nachdrücklich empfohlen.

Daraus folgt nicht, dass ein konkretes Netz eine dieser Größen verwendete.

Fragmentierung verschob die Arbeit zum Empfänger

Die Fragmente wurden in Reihenfolge gesendet. Der Empfänger durfte ein Paket verwerfen, wenn ein Fragment außerhalb der Reihenfolge eintraf, und sollte schon nach dem ersten Fragment Platz für das gesamte Paket reservieren. Blieben weitere Fragmente einige Sekunden aus, konnte auch die unvollständige Rekonstruktion enden. Ein wiederholtes Fragment war hingegen kein Grund zum Abbruch: Das ARCNET-Gerät konnte den Rahmen empfangen, obwohl die Bestätigung den Sender nicht erreichte. Dieser durfte erneut senden; die Software sollte das doppelte Fragment ignorieren.

Eine bestätigte Rahmenübertragung bewies damit noch kein wiederhergestelltes IP-Datagramm. RFC 791 beschreibt IP-Datagramme und IP-Fragmentierung, RFC 826 den ARP-Kontext. RFC 1201 beschreibt ARCNETs eigene Grenze dazwischen, ohne eine reale Paketaufzeichnung, Wiederholungsrate oder Anwendungsauslieferung zu berichten.

504 Oktette vermieden die ARCNET-Fragmentierung, erhöhten aber die Zahl der IP-Pakete, die jeder Knoten im Pfad bearbeiten musste. Als Signalisierung nannte die RFC die TCP-MSS-Option und eine MTU-Ermittlung wie RFC 1063. Die spätere RFC 1191 behandelt die IPv4-Pfad-MTU-Ermittlung; sie belegt weder eine ARCNET-Konfiguration noch die Zustellung eines bestimmten Datagramms.

Gemeinsames Kabel bedeutete keine gemeinsame Sprache

RFC 1201 berichtet, dass sich 1989 fünf Unternehmen auf das referenzierte ARCNET-Sicherungsformat verständigt hatten. Die neue Zuordnung verwendete die Protokollkennungen 212 für IP, 213 für ARP und 214 für RARP. Die Vorgänger-RFC 1051 hatte andere Werte festgelegt. Laut RFC 1201 konnten beide Kapselungen auf demselben ARCNET bestehen, aber nicht miteinander kommunizieren. Das gemeinsame Medium machte die unterschiedlichen Paketregeln nicht kompatibel.

Der RFC Editor führt RFC 1201 heute als STD 46 / Internet Standard. Dieser Katalogstatus belegt eine Norm, keine Zahl installierter Geräte. Der dokumentierte Wandel ist enger: Die feste Rahmengröße erforderte Fragmentierung auf Sicherungsschicht, die praktische Maximalgröße blieb eine lokale Konfiguration, und die geänderte Kennung markierte eine sichtbare Kompatibilitätsgrenze.

Quellen