Zusammenfassung

  • In RFC 9892 bezeichnet eine TID einen vollständigen Klassifikationssatz, eine FID einen Datenstrom darin. Beide Werte gelten nur im Namensraum des Modems und belegen weder Warteschlange noch Credit Window, Übertragung oder Zustellung.
  • Der Router validiert und ersetzt den gesamten Satz, unterscheidet explizite Regeln von Wildcards und gibt Ethernet bei einem gleichzeitigen Diffserv-Treffer Vorrang. Erst eine ausgehandelte Erweiterung verleiht dem Ergebnis eine Verwendung; seine Wirkung muss anschließend im Datenpfad beobachtet werden.

Im Monitoring standen zwei leere Klassifikationen nebeneinander. Beide waren als „Default“ markiert. Die erste sollte überhaupt keinen Verkehr auswählen, die zweite jeden DSCP, der keiner expliziten Regel entsprach. Die Oberfläche hatte gegensätzliche Entscheidungen auf dasselbe Wort reduziert.

RFC 9892 wurde im Januar 2026 auf dem Standards Track der IETF veröffentlicht. Er definiert ein Traffic Classification Data Item für das Dynamic Link Exchange Protocol. Ein Modem bündelt Beschreibungen unter einer Traffic Classification Identifier, kurz TID. In den Sub-Data Items bezeichnet jeweils eine Flow Identifier, kurz FID, den durch Headerregeln ausgewählten Datenstrom.

Die ersten standardisierten Formate behandeln Diffserv sowie Ethernet. Ihre Struktur ist absichtlich nicht an einen bestimmten Zweck gebunden. RFC 9892 beschreibt, wie Verkehr erkannt wird; eine andere Erweiterung legt fest, wofür das Ergebnis gebraucht wird. Gerade diese Wiederverwendbarkeit verbietet es, klassifiziert als Synonym für behandelt zu lesen.

Ohne Modem und Sitzung hat die Zahl keine Identität

TID und FID besitzen nur modemlokalen Geltungsbereich. Die TID 9 eines Geräts hat keine notwendige Beziehung zur TID 9 eines anderen. Selbst am selben Anschluss kann die Zahl nach einem Gerätewechsel oder Sitzungsneustart wiederkehren, ohne dass der alte Gegenstand fortbesteht.

RFC 8175 ordnet DLEP der lokalen Verbindung zwischen einem Modem und seinem angeschlossenen Router zu. Eine Verbindung bildet eine Sitzung; Erweiterungen werden je Sitzung ausgehandelt; getrennte Verbindungen sind getrennte Sitzungen. Wie das Modem Informationen über das darunterliegende Medium gewinnt, liegt außerhalb des Basisprotokolls.

Ein belastbarer Schlüssel umfasst deshalb Peer-Identitäten, Sitzung und Lebenszyklus, Empfangsnachricht, Zeitpunkt, vollständige Klassifikatorversion und nutzende Erweiterung. Wer nur TID und FID exportiert, verwandelt eine flüchtige lokale Referenz in einen vermeintlich dauerhaften Geschäftsgegenstand.

Das IANA-Register für DLEP-Parameter führt Traffic Classification als Data Item Typ 29 und enthält die anfänglichen Sub-Data-Item-Typen für Diffserv und Ethernet. Das Register koordiniert Codes auf der Leitung. Es belegt weder die Implementierung in einem Produkt noch die Aushandlung in einer Sitzung, die aktuelle Konfiguration oder einen Paketreffer.

Heng Lus Gedanke vom laufenden Code als primärem Beleg schützt hier vor einer Abkürzung. Ein gemeinsamer Standard macht Verhalten möglich und interoperabel. Der laufende Zustand zeigt, welches Verhalten tatsächlich vorlag. Registereintrag und Betrieb gehören zusammen, dürfen aber nicht miteinander verwechselt werden.

Ein Update ersetzt den Satz

