2.5.10 Path Computation Element (pce)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-05-20


Adrian Farrel <adrian@olddog.co.uk>
JP Vasseur <jpv@cisco.com>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Alex Zinin <zinin@psg.com>

Mailing Lists:

General Discussion: pce@ietf.org
To Subscribe: pce-request@ietf.org
In Body: subscribe pce
Archive: http://www.ietf.org/mail-archive/web/pce/

Description of Working Group:

The PCE Working Group is chartered to specify a Path Computation
(PCE) based architecture for the computation of paths for MPLS and
Traffic Engineering LSPs.

In this architecture path computation does not occur on the head-end
(ingress) LSR, but on some other path computation entity that may
physically not be located on the head-end LSR.

The PCE WG will work on application of this model within a single
or within a small 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
Internet is not thought to be possible, and the PCE WG will not spend
energy on that topic.

The WG will specify a protocol for communication between LSRs (termed
Path Computation Clients - PCCs) and PCEs, and between cooperating
This protocol will be capable of representing requests for path
computation including a full set of constraints, will be able to return
multiple paths, and will include security mechanisms such as
authentication and confidentiality.

The WG will determine requirements for extensions to existing routing
and signaling protocols in support of PCE discovery and signaling of
inter-domain paths. Candidate protocols for extensions are RSVP-TE,
OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in
collaboration with the Working Groups responsible for the protocols.

The Working Group will also work on the definition of metrics to
evaluate path quality, scalability, responsiveness and robustness of
path computation models.

Work Items:

- Functional specification of MPLS and GMPLS Traffic Engineered LSP
computation models involving Path Computation Element(s). 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. The WG will address
the inter-area (single IGP domain) scenario first. WG progress will be
evaluated before inter-AS related work is started.

- Specification of the PCE-based architecture.

- Specification of requirements and protocol extensions related to
the policy, and security aspects of PCE-based path computation
PCEs of multiple administrative entities.

- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,
MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP
signaling (RSVP-TE) extensions required to support PCE-based path
computation models.

- Specification of techniques in support of PCE discovery within and
across domains. Where such techniques result in the extensions of
existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in
conjunction with the appropriate WGs.

- Specification of a new communication protocol for use between a PCC
and a PCE, and between PCEs. A single protocol will be selected from
among candidates that include the existing protocols defined in other

- Definition of objective metrics to evaluate various criteria such as
the measurement of path quality, response time, robustness and
scalability of path computation models.

Review of the document "Requirements for path computation element in
GMPLS inter-domain networks" produced by the CCAMP WG.

Goals and Milestones:

Done  Submit first draft of PCE architecture document
Feb 05  Submit first draft of PCE discovery requirements and protocol extensions documents
Done  Submit first draft of the PCE communication protocol requirements
May 05  Submit first draft of the definition of objective metrics
Jul 05  Submit first draft of the PCE communication protocol specification
Aug 05  Submit PCE architecture specification to the IESG to be considered as Informational RFC
Nov 05  Submit first draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering)
Nov 05  Submit first draft of the MIB module for the PCE protocol
Dec 05  Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC
Dec 05  Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard
Dec 05  Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard
Feb 06  Submit the applicability and metrics documents to the considered as Informational RFCIESG to be
Feb 06  Evaluate WG progress, recharter or close


  • draft-ietf-pce-architecture-01.txt
  • draft-ietf-pce-comm-protocol-gen-reqs-01.txt
  • draft-ietf-pce-discovery-reqs-01.txt

    No Request For Comments

    Current Meeting Report

    PCE Working Group meeting minutes 
    IETF-63 - Paris, France - Tuesday, August 2, 2005.
    (Thanks to Jaudelice and Deborah for having taken the minutes)
    1. Agenda (Adrian)
    1) Agenda/Admin (10mn)
    2) Progress against milestones (5mn)
    3) Drafts (55mn)
    	- draft-ietf-pce-architecture-01.txt (Farrel - 10mn)
    	- draft-ietf-pce-discovery-reqs-01.txt (Le Roux -  10mn)
    	- draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 10mn)
    	- draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn)
    	- draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn)
    	- draft-choi-pce-metric-protocol-02.txt (Choi - 10mn)
    4) Working Group next steps (20mn)
    2. Progress against Milestones (JP)
    1. Submit first draft of PCE architecture document: done
    2. Submit first draft of PCE discovery requirements and protocol extensions documents
       (half-done: PCE discovery requirements ID is done)
    3. Submit first draft of the PCE communication protocol requirements (done)
    4. Definition of the objective metrics (to be done later - more progress required on other
    IDs first)
    5. PCE communication protocol specification (decision to be made by the WG soon)
    PCE Architecture ID: draft-ietf-pce-architecture-01.txt (Adrian)
    Adrian thanked everyone that contributed to help get this version out
    Mainly editorial revisions resulting from Minneapolis meeting have been done (Clarifications, but nothing major)
    More a framework, and an architecture overview and deployment scenarios. 
    Describes the architectural overview and building blocks
    Many mailing list comments and private comments
    Not any major substantial changes
    Plan to add discussion of policy, will separate exchange of policy info in the PCE communication and the use of policy within the architecture
    Question (?): present a functional view as well as component view?
    Adrian: currently view point is third dimension
    Arthi: policy: how will it be addressed in the document?
    Adrian: the current doc will only have something high level. Lou will provide draft text
    Igor: when I issue a path request, can I disallow paths requiring distributed computation, 
    Adrian: that's something for the computation
    Dimitri: is this the only document for policy or we will do something else ?
    JP: we need requirements and solution detailed in a separate ID.
    Lou: we had discussion, as Adrian said, we will have later a standalone document with more details after we have more discussion in the WG
    Dimitri: Other WG have shown that the main pre-occupation for RSVP-TE as inter-domain signaling protocol is the policy at the domain boundaries therefore is it an essential element this WG must address
    Adrian: agree
    Igor: I disagree with the current definition of the distributed path computation.
    In the document:
    centralized path computation = computation performed by a single PCE
    distributed path computation = computation performed by multiple PCEs
    In my opinion:
    centralized path computation = path computation that returns all requested
    paths in the *explicit* form in the first response, so that no more
    requests will be needed neither from the original requestor nor from any
    other PCCs for the service in question
    distributed path computation is when the original path computation request
    is responded with at least one non-explicit path, so that more path
    computations will be issued from the original or some other PCCs.
    In other words from the original requestor point of view (which is
    ultimate user of the PCE service) it does not matter how many PCEs will be
    involved to satisfy its request, what is important is how many additional
    path computations is needed (0 -centralised
    path computation, >0 - distributed path computation).
    Plans: architecture is believed to be stable but needs discussions resulting from emails on the list.
    Requirements for PCE Discovery: draft-ietf-pce-discovery-reqs-01.txt (Jean-Louis)
    Set of requiretments for automatic pce discovery
    comments and discussions on the list have been addressed in the new version -01
    * multi-area example
    * application scenario
    * reorganized PCE info to be disclosed (mandatory versus optional)
    It must be noted that this is optional in the pce discovery mechanism, not necessarily optional for pce architecture, 
    * extensibility section
    * security requirements
    * PCE capabilities definition is out of the scope (should be in a separate document)
    Open issues:
    - two stage discovery ? should limit to basic or include more detailed - all as part of this document
    - security trust model- need to detail requirements
    - need feedback on discovery of pce power and congestion status- should be part of this discovery mechanism or as part of a more detailed requirements phase?
    Next steps:
    * address open issues
    Dimitri: the question on one or two stages, for me it's the question how many PCCs will subscribe to the initial PCE advertisement- if only a small group of PCCs at each point in time, then a certain number of sessions, with more detailed information, can be supported. Hence, there is a tradeoff, with a small set, a two stage approach with a dedicated for exchanging more detailed information can be used.
    JP: could use a flooding based mechanism
    Dimitri: but what is expected then on the use of this information ?
    Arthi: It is premature to talk about solution. Do we have a sense of what direction we might be taking? On the section on scalability: number of pce pccs are factors but also should consider the load on a pce.
    The details that you have might not be relevant to a PCE.
    Dimitri: should say if the info is of interest to all the PCCs or not
    Arthi: I'm less concerned with the PCE if the PCE is itself a PCC
    Igor: Flooding is good, but it has problems: scalability and security. You still want to know the capabilities of pce so you may need to establish a session.
    JP: we may now be discussing solutions on how to do basic capabilities and additional capabilities
    Igor: we will need this discussion though
    JP: I don't see this as pce discovery, this is a capabilities exchange
    JL: Do you have an idea of a communication protocol
    Igor: It should not be flooding.
    JL: For general discovery we should use flooding.
    JL: You must be able to control to which pcc you will be disclosing the information: all pccs in an area, etc.
    Adrian: the draft though today does include some capabilities
    Dimitri: can you provide more detailed requirements on the dynamics needed for these capabilities?
    JP: A limited number of capabilities such as the congestion parameter is likely to be dynamic
    Richard: propose discuss possible solutions over email exchange, even though it's not to be included in the requirements, the discussion helps to understand
    Arthi: agree should discuss to an extend some of the solutions
    JP: thanks to quickly resolve the set of open issues. The draft should then be ready for Working Group LC.
    PCE Communication Protocol- Generic Requirements
    Generic requirements applicable to all PCEs
    application-specific requirements to be addressed in separate requirements documents
    A table with a summary is included.
    Open Issues
    * requirements for less constrained path requests/response
    * requirements for responsiveness & session maintenance
    * detailed requirements on throttling messages under overload
    * specify 'boundary' numbers on scalability
    * clearly state supported policy models & corresponding requirements/implications
    * avoid feature creep
    * need to progress application-specific requirements
    * PCE  protocol proposal needs to identify how generic & application-specific requirements are met
    JP: Detailed scalability issues are related to implementation.
    Adrian: we need a range as don't want protocol to provide the limit
    JP: on the less-constrained path computation topic, we don't have a consensus yet, we should have a separate document
    Arthi: we had a discussion in the pwe group that there may be requirements for pce
    Adrian: by us splitting the document between generic and extended reqs (more application specific) we could handle this better
    Arthi: also though may not be in scope
    Adrian: yes we should say if it's out of scope
    Arthi: Some new requirements may come up for PCE, we need to have a plan on how to address that.
    Adrian: The document is extensible.
    Arthi: We might see other consumers of PCE
    JP: Sure and the protocol should be designed to handle extensions so as to meet new requirements but we may need to recharter
    PCE Communication Protocol Application Model
    * how to avoid contention with TE link fails
    * how to load balance among PCEs
    * how to update the PCEs about resource allocation
    JP asked who has read the draft: good show of hands
    Adrian: rather than saying this is the way forward, would prefer emphasis on what are the requirements
    Li defeng: this draft addresses a way to ...
    Adrian: yes, this draft has requirements on an implementation, would like first to see top level requirements and architecture
    Igor: one of the requirements for the protocol is getting updates, etc, 
    Adrian: first need requirements
    Igor: my view this is not a signaling protocol, not rsvp, we shouldn't go thru the process of using a signaling protocol
    JL: I have a major concern on scalability with the draft's approach, one major bottleneck is on the PCC-PCE signaling, we should minimize the signaling, the objective is to have distribution to reduce this, whereas this draft re-introduces this overhead for synchronization. You are redefining the concept of cluster. Why not rather use a single PCE and clusterize the PCE engine?
    One major bottleneck on the PCE architecture is the pcc-pce signalling. To ensure path computation, reduce the number of path computation requests received by a pce. 
    Author: it does not consume much bandwidth.
    JL: It is not a problem of bandwidth but communication overhead.
    JP: I have similar concerns. Have you tried to evaluate what would be the overhead in term of extra signaling due to this mechanism? One way to roughly evaluate would be by using simulations.
    Adrian: best for us to discuss over email to provide adequate time for the discussion.
    Path Computation Element (PCE) communication Protocol (PCEP)-
    PCC-PCE and between PCEs communication
    There were two proposals in the past which were discontinued and a completely new protocol has been designed (PCEP) highly driven by the PCE WG requirement document. Chief objective was to make it extensible to cope with future requirements.
    Major changes from 00 to 01:
    * rewritten for clarity
    * few sections removed
    * new section on protocol model
    * added security consideration
    * very rough manageability consideration section added (to be fleshed out)
    * two new objects defined
    Unique communication protocol for PCC-PCE and PCE-PCE.
    Summary: pcep meets most of the requirements.
    Open issues (need inputs from the working group)
    * Objective functions needs to be defined (next revision)
    * Protocol recovery: requires more detailed requirements
    * Policy: requires more discussion
    Bijan Jabbari: What was the reason for TCP?
    JP: reliability and flow control. TCP was a very good candidate for that.
    Bijan: Question of scalability of TCP.
    JP (vendor hat): We do not see any scalability issue with TCP. Current TCP implementations can support a very high number of TCP sessions.
    Richard Rabbat: You are creating a new protocol. Did you do an analysis on existing protocols and reasons for not using them?
    Adrian: yes we did , but here formal requirement for the WG to take reqs to other groups to ask if have anything, so this draft progressing depends on answer.
    Lou: Many protocols have been worked on. Instead of reinventing the weel, why not use one already existing. What we are doing here in path computation is a new application, but session application (keep alive, discovery) have been resolved before and it would be great to concentrate on what is related to pce.
    Adrian: great if we can learn lessons
    Lou: and reuse
    Adrian: agree
    Dimitri: agree as Lou said
    Lou: session management, keep alives, etc have been done already
    JP: the question is, is there anything specifics to PCE that we need a new protocol
    Dimitri: With a new solution we will have to pass all the stages the others have passed to achieve a robust solution. Therefore, protocol solutions already developed by other WGs should be considered and evaluated wrt requirements provided by this working group so as to concentrate on the PCE specifics
    JP: That's why we have the question here. 
    Adrian: yes, this protocol in this draft has not been selected
    Bijan: If this is IP only, was DNS discussed?
    Adrian: this is IP only
    Bijan: have we looked at DNS ?
    Adrian: bring it to the list to suggest
    Lou: Comment on need to go back and use an existing mechanism whenever you can.
    JP: yes, whenever you can.
    Loa: if we have TCP, then we have a basis, to do more, we need justification,
    JP: agree
    Jerry: can you include what is met and not met on requirements into the draft ?
    JP: ok, will do.
    Jerry: Jerry: if we do not have a list of requirements *including application-specific requirements*, how can we proceed *with pcep*?
    JP: PCEP has been designed to be easily extensible to cope with future application-specific requirements.
    Yakov: Comment on the need for protocol specific keep-alive: we need a PCE specific keep-alive protocol since TCP will not take care of it.
    JP: fully agree.
    Lou: You need keep-alive (TCP-based solutions already have keep-alives). Find out what's the requirement, then lift the existing solution.
    Lou: my comment is to look at experience e.g. if need keepalives, it's a mistake to look at this again without considering previous work, and do all the requirements all over again, should look at existing protocols, transaction semantics
    Adrian: yes, persistency should be addressed in the requirements
    Sue: keepalives in a protocol is needed in addition to tcp, need to pay careful attention to the state machine interaction between the two - pcc-pce. Need to ensure handle failure scenarios, noticed missing here some of what protocol has to solve, should feed back into requirements
    JP: Sometimes you do not want a permanent session, and sometimes you do. Do we need two modes? 
    Adrian: question should be asked to the requirements team.
    JL: we should be more flexible and support both request and permanent as it will depend on the request, and number of pces to maintain, may have a full mesh and may not want to maintain a permanent
    JP: this is what we heard: may only need on request, other times will need permanent, so may want both modes, and negotiate upon session establishment.
    Adrian: when doing the solutions and have a question, should take back to the requirements folks
    JP: Less-constrained path computation aspects will be removed from this draft and be worked out in a separate ID.
    Path Computation Element Metric Protocol (PCEMP)-
    (Dipnarayan Guha)
    PCE metric protocol (PCEMP): generic routing and path computation protocol targeted towards inter-domain pce peers.
    Reviewed slides
    JP: we encourage you to provide simulation results to the mailing list it will help
    No discussion
    Comment from Igor: neither of them satisfies the requirement of the extensibility. Introducing new constraints, objection functions, diversity types, etc will be extremely painful. Hence a meta-language style protocol should be considered
    working group next steps (JP)
    - new revision of the PCE architecture ID to be published soon (WG last call soon after this ietf)
    - new revision of the generic pce communication requirement ID (WG last call soon after this ietf)
    - submit a new ID for pce discovery protocol extensions (minor protocol work only)
    Start application-specific requirements IDs for PCE based computation
    *Inter-area: Jean-Louis
    *Inter-As: Raymond, Nabil
    JP: note that such ID must be PCE-specific (take into account RFC4105 and inter-as requirements ID produced by the TE WG).
    Adrian: WG to decide on which pce communication protocol solution to pursue 
    - two proposals presented
    - selection of one solution as a basis now does not imply rejecting good points of other solution nor accepting bad points of selected solutions. 
    If pick one, that does not prevent us from taking the best of other one also, and also other ietf protocols. email will be sent to the application ADs to ask their input.
    - New ID on the less contrained path problem comprising the requirement + solution
    - Need to verify the solution model for inter-domain pce with CCAMP, MPLS working groups
    Adrian: other application specific requirements IDs (interlayer, p2mp) should continue their work, just realize other work needs to be done first:
    	inter-layer: Eiji, Kenji
    	P2MP: Seisho (currently out of scope of PCE WG charter)


    draft-ietf-pce-architecture-01.txt - Farrel
    draft-ietf-pce-discovery-reqs-01.txt (Le Roux)
    draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash)
    draft-zhang-pce-comm-app-model-01.txt (Zhang)
    draft-vasseur-pce-pcep-01.txt (Vasseur)
    draft-choi-pce-metric-protocol-02.txt (Choi)