Zusammenfassung

  • RFC 9895 ist ein IETF-Standards-Track-Dokument für die IEEE-802.1Q-Aware-Credit-Window-Erweiterung von DLEP, mit gemeinsamen und zielbezogenen Fenstern.
  • Treffen Diffserv- und Ethernet-Klassifikatoren beide zu, hat nach RFC 9892 Ethernet Vorrang; DSCP allein erklärt dann nicht das gewählte Kreditfenster.
  • Der Peer muss die Nutzung über Extensions Supported anzeigen; der Extension Type ist 5.

Die Erweiterung verbindet die Verkehrsklassifizierung aus RFC 9892 mit der Kreditsteuerung aus RFC 9893. Logische Fenster werden DLEP-Zielen, VLAN-Kennungen und IEEE-802.1Q-PCP-Werten zugeordnet. Die Anzeige ist eine verpflichtende Abhängigkeitskette: Eine Implementierung, die die Erweiterung anbietet, muss die zugehörigen Nachrichten und Data Items aus RFC 9892 und RFC 9893 sowie Ethernet-Klassifizierung und -Verarbeitung unterstützen. DLEP selbst bildet dabei die Grundlage in RFC 8175.

Fenster können gemeinsam oder zielbezogen sein. Modems sollten eine Konfiguration von PCP zu Fenster unterstützen und dürfen zusätzlich eine PCP-Zuordnung pro VLAN anbieten. Werden VLANs ohne PCP unterstützt, sollte eine konfigurierbare VLAN-zu-Fenster-Zuordnung vorhanden sein. Die RFCs legen jedoch kein einziges universelles VLAN/PCP-Design fest.

Die VID-Semantik ist nicht nebensächlich: VID null bedeutet, dass die VID ignoriert wird; 0xFFFF ist reserviert; für die Klassifizierung verwendbar sind 0x0001 bis 0xFFFE. Ein PCP- oder VID-Wildcard kann unerwartete oder neu auftretende Flüsse erfassen und wird nur empfohlen, wenn es klar erforderlich ist. Meldet ein Peer mehr Fenster, als der Router unterstützt, soll der Router eine unterstützte Teilmenge verwenden oder darf die Sitzung zurücksetzen; die Abweichung ist über die üblichen Managementmechanismen zu melden.

Sind Fenster aktiv, darf der Router keinen Verkehr ohne ausreichende Credits senden. Eingespeistes Vergrößern oder Verändern von Fenstern kann einen Denial-of-Service verursachen. Die Quellen belegen weder Einsatzverbreitung noch gemessene Leistungsgewinne. Sie schreiben außerdem keine Warteschlangenanzahl, keinen Telemetrieschwellenwert, keinen Rollback-Timer, keine CLI und kein YANG-Modul vor. Die Vertrauensgrenze für VLAN- und PCP-Markierungen zwischen Verwaltungsdomänen bleibt eine Betreiberentscheidung.

Konkrete Prüf-Fixtures

  1. Sende ein Paket mit bekanntem DSCP, gültiger VID und bekanntem PCP. Prüfe, dass der Klassifizierer Ethernet auswählt und das Ethernet-Fenster belastet, nicht das Diffserv-Fenster.
  2. Prüfe VID null, 0xFFFF sowie 0x0001 bis 0xFFFE, jeweils mit explizitem und fehlendem PCP, und verifiziere Ignorieren, Reservierung und gültigen Bereich.
  3. Zeige Extension Type 5 an und prüfe die Unterstützung aller erforderlichen RFC-9892/9893-Nachrichten und Data Items. Wiederhole den Test mit mehr angekündigten Fenstern, als der Router tragen kann.
  4. Prüfe ein gemeinsames und ein zielbezogenes Fenster, PCP-zu-Fenster, die optionale PCP-Zuordnung pro VLAN sowie VLAN ohne PCP.
  5. Aktiviere PCP- und VID-Wildcards nur im Test, beobachte neue Flüsse, injiziere eine Fensteränderung und verifiziere sowohl die Sendesperre bei fehlenden Credits als auch die Begrenzung des DoS-Effekts.

Entscheidungsweg für Betreiber

Zuerst Markierungsvertrauen und Verwaltungsgrenzen festlegen. Danach Peer-Anzeige und den vollständigen RFC-9892/9893-Abschluss prüfen, Sonderwerte testen und gemeinsame oder zielbezogene Fenster auswählen. Anschließend Zuordnungen definieren und den Konflikt zwischen DSCP und Ethernet nachstellen. Bei Überlast der Router-Fähigkeiten die unterstützte Teilmenge verwenden oder den Sitzungsreset gemäß Standard zulassen. Senden erst freigeben, wenn die Credit-Bedingung nachgewiesen ist.

Quellen