Zusammenfassung

  • RFC 9894 ist ein IETF-Standards-Track-Dokument für die DLEP-Erweiterung „Diffserv Aware Credit Window“ mit gemeinsamen und zielbezogenen Flusskontrollfenstern.
  • Die Ankündigung ist eine Zusage für den gesamten Mechanismus aus RFC 9892 und RFC 9893, kein loses Feature-Flag; der Extension-Type-Wert ist 6.
  • Der belastbare Pfad lautet: Peer-Unterstützung prüfen, realisierbare Teilmenge bestimmen, diese verwenden oder bei Unvereinbarkeit zurücksetzen und den Mismatch über die normale Verwaltung melden.

Die eigentliche Zusage

Die Nutzung der Erweiterung wird im Data Item „Extensions Supported“ angekündigt. Ein Teilnehmer darf seine Erweiterungs-Data-Items erst senden, wenn die Peer-Unterstützung in der empfangenen Initialisierungsnachricht vorhanden war. Wer die Erweiterung ankündigt, muss außerdem die einschlägigen Nachrichten, Data Items sowie Diffserv-Klassifizierung und -Verarbeitung aus RFC 9892 und RFC 9893 unterstützen. Diese Abhängigkeit ist obligatorisch: Eine Teilimplementierung von RFC 9894 ohne die nötige Klassifizierungs- oder Kreditfensterbasis genügt nicht.

Die Zuordnung verbindet DLEP-Ziele und DSCP-Werte mit logischen Fenstern. Ein gemeinsames Fenster kann mehreren Flüssen oder Zielen dienen; ein zielbezogenes Fenster beschränkt das Guthaben auf ein bestimmtes Ziel. Ein Wildcard-Geltungsbereich kann vorhandene und künftig auftretende Flüsse erfassen. RFC 9894 empfiehlt deshalb, Wildcards nur bei Bedarf zu verwenden: Eine unerwartete Erweiterung des Bereichs verändert die tatsächlich kreditierte Menge.

Treffen Diffserv- und Ethernet-Klassifizierung beide zu, hat nach RFC 9892 die Ethernet-Klassifizierung Vorrang. Eine DSCP-Tabelle darf diese Vorrangregel nicht übergehen. Sind Kreditfenster aktiv, darf der Router Verkehr ohne verfügbares Guthaben nicht an das Modem senden. „Kein Kredit, kein Senden“ ist eine normative Sendesperre, nicht bloß ein Telemetriehinweis.

Entscheidungsweg für Betreiber

  1. Prüfen und protokollieren, ob der Peer in der Initialisierung Extension Type 6 unterstützt, bevor Erweiterungs-Data-Items aktiviert werden.
  2. Jede DSCP-Zuordnung, jedes Ziel, jeden Wildcard-Bereich sowie jedes gemeinsame oder zielbezogene Fenster gegen die realen Queue- und Kreditkombinationen des Routers halten.
  3. Wenn eine Teilmenge die Ethernet-Priorität und die Kein-Kredit-kein-Senden-Regel korrekt abbildet, nur diese Teilmenge aktivieren und ihre Grenzen dokumentieren.
  4. Wenn die Form nicht abbildbar ist, die Sitzung zurücksetzen und den Mismatch über die üblichen Managementmechanismen melden. Keine stille Nachbildung behaupten.
  5. Mit Prüf-Fixtures testen: Peer ohne Ankündigung, ein DSCP je gemeinsamem und zielbezogenem Fenster, neu auftauchender Wildcard-Fluss, gleichzeitiger Ethernet-/Diffserv-Treffer und ein Paket ohne Kredit. Erwartet werden Unterlassung der Erweiterungs-Data-Items, korrekte Ethernet-Priorität, keine Sendung ohne Kredit und ein sichtbarer Reset- oder Teilmengenstatus.

Bekannte Grenzen des Wissens

Die Quellen belegen weder Verbreitung noch gemessene Leistungsverbesserung und definieren keine universelle DSCP-zu-Fenster-Zuordnung. Sie schreiben auch keine bestimmte Queue-Anzahl, proprietäre CLI, YANG-Module, Telemetrieschwelle oder Rollback-Zeit vor. Ob DSCP-Markierungen über Verwaltungsgrenzen hinweg vertrauenswürdig sind, bleibt eine Betreiberfrage und ist kein Ergebnis von RFC 9894.

Quellen