Zusammenfassung

  • Im Standardformat Header-Last konnte der Sender zunächst die komprimierte Größe sehen und erst danach markieren, ob ein SDTP-Paket einen seriellen Frame begann, fortsetzte oder beendete.
  • Die Segmentierungsbits in RFC 1963 waren B und F. E zeigte eine CS-Headererweiterung an; ein Sequenzfeld gab es in SDTP nicht. B/E und Sequenznummer gehörten zum PPP Multilink aus RFC 1990.
  • Length trennte SDTP-Pakete in einem zusammengesetzten PPP-Frame, Port wählte einen ausgehandelten Kanal. Keines von beiden belegte lückenlosen Empfang oder die Wiederherstellung des Nutzerdienstes.

Dass ein Header nach seinen Nutzdaten kommt, wirkt wie eine Umkehr der üblichen Paketlogik. Genau das war der Ausgangspunkt des im August 1996 als Informational veröffentlichten RFC 1963. Das Serial Data Transport Protocol legte im voreingestellten Format zuerst die transportierten Daten und am Ende den Terminal-Adaptation-Header ab. Dessen Oktette standen ebenfalls in umgekehrter Reihenfolge. Der Empfänger musste das Paket von zwei Seiten lesen.

Die Ursache lag nicht im Geschmack der Autoren, sondern im Zeitpunkt der Information. Die zugrunde liegende Arbeit betraf unter anderem die Kompression synchroner Daten in DSU/CSUs. Sollte ein komprimierter serieller Frame auf mehrere SDTP-Pakete verteilt werden, kannte der Sender die geeignete Grenze möglicherweise erst, nachdem der Kompressor genügend Ausgabe erzeugt hatte. Ein vorangestellter Header hätte eine frühe Entscheidung verlangt. Ein nachgestellter Header erlaubte, die Größe zu beobachten, den Fragmenttyp festzulegen und anschließend auch den Header durch den Kompressor zu führen.

Header-Last schrieb diesen Ablauf in das Drahtformat. Header-First blieb aushandelbar, wenn Frames nicht aufgeteilt wurden, die Kompression nicht mit SDTP gekoppelt war oder die Hardware einen konventionellen Datenpfad bevorzugte. Die Wahl bewies nur, dass beide Enden dieselbe Darstellung benutzten. Sie sagte nichts über Kompressionsverhältnis, Kompressorstatus oder erfolgreiche Wiederherstellung.

Auch der Betriebszustand hatte Grenzen. PPP musste die Network-Layer-Protocol-Phase erreicht haben, SDCP den Zustand Opened. IANA führt 0x0049 für PPP-SDTP und 0x8049 für PPP-SDCP. Diese Kennungen und der ausgehandelte Zustand waren ein Beleg für gemeinsame Syntax. Sie waren kein Beleg dafür, dass ein späterer Frame vollständig oder brauchbar war.

Normalerweise enthielt ein PPP-Information-Feld genau ein SDTP-Paket. Length erschien erst, wenn sowohl Length-Field-Present als auch die LCP-Option Compound-Frames aus RFC 1570 erfolgreich vereinbart waren. Dann konnten mehrere SDTP-Pakete in einem PPP-Container liegen. Jede Längenangabe umfasste ihr eigenes Feld, einen optionalen Port, den Anpassungsheader, die Daten und mögliches Odd-Pad. Ein Oktett kodierte Gesamtwerte von 2 bis 255, zwei Oktette reichten bis 65535, und Null meinte den gesamten verbleibenden Rest des Information-Felds.

Damit konnte ein Parser Einheiten voneinander trennen. Length belegte jedoch nicht, dass ein ursprünglicher serieller Frame vollständig war. Benachbarte Einheiten konnten andere Fragmente, Frames oder Ports betreffen. Eine sauber erkannte Containergrenze ersetzte kein Signal über einen verlorenen Teil.

Multi-Port fügte einen ausgehandelten Namensraum hinzu. Ohne die Option galt implizit Port 0 und kein Port-Oktett wurde übertragen. Mit der Option trug jedes Paket eine Nummer. 0 bis 254 waren Datenports, 255 war für Steuerung reserviert. Manche Einstellungen galten pro Port, während eine Flusssteuerungsnachricht auf 255 alle Ports betreffen konnte.

