Path Computation Element (pce) Internet Drafts

      
 PCEP Extension for Flexible Grid Networks
 
 draft-ietf-pce-flexible-grid-19.txt
 Date: 17/09/2026
 Authors: Haomian Zheng, Young Lee, Ramon Casellas, Daniele Ceccarelli
 Working Group: Path Computation Element (pce)
 This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid networks.
 Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR)
 
 draft-ietf-pce-sr-path-segment-15.txt
 Date: 20/04/2026
 Authors: Cheng Li, Mach Chen, Weiqiang Cheng, Rakesh Gandhi, Quan Xiong
 Working Group: Path Computation Element (pce)
 The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers.
 Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) LSPs
 
 draft-ietf-pce-sr-bidir-path-25.txt
 Date: 06/03/2026
 Authors: Cheng Li, Mach Chen, Weiqiang Cheng, Rakesh Gandhi, Quan Xiong
 Working Group: Path Computation Element (pce)
 Segment Routing (SR) steers packets through a network using the IPv6 or MPLS data planes via source routing. Stateful Path Computation Element Communication Protocol (PCEP) extensions are defined for SR Traffic Engineering (TE) LSPs. PCEP supports grouping two RSVP-TE signaled, unidirectional MPLS-TE Label-Switched Paths (LSPs) with one in each direction in a network into an associated bidirectional LSP. This document extends PCEP support to group two unidirectional SR LSPs into an associated bidirectional SR LSP. The mechanisms defined in this document apply to both stateless and stateful PCEs for PCE-initiated and PCC- initiated LSPs.
 PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution
 
 draft-ietf-pce-pcep-extension-pce-controller-sr-14.txt
 Date: 10/02/2026
 Authors: Zhenbin Li, Shuping Peng, Mahendra Negi, Chao Zhou
 Working Group: Path Computation Element (pce)
 The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution.
 Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information
 
 draft-ietf-pce-multipath-29.txt
 Date: 23/06/2026
 Authors: Mike Koldychev, Samuel Sidor
 Working Group: Path Computation Element (pce)
 This document defines Path Computation Element Communication Protocol (PCEP) extensions to signal multipath information, associating multiple forwarding paths with a single PCEP Label Switched Path (LSP) to allow load-balancing and redundancy across diverse paths. The extensions are generic and applicable to both stateless and stateful PCEP, and are designed to be reusable for future path types. Their primary application is Segment Routing (SR) Policy, where a Candidate Path can contain multiple Segment Lists: current PCEP extensions for SR Policy only allow signaling of a single Segment List per Candidate Path. These extensions enable multipath capabilities such as weighted or equal-cost load-balancing across paths.
 Procedures for Communication between Stateful Path Computation Elements
 
 draft-ietf-pce-state-sync-15.txt
 Date: 11/06/2026
 Authors: Haomian Zheng, Stephane Litkowski, Siva Sivabalan, Cheng Li, Daniel King
 Working Group: Path Computation Element (pce)
 The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) and Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions toward multiple PCEs. In some use cases, inter-PCE stateful communication can bring additional resiliency in the design, for instance, when some PCC-PCE session fails. This document describes the procedures to allow stateful communication between PCEs for various use cases, and also the procedures to prevent computational loops.
 PCEP extensions for SR P2MP Policy
 
 draft-ietf-pce-sr-p2mp-policy-21.txt
 Date: 08/09/2026
 Authors: Hooman Bidgoli, Dan Voyer, Anuj Budhiraja, Rishabh Parekh, Siva Sivabalan
 Working Group: Path Computation Element (pce)
 Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of policies that enable an architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths for SR-MPLS from a Root to a set of Leaf nodes.
 PCEP Extension for Layer 2 (L2) Flow Specification
 
 draft-ietf-pce-pcep-l2-flowspec-10.txt
 Date: 03/04/2026
 Authors: Dhruv Dhody, Adrian Farrel, Zhenbin Li
 Working Group: Path Computation Element (pce)
 The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. This document updates RFC 9168 by updating the assignment policies for a range of Flow Specification TLV Type Indicators. The extensions defined in this document extend the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with Layer 3 (L3) flowspecs.
 Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP)
 
 draft-ietf-pce-pcep-pmtu-10.txt
 Date: 16/09/2026
 Authors: Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor, Samuel Sidor
 Working Group: Path Computation Element (pce)
 The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for the SR path is unavailable at the headend. This document specifies the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR, but not limited to it. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU.
 Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT
 
 draft-ietf-pce-pcep-ifit-09.txt
 Date: 06/07/2026
 Authors: Hang Yuan, wangxuerong, Pingan Yang, Weidong Li, Giuseppe Fioccola
 Working Group: Path Computation Element (pce)
 In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document.
 A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP)
 
 draft-ietf-pce-pcep-srv6-yang-09.txt
 Date: 13/05/2026
 Authors: Cheng Li, Siva Sivabalan, Shuping Peng, Mike Koldychev, Luc-Fabrice Ndifor
 Working Group: Path Computation Element (pce)
 This document augments a YANG data model for the management of Path Computation Element Communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6 (SRv6) and SR Policy. The data model includes configuration data and state data (status information and counters for the collection of statistics).
 Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies
 
 draft-ietf-pce-circuit-style-pcep-extensions-16.txt
 Date: 16/03/2026
 Authors: Samuel Sidor, Praveen Maheshwari, Andrew Stone, Luay Jalil, Shuping Peng
 Working Group: Path Computation Element (pce)
 Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy can consist of one or a set of candidate paths, where each candidate path is represented by a segment list or a set of segment lists, which are essentially instructions that define a source-routed path. This document specifies a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path modification and the option to request a strict hop-by-hop path, being also applicable for generic SR policy use cases where controlling path modification or deterministic and persistent path requirements are applicable.
 Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions
 
 draft-ietf-pce-entropy-label-position-05.txt
 Date: 07/05/2026
 Authors: Quan Xiong, Shaofu Peng, Fengwei Qin, Junfeng Zhao
 Working Group: Path Computation Element (pce)
 Entropy label (EL) can be used in the SR-MPLS data plane to improve load-balancing and multiple Entropy Label Indicator (ELI)/EL pairs may be inserted in the SR-MPLS label stack as per RFC8662. This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to configure the Entropy Label Positions (ELP) for SR-MPLS networks.
 PCEP extensions for Distribution of Link-State and TE Information
 
 draft-ietf-pce-pcep-ls-07.txt
 Date: 04/07/2026
 Authors: Dhruv Dhody, Shuping Peng, Daniele Ceccarelli, Aijun Wang, Gyan Mishra
 Working Group: Path Computation Element (pce)
 In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension to allow gathering more deployment and implementation feedback on the use of PCEP in this way.
 Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space
 
 draft-ietf-pce-controlled-id-space-05.txt
 Date: 23/06/2026
 Authors: Cheng Li, Guanming Zeng, Aijun Wang, Weiqiang Cheng, Chao Zhou
 Working Group: Path Computation Element (pce)
 The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC provisioning or Binding Segment Identifier (SID) for Segment Routing (SR) allocation, there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE to be aware of various identifier spaces from where to make allocations on behalf of a PCC. This document defines a generic mechanism by which a PCC can inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other identifier that can be allocated and managed by the PCE.
 Update to Automatic Bandwidth Adjustment Procedure of Stateful PCE for MPLS-TE and SR-TE LSPs
 
 draft-ietf-pce-stateful-pce-autobw-update-04.txt
 Date: 03/05/2026
 Authors: Shuping Peng, Dhruv Dhody, Rakesh Gandhi
 Working Group: Path Computation Element (pce)
 The Stateful PCE extensions allow Stateful control of Traffic Engineering (TE) LSPs using PCEP for RSVP-TE and Segment Routing (SR) (for both MPLS and IPv6 Data planes) for both PCE-Initiated and PCC- Initiated LSPs. Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to remove an attribute identified by the sub-TLV explicitly. This document updates RFC 8733 by defining the behaviour to remove an attribute explicitly. In addition, this updates allow applying this PCEP extensions to SR-TE LSPs (for both MPLS and IPv6 Data planes), in addition to MPLS-TE LSPs.
 PCEP Operational Clarification
 
 draft-ietf-pce-operational-03.txt
 Date: 05/07/2026
 Authors: Mike Koldychev, Siva Sivabalan, Shuping Peng, Diego Achaval, Hari Kotni, Andrew Stone
 Working Group: Path Computation Element (pce)
 This document clarifies certain operational behavior aspects of the Path Computation Element Communication Protocol (PCEP). The content of this document has been compiled based on several interop exercises. This document does not make any updates or revisions to any PCEP specifications, instead it provides additional information to aid in the interpretation of those documents.
 Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP)
 
 draft-ietf-pce-pcep-nrp-01.txt
 Date: 06/07/2026
 Authors: Jie Dong, Li Zhang, Quan Xiong, Shaofu Peng, Liuyan Han, Minxue Wang, Vishnu Beeram, Tarek Saad, Sheng Fang
 Working Group: Path Computation Element (pce)
 This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to carry Network Resource Partition (NRP) related information in the PCEP messages. The extensions in this document can be used to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization.
 Path Computation Element Communication Protocol (PCEP) Extensions for Topology Filter
 
 draft-ietf-pce-topology-filter-01.txt
 Date: 07/05/2026
 Authors: Quan Xiong, Shaofu Peng, Vishnu Beeram, Tarek Saad, Mike Koldychev
 Working Group: Path Computation Element (pce)
 A topology filter is a data construct that is used to filter network topologies. The Path Computation Element (PCE) MUST take into account the topology related constraints during the path computation. This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to support the topology filter.
 PCEP Extensions for Distribution of Link-State and TE Information for Optical Networks
 
 draft-ietf-pce-pcep-ls-optical-00.txt
 Date: 17/09/2026
 Authors: Yang Zhao, Daniele Ceccarelli, LiXiao, Bin Yoon, Adrian Farrel
 Working Group: Path Computation Element (pce)
 In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). This Link State and TE information has previously been obtained from a link state routing protocol that supports traffic engineering extensions. Link-State (LS) and Traffic Engineering (TE) information can also be carried in the Path Computation Element Communication Protocol (PCEP) using experimental exensions to PCEP known as Link-State PCEP (PCEP- LS). This document provides further experimental extensions to collect Link-State and TE information for optical networks.

