Zusammenfassung

  • RFC 3317 ließ ein DiffServ-Gerät vor der Policy-Installation unterstützte Funktionen, Richtungen, Warteschlangen, Scheduler-Grenzen, maximale Kettentiefe und zulässige Elementverbindungen melden.
  • Diese Meldung grenzte den Entwurf ein, garantierte aber nicht den vollständigen Graphen: Eine nicht realisierbare Policy musste der PEP ablehnen, und Installation allein bewies keine Paketbehandlung.

Ein Controller kann eine Kette beliebig verlängern. Hardware kann das nicht. RFC 3317 machte deshalb die maximale Zahl aufeinanderfolgender Verarbeitungselemente zu einer meldefähigen Geräteeigenschaft. Ebenso wichtig war die Frage, welcher Elementtyp auf welchen folgen durfte.

Das 2003 als Informational veröffentlichte Dokument definierte eine Policy Information Base für Differentiated Services. Ein Paket konnte klassifiziert, gemessen, markiert, einem Drop-Algorithmus unterzogen, in eine Warteschlange gestellt und von einem Scheduler weitergegeben werden. Provisioning Classes beschrieben diese Funktionen; konkrete Instanzen konnten etwa mit COPS-PR vom Policy Decision Point zum Policy Enforcement Point gelangen.

Die Grundreihenfolge lautete classifier, meter, action, algorithmic dropper, queue und scheduler. Musste eine Behandlung zu einem früheren Typ zurückkehren, wurde ein weiterer Traffic Conditioning Block kaskadiert. Next-Verweise verbanden die Instanzen. Je nach Klassifikation oder Messergebnis konnte der Pfad verzweigen. Die PIB war damit nicht bloß eine Liste von Einstellungen, sondern eine Darstellung eines gerichteten Verarbeitungsgrafen.

Verdrahtung und Parametrisierung blieben getrennt. Ein Meter konnte auf Token-Bucket-Parameter mit Rate und Burst verweisen, Scheduler auf Mindest- und Höchstraten. Parameter ließen sich wiederverwenden und durch andere PIBs erweitern. Aus der syntaktischen Gültigkeit aller Zeilen folgte jedoch nicht, dass ihre Gesamtheit in die interne Pipeline eines bestimmten Geräts passte.

Darum begann der operative Ablauf mit einer Meldung des PEP. Er teilte dem PDP mit, welche PRCs er verstand, welche Schnittstellentypen und Rollenkombinationen vorhanden waren und welche Capability Sets für Eingangs- oder Ausgangsrichtung galten. Klassifikationsfähigkeiten beschrieben verfügbare Felder; Metering-Fähigkeiten den Umgang mit Verkehr außerhalb des Profils; hinzu kamen Drop-Verfahren, Zahl und Speicher der Queues, Scheduler-Methode und Eingänge sowie Höchstratenstufen.

Die Tabellen für Elementtiefe und Elementverknüpfung legten den Rand des Graphen fest. Ein Gerät konnte jeden benötigten Baustein einzeln besitzen, aber die gewünschte Kante nicht zulassen. Es konnte eine Reihe von vier Stufen verarbeiten, jedoch keine fünfte. Oder ein bestimmter Scheduler konnte nur eine begrenzte Zahl von Eingängen aufnehmen. „Unterstützt“ musste deshalb eine Aussage über Knoten, Kanten, Richtung und Tiefe sein.

Mit diesem Wissen erzeugte der PDP eine Policy für Verwaltungsdomäne, Schnittstellentyp, Rolle und Richtung. Ein Eintrag in dsDataPathTable benannte das erste Funktionselement. Fehlte der Eintrag oder stand dort zeroDotZero, blieb es bei normaler IP-Verarbeitung. Der Ansatz beschrieb Typen statt einzelner physischer Ports und gewann Wiederverwendbarkeit, ohne lokale Ressourcenunterschiede vollständig zu erfassen.

RFC 3317 erklärte die Capability Classes ausdrücklich zu allgemeinen Leitlinien. Sie mussten nicht jede mögliche und unmögliche Konfiguration darstellen. Gemeinsame Puffer, interne Prozessoren oder Wechselwirkungen zwischen Stufen konnten einen formal passenden Graphen immer noch verhindern. Erhielt ein PEP eine nicht implementierbare Policy, musste er dem PDP einen Fehler melden. Die Fehlermeldung war die verbindliche Antwort dort, wo das Näherungsmodell endete.

Damit entstehen getrennte Belege. Eine Capability-Meldung dokumentiert eine allgemeine Selbstauskunft des Geräts. Der kompilierte Graph dokumentiert die Absicht des Controllers. Die COPS-PR-Antwort dokumentiert eine Provisioning-Transaktion. Ein Readback dokumentiert gespeicherten Zustand. Erst eine Beobachtung im Datenpfad kann zeigen, welche Behandlung Pakete tatsächlich erhielten; auch sie beweist noch nicht die vom Kunden wahrgenommene Qualität.

Beide Kommunikationsrichtungen enthielten schützenswerte Information. Installierbare Zeilen konnten Dienstverträge oder Filter offenlegen und bei Manipulation DiffServ-Verhalten verändern. Notify-Zeilen verrieten Geräteeigenschaften. Das RFC verwies auf IPsec zwischen PDP und PEP: Gefälschte Fähigkeiten konnten einen falschen Entwurf provozieren, gefälschte Policies Ressourcen und Prioritäten verschieben.

2016 stufte die IESG RFC 3317, das Framework PIB, COPS-PR und SPPI als Historic ein. Die Begründung nannte begrenzte Verbreitung und den Schwerpunkt der Konfigurationsarbeit auf NETCONF und YANG. Diese spätere Entscheidung begrenzt die historische Aussage: Die detaillierte Spezifikation ist kein Beleg für breite Implementierung. Sie zeigt vielmehr, welche Kontrollfrage eine nicht dauerhaft erfolgreiche Standardsfamilie präzise formulierte.

Zentrale Steuerung braucht eine Grenze, die vom Zielsystem kommt. Das Fähigkeitsmodell soll unrealistische Entwürfe früh aussortieren; der endgültige Fehler muss dennoch erhalten bleiben, weil das Modell nicht alle Kombinationen kennt. Wer nur einen der beiden Belege speichert, macht aus einem Plan entweder blindes Probieren oder eine unbegründete Ausführungsgarantie.

Quellen: RFC 3317, RFC 3318, RFC 3290, RFC 3084, RFC 3159, RFC 2475 und die IESG-Statusänderung von 2016.