Zusammenfassung

  • RFC 9892 ist eine IETF-Spezifikation auf dem Standards Track. Sie definiert ein erweiterbares DLEP Traffic Classification Data Item mit anfänglichen Diffserv- und Ethernet-Sub-Data-Items.
  • Eine TID bezeichnet einen modemlokalen Klassifikationssatz; FIDs kennzeichnen Flows innerhalb eines Sub-Data-Items. Die Zielzuordnung und die operative Verwendung liefert die konsumierende Erweiterung.
  • Ein empfangener TID initialisiert oder ersetzt die zugehörige Klassifikationsinformation. Die Formate selbst legen jedoch weder Scheduler, Queue-Gewichte, Admission Policy noch einen Credit-Window-Algorithmus fest.

Der Mechanismus

DLEP kann auf Ebene der Endpunkte identifizieren. RFC 9892 ergänzt diese Sicht um die Möglichkeit, dass ein Modem dem Router mitteilt, wie Datenebenen-Kennungen zu Flows gruppiert werden. Die Traffic Classification Identifier, kurz TID, ist dabei ein modemlokaler Name für einen Klassifikationssatz. Sie ist kein automatisch global eindeutiger Vertrag. Flow Identifiers, FIDs, benennen die Flows innerhalb des jeweiligen Sub-Data-Items.

Welche Zieladresse ein TID betrifft und welche operative Bedeutung seine FIDs erhalten, bleibt der konsumierenden, ausgehandelten Erweiterung überlassen. RFC 9892 stellt dafür die Datenstruktur bereit; es entscheidet nicht selbst, welche konkrete Datenpfadaktion folgt. Sobald ein TID mit Klassifikationsinformation empfangen wird, initialisiert oder ersetzt er die zugehörige Information. Der Router muss den verwandten Datenpfadstatus bei Bedarf aktualisieren. Das ist als Ersetzung des zugehörigen Satzes zu behandeln, nicht als stillschweigend erlaubtes Zusammenführen alter und neuer Einträge.

Im Diffserv-Sub-Data-Item gruppieren FIDs DSCP-Werte. Eine Anzahl von null ist ein Wildcard für sonst nicht zugeordnete DSCP-Werte. Im Ethernet-Sub-Data-Item gruppieren FIDs VLAN/PCP-Werte; eine PCP-Anzahl von null liefert den Default-Treffer. Innerhalb eines einzelnen Traffic Classification Data Items sind doppelte DS-Field-Werte Fehler. Ebenso sind doppelte Prioritäten innerhalb eines einzelnen Data Items Fehler. Die Prüfung muss sich auf das vollständige Data Item beziehen, nicht nur auf einen gerade verarbeiteten Teil.

Bei einem gleichzeitigen Treffer beider Klassifikatorarten gewinnt Ethernet VID/PCP; die TID dieses Ethernet-Treffers ist zu verwenden. Bei Ethernet werden explizite VLAN-Treffer vor dem PCP-Default berücksichtigt. Der Wildcard- oder Default-Fall ersetzt also keinen expliziten Treffer. Diese Vorrangregel ist eine Klassifikationsregel, nicht die Aussage, dass DSCP generell unwichtig wäre.

Die normative Grenze

RFC 9892 definiert keinen Scheduler, keine Queue-Gewichte, keine Admission Policy und keinen Credit-Window-Algorithmus. RFC 9893 kann als Beispiel für eine Erweiterung mit Credit-Window-Kontrolle dienen, gehört aber nicht zum Mandat von RFC 9892. Ebenso belegen die Quellen weder die Verbreitung einer Bereitstellung noch gemessene Performance noch eine Produktions-Warteschlangenpolicy.

Künftige Klassifikatortypen, etwa Five-Tuples, sind Beispiele für Erweiterbarkeit und keine Definitionen dieses RFC. Zielzuordnung und operative Bedeutung eines TID bleiben erweiterungsspezifisch. Die Quellen belegen außerdem nicht, dass DSCP-Markierungen über administrative Grenzen hinweg Ende zu Ende vertrauenswürdig sind. Eine Markierung ist daher nicht automatisch eine belastbare Identität oder Autorisierung.

