Zusammenfassung

  • RFC 1490 empfahl, aber verlangte nicht, Pakete zu fragmentieren, wenn sie die maximale Frame-Größe eines Frame-Relay-Netzes überschritten. Die Wiederherstellung blieb an den DTEs am Netzeingang und -ausgang.
  • Die Fragmente mussten auf derselben virtuellen Verbindung in Reihenfolge bleiben. Ein verlorenes oder beschädigtes Teil führte dazu, dass die gesamte Nachricht verworfen wurde; die erneute Übertragung oblag dem Protokoll darüber.
  • RFC 2427 berichtete 1998, dass die Kapselung insgesamt breit implementiert war, der Fragmentierungsalgorithmus aber keine interoperablen Implementierungen hatte. Sie strich ihn und verwies auf FRF.12.

RFC 2427 liefert eine feinere Bilanz als „RFC 1490 war erfolgreich“ oder „RFC 1490 scheiterte“. Der 1998 veröffentlichte Nachfolger sagt, die Multiprotokoll-Kapselung aus RFC 1490 sei breit implementiert und genutzt worden. Im selben Anhang steht, dass es keine interoperablen Implementierungen des dort beschriebenen Fragmentierungsalgorithmus gab. Die neue Spezifikation entfernte das Verfahren und ersetzte es durch FRF.12. Sie behauptet nicht, niemand habe jemals Code dafür geschrieben. Sie hält fest, dass getrennte Implementierungen nicht miteinander funktionierten. Genau diese Unterscheidung macht die Geschichte aus.

1993 ging es um ein konkretes Größenproblem. RFC 1490 vom Juli beschrieb, wie geroutete und gebrückte Pakete über ein Frame-Relay-Backbone transportiert werden konnten. Ein Netz konnte eine maximale Frame-Größe von nur 262 Oktetten unterstützen; ein bereits gekapseltes Paket konnte größer sein. Fragmentierung bot einen Weg, die Daten in passende Frames zu teilen und am anderen Ende wiederherzustellen. Die RFC empfahl Fragmentierung und Reassembly, machte sie aber nicht verpflichtend. Die grundlegende Kapselung ließ sich somit einsetzen, ohne dass jedes Gerät diese optionale Funktion mitbrachte.

Entscheidend war, wo das Verfahren endete. RFC 1490 begrenzte es auf die DTEs an den Grenzen des Frame-Relay-Netzes. Das sendende Gerät kapselte das Paket zunächst und teilte es danach in Frames, die zum Netzlimit passten. Das empfangende DTE setzte das Paket wieder zusammen und übergab es demselben Verarbeitungspfad wie ein ungeteiltes Paket. IP erhielt keine Folge kleinerer IP-Datagramme. Das Verfahren umging eine Frame-Grenze eines bestimmten Dienstes, änderte aber nicht die Identität des IP-Datagramms.

RFC 791 definiert eine andere Fragmentierung auf der IP-Schicht. Das IP-Datagramm trägt seine Identifikation, seinen Offset und die Fragmentierungskennzeichen; die IP-Zieladresse setzt das ursprüngliche Datagramm wieder zusammen. RFC 1490 legte dagegen eine eigene Fragmentierungsstruktur um das bereits gekapselte Paket und sah die Wiederherstellung an der Frame-Relay-Grenze vor der normalen Protokollverarbeitung vor. Beide Verfahren teilen Daten in Teile, aber sie setzen unterschiedliche Schichten, Empfänger und Zuständigkeiten voraus.

Das Format führte Zustand ein. Jeder Teil enthielt die Kapselungskennung, eine zwei Oktette lange Sequenznummer, einen Offset und ein Kennzeichen für das letzte Fragment. Die Sequenznummer stieg für jede neue fragmentierte Nachricht und begann bei der Initialisierung mit einem zufälligen Wert. Der Offset wurde in Einheiten von 32 Oktetten angegeben; das erste Fragment begann bei null. Damit konnte das DTE die Teile einer Nachricht zuordnen, richtig positionieren und das Ende erkennen.

Auch die Reihenfolge war Teil des Vertrags. Die Fragmente mussten mit Offset null beginnen und ohne Unterbrechung durch andere Informationen für dieselbe Datenverbindung gesendet werden. Ein Endgerät musste mindestens 2 KiB wieder zusammensetzen können; 8 KiB waren empfohlen. Fehlte ein Fragment oder war es beschädigt, wurde die gesamte Nachricht verworfen. Die Fragmentierung selbst wiederholte keine Einzelteile. Für den erneuten Versuch war das Protokoll der nächsthöheren Ebene zuständig.

Einen Reassembly-Timer gab es nicht. RFC 1490 begründete das damit, dass der Frame-Relay-Dienst Frames in Reihenfolge liefern sollte. Der Empfänger sollte daher keinen lokalen Timer benötigen, um eine unvollständige Folge als veraltet einzustufen. Das ist eine im Dokument festgehaltene Entwurfsannahme, kein Nachweis für die Leistung jedes Netzbetreibers oder jedes Geräts. Unvollständige Nachrichten beanspruchten weiterhin Speicher; ein verlorener Teil führte weiter zum Verwerfen des Ganzen, und die Wiederherstellung blieb dem Protokoll darüber überlassen.

Der Bericht von 1998 trennt die Ergebnisse nach Mechanismus. RFC 2427 bezeichnete die Kapselung als breit implementiert und verwies auf ihre Übernahme in Branchen- und ITU-Spezifikationen. Für den Fragmentierungsalgorithmus meldete sie dagegen keine interoperablen Implementierungen und erwähnte Hinweise, dass das Verfahren für einige Frame-Relay-Anwendungen nicht ausreichte. Die Nachfolgerin strich es zugunsten von FRF.12. Sie nennt weder Hersteller noch Testzahlen oder den konkreten Fehler. Die Quellen zeigen das Ergebnis, aber nicht dessen genaue Ursache.

Damit fallen zwei vereinfachte Lesarten weg. Eine nicht interoperable Option beweist nicht, dass RFC 1490 insgesamt ungenutzt war; der Nachfolger sagt ausdrücklich das Gegenteil über die Kapselung. Umgekehrt beweist die Verbreitung der Kapselung nicht, dass jede darin beschriebene Funktion zwischen Geräten funktionierte. Ein Standard kann mehrere technische Verträge mit unterschiedlichen Implementierungszyklen enthalten.

Die Inventarangabe „RFC 1490 unterstützt“ beantwortet deshalb nicht die Betriebsfrage. Welche Funktion ist gemeint? Welche maximale Frame-Größe gilt je Verbindung? Haben beide DTE denselben Fragmentaufbau und dieselben Reihenfolgeregeln? Was passiert beim Verlust eines Teils? RFC 2427 hinterließ eine mechanistische Antwort: Für die Kapselung gab es eine breite Implementierungsbasis, für diesen Fragmentierungsalgorithmus keine belegte Interoperabilität. Der Verweis auf FRF.12 dokumentiert die Ablösung, nicht deren universelle Einführung.