Conveying Vendor-Specific Information in the Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCEHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinac.l@huawei.comHuawei TechnologiesH1, Huawei Xiliu Beipo Village, Songshan LakeDongguanGuangdong523808Chinazhenghaomian@huawei.comCiena385 Terry Fox DriveKanataOntarioK2K 0L1Canadamsiva282@gmail.comCisco Systems, Inc.ssidor@cisco.comCisco Systems, Inc.zali@cisco.com
RTG
pcePCEVendor specificvendor-specificThis document specifies extensions to the Path Computation Element
Communication Protocol (PCEP) that enable the inclusion of
vendor-specific information in stateful Path Computation Element (PCE) operations. These extensions
allow vendors to incorporate proprietary data within PCEP messages,
facilitating enhanced network optimization and functionality in
environments requiring vendor-specific features. The extensions maintain
compatibility with existing PCEP implementations and promote
interoperability across diverse network deployments. RFC 7470 defines a
facility to carry vendor-specific information in stateless PCEP messages. This document extends this
capability for the stateful PCEP messages.
This document updates RFC 7470 to specify that Enterprise Numbers
are managed through the "Private Enterprise Numbers (PENs)" registry.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
.
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
() 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
. Introduction
. Requirements Language
. Use of RBNF
. Procedures for the Vendor Information Object
. Procedures for the Vendor Information TLV
. Manageability Considerations
. Control of Function and Policy
. Information and Data Models
. Liveness Detection and Monitoring
. Verifying Correct Operations
. Requirements On Other Protocols
. Impact on Network Operations
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgments
Contributors
Authors' Addresses
IntroductionThe Path Computation Element Communication Protocol (PCEP) provides mechanisms for a Path
Computation Element (PCE) to perform path computation in response to a
Path Computation Client (PCC) request.A stateful PCE is capable of considering, for the purposes of
path computation, not only the network state in terms of links and nodes
(referred to as the Traffic Engineering Database or TED) but also the
status of active services (previously computed paths, and currently
reserved resources, stored in the Label Switched Paths Database
(LSP-DB)). describes general
considerations for a stateful PCE deployment and examines its
applicability and benefits, as well as its challenges and limitations
through a number of use cases. describes a set of
extensions to PCEP to provide stateful control. A stateful PCE has
access to not only the information carried by the network's Interior
Gateway Protocol (IGP), but also the set of active paths and their
reserved resources for its computations. The additional state allows the
PCE to compute constrained paths while considering individual LSPs and
their interactions. describes
the setup, maintenance, and teardown of PCE-initiated LSPs under the
stateful PCE model. These extensions add new messages in PCEP for
stateful PCE. defines the Vendor Information
object, which can carry arbitrary, proprietary information, such as
vendor-specific constraints, in stateless PCEP. It also defines the
VENDOR-INFORMATION-TLV, which allows arbitrary information to be embedded
within any existing or future PCEP object that supports TLVs.While originally designed for stateless PCEP, the Vendor Information
object and VENDOR-INFORMATION-TLV are also useful in the stateful PCE model.
The VENDOR-INFORMATION-TLV can already be included in any of the stateful PCEP
objects per . This
document further extends stateful PCEP messages to support the use of the
Vendor Information object.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 when, and only when, they appear in all capitals, as
shown here.
Use of RBNFThe message formats in this document are illustrated using Routing
Backus-Naur Form (RBNF) encoding, as specified in . The use of RBNF is illustrative
only and may omit certain important details; the normative
specification of messages is found in the descriptive text. If there
is any divergence between the RBNF and the descriptive text, the
descriptive text is considered authoritative.Procedures for the Vendor Information ObjectA Path Computation LSP State Report message (also referred to as
PCRpt message; see ) is a PCEP message sent by a
PCC to a PCE to report the current state of an LSP. A PCC that wants to
convey proprietary or vendor-specific information or metrics to a PCE
does so by including a Vendor Information object in the PCRpt message.
The contents and format of the object, including the VENDOR-INFORMATION
object and the VENDOR-INFORMATION-TLV, are described in
. The PCE determines how to
interpret the information in the Vendor Information object by examining
the Enterprise Number it contains. stated that:
Enterprise Numbers are assigned by IANA and managed through an IANA
registry .
This document updates and replaces this text with:
Enterprise Numbers are assigned by IANA and managed
through the "Private Enterprise Numbers (PENs)" registry as
described in .
The Vendor Information object is OPTIONAL in a PCRpt message.
Multiple instances of the object MAY be contained in a single PCRpt
message. Different instances of the object MAY have different Enterprise
Numbers.The format of the PCRpt message (with as the base) is
updated as follows:
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<path>
[<vendor-info-list>]
Where:
<vendor-info-list> ::= <VENDOR-INFORMATION>
[<vendor-info-list>]
<path> is defined in [RFC8231].
A Path Computation LSP Update Request message (also referred to as
PCUpd message; see ) is a PCEP message sent by a
PCE to a PCC to update the attributes of an LSP. The Vendor Information
object can be included in a PCUpd message to convey proprietary or
vendor-specific information.The format of the PCUpd message (using the format described in as the base) is
updated as follows:
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>
[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<path>
[<vendor-info-list>]
Where:
<vendor-info-list> ::= <VENDOR-INFORMATION>
[<vendor-info-list>]
<path> is defined in [RFC8231].
A Path Computation LSP Initiate Message (also referred to as
PCInitiate message; see ) is a PCEP message sent by a
PCE to a PCC to trigger an LSP instantiation or deletion. The Vendor
Information object can be included in a PCInitiate message to convey
proprietary or vendor-specific information.The format of the PCInitiate message (using the format described in as the base) is
updated as follows:
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::=
(<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<ERO>
[<attribute-list>]
[<vendor-info-list>]
Where:
<vendor-info-list> ::= <VENDOR-INFORMATION>
[<vendor-info-list>]
<PCE-initiated-lsp-deletion> and <attribute-list> are as defined in
.A legacy implementation that does not recognize the Vendor
Information object will act according to the procedures set out in and . An implementation that supports the Vendor
Information object, but receives one carrying an Enterprise Number that
it does not support, MUST ignore the object in the same way as described
in .Procedures for the Vendor Information TLVThe Vendor Information TLV can be used to carry vendor-specific
information that applies to a specific PCEP object by including the TLV
in the object. This includes objects used in Stateful PCE extensions
such as Stateful PCE Request Parameter (SRP) and LSP objects. All of the
procedures are as described in .Manageability ConsiderationsAll manageability requirements and considerations listed in , , , and apply to the PCEP protocol extensions
defined in this document. In addition, the requirements and
considerations listed in this section apply.Control of Function and PolicyThe requirements for control of function and policy for
vendor-specific information as set out in [RFC7470] continue to apply
to Stateful PCEP extensions specified in this document.Information and Data ModelsThe PCEP YANG module is specified in . Any standard YANG module will not
include details of vendor-specific information. However,
a standard YANG module could be extended to report the use of the
Vendor Information object or TLV and the Enterprise Numbers that the
objects and TLVs contain.Liveness Detection and MonitoringMechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in .Verifying Correct OperationsMechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in and .Requirements On Other ProtocolsMechanisms defined in this document do not imply any new
requirements on other protocols.Impact on Network OperationsMechanisms defined in and
also apply to PCEP
extensions defined in this document. highlights
how the presence of additional vendor-specific information in PCEP
messages may congest the operations and how to detect and handle it.
This also applies to stateful PCEP messages as outlined in .
Specifically, a PCEP speaker SHOULD NOT include vendor information in
stateful PCEP message if it believes the recipient does not support
that information.Encoding optimization for the Vendor Information object, for
example, in case the object has the same content encoded for
multiple LSPs, is considered out of the scope of this document and may
be proposed in the future as a separate document applicable to other
PCEP objects.IANA ConsiderationsThis document has no IANA actions.Security ConsiderationsThe protocol extensions defined in this document do not change the
nature of PCEP. Therefore, the security considerations set out in , , , and apply unchanged.Per , it is RECOMMENDED
that these PCEP extensions only be activated on authenticated and
encrypted sessions across PCEs and PCCs using Transport Layer Security
(TLS) . See the
recommendations and best current practices for using TLS in RFC 9325 .The use of vendor-specific information as defined in and in this document may provide a
covert channel that could be misused by PCEP speaker implementations or
by malicious software at PCEP speakers. While there is limited protection
against this, an operator monitoring the PCEP sessions can detect the
use of vendor-specific information, be aware of the decoding mechanism
for this data, and inspect it accordingly. It is crucial for the
operator to remain vigilant and monitor for any potential misuse of this
object. Appropriate steps need to be taken to prevent the installation of
malicious software at the PCEP speaker by implementing robust integrity,
authentication, and authorization techniques for installation and
updating, which are out of scope of this document.ReferencesNormative ReferencesDeprecating TLS 1.0 and TLS 1.1This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Path Computation Element (PCE) Communication Protocol (PCEP)This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol SpecificationsSeveral protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK]Conveying Vendor-Specific Constraints in the Path Computation Element Communication ProtocolThe Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs.This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCEThe Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE ModelThe Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.Informative ReferencesA YANG Data Model for Path Computation Element Communications Protocol (PCEP)HuaweiJuniper NetworksNvidiaWork in ProgressStructure of Management Information Version 2 (SMIv2)It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]Applicability of a Stateful Path Computation Element (PCE)A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.This document updates RFC 5440 in regards to the PCEP initialization phase procedures.Registration Procedures for Private Enterprise Numbers (PENs)This document describes how Private Enterprise Numbers (PENs) are registered by IANA. It shows how to request a new PEN and how to modify a current PEN. It also gives a brief overview of PEN uses.AcknowledgmentsThanks to for shepherding the document and for their significant contributions and suggestions.Thanks to , ,
, ,
, ,
, ,
, ,
, ,
, ,
, ,
, , and
for their reviews, comments, and suggestions.ContributorsHuaweiIndiadhruv.ietf@gmail.comCienamkoldych@proton.meAuthors' AddressesHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinac.l@huawei.comHuawei TechnologiesH1, Huawei Xiliu Beipo Village, Songshan LakeDongguanGuangdong523808Chinazhenghaomian@huawei.comCiena385 Terry Fox DriveKanataOntarioK2K 0L1Canadamsiva282@gmail.comCisco Systems, Inc.ssidor@cisco.comCisco Systems, Inc.zali@cisco.com