data-group-menu-data-url="/group/groupmenu.json">

Path Computation Element (pce)

WG Name Path Computation Element
Acronym pce
Area Routing Area (rtg)
State Active
Charter charter-ietf-pce-08 Approved
Status update Show Changed 2021-07-22
Document dependencies
Additional resources GitHub
Wiki, Zulip stream
Personnel Chairs Dhruv Dhody, Julien Meuric
Area Director Ketan Talaulikar
Secretary Andrew Stone
Delegate Andrew Stone
Mailing list Address [email protected]
To subscribe https://www.ietf.org/mailman/listinfo/pce
Archive https://mailarchive.ietf.org/arch/browse/pce/
Chat Room address https://zulip.ietf.org/#narrow/stream/pce

Charter for Working Group

The PCE Working Group is chartered to specify the required protocols
to enable a Path Computation Element (PCE)-based architecture for the
computation of paths for MPLS and GMPLS Point to Point and Point to
Multi-point traffic-engineered LSPs, as well as new path setup types
of Segment Routing (SR), BIER, and Detnet.

In this architecture path computation does not necessarily occur on
the head-end (ingress) node, but on some other path computation
entity that may not be physically located on each head-end node. The
TEAS Working Group is responsible for defining and extending
architectures for Traffic Engineering (TE) and it is expected that the
PCE and TEAS WGs will work closely together on elements of TE
architectures that utilize PCE.

