Zusammenfassung

  • RFC 5133 ist ein Proposed Standard von Dezember 2007 und aktualisiert RFC 4233.
  • RFC 4129 hatte Management-Typ 5 bereits dem DUA DLC Status Request zugeordnet.
  • RFC 4233 ordnete denselben Typ 5 später dem IUA TEI Query Request zu.
  • Mit identischer Klasse 0 und identischem Typ 5 waren die beiden Operationen im Header ununterscheidbar.
  • RFC 5133 verlangt für TEI Query Request den Typ 8.
  • Das heutige IANA-Register führt DLC Status Request unter 5 und TEI Query Request unter 8.
  • Die eindeutige Registrierung beweist keine Aktualisierung installierter Software.
  • Eine aktive SCTP-Association beweist weder ASP-Aktivität noch Unterstützung für Typ 8.
  • RFC 4129 empfiehlt PPID 10 für DUA, erlaubt in kombinierten Szenarien aber auch IUA-PPID 1.
  • SCTP wertet den PPID nicht selbst aus; er ist weder Authentisierung noch semantische Durchsetzung.
  • ASSIGNED ist eine Q.921-Zustandsaussage und keine Geräte- oder Teilnehmeridentität.
  • Sichere Migration trennt Registry-, Build-, Konfigurations-, Transport-, Wire-, Decode-, Response-, Link- und Servicebelege.

Ein Retry mit anderer Bedeutung

Bei einem gewöhnlichen Transport-Retry bleibt die Operation gleich: dieselbe Nutzlast wird erneut zugestellt. Der Wechsel von 8 auf 5 ist anders. Er verändert den Discriminator, der dem Empfänger sagt, welche Operation gemeint ist.

RFC 4129 definierte für DUA in der Management-Klasse den DLC Status Request als Typ 5, Confirm als 6 und Indication als 7. RFC 4233 ergänzte den TEI Query Request und verwendete ebenfalls Typ 5. Dadurch konnte class 0/type 5 zwei Fragen bedeuten. RFC 5133 verschob die TEI-Anfrage auf 8.

Ein Fallback auf 5 führt also nicht einfach in den Zustand vor einem Syntax-Update zurück. Er führt in einen Namespace zurück, in dem die Bytes nicht genug Information enthalten. In einer DUA- oder kombinierten Umgebung kann der Empfänger einen DLC-Statusvorgang annehmen, während der Sender glaubt, TEIs abzufragen.

Ein Erfolgscode oder irgendeine Antwort macht das nicht sicher. Gerade eine plausible Antwort kann die Fehlinterpretation verdecken.

PPID beseitigt das Risiko nicht

RFC 4129 empfiehlt unterschiedliche SCTP Payload Protocol Identifier: 10 für DUA, 1 für IUA. Zugleich darf DUA den IUA-Wert verwenden, wenn ISDN und DPNSS über dieselbe Association zurückgeführt werden. SCTP selbst nutzt den PPID nicht direkt; bestimmte Entities können ihn zur Erkennung der transportierten Information verwenden.

Der PPID ist damit Kontext für die obere Schicht, kein vom Transport erzwungener Typvertrag. Eine zulässige Konfiguration kann ihn teilen. Ein Capture kann ihn verlieren. Ein Parser kann zu früh anhand einer Rolle verzweigen. Deshalb musste der innere class/type-Raum selbst kollisionsfrei werden.

PPID 1 plus class 0/type 8 ist ein starker Wire-Beleg für eine moderne IUA-TEI-Anfrage. Es ist kein Beleg für organisatorische Identität, Berechtigung, den Build des Empfängers oder eine vollständige Antwort.

Die Registry ist Norm, nicht Flotteninventar

IANA zeigt heute den eindeutigen Sollzustand. Der Eintrag ist verbindliche Orientierung für Implementierungen und Analyzer. Er sagt nicht, welche Appliance noch nach der alten Tabelle arbeitet.