Das Modem darf Klassifikationen in der Session Initialization Response übermitteln und neue oder geänderte Sätze in einer Session Update senden. Kennt der Router die empfangene TID bereits, muss er nach RFC 9892 die zugehörigen Angaben ersetzen und den verbundenen Datenpfadzustand nach Bedarf aktualisieren.

Das ist eine aktuelle Gesamtsicht, keine fortlaufende Sammlung von Teilfakten. Werden neue Sub-Data Items an alte angehängt, entsteht ein Satz, den kein Peer je gesendet hat. Wird die alte Version spurlos überschrieben, geht der Übergang verloren, der eine Verhaltensänderung erklärt. Benötigt werden daher ein vollständiger aktiver Satz und eine unveränderliche, zeitlich geordnete Versionsfolge.

Auch die Reihenfolge der Sub-Data Items darf nicht als versteckte Priorität dienen. Der Standard gibt ihr keine Semantik. Weder die erste Position noch der kleinere FID-Wert gewinnt. Entscheidend sind der Typ, die Match-Regeln und die Erweiterung, die das Ergebnis verarbeitet.

Besonders aufschlussreich sind die leeren Fälle. Ein Traffic Classification Data Item mit null Sub-Data Items bedeutet: Kein Verkehr passt zu dieser TID. Ein Diffserv Sub-Data Item mit null DSCP-Werten ist dagegen eine Wildcard für alle DSCPs, die keiner expliziten FID zugewiesen wurden. Eine VID von null im Ethernet-Format weist den Empfänger an, das VLAN-Feld zu ignorieren.

Eine einzige Anzeige „Default“ kann diese drei Zustände nicht vertreten. Sie spart Zeichen, indem sie die eigentliche Entscheidung entfernt.

Das entspricht Heng Lus Prinzip der minimalen Anfangsspezifikation und späteren lokalen Entscheidung. Das Gemeinsame muss Format, Grenzen, Fehler und Vorrang regeln. Verwendung, Konfiguration und Risiko verbleiben bei den Akteuren, die den späteren Zustand betreiben.

Gültigkeit wird über den vollständigen Satz geprüft

Ein Diffserv Sub-Data Item verbindet eine FID mit einem oder mehreren DSCP-Werten. Der Router muss die Angaben vor ihrer Verwendung prüfen. Jeder DS-Field-Wert darf im gesamten Traffic Classification Data Item nur einmal vorkommen, nicht einmal je Unterelement. Derselbe Wert in zwei getrennten Sub-Data Items macht den Satz fehlerhaft; er erzeugt keine Auswahlmöglichkeit.

RFC 2474 bezeichnet einen Klassifikator als die Instanz, die Pakete nach Headerinhalt und festgelegten Regeln auswählt. Anschließend wird ein DSCP an einem Knoten einem Per-Hop Behavior zugeordnet, häufig über Warteschlangenbedienung und -verwaltung. Auswahl, lokales Verhalten und erlebter Dienst sind aufeinander bezogen, aber nicht identisch.

Die Diffserv-Architektur aus RFC 2475 setzt Klassifikatoren und Traffic Conditioner in administrative Domänen und an deren Grenzen. Eine Markierung kann eine Grenze überqueren. Die Richtlinie, die sie auslegt, wird dadurch nicht automatisch mittransportiert. Ein DSCP ist deshalb keine Ende-zu-Ende-Quittung für Dienstgüte.

Das Ethernet Sub-Data Item ergänzt VLAN und Priority Code Point. Eine VID von null lässt die VLAN-Dimension außer Betracht, der reservierte Höchstwert ist unzulässig, und explizite VLAN-Zuordnungen werden vor der Standardzuordnung betrachtet.

Trifft ein Paket gleichzeitig auf Diffserv- und Ethernet-Regeln, verlangt RFC 9892 den Vorrang der Ethernet-VLAN/PCP-Information. Die Aussage „DSCP getroffen“ kann also als Beobachtung wahr und als Erklärung der ausgewählten FID falsch sein.