The PCE WG works on the application of this model within a single
domain or within a group of domains (where a domain is a layer, IGP
area, or Autonomous System with limited visibility from the head-end
LSR). At this time, applying this model to large groups of domains
such as the Internet is not thought to be possible, and the PCE WG
will not spend energy on that topic.

The WG specifies the PCE communication Protocol (PCEP) and needed
extensions for communication between Path Computation Clients (PCCs)
and PCEs, and between cooperating PCEs. Security mechanisms such as
authentication and confidentiality are included.

The WG works on the mechanisms for inter-domain as well as multi-layer
path computation and PCEP extensions for communication between several
domains or network layers.

The WG defines the required PCEP extensions for Wavelength Switched
Optical Networks (WSON) and Flexible Grid while keeping consistency
with the GMPLS protocols specified in the CCAMP and TEAS WGs.

Work Items:

  • PCEP extensions to support MPLS and GMPLS Traffic Engineered LSP
    path computation models involving PCEs. This includes the case of
    computing the paths of intra- and inter-domain TE LSPs. Such path
    computation includes the generation of primary, protection, and
    recovery paths, as well as computations for (local/global)
    reoptimization and load balancing. Both intra- and inter-domain
    applications are covered.

  • In cooperation with the TEAS Working Group, development of PCE-
    based architectures for Traffic Engineering including PCE as a
    Central Controller (PCECC) and Centralized Control Dynamic Routing
    (CCDR). The PCEP extensions are developed in the PCE Working Group.

  • In cooperation with protocol-specific Working Groups (e.g., MPLS,
    CCAMP), development of LSP signaling (RSVP-TE) extensions required
    to support PCE-based path computation models.

  • Specification of PCEP extensions for expressing path computation
    requests and responses in the various GMPLS-controlled networks,
    including WSON and Flexible Grid.

  • Specification of PCEP extensions for path computation in multi-layer
    and inter-domain networks.

  • Specification of the PCEP extensions used by a stateful PCE for
    recommending a new path for an existing or new LSP to the PCC/PCE.
    Further protocol extensions must cover the case where the receiving
    PCC/PCE chooses not to follow the recommendation. The PCEP
    extensions for state synchronization are also in scope.

  • Specification of the PCEP extensions for SR-MPLS and SRv6 paths as
    per the SR Policy architecture in cooperation with SPRING Working
    Group.

  • Specification of the PCEP extensions for new path setup types (such
    as BIER and DETNET) in cooperation with the respective Working
    Groups.

Milestones

Date Milestone Associated documents
Mar 2026 Evaluate WG progress, recharter or close
Jul 2025 Submit PCECC extensions
Apr 2025 Submit PCEP extensions for Multipath as Proposed Standard draft-ietf-pce-multipath
Mar 2025 Submit State-sync extension as Proposed Standard draft-ietf-pce-state-sync
Feb 2025 Submit SR-Algorithm Extension as Proposed Standard rfc9933 (was draft-ietf-pce-sid-algo)

Done milestones

Date Milestone Associated documents
Done Submit Enhancements to Stateful PCE rfc9753 (was draft-ietf-pce-stateful-pce-optional)
rfc9863 (was draft-ietf-pce-pcep-color)
rfc9752 (was draft-ietf-pce-stateful-pce-vendor)
Done Submit PCEP extensions for SR Policy as Proposed Standard rfc9862 (was draft-ietf-pce-segment-routing-policy-cp)
Done Submit PCEP YANG Model as a Proposed Standard rfc9826 (was draft-ietf-pce-pcep-yang)
Done Submit PCEP Native-IP extensions as a Proposed Standard rfc9757 (was draft-ietf-pce-pcep-extension-native-ip)