Zusammenfassung

  • RFC 1055 beschreibt SLIP als minimale Rahmung von IP-Datagrammen auf einer seriellen Leitung: END beendet die Einheit, ESC schützt die zwei Datenwerte, die sonst wie Struktur aussähen.
  • Ein vorangestelltes END erzeugt auf einer störungsfreien Leitung eine verworfene leere Einheit, schneidet nach Rauschen aber den unklaren Pufferrest von der nächsten Rahmung ab.
  • Eine Grenze gefunden zu haben, die Unversehrtheit der Bytes zu kennen und einen zustandsbehafteten Dekompressor zu synchronisieren, sind verschiedene Leistungen. RFC 1144 und RFC 1662 lassen sie getrennt sichtbar werden.

Eine absichtlich dünne gemeinsame Regel

RFC 1055 ist bemerkenswert, weil er SLIP nicht größer macht als es ist. Das Dokument von 1988 nennt Serial Line IP einen de-facto-Ansatz für punktuelle serielle TCP/IP-Verbindungen und zugleich ausdrücklich keinen Internet Standard. SLIP sei lediglich ein Paket-Rahmungsprotokoll: Es definiere eine Zeichenfolge, die IP-Pakete auf einer seriellen Leitung einrahmt, und sonst nichts.

Dieses „sonst nichts“ ist eine technische Zuständigkeitsgrenze. SLIP liefert keine Adressierung, keine Pakettypkennung, keine Fehlererkennung oder -korrektur und keine Kompression. Die beiden Enden müssen die IP-Adressen auf anderem Weg kennen. Mehrere Protokolle können die Leitung nicht aufgrund eines SLIP-Typfeldes teilen, denn ein solches Feld existiert nicht. Auch ein Bytefeld zwischen zwei END-Werten wird nicht deshalb als unbeschädigt bestätigt.

Rückblickend SLIP als unvollständiges PPP zu behandeln, verstellt die eigentliche Entscheidung. Auf einer langsamen Leitung brauchten zwei Implementierungen eine kleine Regel, mit der sie aus einem fortlaufenden Strom wieder ein IP-Datagramm abgrenzen konnten. Zwei Werte aus den Nutzdaten durften diese Regel nicht nachahmen. Weitergehende Deutungs- oder Kontrollmacht übernahm das Format nicht.

RFC 1055 reserviert dazu END, oktal 0300, dezimal 192, und ESC, oktal 0333, dezimal 219. Ein Daten-END wird als ESC gefolgt von 0334 gesendet; ein Daten-ESC als ESC gefolgt von 0335. Nach den so geschützten Daten folgt END. Der Empfänger kehrt die beiden Ersetzungen innerhalb der SLIP-Grammatik um und behandelt END als Abschluss.

Es handelt sich nicht um eine allgemeine Aussage über Zeichen. END ist nur für einen Empfänger strukturell, der gerade einen SLIP-Rahmen zusammensetzt. ESC leitet nur zwei festgelegte Ersetzungen ein. Der Sender hinterlässt eine lokale, reversible Spur, damit die äußere Grammatik einen Nutzwert nicht als Steuerung missversteht; der passende Leser entfernt genau diese Spur. Damit ist Nutzdatentransparenz gewonnen, aber weder Integrität noch Vertrauenswürdigkeit der Nutzdaten bewiesen.

Erst abschließen, dann beginnen

Der Vorschlag von Phil Karn macht die kleine Regel zu einem präzisen Wiederanlaufmechanismus. RFC 1055 empfiehlt, ein Paket nicht nur mit END zu beenden, sondern auch mit END zu beginnen. Dadurch sollen fehlerhafte Bytes aus dem Empfänger herausgespült werden, die Leitungsrauschen dort angesammelt haben könnte.

Auf einer ruhigen Leitung stehen dann zwei END hintereinander: das Ende des vorigen Pakets und der Auftakt des nächsten. Der RFC verschweigt den Preis nicht. Es entsteht ein leeres oder schlechtes IP-Paket, das die IP-Implementierung verwirft; die gezeigte Empfangsroutine ignoriert ein END sogar direkt, wenn noch keine Daten gesammelt wurden. Der leere Rahmen ist kein versteckter Sonderfall, sondern eine absichtlich bezahlte, sichtbare Reserve für eine klare Grenze.

Nach einer Störung verändert sich seine Funktion. Im Puffer können Bytes liegen, die weder noch verlässlich zum alten Datagramm gehören noch als Anfang des neuen gelten dürfen. Das führende END beendet diese unbestimmte Ansammlung. Der Rauschrest wird verworfen, bevor die Bytes der nächsten Behauptung als Rahmeninhalt gelesen werden. Der Empfänger steht wieder an einer bekannten Grenze und wartet auf Daten danach.

