Zusammenfassung

  • Eine CCP-Option beschreibt die Dekompressionsfähigkeit des Empfängers. Hin- und Rückrichtung dürfen verschiedene Algorithmen wählen; scheitert die Einigung, bleibt nur diese Richtung unkomprimiert.
  • Configure-Ack bestätigt einen bestimmten Antrag, 0x00FD bezeichnet ein komprimiertes Datagramm ohne Algorithmusnamen, Reset-Ack bestätigt den passenden Reset. Keines beweist allein Integrität, Wiedergewinn verlorener Daten oder Anwendungszustellung.

Das Wörterbuch liegt dort, wo die Kurzschrift gelesen wird. Mit diesem Blick wird verständlich, warum CCP nicht einen Kompressor für die ganze Leitung auswählt. Jeder Empfänger veröffentlicht seine eigene sichere Lesefähigkeit.

CCP darf erst in der Network-Layer-Protocol-Phase von PPP verkehren; frühere Pakete sollen still verworfen werden. Komprimierte Daten warten zusätzlich auf den Zustand Opened. Linkaufbau, Einigung und Nutzung sind getrennte Übergänge.

Zwei Empfänger, zwei Verträge

Ein Empfänger kann mehrere Verfahren anbieten und für eingehende Daten eines auswählen. Die Gegenrichtung wird unabhängig ausgehandelt. Unterschiede bei Speicher, Geschwindigkeit, Kosten oder Lizenzen können deshalb zwei Algorithmen oder nur einseitige Kompression ergeben.

Unbekannte Optionen erhalten Configure-Reject. Bekannte Verfahren mit unzulässigen Werten erhalten Configure-Nak mit akzeptablen Werten. Werden alle Vorschläge abgelehnt, läuft die Richtung unkomprimiert weiter. Lokale Inkompatibilität beendet nicht automatisch den Link.

Die enge Aussage eines Ack

Nach RFC 1661 ist Configure-Ack die positive Antwort auf genau einen gültigen Configure-Request. Für einen späteren Frame fehlen noch Kennung, Richtung, Optionsbytes, Parameter, Zustandsepoche, Opened-Nachweis und Ausschluss einer neueren Aushandlung.

RFC 2153 schuf eine allgemeine Hülle für Herstellererweiterungen. Eine OUI ordnet einen Namensraum zu, garantiert aber keine identische Implementierung. RFC 1915 dokumentiert die Verfahrensvarianz bei patentierten Verfahren, nicht deren Einsatz oder Leistung.

0x00FD ist keine Algorithmus-ID

Im geöffneten Zustand bezeichnet 0x00FD ein Compressed Datagram. Bei getrennter Kompression physischer Links eines Multilink-Bündels dienen 0x00FB für Daten und 0x80FB für Steuerung. IANA registriert diese Werte.

RFC 1962 sagt ausdrücklich, dass der Protocol-Wert den Algorithmus nicht nennt. Der Empfänger verbindet ihn mit dem aktuell für diese Richtung ausgehandelten Hauptverfahren. Ohne CCP-Dialog und Epoche ist der Frame nicht eindeutig einem Decoder zuzuordnen.

Auch „compressed“ verspricht keine Größenersparnis. Wächst die Ausgabe über das PPP-Limit, kann der Sender auf das native Paket oder profilspezifische Fragmentierung zurückfallen.

Erkennung kommt aus dem Profil

Bei zustandsbehafteter Kompression kann ein verlorenes Paket alle folgenden Wörterbücher verschieben. CCP definiert keinen universellen CRC. Das Verfahren muss Zuverlässigkeit erkennen oder einen zuverlässigen Transport wie RFC 1663 verlangen.

RFC 1974 zeigt Sequenznummer, LCB, CRC und mehrere Histories für Stac LZS; RFC 1967 verwendet eigene Prüf- und Reset-Signale. Nichts davon steckt in 0x00FD. Klassifikation und erfolgreiche Dekompression bleiben getrennte Prüfungen.

Reset stellt Zustand her, nicht Daten

Bei einem Fehler sendet der Empfänger Code 14 Reset-Request und verwirft weitere komprimierte Pakete dieser Richtung, bis Code 15 Reset-Ack mit erwarteter Kennung eintrifft. Der Peer leert seinen Sendekompressor und antwortet; der Empfänger leert seinen Dekompressor. Die Gegenrichtung bleibt unberührt.

Die verworfenen Datagramme kehren jedoch nicht zurück. Der Ack beweist weder den nächsten CRC noch Linkzuverlässigkeit, TCP-Wiederholung oder Geschäftsergebnis. Er quittiert einen gemeinsamen Ausgangszustand.

Heng Lus Running-Code Primacy hält die Schlussfolgerung eng: Dokument, Register und Ack koordinieren Ausführung, ersetzen sie aber nicht. Die Beweiskette lautet Phase, Richtungsantrag, Ack, Opened, realer Kompressor, Frame-Marker, Integritätsprüfung, Reset, erstes gültiges Ergebnis, Endpunkt und Anwendung. Die Stärke von RFC 1962 liegt darin, keine Stufe mit der nächsten zu verwechseln.

Sources