Zusammenfassung

  • RFC 9753 handelt die Nutzung der vorhandenen P- und I-Bits im Objektheader für Stateful PCEP aus. Ein unbekanntes Objekt mit gelöschtem P darf ignoriert werden, während die Nachricht weiterverarbeitet wird.
  • Fortsetzung, I-Anzeige und PCRpt sind begrenzte Protokollbelege. Sie beweisen weder erhaltene Semantik noch Pfadgleichwertigkeit, Hardwareprogrammierung oder sicheren Paketlauf.

Die folgenreichste Änderung kann ohne Fehlermeldung enden. Ein PCC meldet einen LSP mit mehreren beabsichtigten Attributen. Ein Objekt enthält eine Bedingung, die nur der neuere Peer kennt. Die lokale Richtlinie des Senders hat P gelöscht. Der Empfänger überspringt das Objekt, verarbeitet den Rest und hält die Sitzung offen. Kein Pflichtobjekt fehlt, die Nachricht ist gültig, und der Ablauf entspricht RFC 9753.

Nicht die Nachricht ist verloren gegangen, sondern ein Teil ihrer Bedeutung.

RFC 9753 wurde im April 2025 als IETF-Standards-Track-Dokument veröffentlicht und aktualisiert RFC 8231. RFC-Editor-Datensatz und Datatracker belegen Identität und Status. Das Dokument macht ausgewählte Objekte in PCRpt, PCUpd und PCInitiate optional verarbeitbar, damit ein Fähigkeitsunterschied nicht stets den gesamten Vorgang beendet.

RELAX vereinbart eine Grammatik, keine gemeinsame Richtlinie

Im Basis-PCEP von RFC 5440 ist P die Processing Rule; I zeigt an, dass ein optionales Objekt ignoriert wurde. RFC 8231 verlangte für Stateful-Objekte P=0 und I=0. RFC 9753 ergänzt R, RELAX, im STATEFUL-PCE-CAPABILITY TLV. Das IANA-PCEP-Register führt RELAX als Bit 17.

PCE und PCC müssen R setzen. Wer R nicht angekündigt hat, ignoriert gesetzte P/I-Bits nach der alten Regel. Beidseitiges R belegt damit nur die Bereitschaft, diese Grammatik in der Sitzung anzuwenden. Es belegt keine gemeinsame Liste optionaler Objekte, keine gleiche Richtlinienversion und keine einheitliche Bewertung von Verzögerung, Bandbreite, Affinität oder Schutz.

Der RFC empfiehlt P=1 als Standard. P darf aufgrund lokaler Konfiguration oder Richtlinie gelöscht werden, wenn die zugehörige Bedingung verzichtbar ist oder das Objekt sicher ignorierbare Information enthält. Das Protokoll entdeckt Harmlosigkeit nicht; eine lokale Stelle entscheidet darüber.

Der Geltungsbereich ist das ganze Objekt

P und I greifen nicht nur auf einen unbekannten optionalen TLV innerhalb eines Objekts zu. Sie gelten für das gesamte PCEP-Objekt. Ein prüfbarer Datensatz braucht Klasse, Typ, Nachricht, Richtung, SRP oder Request, LSP, Richtlinienversion und Byte-Hash. Sonst kann ein Team annehmen, nur ein unbekanntes Detail sei entfallen, obwohl der gesamte Träger einer Bedingung aus der Entscheidung entfernt wurde.

Pflichtobjekte bleiben Pflicht. Für PCRpt nennt RFC 9753 LSP und den beabsichtigten ERO; für PCUpd und PCInitiate aus RFC 8281 SRP, LSP und ERO. Ist P dort fälschlich gelöscht, ist PCErr Error-Type 10, Error-value 1 erforderlich.

Bei anderen Objekten verzweigt die Verarbeitung. Ist P=1 und der Empfänger versteht oder unterstützt das Objekt nicht, muss die gesamte Stateful-Nachricht mit Unknown Object oder Not supported object abgelehnt werden. Bei P=0 darf er es ignorieren und fortfahren. „Kein Fehler“ kann daher vollständiges Verständnis oder erlaubten Verlust bedeuten. Eine Erfolgsquote trennt beides nicht.

Delegation verschiebt die Änderungsbefugnis

In PCRpt bestimmt P, was der PCE bei Zustandspflege, Berechnung oder Neuoptimierung berücksichtigen muss. In PCUpd und PCInitiate bestimmt P, was der PCC beim Pfadaufbau berücksichtigen muss. RFC 8051 liefert den Anwendungskontext; RFC 8231 belässt die LSP-Zustandseigentümerschaft beim PCC und unterstellt PCE-Attribute dessen lokaler Richtlinie.

