Internet Engineering Task Force (IETF) C. Li
Request for Comments: 9753 H. Zheng
Updates: 8231 Huawei Technologies
Category: Standards Track S. Litkowski
ISSN: 2070-1721 Cisco
April 2025
Extension for Stateful PCE to Allow Optional Processing of Path
Computation Element Communication Protocol (PCEP) Objects
Abstract
This document introduces a mechanism to mark some of the Path
Computation Element Communication Protocol (PCEP) objects as optional
during PCEP message exchange, so the stateful Path Computation
Element (PCE) model can relax some constraints during path
computation and setup. This document introduces this relaxation to
stateful PCE, and it updates RFC 8231.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9753.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
1.1. Requirements Language
2. Overview
2.1. Usage Example
3. PCEP Extension
3.1. STATEFUL-PCE-CAPABILITY TLV
3.2. Handling of the P Flag
3.2.1. The PCRpt Message
3.2.1.1. Delegation
3.2.2. The PCUpd Message and the PCInitiate Message
3.3. Handling of the I Flag
3.3.1. The PCUpd Message
3.3.2. The PCRpt Message
3.3.3. The PCInitiate Message
3.4. Unknown Object Handling
4. Security Considerations
5. IANA Considerations
5.1. STATEFUL-PCE-CAPABILITY TLV
6. Manageability Considerations
6.1. Control of Function and Policy
6.2. Information and Data Models
6.3. Liveness Detection and Monitoring
6.4. Verify Correct Operations
6.5. Requirements on Other Protocols
6.6. Impact on Network Operations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
1. Introduction
[RFC5440] describes the Path Computation Element Communication
Protocol (PCEP), which enables communication between a Path
Computation Client (PCC) and a Path Control Element (PCE), or between
two PCEs based on the PCE architecture [RFC4655].
PCEP extensions for the stateful PCE model [RFC8231] describes a set
of extensions to PCEP to enable active control of Multiprotocol Label
Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS)
tunnels. [RFC8281] describes the setup and teardown of PCE-initiated
LSPs under the active stateful PCE model, without the need for local
configuration on the PCC, thus allowing for dynamic control.
[RFC5440] defined the P flag (Processing-Rule) in the Common Object
Header to allow a PCC to specify in a Path Computation Request
(PCReq) message (sent to a PCE) whether the object must be taken into
account by the PCE during path computation or is optional. The I
flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep)
message to indicate to a PCC whether or not an optional object was
considered by the PCE during path computation. Stateful PCE
[RFC8231] specifies that the P and I flags of the PCEP objects are to
be set to zero on transmission and ignored on receipt, since they are
exclusively related to the path computation requests. This document
defines a new flag, the R (RELAX) flag in STATEFUL-PCE-CAPABILITY
TLV, in the PCEP common object header to indicate a PCE speaker
supporting P and I flags processing, and it also specifies how the P
and I flags could be used in the stateful PCE model to identify
optional objects in the Path Computation State Report (PCRpt)
[RFC8231], the Path Computation Update Request (PCUpd) [RFC8231], and
the LSP Initiate Request (PCInitiate) [RFC8281] messages.
This document updates [RFC8231] concerning usage of the P and I flags
as well as the handling of unknown objects in stateful PCEP message
exchange.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Overview
Setting the P flag in the PCReq message to handle unknown objects is
as described in Section 7.2 of [RFC5440]. Further, [RFC8231] defined
the usage of the LSP Error Code TLV in the PCRpt message in response
to a failed LSP Update Request via the PCUpd message (for example,
due to an unsupported object or TLV).
This document specifies the procedure of marking some objects as
'optional to be processed' by the PCEP peer in the stateful PCEP
messages. Furthermore, this document updates the procedure for
handling unknown objects in stateful PCEP messages based on the P
flag.
2.1. Usage Example
The PCRpt message is used to report the current state of an LSP. As
part of the message, both the <intended-attribute-list> and <actual-
attribute-list> are encoded (see [RFC8231]). For example, the
<intended-attribute-list> could include the METRIC object to indicate
a limiting constraint (Bound 'B' flag set) for the Path Delay
Variation metric [RFC8233]. In some scenarios, it would be useful to
indicate that this constraint can be relaxed by the PCE in case it
cannot find a path. In these cases, it would be useful to mark the
objects as 'optional' so they could be ignored by the PCEP peer.
Also, it would be useful for the PCEP speaker to learn if the PCEP
peer has relaxed the constraint and ignored the processing of the
PCEP object.
Thus, this document specifies how the already existing P and I flags
in the PCEP common object header could be used during the stateful
PCEP message exchange. The scope of how P and I flags are applied is
defined in [RFC5440] and is unchanged by this document. Therefore,
these flags can only be applied to an entire PCEP object; they cannot
be applied at the granularity of optional TLVs encoded in the PCEP
object.
3. PCEP Extension
3.1. STATEFUL-PCE-CAPABILITY TLV
A PCEP speaker indicates its ability to support the handling of the P
and I flags in the stateful PCEP message exchange during the PCEP
initialization phase, as follows. During the PCEP initialization
phase, a PCC sends an Open message with an OPEN object that contains
the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new
flag, the R (RELAX) flag, is added to this TLV to indicate support
for relaxing the processing of some objects via the use of the P and
I flags in the PCEP common object header.
R (RELAX bit - 17): If set to 1 by a PCEP Speaker, the R flag
indicates that the PCEP Speaker is willing to handle the P and I
flags in the PCEP common object header for the PCEP objects in the
stateful PCEP messages. If the bit is unset, it indicates that the
PCEP Speaker will not handle the P and I flags in the PCEP common
object header for stateful PCE messages.
The R flag MUST be set by both the PCC and PCE to indicate support
for handling the P and I flags in the PCEP common object header to
allow relaxing some constraints by marking objects as 'optional to
process'. If the PCEP speaker does not set the R flag but receives
PCEP objects with the P or I bits set, it MUST ignore the flags.
[RFC8231] states that P and I flags of the PCEP objects are set to 0
on transmission and ignored on receipt. It fails to mention the
behaviour of objects defined outside of [RFC8231], leading to
ambiguity.
3.2. Handling of the P Flag
3.2.1. The PCRpt Message
The P flag in the PCRpt message [RFC8231] allows a PCC to specify to
a PCE whether the object must be taken into account by the PCE
(during state maintenance, path computation, or re-optimisation) or
is optional to process. When the P flag is set in the PCRpt message
received on a PCEP session on which the R bit is set by both peers,
the object MUST be taken into account by the PCE. Conversely, when
the P flag is cleared, the object is optional and the PCE can ignore
it. The P flag for the mandatory objects, such as the LSP and the
ERO (Explicit Route Object) object (intended path), MUST be set in
the PCRpt message. If a mandatory object is received with the P flag
set incorrectly according to the rules stated above, the receiving
peer MUST send a PCErr message with Error-Type=10 (Reception of an
invalid object) and Error-value=1 (Reception of an object with P flag
not set). On a PCEP session on which the R bit was set by both
peers, the PCC SHOULD set the P flag by default, unless a local
configuration or local policy indicates that some constraints
(corresponding PCEP objects) can be marked as optional and could be
ignored by the PCE or the object itself conveys informational
parameters that can be safely ignored.
3.2.1.1. Delegation
Delegation is an operation to grant a PCE temporary rights to modify
a subset of parameters on one or more LSPs by a PCC as described in
[RFC8051]. Note that for the delegated LSPs, the PCE can update and
mark some objects as ignored even when the PCC has set the P flag
during the delegation. Similarly, the PCE can update and mark some
objects as a 'must to process' even when the PCC has not set the P
flag during delegation.
The PCC MUST acknowledge this by sending the PCRpt message with the P
flag set as per the PCE expectation for the corresponding object. If
the PCC cannot accept the update message, it MUST react as per the
processing rules of unacceptable update in Section 5.8.3 of
[RFC8231].
3.2.2. The PCUpd Message and the PCInitiate Message
The P flag in the PCUpd message [RFC8231] and the PCInitiate message
[RFC8281] allows a PCE to specify to a PCC whether the object must be
taken into account by the PCC (during path setup) or is optional to
process. When the P flag is set in the PCUpd/PCInitiate message
received on a PCEP session on which the R bit was set by both peers,
the object MUST be taken into account by the PCC. Conversely, when
the P flag is cleared, the object is optional and the PCC can ignore
it. The P flag for the mandatory objects -- such as the SRP
(Stateful PCE Request Parameters), the LSP, and the ERO -- MUST be
set in the PCUpd/PCInitiate message. If a mandatory object is
received with the P flag set incorrectly according to the rules
stated above, the receiving peer MUST send a PCErr message with
Error-Type=10 (Reception of an invalid object) and Error-value=1
(Reception of an object with P flag not set). On a PCEP session in
which both peers set the R bit, the PCE SHOULD set the P flag by
default unless a local configuration/policy indicates that some
constraints (corresponding PCEP objects) can be marked as optional
and can be ignored by the PCC or the object itself conveys
informational parameters that can be safely ignored.
3.3. Handling of the I Flag
3.3.1. The PCUpd Message
The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to
a PCC whether or not an optional object was processed. The PCE MAY
include the ignored optional object in its update request and set the
I flag to indicate that the optional object was ignored. When the I
flag is cleared, the PCE indicates that the optional object was
processed.
Note that when a PCE is unable to find the path that meets all the
constraints as per the PCEP object that cannot be ignored (i.e. the
P flag is set), the PCUpd message MAY optionally include the PCEP
objects that caused the path computation to fail along with the empty
ERO.
3.3.2. The PCRpt Message
The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to
a PCE whether or not an optional object was processed in response to
a PCUpd or PCInitiate message. The PCC MAY include the ignored
optional object in its report and set the I flag to indicate that the
optional object was ignored at PCC. When the I flag is cleared, the
PCC indicates that the optional object was processed. The I flag has
no meaning if the PCRpt message is not in response to a PCUpd or
PCInitiate message (i.e., without the SRP object in the PCRpt
message).
Note that when a PCC is unable to set up a path that meets all the
parameters as per the PCEP object that cannot be ignored (i.e., the P
flag is set), the PCRpt message MAY optionally include the PCEP
objects that caused the path setup to fail along with the LSP-ERROR-
CODE TLV [RFC8231] indicating the reason for the failure.
3.3.3. The PCInitiate Message
The I flag has no meaning in the PCInitiate message [RFC8281], so the
I flag MUST set to 0 on transmission and ignored on receipt.
3.4. Unknown Object Handling
This document updates the handling of unknown objects in the stateful
PCEP messages by setting the P flag in the common object header in a
similar way as described in [RFC5440]. That is, if a PCEP speaker
does not understand an object with the P flag set, or if the PCEP
speaker understands the object but decides to ignore the object, 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" [RFC5440]. If the P flag is not set, the PCEP speaker can
ignore the object and continue with the message processing as
defined.
[RFC8231] defined the LSP Error Code TLV to be carried in the PCRpt
message in the LSP object to convey error information. This document
does not change that procedure.
4. Security Considerations
This document specifies how the already existing P and I flags in the
PCEP common object header could be used during stateful PCEP
exchanges. It updates the unknown object error handling in stateful
PCEP message exchange. On their own, these changes do not add any
new security concerns. The security considerations identified in
[RFC5440], [RFC8231], and [RFC8281] continue to apply.
As per [RFC8231], it is RECOMMENDED that these PCEP extensions can
only be activated on authenticated and encrypted sessions across PCEs
and PCCs belonging to the same administrative authority, using
Transport Layer Security (TLS) [RFC8253] as per the recommendations
and best current practices described in [RFC9325].
5. IANA Considerations
5.1. STATEFUL-PCE-CAPABILITY TLV
[RFC8231] defined the STATEFUL-PCE-CAPABILITY TLV and IANA created
the "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry to manage the
value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA has
allocated a new bit in the registry, as follows:
+=====+=============+===========+
| Bit | Description | Reference |
+=====+=============+===========+
| 17 | RELAX | RFC 9753 |
+-----+-------------+-----------+
Table 1
6. Manageability Considerations
6.1. Control of Function and Policy
An implementation supporting this document SHOULD allow configuration
of the capability to support relaxation of constraints in the
stateful PCEP message exchange. They SHOULD also allow configuration
of related LSP constraints (or parameters) that are optional to
process.
6.2. Information and Data Models
An implementation supporting this document SHOULD allow the operator
to view the capability defined in this document. To serve this
purpose, the PCEP YANG module [PCEP-YANG] could be extended in the
future.
6.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440].
6.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[RFC5440].
6.5. Requirements on Other Protocols
Mechanisms defined in this document do not imply any new requirements
on other protocols.
6.6. Impact on Network Operations
Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [RFC5440].
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
7.2. Informative References
[PCEP-YANG]
Dhody, D., Ed., Beeram, V. P., Hardwick, J., and J.
Tantsura, "A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-30, 26 January
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-yang-30>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) to Compute Service-Aware Label Switched
Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
2017, <https://www.rfc-editor.org/info/rfc8233>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
Acknowledgments
Thanks to Jonathan Hardwick for the discussion and suggestions around
this document.
Thanks to Oscar Gonzalez de Dios, Mike Koldychev, Samuel Sidor, and
Peng Shaofu for their review comments.
Contributors
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Authors' Addresses
Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: c.l@huawei.com
Haomian Zheng
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: zhenghaomian@huawei.com