Zusammenfassung

  • RFC 9504 unterscheidet Fähigkeit, Zustandsabgleich, Aktualisierung und Initiierung. Ein Eintrag auf einer dieser Ebenen beantwortet nicht die Fragen der anderen.
  • Die Delegierung erlaubt dem PCE begrenzte Attributänderungen für benannte LSPs; Eigentum am Zustand, lokale Policy und Rücknahme bleiben beim PCC.

Es gibt in Steuerungsarchitekturen eine sprachliche Abkürzung mit hohem Preis. Sobald ein LSP als delegiert erscheint, wird aus einer eng beschriebenen Berechtigung die Behauptung, der PCE habe das Netz übernommen. Die technische Präzision der RFCs spricht gegen diese Abkürzung.

RFC 9504 erlaubt es, die zustandsbehafteten PCEP-Mechanismen in GMPLS-kontrollierten Netzen zu benutzen. PCE und PCC können Fähigkeiten ankündigen, LSP-Zustand abgleichen, Attributänderungen anfordern und die Einrichtung eines LSP anstoßen. Das macht Steuerungsabläufe sichtbar. Es hebt aber nicht die Grenzen zwischen einer Protokollnachricht, einer lokalen Entscheidung und einem tatsächlichen Zustand von Ressourcen oder Geräten auf.

Schon die Fähigkeit ist nur eine Zutrittsbedingung. Für die einschlägigen GMPLS-Funktionen müssen beide Seiten Unterstützung und Erlaubnis signalisieren. Damit ist gesagt, dass ein Austausch stattfinden darf. Nicht gesagt ist, dass eine knappe Ressource verfügbar ist, dass eine Policy die konkrete Änderung zulässt, dass ein Cross-Connect geschaltet wurde oder dass ein Forwarding-Pfad existiert. Auch die IANA-Registrierung von PCEP-Nummern dokumentiert Bezeichner, nicht die Nutzung eines Bezeichners in einer bestimmten Betriebsumgebung.

Der Zustand hat eine eigene Zuständigkeit. Nach RFC 8231 muss ein zustandsbehafteter PCE den LSP-Zustand des PCC kennen, bevor er rechnet oder Attribute aktualisiert. Ein State Report berichtet eine Veränderung; ein Update Request fordert eine Veränderung an. Delegierung gibt dem PCE das Recht, Attribute bestimmter LSPs zu aktualisieren, solange diese Delegierung besteht. Der PCC bleibt jedoch Eigentümer des Zustands, unterwirft Attribute seiner lokalen Policy und kann die Delegierung zurücknehmen. Die Rücknahme ist kein Randfall, sondern beweist, dass die Zuständigkeit nicht verschwunden ist.

Auch PCInitiate sollte wörtlich gelesen werden. RFC 8281 beschreibt einen PCE-initiated LSP als LSP, der infolge einer PCE-Anforderung instanziiert wird; die Nachricht stößt am Endknoten die Einrichtung an. Damit ist der Beginn einer Kette beschrieben. Akzeptanz, Ressourcenreservierung, Gerätekonfiguration, installierter Pfad und beobachteter Verkehr sind weitere, eigenständige Tatsachen. Ein Bericht über beabsichtigte und tatsächliche Pfadinformationen in RFC 9504 ist nützlich, ersetzt aber keine Messung von Kundenwirkung oder Dienstverfügbarkeit.

Die belastbare Darstellung ist daher eine Kette, kein Etikett: erlaubte Fähigkeit, bekannter Zustand, konkrete Delegierung, Anforderung, lokale Policy-Entscheidung, Ressourcen- und Geräteaktion, installierter Zustand und unabhängige Beobachtung. Jede Stufe kann die nächste prüfbar machen. Keine darf die nächste stillschweigend behaupten.

Das folgt einer praktischen Lesart von Heng Lus minimaler Anfangsspezifikation. Die gemeinsame Schicht soll den kleinsten interoperablen Sachverhalt festlegen; die Entscheidung über Annahme und Folgen bleibt dort, wo sie getragen wird. Laufender Code ist ein wichtiger Nachweis für eine funktionierende Mechanik. Er ist kein Ersatz für die Zuordnung von Verantwortung.

Eine Führungskraft sollte deshalb nicht nach einer großen Controller-Zusage fragen, sondern nach der Beweiskette: Welches Attribut, welcher PCC, welche Policy, welcher Gerätebeleg und welche Beobachtung stützen die jeweilige Aussage? So bleibt Automatisierung schnell und ihre Reichweite prüfbar.

Quellen