Darum stellt END nicht „das Paket wieder her“. Es stellt den Leseansatz wieder her. Es repariert die verworfenen Bytes nicht, beweist keine Fehlerfreiheit der folgenden Einheit und setzt keinen Zustand wiederher, den eine darüberliegende Schicht aus der Vergangenheit benötigt. Es verhindert nur, dass der unklare Vorgänger die erste Zeile der nächsten Interpretation schreibt.

Auch der Beispielcode bleibt in dieser Rolle. Er liefert ein Paket nur zurück, wenn vor END Daten eingegangen sind; leere Ergebnisse durch doppelte END ignoriert er. Nach ESC werden nur die zwei erwarteten Folgewertfälle zurückübersetzt. Bei einem anderen Folgewert spricht der Code von einer Protokollverletzung und speichert das Byte unverändert. Das ist kein umfassender Gültigkeitsrichter, sondern ein kleiner Leser für Grenze und zwei geschützte Werte.

Rahmen, Unversehrtheit und Erinnerung

RFC 1144 über TCP/IP-Headerkompression auf langsamen seriellen Verbindungen zeigt, warum diese Bescheidenheit operativ zählt. In seinem Ablauf geht ein IP-Paket zunächst durch einen Compressor und erst dann an einen Framer. Der Compressor hält für Verbindungen auf der seriellen Leitung frühere Header vor; komprimierte Pakete können nur die Abweichungen von diesem Zustand ausdrücken.

Ein END kann also einen Rahmen sauber abschließen, während zwei andere Fragen offen bleiben: Sind die Bytes des Rahmens unbeschädigt, und besitzt der Dekompressor noch den Zustand, den der Sender voraussetzt? RFC 1144 verortet Fehlererkennung auf der Rahmungsebene und verlangt, dass der Dekompressor eine Fehleranzeige erhält, damit er ein schlechtes Paket verwirft und keinen Zustandsfehler fortpflanzt. Das führende SLIP-END liefert diese Anzeige nicht. Dazu wurde es nicht entworfen.

Die Trennung ist keine akademische Feinheit. Wo beginnt oder endet eine Einheit? Ist ihr Inhalt intakt? Ist der historische Kontext eines zustandsbehafteten Lesers kompatibel? Ein Delimiter beantwortet nur die erste Frage. Prüfsumme oder FCS können die zweite behandeln. Rücksetzen oder explizite Synchronisierung kann für die dritte nötig sein. Ein gemeinsames Wort wie „recovered“ ersetzt keine dieser Evidenzen.

RFC 1662 bietet einen späteren, engen Vergleich. PPPs HDLC-artige Rahmung spezifiziert eine Flag Sequence für Anfang oder Ende, Oktett-Transparenz, FCS und ungültige Rahmen. Sie warnt zugleich: Ein Oktett zu sparen, indem ein Schließflag auch als nächster Beginn dient, kann nach Ruhezeit Zuverlässigkeit kosten; ohne neues Öffnungsflag können Rauschzeichen an den nächsten Rahmen angehängt werden. PPP ist kein Urteil darüber, dass SLIP „falsch“ war. Es ist ein breiterer Vertrag, in dem Grenze, Integrität und Verwerfung getrennt benannt sind.

Die Zuständigkeit eines Markers muss enden

Heng Lus Notes 64 und 65 geben für diese Geschichte eine brauchbare Leseregel: Zuerst die kleinste deterministische Funktion bestimmen, die laufende Systeme lokal prüfen können; dann daraus keine umfassende Befugnis ableiten. END in SLIP darf die alte Ansammlung beenden und den nächsten Rahmen neu beginnen lassen. ESC darf zwei Werte schützen. Keines von beiden kann den folgenden Inhalt beglaubigen oder den Zustand eines anderen Decoders zurückbringen.

Eine Untersuchung eines Wiederanlaufs sollte daher Rohbytes vor dem Marker, den beobachteten END, die zusammengestellten Rahmenbytes, das unabhängige Integritätsurteil und den Zustand jedes geschichtsabhängigen Decoders getrennt bewahren. Der Satz „Paket wiederhergestellt“ verdeckt mehrere voneinander unabhängige Entscheidungen.

Quellen und Evidenzgrenzen

Die geschlossene Quellenmenge besteht aus RFC 1055, RFC 1144 und RFC 1662. Sie belegt END/ESC-Grammatik, den Grund für das führende END, die ausdrücklich fehlenden SLIP-Funktionen, die Compressor/Framer-Trennung und den begrenzten PPP-Vergleich. Sie belegt keine universelle SLIP-Nutzung, kein Verhalten heutiger Geräte, keine gemessene Rauschrate, kein Sicherheitsresultat und nicht den Einsatz von RFC 1144 auf jeder SLIP-Leitung.