Während einer Delegation kann der PCE gemäß RFC 9753 die Behandlung ändern: Er kann ein zuvor vom PCC mit P versehenes Objekt als ignoriert markieren oder ein zuvor optionales Objekt verlangen. Der PCC muss diese Erwartung in PCRpt bestätigen oder die Regeln für eine nicht akzeptable Aktualisierung anwenden.

Das letzte P-Bit erzählt diese Geschichte nicht. Nötig sind Delegationsinhaber, Sitzungsgeneration, SRP/Request, Objekt, Werte vor und nach der Änderung, freigebende Richtlinie und Antwort des PCC.

I meldet Verarbeitung, nicht Erfüllung

Ein PCE darf ein ignoriertes optionales Objekt in PCUpd wiedergeben und I setzen. Ein PCC darf dies in einem PCRpt als Antwort auf PCUpd oder PCInitiate tun. I=0 bedeutet, dass der Peer das Objekt nach eigener Aussage verarbeitet hat. Ohne korrelierendes SRP hat I in PCRpt jedoch keine Bedeutung; in PCInitiate muss I null sein.

Auch im richtigen Kontext heißt verarbeitet nicht erfüllt. Ein Parser kann das Objekt erkennen, ein Richtlinienmodul es lesen und dennoch kann eine andere Bedingung die Auswahl bestimmen. Ein PCC-Zustandsbericht ist außerdem keine unabhängige Abfrage der Forwarding-Hardware.

Das Beispiel von RFC 9753 zeigt die semantische Ausgabe. PCRpt kann beabsichtigte und tatsächliche Attributlisten tragen. Ein METRIC-Objekt kann nach RFC 8233 eine Obergrenze für Path Delay Variation setzen. Ist kein passender Pfad vorhanden, kann Optionalität vernünftig sein. Ein anschließender Erfolg erhält aber die ursprüngliche Grenze nicht. Belegt werden müssen Wert und Einheit, Ignore-Entscheidung, Neuberechnung, tatsächlicher Pfad und Verkehrsmessung.

Der Zustandsbericht endet vor der Weiterleitung

RFC 8231 beschreibt die Anfangssynchronisation als Zeitpunkt-Replik des PCC-LSP-Zustands beim PCE. PCRpt kann Pfad, Bandbreite sowie Betriebs- und Verwaltungsstatus melden. Zwischen Bericht und Paket liegen lokale Richtlinie, Signalisierung, Ressourcenaufnahme, RIB- oder Labeltabellen-Auswahl, Next-Hop-Auflösung und Hardwareprogrammierung.

Diese Grenze trennt den Gegenstand von RFC 9757 über zentrale Native-IP-Anweisungen und RFC 9826 über das PCEP-YANG-Modell. Eine vollständige Steuerungs- oder Managementsicht ist weiterhin kein unabhängiger Zeuge für Forwarding.

RFC 9753 empfiehlt die Aktivierung nur auf authentisierten, verschlüsselten Sitzungen unter derselben administrativen Hoheit, mit PCEPS nach RFC 8253 und der TLS-Praxis aus RFC 9325. Das schützt Kanal und Peeridentität; die Bedeutung oder Richtigkeit der Optionalitätsrichtlinie wird dadurch nicht authentisiert.

Implementierungen sollen RELAX und zugehörige optionale Bedingungen konfigurierbar und sichtbar machen. Der RFC fügt keine neuen Anforderungen zur Betriebsprüfung hinzu. Das begrenzt den Standard, nicht die Nachweispflicht eines Dienstes.

Heng Lus Reality Layers dienen als offengelegte redaktionelle Linse: ausgehandeltes Symbol, angenommene Operation, dargestellter Zustand, umgesetzte Programmierung und beobachtetes Ergebnis sind verschiedene Tatsachen. Ein belastbares Register verbindet Peer/Sitzung, beidseitiges R, Nachricht/Objekt, Senderrichtlinie, Parser, Ignore/Fehler, verlorene Bedeutung, Neuberechnung, PCE/PCC-Abgleich, Gerätezustand, Verkehr und Rollback.

Quellen

Der technische Bestand umfasst RFC 9753, den RFC-Editor-Datensatz, den Datatracker, IANA PCEP, RFC 5440, RFC 8231, RFC 8281, RFC 8051, RFC 8233, RFC 8253, RFC 9325, den benachbarten RFC 9757 und RFC 9826. Es werden keine Hersteller, Implementierungen, Einsätze, Vorfälle, Interoperabilitätstests oder Adoptionsraten behauptet.