Path Computation Element (pce)

The PCE working group is responsible for the Path Communication Element Communication Protocol (PCEP).  PCEP allows a Path Computation Client (PCC - for example, a head-end router) to request paths from, or have paths created by, a Path Computation Server (PCE).

The WG is actively working on adding to PCEP the concept of an "association group" which binds together arbitrary sets of LSPs and/or policies for the purposes of path computation.  The base draft for this [1] is very flexible and allows for many follow-on innovations, ranging from associations reflecting common policies to those mandating resource diversity and other relationships such as bidirectionality and resource sharing. Another significant piece of work in progress is the extension that allows a PCE to act as a central controller, by instantiating path state on each hop in an LSP [2] and using a flow specifier to add traffic classification to the head-end node of the LSP [3].

There have been some new proposals to clarify RFC 8231 as well as refinement to stateful PCE extensions for state synchronisation between stateful PCEs [4] and relaxing constraints [5].

[Last Updated: August 08, 2019.]

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/
[2] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
[3] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/
[4] https://datatracker.ietf.org/doc/draft-litkowski-pce-state-sync/
[5] https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-optional/

The PCE working group is responsible for the Path Communication Element Communication Protocol (PCEP).  PCEP allows a Path Computation Client (PCC - for example, a head-end router) to request paths from, or have paths created by, a Path Computation Server (PCE).

The WG is concluding the recent effort on generalizing PCEP to include segment routing paths for an MPLS data plane [1].  Another piece of work reaching its conclusion is the extension of PCEP for GMPLS networks [2]. 

The WG is progressing the work related to use of PCE (and PCEP) for the hierarchy of controllers (as per the Abstraction and Control of TE networks (ACTN) framework). We are also concluding the protocol extensions to allow for a hierarchical structure of PCEs (H-PCE) which provides a parent PCE to coordinate the operation of per-domain child PCEs [3]. We have made progress in moving the Stateful operations for P2MP TE tunnels [7] (used by Multicast applications) and automatic bandwidth adjustments [8]. 

The WG is actively working on adding to PCEP the concept of an "association group" which binds together arbitrary sets of LSPs and/or policies for the purposes of path computation.  The base draft for this [4] is very flexible and allows for many follow-on innovations, ranging from associations reflecting common policies to those mandating resource diversity and other relationships such as bidirectionality and resource sharing. Another significant piece of work in progress is the extension that allows a PCE to act as a central controller, by instantiating path state on each hop in an LSP [5] and using a flow specifier to add traffic classification to the head-end node of the LSP [6].

[Last Updated: March 26, 2019.]

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/
[2] https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/
[3] https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/
[4] https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/
[5] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
[6] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/
[7] https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/
[8] https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-auto-bandwidth/

The PCE working group is responsible for the Path Communication Element Communication Protocol (PCEP).  PCEP allows a Path Computation Client (PCC - for example, a head-end router) to request paths from, or have paths created by, a Path Computation Server (PCE).

The WG is concluding the recent effort on generalizing PCEP to include segment routing paths for an MPLS data plane [1].  Another piece of work reaching its conclusion is the extension of PCEP for GMPLS networks [2].  We are also concluding the protocol extensions to allow for a hierarchical structure of PCEs (H-PCE) which provides a parent PCE to coordinate the operation of per-domain child PCEs [3].

The WG is actively working on adding to PCEP the concept of an "association group" which binds together arbitrary sets of LSPs and/or policies for the purposes of path computation.  The base draft for this [4] is very flexible and allows for many follow-on innovations, ranging from associations reflecting common policies to those mandating resource diversity and other relationships such as bidirectionality and resource sharing. Another significant piece of work in progress is the extension that allows a PCE to act as a network controller, by instantiating path state on each hop in an LSP [5] and using a flow specifier to add traffic classification to the head-end node of the LSP [6].

[Last Updated: November 8, 2018.]

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/
[2] https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/
[3] https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/
[4] https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/
[5] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
[6] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/

The PCE working group is responsible for the Path Communication Element Communication Protocol (PCEP).  PCEP allows a Path Computation Client (PCC - for example, a head-end router) to request paths from, or have paths created by, a Path Computation Server (PCE).

The WG is concluding the recent effort on generalizing PCEP to include segment routing paths for an MPLS data plane [1].  Another piece of work reaching its conclusion is the extension of PCEP for GMPLS networks [2].  We are also concluding the protocol extensions to allow for a hierarchical structure of PCEs (H-PCE) which provides a parent PCE to coordinate the operation of per-domain child PCEs [3].

The WG is actively working on adding to PCEP the concept of an "association group" which binds together arbitrary sets of LSPs and/or policies for the purposes of path computation.  The base draft for this [4] is very flexible and allows for many follow-on innovations, ranging from associations reflecting common policies to those mandating resource diversity and other relationships such as bidirectionality and resource sharing. Another significant piece of work in progress is the extension that allows a PCE to act as a network controller, by instantiating path state on each hop in an LSP [5] and using a flow specifier to add traffic classification to the head-end node of the LSP [6].

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/
[2] https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/
[3] https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/
[4] https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/
[5] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
[6] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/

Changed milestone "Submit the discovery MIB to the IESG to be considered as a Proposed Standard", set due date to April 2014 from February 2012, added draft-ietf-pce-disc-mib to milestone

Changed milestone "Submit the PCEP MIB to the IESG to be considered as a Proposed Standard", set due date to January 2014 from January 2012, added draft-ietf-pce-pcep-mib to milestone

Changed milestone "Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard", set due date to November 2013 from February 2013

Changed milestone "Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard", set due date to September 2013 from June 2012, added draft-ietf-pce-gmpls-pcep-extensions to milestone

Changed milestone "Submit PCE P2MP PCEP protocol extensions to the IESG to be considered as an Proposed Standard RFC", set due date to December 2008 from December 2008

Changed milestone "Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard", set due date to December 2005 from December 2005

Changed milestone "Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard", set due date to December 2005 from December 2005

Changed milestone "Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC", set due date to December 2005 from December 2005