Eine prüfbare Entscheidung bewahrt alle Match-Kandidaten, das Ergebnis der satzweiten Validierung, den expliziten oder Wildcard-Pfad und die angewandte Vorrangregel. Das endgültige Label mag für die Weiterleitung genügen. Für Rechenschaft genügt es nicht.

Die nutzende Erweiterung besitzt die nächste Semantik

RFC 9892 sagt ausdrücklich, dass seine Formate zum Einsatz kommen, wenn eine Erweiterung sie benötigt. Der Klassifikator löst für sich allein keine allgemeine Aktion aus. Ohne ausgehandelten Verbraucher bleibt ein formal gültiger Satz eine Beschreibung ohne zugewiesene Behandlung.

RFC 9894 liefert mit der Diffserv Aware Credit Window ein Beispiel. Teilnehmer müssen die Unterstützung bei der Initialisierung bekannt geben. Wer die Erweiterung implementiert, muss außerdem die erforderlichen Nachrichten, Data Items und Verfahren aus RFC 9892 und RFC 9893 beherrschen. Ohne Unterstützungsanzeige des Peers dürfen die betreffenden Daten nicht wie ausgehandelte Steuerung versandt werden.

RFC 9893 definiert gesondert ein Credit Window Association Data Item. Es bindet TIDs an ein DLEP-Ziel und ein Credit Window. Eine TID nimmt nicht schon wegen ihrer Existenz am Verfahren teil, sondern erst durch diese Zuordnung. Überschneidende TIDs in verschiedenen Fenstern sind ein Fehler.

Hier verläuft die Grenze zur früheren Leadership-Alliance-Analyse über RFC 9893. Dort ging es um die Frage, warum eine Credit Window Grant eine Sendeerlaubnis, aber kein Nachweis der Zustellung über den angeschlossenen Link ist. Der vorliegende Text bleibt eine Stufe davor: Welcher Klassifikationssatz war gültig, welche Regel gewann, und welche Erweiterung machte die FID zum Steuereingang?

Danach folgen noch Installation, Auswahl von Warteschlange oder Fenster, Annahme eines konkreten Pakets, gegebenenfalls Belastung des Guthabens, Übertragung, entfernter Empfang und Anwendungsergebnis. Keine Stufe erbt automatisch den Beweiswert ihrer Vorgängerin.

Ein authentischer Absender kann eine falsche Regel senden

RFC 9892 warnt, dass ein Angreifer, der sich als DLEP-Peer ausgibt, einen anderen Klassifikator einschleusen könnte. Dadurch ließe sich die Zuordnung von Verkehr zu Warteschlangen ändern und Verzögerung, Überlastung oder Verlust verursachen. Transport- oder Layer-2-Schutz aus RFC 8175 kann Fälschung und Manipulation erschweren.

Authentisierung beantwortet jedoch nur, wer die Nachricht sandte. Sie belegt weder, dass die Policy sachgerecht war, noch dass der Router korrekt validierte, Hardwarezustand installierte oder ein bestimmtes Paket wie vorgesehen behandelte. Herkunft und Wirkung gehören in getrennte Nachweisspalten.

Eine belastbare Akte bewahrt Peer-Identität, Sitzung, Nachrichtenhash und Validierungsergebnis. Daran schließen sich ausgewählte FID, nutzende Erweiterung, Ziel, Sollzustand, beobachteter Zustand, Zähler, Linkübertragung und entferntes Ergebnis an. Fehlt ein Übergang, kann ihn der Erfolg davor nicht ersetzen.

In Realitätsschichten und symbolischer Macht beschreibt Heng Lu, wie ein Begriff Macht gewinnt, indem er Vorgänge vereinnahmt, die er nicht beobachtet hat. Wenn klassifiziert zugleich empfangen, gültig, zugeordnet, installiert und zugestellt heißen soll, wird eine lokale Bezeichnung zur unberechtigten Gesamtaussage.

Der Klassifikator benannte den Datenstrom. Vertrauenswürdig wird der Datensatz erst, wenn er ebenso genau festhält, was dieser Name nicht bewies.

Quellen