Ein Build-Artefakt kann die Änderung enthalten. Ein Softwareinventar kann dieses Artefakt einem Knoten zuordnen. Die Konfiguration kann IUA- oder DUA-Rolle und PPID festlegen. Ein Packet Capture zeigt die tatsächlichen Bytes. Eine Receiver-Trace zeigt den ausgeführten Handler. Erst eine Response zeigt die Aussage des Peers. Diese Belege liegen nicht auf derselben Ebene.

Die Registry ist deswegen keineswegs unwichtig. Vor der Reparatur konnte selbst eine perfekte Aufnahme die beiden Operationen nicht aus dem Header unterscheiden. Die eindeutige Zuteilung macht operative Wahrheit messbar; sie liefert sie nicht automatisch.

Transportzustand und Anwendungszustand

RFC 4233 trennt SCTP-Association, ASP-Zustand und Application Traffic. Bei bestehender Association kann der ASP INACTIVE sein. Die Zuordnung eines Interface Identifier zu Association und Stream ist dynamisch und während Failover zeitweise ungültig.

„SCTP up“ beweist also Transporterreichbarkeit. Es beweist nicht, dass Typ 8 verstanden wird, der richtige Application Server aktiv ist oder das Interface korrekt zugeordnet wurde.

Für jede Migration gehören Peer, Association, Stream, PPID, Version, Klasse, Typ, Länge, Richtung, Sender- und Empfängerbuild sowie Parserentscheidung in einen gemeinsamen Datensatz. Unsupported Message Type, Unexpected Message und Protocol Error müssen getrennt bleiben. Auch Schweigen ist kein Erfolg: Es kann stilles Verwerfen, Messlücke oder einen späteren Lookup-Fehler bedeuten.

Der TEI-Status endet bei Q.921

Der ASP sendet TEI Query an die Signaling Gateway. Den DLCI im IUA-Header muss die SG ignorieren. Ein sichtbares Feld darf deshalb nicht als Ziel, Kunde oder Korrelationsschlüssel interpretiert werden.

ASSIGNED bedeutet, dass Q.921 den TEI als zugeteilt betrachtet. UNASSIGNED bedeutet das Gegenteil. Die Aussage authentisiert weder Endgerät noch Teilnehmer und beweist keine bestehende Datenverbindung.

Sie kann dennoch eine richtige nächste Aktion auslösen: Signalisierung vorbereiten, Establish anfordern oder einen unerwarteten TEI untersuchen. Für einen Servicebeleg braucht es danach die vollständigen Status Indications, ihren Zeit- und Interfacekontext, Q.921-Linkzustand, Establish-Ablauf, Signalisierungsverkehr und Anwendungsergebnis.

Ein begrenzter Legacy-Vertrag

Wo Typ 5 vorübergehend unterstützt werden muss, braucht er einen expliziten Vertrag: namentlich bekannte Peers, nachgewiesener IUA-only-Kontext, Telemetrie je Nutzung, Sperre für DUA und kombinierte Associations, Ablaufdatum und negative Tests. Ein Typ-5-Paket darf bei möglicher Kollision nie den TEI-Handler erreichen.

Unsichtbare Kompatibilität verändert die Anreize. Der letzte alte Peer muss nicht modernisieren; alle anderen Teams tragen dauerhaft zusätzliche Parserlogik und Incident-Risiko. „Vorübergehend“ wird zur Architektur, sobald niemand seine Verwendung messen kann.

Die Testmatrix umfasst neu-neu, neu-alt, alt-neu, IUA-only, DUA-only, kombiniert und Failover. Sie muss nicht nur richtige Erfolge, sondern auch sichtbare, sichere Ablehnung mehrdeutiger Kombinationen zeigen.

Beweisgrenzen

RFC Editor und Datatracker belegen Status und Historie. RFC 5133 belegt Kollision und 5→8. RFC 4129 belegt DLC-Typen und PPID-Ausnahmen. RFC 4233 belegt Header, Fehler, TEI-Prozedur und Zustände. IANA belegt die aktuelle Zuteilung; SCTP-Dokumente den Transport.

Nicht belegt sind ein konkreter Vendor-Build, ein Produktionspaket, die Identität eines Terminals oder ein Dienstergebnis. Dafür braucht es lokale, aktuelle Evidenz. Der Standard definiert die Messlatte; der Betrieb muss messen.

Sources