Diese Nummer war ein Demultiplex-Schlüssel, keine Identität. RFC 1963 band Port 7 weder kryptografisch an ein Kabel noch an ein Gerät, einen Kunden oder einen Dienst. Nur der lokale Zustand beider Enden gab dem Wert Bedeutung. Ob dieser Zustand noch zur physischen Wirklichkeit passte, musste anders belegt werden.

Für die Grenzen des seriellen Frames waren B und F zuständig. Im synchronen HDLC-ähnlichen Modus stand B für den Beginn und F für den letzten Teil. Kein Bit bedeutete einen mittleren Teil, beide Bits einen vollständigen Frame in einem Paket. Im asynchronen Modus mussten beide gesetzt sein. E hatte eine andere Aufgabe: Es kündigte die optionale CS-Erweiterung an. E war kein Endbit.

Diese Unterscheidung korrigiert eine naheliegende Verwechslung. RFC 1990 PPP Multilink benutzte B/E zusammen mit einer 12- oder 24-Bit-Sequenznummer über ein Bündel von Links. RFC 1963 tat das nicht. SDTP enthielt überhaupt kein Sequenzfeld und konnte deshalb fehlende Fragmente nicht anhand des Fortschritts einer Multilink-Nummer erkennen.

Das Dokument selbst zeigt, warum Prosa und Diagramm gegeneinander geprüft werden müssen. In seiner B/F-Tabelle steht für Begin Frame und Final Frame jeweils 1,0, obwohl der Satz unmittelbar davor F eindeutig als Kennzeichen des letzten Teils definiert. Die umgebenden Definitionen stützen B/F. Daraus folgt aber keine Aussage über eine konkrete Implementierung. Dafür wären Quellcode, Tests oder Paketmitschnitte erforderlich.

Besonders deutlich wird die Beweisgrenze beim inneren FCS. SDTP transportierte bei HDLC-ähnlichen Frames die Bytes zwischen den Flags, nicht die Flags. Standardmäßig reiste der FCS mit. Die Option FCS-Type konnte erlauben, ihn beim Sender zu entfernen und beim Empfänger neu zu erzeugen. RFC 1963 warnte, dies nicht ohne PPP Reliable Transmission oder eine andere Schicht zu tun, die verlorene Pakete zuverlässig meldete. Ein unvollständiger oder fehlerhafter Frame durfte nicht mit einem frisch erzeugten gültigen FCS an den Nutzer weitergegeben werden.

Die Warnung beschreibt, was die Felder nicht wussten. B/F lieferte scheinbare Anfangs- und Endpunkte, Length eine Paketgrenze, Port eine ausgehandelte Zuordnung. Kein Feld meldete Verlust. Verschwand ein mittlerer Teil unbemerkt, konnte ein Empfänger dennoch eine überzeugend geformte Einheit sehen. Ein neuer FCS hätte dann fehlende Evidenz als Integrität maskiert.

RFC 1663 verhandelte Numbered-Mode, Fenster, Bestätigungen und Wiederholungen für ein anderes Problem. RFC 1962 verhandelte Kompressionsalgorithmen und Reset-Austausch. Ihre Funktionen dürfen nicht stillschweigend den SDTP-Feldern zugeschrieben werden. Header-Last koordinierte eine Segmentierungsentscheidung mit dem Zeitpunkt der Kompression; es war weder der Kompressor noch ein Zuverlässigkeitsprotokoll.

Lu Hengs Trennung von deklarierter Struktur und ausführbarem Nachweis macht die Architektur lesbar. RFC 1963 legte eine kleine gemeinsame Grammatik fest: Position, Erweiterung, Grenze, Länge und Portbezeichnung. Ein laufendes System musste weiterhin Ankunftsreihenfolge, Verlustbehandlung, Pufferpolitik, lokale Portbindung, FCS-Behandlung und Übergabe an den Nutzer nachweisen. Die Spezifikation machte Verantwortungen präzise, ohne ihren Vollzug vorzutäuschen.

Quellen