Extension for Stateful PCE to Allow Optional Processing of Path Computation Element Communication Protocol (PCEP) Objects
updates
- rfc-8231 — Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
Extracted elements (18)
The P and I flags already existed in the PCEP common object header (RFC 5440) for path computation requests but were disallowed in stateful PCEP. Rather than define new flags, this document reuses the existing P and I flags under a new capability negotiation (R flag), keeping the semantics consistent while extending applicability to stateful messages.
The P and I flags apply only to an entire PCEP object; they cannot be applied at the granularity of optional TLVs encoded within a PCEP object. This scope limitation is inherited from RFC 5440 and is explicitly preserved unchanged by this document.
The relaxation mechanism is motivated by scenarios where a PCC wants to indicate that a constraint (e.g., a METRIC object with Bound flag set for Path Delay Variation) can be relaxed by the PCE if no conforming path exists. Marking objects as optional allows the PCE to compute a best-effort path without a hard failure.
RFC 8231 specified that P and I flags of PCEP objects are set to 0 on transmission and ignored on receipt in stateful PCE contexts, and failed to mention behavior of objects defined outside RFC 8231, causing ambiguity. This document resolves that ambiguity by introducing the R flag negotiation mechanism.
For delegated LSPs, when a PCE updates and marks objects with new P flag expectations, the PCC MUST acknowledge this by sending a PCRpt message with the P flag set as per the PCE expectation. If the PCC cannot accept the update, it MUST react per the processing rules of unacceptable update in RFC 8231 Section 5.8.3.
If a mandatory object is received with the P flag set incorrectly in a PCUpd or PCInitiate message, the receiving peer MUST send a PCErr message with Error-Type=10 and Error-value=1. On a session where both peers set the R bit, the PCE SHOULD set the P flag by default unless local configuration/policy indicates otherwise.
If a PCEP speaker does not understand an object with the P flag set, or understands but decides to ignore it, the entire stateful PCEP message MUST be rejected and the PCE MUST send a PCErr message with Error-Type 'Unknown Object' or 'Not supported object'. If the P flag is not set, the speaker can ignore the object and continue processing.
On a PCEP session where the R bit was set by both peers, the PCC SHOULD set the P flag by default in PCRpt messages, unless local configuration or policy indicates that some constraints can be marked as optional or the object conveys informational parameters that can be safely ignored.
The I flag has no meaning in the PCInitiate message; it MUST be set to 0 on transmission and ignored on receipt.
The R flag MUST be set by both the PCC and PCE to activate handling of the P and I flags in the PCEP common object header for relaxing constraints by marking objects as 'optional to process'. If a PCEP speaker does not set the R flag but receives PCEP objects with P or I bits set, it MUST ignore those flags.
When the P flag is set in a PCUpd or PCInitiate message received on a session where the R bit was set by both peers, the object MUST be taken into account by the PCC. The P flag for mandatory objects (SRP, LSP, ERO) MUST be set in PCUpd/PCInitiate messages.
A new R (RELAX) flag, bit 17, is added to the STATEFUL-PCE-CAPABILITY TLV. When set to 1, it indicates the PCEP speaker is willing to handle the P and I flags in the PCEP common object header for stateful PCEP messages; when unset, those flags are not handled for stateful messages.
The I flag in the PCRpt message allows a PCC to indicate to a PCE whether an optional object was processed in response to a PCUpd or PCInitiate message. The I flag has no meaning in a PCRpt message that is not in response to a PCUpd or PCInitiate (i.e., without an SRP object).
The I (Ignore) flag in the PCUpd message allows a PCE to indicate to a PCC whether an optional object was processed. The PCE MAY include the ignored optional object and set the I flag to indicate it was ignored; when the I flag is cleared, the optional object was processed.
When a PCC is unable to set up a path meeting all parameters for objects that cannot be ignored (P flag set), the PCRpt message MAY optionally include the PCEP objects that caused path setup failure along with the LSP-ERROR-CODE TLV indicating the reason for the failure.
When a PCE is unable to find a path meeting all constraints for objects that cannot be ignored (P flag set), the PCUpd message MAY optionally include the PCEP objects that caused path computation failure along with an empty ERO to communicate the failure details.
IANA has allocated bit 17, labeled 'RELAX', in the 'STATEFUL-PCE-CAPABILITY TLV Flag Field' registry (originally created by RFC 8231) with reference to RFC 9753.
The P and I flag extensions for stateful PCEP do not introduce new security concerns on their own; the security considerations of RFC 5440, RFC 8231, and RFC 8281 continue to apply. It is RECOMMENDED that these extensions be activated only on authenticated and encrypted sessions using TLS (RFC 8253) per RFC 9325 best practices.