Zusammenfassung

  • Eine COPS-PR-DEC-Nachricht war in RFC 3084 eine unteilbare Transaktion. Entweder gelangen alle Installationen und Löschungen, oder der PEP meldete den Fehler und stellte den letzten erfolgreichen Zustand wieder her.
  • Die Erfolgsmeldung bewies keine dauerhafte Übereinstimmung. Während einer Unterbrechung durfte das Gerät seine zwischengespeicherte Policy weiterverwenden; nach der Rückkehr mussten die Request-States synchronisiert oder ihre Gleichheit angenommen werden.

Der Befehl musste in einem anderen System Wirklichkeit werden

Ein PDP sendet in derselben DEC die Löschung eines alten Filters und die Installation seines Nachfolgers. TCP liefert die Nachricht. Der PEP antwortet mit Success. Damit besitzt der Server mehr als einen Sendenachweis: Das Gerät erklärt die Transaktion für ausgeführt.

Der Beleg endet jedoch an dieser Grenze. Der PEP muss die PIB-Instanzen in lokale Queues, Klassifizierer oder Scheduler übersetzen. Ein RPT ist weder ein Paketmitschnitt noch eine Messung der Dienstgüte. Er bestätigt die Handlung des Enforcement Point, nicht automatisch das Ergebnis für die Anwendung.

RFC 3084 erschien im März 2001 und definierte COPS-PR, eine Nutzung des Common Open Policy Service zur Bereitstellung von Policy-Informationen. Ein Policy Decision Point versorgte einen Policy Enforcement Point. Eine Policy Information Base ordnete Klassen und Instanzen; PRI bezeichnete eine Instanz, PRID deren Kennung. Der Mechanismus war nicht auf QoS oder Sicherheit festgelegt und beanspruchte kein universelles Datenmodell.

Damit liegt die Grenze anders als im bereits veröffentlichten Artikel zu RFC 3060. PCIM zeigte, dass ein gemeinsames Informationsschema keinen gemeinsamen Auswertungsalgorithmus garantiert. COPS-PR fragte anschließend, wie eine verstandene Entscheidung installiert, quittiert, gespeichert und nach einer Störung wieder mit dem Server abgeglichen wird.

Atomarität schützte den Austausch einer Policy

Eine DEC durfte mehrere Entscheidungen enthalten. Löschungen standen vor Installationen, um Vorrang innerhalb der Transaktion zu regeln, nicht um zwei unabhängige Zeitphasen zu versprechen. Die gesamte Nachricht musste einen einzigen Ausgang haben. Scheiterte ein Teil, meldete der PEP Failure und kehrte zum Zustand der letzten erfolgreichen DEC zurück.

So sollte die alte Policy nicht verschwinden, wenn ihre Nachfolgerin nicht installiert werden konnte. Jede DEC verlangte ein angefordertes RPT, selbst eine leere Entscheidung. Absicht, Annahme und später beobachtete Wirkung blieben unterscheidbare Nachweise.

Der Text beschrieb zugleich eine Grenze des Rollbacks. Ein unmittelbar angeforderter Fehler besaß noch einen klaren vorherigen Zustand. Eine zuvor erfolgreiche Konfiguration konnte später ausfallen und ein nicht angefordertes Failure erzeugen. Unter solchen asynchronen Bedingungen konnte der richtige Rückkehrpunkt bereits mehrdeutig sein. Der PEP meldete dann eine Störung, ohne die Vergangenheit sicher rekonstruieren zu können.

Versionsunterschiede wirkten je nach Richtung anders

PIBs konnten neue Provisioning-Klassen erhalten. Sendete ein neuer PDP eine unbekannte PRC an einen alten PEP, musste dieser einen Fehler melden und seinen vorherigen guten Zustand wiederherstellen. Traf dagegen ein neuer PEP auf einen alten PDP, erhielt er für die neue Klasse schlicht keine Instanzen. Für veraltete Klassen galten weitere Regeln.

Das begrenzte Schäden, machte die Versionen aber nicht gleich. Eine erfolgreiche Transaktion belegte die tatsächlich verarbeiteten Objekte. Sie bewies nicht, dass beide Seiten dieselben Erweiterungen kannten, dieselben Fähigkeiten besaßen oder dieselben lokalen Mechanismen bauten.

COPS-PR konzentrierte außerdem den Schreibzugriff. Für einen durch Client-Type bezeichneten Policy-Bereich aktualisierte nur ein Server die Konfiguration. Während der Verbindung galt sie sogar gegenüber Änderungen an der lokalen Konsole als gesperrt. Ein einzelner Schreiber reduzierte Konflikte, machte aber die Identität des PDP, die Sitzung und dessen gespeicherten Zustand zu Teilen der Autoritätskette.

Während der Trennung regierte der Cache

Bei Verbindungsverlust versuchte der PEP zuerst den letzten PDP und danach einen konfigurierten Ersatzserver. Bis dahin blieb der aktive Request-State in Kraft. Beim Wiederverbinden konnte LastPDPAddr anzeigen, von welchem PDP die noch gespeicherten Entscheidungen stammten. Der Server durfte mit SSQ eine Synchronisierung anfordern.

Dann musste der PEP die REQ-Nachrichten sämtlicher bekannter Request-States erneut senden. Der PDP löschte bei Bedarf einzelne PRIDs oder Präfixe, bis ein bekannter konsistenter Zustand entstand. Forderte der Server keine Synchronisierung, durfte der Client annehmen, erkannt worden zu sein und einen korrekten Zustand zu besitzen. Diese Annahme war eine Protokollregel, keine unabhängige Messung.

Lokale Änderungen während der Unterbrechung mussten nachgemeldet werden. Blieb die Verbindung länger als die administrativ bestimmte Frist aus, löschte der PEP seine installierten Request-States; der PDP ließ seine zugehörigen Einträge ebenfalls ablaufen. Zwei Ablaufregeln begrenzten verwaiste Autorität, garantierten aber keinen identischen Löschzeitpunkt.

SPPI und spätere PIB-Dokumente erweiterten das Modell um QoS-, Rahmen- und Nutzungsdaten. 2016 stufte die IETF RFC 3084 und verwandte Texte als Historic ein. Die Begründung nannte begrenzte Verbreitung und die Verlagerung der Konfigurationsarbeit zu NETCONF und YANG. Das dokumentiert eine technische Richtung, nicht das Verschwinden jeder Implementierung.

Die bleibende Lehre ist eine Kette getrennter Tatsachen: Absicht des PDP, atomare DEC, RPT, Cache, Resynchronisierung, lokale Installation und Verkehrswirkung. Zuverlässige Übertragung bringt eine Policy zum Gerät. Erst Abgleich und Beobachtung zeigen, welche Policy dort weiterlebt.

Quellen

  1. https://www.rfc-editor.org/info/rfc3084
  2. https://www.rfc-editor.org/rfc/rfc3084.html
  3. https://datatracker.ietf.org/doc/rfc3084/
  4. https://www.rfc-editor.org/errata/rfc3084
  5. https://www.rfc-editor.org/rfc/rfc2748.html
  6. https://www.rfc-editor.org/rfc/rfc2753.html
  7. https://www.rfc-editor.org/rfc/rfc3159.html
  8. https://www.rfc-editor.org/rfc/rfc3198.html
  9. https://www.rfc-editor.org/rfc/rfc3317.html
  10. https://www.rfc-editor.org/rfc/rfc3318.html
  11. https://www.rfc-editor.org/rfc/rfc3483.html
  12. https://datatracker.ietf.org/doc/status-change-copspr-sppi-to-historic/
  13. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  14. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/