Ein böswilliger Peer, der die Zuordnung von Klassifikation zu Warteschlange verändert, kann Verzögerung, Überlast oder Verlust in Serviceklassen auslösen. RFC 9892 definiert dafür kein neues Ende-zu-Ende-Vertrauensmodell, sondern verweist auf geeignete DLEP-Transport- und Link-Security im Rahmen des DLEP-Baselines. Solche Maßnahmen dürfen deshalb nicht als umfassende End-to-End-Vertrauensgarantie dargestellt werden.

Analyse von Theo March

Die folgenden Vorschläge sind Analyse von Theo March und keine Anforderungen aus RFC 9892. Ein Betreiber sollte einen Audit-Trail führen, der DLEP-Sitzung und Peer, Zeitpunkt, TID, Data-Item-Version, Validierungsergebnis und konsumierende Erweiterung miteinander verbindet. Für jeden Ersatz sollte ein Rollback-Punkt mit dem vorherigen Zustand bestehen. Alte Daten sollten nicht allein wegen ihrer Form erneut angewendet werden, ohne Sitzung, Reihenfolge und Gültigkeit zu prüfen.

Queue-Telemetrie kann diese Analyse unterstützen: Latenz, Verlust, Belegung und Klassifikationsentscheidungen lassen sich vor und nach einem Update vergleichen. Das beweist keine Kausalität und macht aus einer RFC-9892-Klassifikation keine Scheduler-Policy. Ebenso sollte das Vertrauen in Markierungen zwischen Verwaltungsdomänen als eigene Governance-Frage behandelt werden.

Entscheidungsweg für den Betrieb

  1. Prüfen, ob eine DLEP-Erweiterung ausgehandelt ist, die TID/FID verlangt und interpretiert; Zielzuordnung und Verwendungszweck dokumentieren.
  2. Das vollständige Data Item validieren: doppelte DS-Field-Werte und doppelte Prioritäten ablehnen, Wildcards korrekt erfassen und die Version protokollieren.
  3. Die Trefferentscheidung nachvollziehen: DSCP und VLAN/PCP prüfen, bei Doppelmatch Ethernet VID/PCP priorisieren und die verwendete TID ausweisen.
  4. Die tatsächliche Datenpfadaktion der Erweiterung identifizieren. Keine Queue-Gewichte, Schedulerregeln oder Credit-Window-Algorithmen RFC 9892 zuschreiben.
  5. DLEP-Transport- und Link-Security prüfen und die Vertrauensgrenze bei administrativen Übergängen bewerten, ohne ein Ende-zu-Ende-Versprechen zu erfinden.
  6. Bei fehlerhafter Validierung oder unerwarteten Effekten die alte, nachweisbar passende Version wiederherstellen und den Vorfall im Audit-Trail markieren.

Konkrete Prüfungs-Fixtures

  • Diffserv-Fixture: Ein FID enthält eindeutige DSCP-Werte und zusätzlich eine DSCP-Anzahl von null. Erwartung: nicht anderweitig zugeordnete Werte treffen den Wildcard-Fall.
  • Ablehnungs-Fixture: Derselbe DS-Field-Wert erscheint zweimal in einem Data Item. Erwartung: vollständige Validierung schlägt fehl.
  • Ethernet-Fixture: Explizite VLAN/PCP-Werte werden zusammen mit PCP-Default geliefert. Erwartung: explizite Werte werden zuerst getroffen, der Default nur bei fehlendem spezifischem Treffer.
  • Vorrang-Fixture: Ein Paket erfüllt DSCP und VLAN/PCP. Erwartung: Ethernet VID/PCP gewinnt und die Ethernet-TID wird protokolliert.
  • Ersatz-Fixture: Unter derselben TID wird erst Satz A, dann Satz B übertragen. Erwartung: Satz B ersetzt die zugehörige Klassifikationsinformation; ein nicht spezifiziertes Mischen wird nicht unterstellt.

Die Fixtures prüfen Protokollgrenzen, nicht Produktionsleistung oder eine konkrete Schedulerpolitik.

Quellen