Zusammenfassung

  • RFC 3290 stellte die Diffserv-Behandlung innerhalb eines Routers als zusammenhängenden gerichteten azyklischen Graphen funktionaler Elemente dar. So konnten Managementsysteme Klassifizierung, Messung, Markierung, Warteschlangen, Scheduling und Verwerfen beschreiben.
  • Der Graph war bewusst ein Informationsmodell: Er erleichterte die Beschreibung des Verhaltens, schrieb aber keine Implementierung vor und bewies nicht, dass ein Paket den zugesagten Dienst erhielt.

Ein Codepunkt ist erst der Anfang des Pfads

Der DSCP im Paketkopf ist leicht zu finden. Aus diesem sechs Bit breiten Wert allein lässt sich jedoch nicht ableiten, was ein bestimmter Router als Nächstes tut. Er kann einem Behavior-Aggregate-Klassifizierer bei der Wahl eines Zweigs helfen; danach wirken weiterhin Filter, Messer, Markierungs- oder Verwerfungsaktionen, Warteschlangen und Scheduler.

RFC 3290, das Diffserv Informal Management Model, machte diesen Unterschied sichtbar. Das Informational RFC von 2002 beschrieb Verkehrsbehandlung und Warteschlangenverhalten eines Routers als gerichteten azyklischen Graphen funktionaler Datenpfadelemente. Ein Klassifizierer kann einen Strom aufteilen; ein Messer kann Pakete je nach Konformität auf verschiedene Ausgänge verteilen; nachfolgende Aktionen markieren, zählen, verwerfen oder multiplexen; Warteschlangen und Scheduler beeinflussen Abgang und Verlust.

Die Erklärungseinheit ist also die Zusammensetzung. Der DSCP kann einem BA-Klassifizierer bei der Zweigwahl helfen, während ein anderer Klassifizierer weitere Paketfelder auswertet. Ausgänge eines Messers können zu unterschiedlichen Entscheidungen über Markierung, Warteschlange oder Verwerfen führen. Die endgültige Behandlung hängt von verbundenen Funktionen und Parametern ab, nicht vom Etikett allein.

RFC 3290 fasste Elemente niedriger Ebene außerdem zu Traffic Conditioning Blocks (TCBs) zusammen. Administratoren konnten solche Blöcke am Ein- oder Ausgang einer Schnittstelle betrachten und seriell oder parallel verbinden. Ein TCB war eine Managementhilfe – eine logische Blackbox mit einem Eingang und einem oder mehreren Ausgängen –, keine Behauptung über eine einheitliche physische Routerarchitektur.

Eine Managementkarte, kein Bauplan für Silizium

Diese Grenze ist der wichtigste Vorbehalt des RFC. Das Modell war eine Abstraktion für Konfigurations- und Managementwerkzeuge wie SNMP oder andere Policy-Schnittstellen. Es sollte Routerimplementierungen weder einschränken noch vorschreiben. Eine logische Warteschlange oder ein Messer muss keinem einzelnen physischen Bauteil entsprechen.

Die Abstraktion macht unterschiedliche Geräte vergleichbar, lässt aber Fragen offen. RFC 3290 behandelt den Routingkern als idealisierte Verbindung; reale Verzögerung, Verluste und Überlast des Switching-Fabrics müssen an anderer Stelle modelliert werden. Warteschlangenparameter beschreiben logisches Verhalten, nicht die Puffer eines Geräts. Der Graph kann die konfigurierte Behandlung darstellen, aber nicht allein belegen, dass sie korrekt im Forwarding-Pfad installiert wurde oder was bei Überlast geschah.

Die Darstellung von Messern zeigt das gut. In der Diffserv-Architektur kann ein Messer den Verkehr beobachten und einem Aktionselement ein Steuersignal senden. RFC 3290 zeichnet es stattdessen als logische 1-zu-N-Verzweigung im Datenpfad, deren Konformitätsausgänge jeweils mit dem nächsten Element verbunden sind. Laut den Autoren ändert diese andere Beschreibung die Funktion nicht. Sie erleichtert jedoch die Zusammensetzung des Pfads und erinnert daran, dass Modellverbindungen nicht zwingend Implementierungsschaltungen sind.

RFC 3444 unterschied später deutlicher zwischen abstrakten Informationsmodellen und konkreten Datenmodellen, die sie für bestimmte Managementprotokolle kodieren. So gelesen bietet RFC 3290 gemeinsame Begriffe und Strukturen, aber keine Konstruktionsvorschrift für die Paketverarbeitung.

Was der Graph belegt – und was nicht

Der Graph hilft, die vorgesehenen Beziehungen zwischen Klassifizierung, Behandlung und Warteschlangen zu prüfen sowie Parameter, Zähler und Managementobjekte zuzuordnen. Er macht Policy-Komposition überprüfbar: Ein „out-of-profile“-Zweig hat erst dann operative Bedeutung, wenn das nächste Element und das endgültige Warteschlangen- oder Verwerfungsverhalten bekannt sind.

Ein konfigurierter Graph ist aber nur eine Beweisebene. Für den tatsächlich erbrachten Dienst braucht es außerdem die gerätespezifische Konfigurationsauslese, das Implementierungsverhalten, Zähler oder Paketbeobachtungen und Messungen an der Dienstgrenze. Ein DSCP verspricht keine Latenz; der Name eines PHB misst keine Warteschlangentiefe; ein Managementmodell beweist nicht, dass ein Scheduler unter Last wie beabsichtigt gearbeitet hat.

RFC 3290 bleibt nützlich, ohne als universeller Routerentwurf missverstanden zu werden. Es beschreibt die Behandlungslogik zwischen Paketmarkierung und Abgang. Es reduziert diese Logik weder auf das Markierungsfeld noch macht es aus einer Absichtsskizze einen Nachweis gelieferter Leistung.

Quellen