2.6.10 Path Computation Element (pce)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-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 2005  Submit first draft of PCE discovery requirements and protocol extensions documents
Done  Submit first draft of the PCE communication protocol requirements
May 2005  Submit first draft of the definition of objective metrics
Jul 2005  Submit first draft of the PCE communication protocol specification
Aug 2005  Submit PCE architecture specification to the IESG to be considered as Informational RFC
Nov 2005  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 2005  Submit first draft of the MIB module for the PCE protocol
Dec 2005  Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC
Dec 2005  Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard
Dec 2005  Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard
Feb 2006  Submit the applicability and metrics documents to the considered as Informational RFCIESG to be
Feb 2006  Evaluate WG progress, recharter or close


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

    No Request For Comments

    Current Meeting Report

    Draft of the PCE Working Minutes - IETF-64 - Vancouver, November 2005
    Chairs: JP Vasseur, Adrian Farrel	
    Thanks to Richard Rabbat and Scott Brim for the notes.
    1) Agenda/admin (Chairs-5mn)
    2) PCE WG Milestone update (Chairs-10mn)
    JP> discussed status of drafts 
    See the slides for content.
    3) PCE Policy Architecture,
    draft-berger-pce-policy-architecture-00.txt (Lou Berger - 10mn)
    See the slides for content.
    - Most of the text could be incorporated in the architecture
    reference scenarios; some text could be put in PCE framework document,
    - Non exhaustive list of scenarios,
    - Looking for more scenarios from the participants
    George Swallow> policy will be the dominant part of architecture for PCE to take off.
    JP> Policy is certainly a MUST for some scenario, not for all. For example, 
    for inter-area: no need for policy, for inter-provider: clear need.
    Adrian> on slide 2, slides only cover communication; what do you have to say about discovery?
    Lou> policy may guide which PCE to use; discovery has to support policy 
    but how this is done is outside the scope
    Dimitri> question for JP; you may use it in intra-domain as well
    JP> the policy module may not be required in every case; it was just an example
    Adrian> fold some of it in architecture and other in framework
    Next steps: 
    Authors think that they don't want to continue with an independent draft. Suggestion to 
    integrate parts within the architecture ID with scenarios in a framework document
    4) Path Computation Policy 
    draft-bryskin-pce-policy-enabled-path-comp-00.txt (Igor Bryskin- 20mn)
    See slides for content.
    Igor> it is not requirements, but the goal is to introduce the need for policy 
    in path computation (e.g.: one path may require minimum delay; other would require shorted path)
    Richard Rabbat> we may need to re-visit last-called drafts
    Igor> which ones?
    Adrian> true, we may need to do due diligence on pce discovery requirements and architecture ID.
    Igor & JP agreed
    Lou> we think there should be minimal impact.
    Lou> note PDP, PEP and COPS are just examples.
    Dimitri> can you tell us how we're going to make progress on pcim?
    Igor> we will meet with pcim people
    JP> Who has read the draft ? 
    10 people have read Igor's draft.
    Next steps:
    JP> that concludes the discussion; we need to work on framework
    Adrian> we talked about updating architecture; we need to look at requirements documents 
    and make sure they take policy into consideration. Generate a framework document.
    Adrian> consider the scenarios and solutions independently
    5) Discussion on the PCE Discovery protocol (Jean-Louis Le Roux - 15mn)
    See slides for content
    JP> one of the strengths is that you use existing ISIS Router capability TLV and 
    OSPF Router Information LSA with no change in term of elements of procedures.
    JP> it's fair to make the assumption that it could be easily used
    Dimitri> we may need another protocol for extensions?
    JL> in inter-area application, it's a good solution
    JP> we need feedback from working group
    JP> are we happy to use IGP as discovery mechanism?
    Igor> discovery can be used to learn about policy
    JP> have more discussion on the ML
    JP wants feedback from the WG.  Is this useful?  Is it to good to
    use the IGP to do that?  
    Someone> Does the PCE have to run IGP ?
    JL> yes, assumes PCE is LSR or server running an IGP instance.
    JP> Who is in favor of *allowing* the use of an IGP for PCE discovery?
    Adrian> are we happy to standardize the use of IGPs as a discovery mechanism?  
    Igor> using IGP is just one way.
    Consensus in the room to start using the IGP for PCE discovery
    Next steps
    WG document adoption to be confirmed on the list.
    6) PCECP discussion and next steps (Adrian)
    See slides for content
    Lou> it would be very useful to separate out the transport aspects of the protocol 
    to the functionality needed; we care about what information is passed back & forth 
    from the actual transport protocol; if there are concerns we can fix either.
    Adrian> is this the transport area that you're talking about?
    Lou> it would be useful if we knew what information we need to carry
    Adrian> you don't think the reqs document has this information?
    Lou> it is not clear. There are parts that need to be in the solution draft; 
    they are in the pcep document all over the place
    Adrian> is this an editorial comment?
    Lou> no. if we're clear on the problem we're solving, that's great.
    Lou> what have we heard from the app area?
    Adrian> entire communication with one response from one individual
    Lou> take whatever decision we make and tell them about
    Adrian> we will communicate with them but not be blocked by them
    Lou> Agree
    Dimitri> within selection process, would one solution fit all? we need the flexibility 
    to use tcp so we can communicate with whatever kind of pce we envision. Wrt to cops, there 
    was pushback but no understanding why. Is this a concern of the transactional model?
    Adrian> heard 2 things:
    	1. applicability-driven question: hard to assess applicability sometimes; a good 
               motivation is that this option is really good for this application; let's not 
               optimize for a particular application
    	2. you felt there was a pushback against an option; I invited people to push 
               forward for their solution; but I only heard back once
    Dimitri> we can't respond without knowing why there was pushback?
    Adrian> I didn't see pushback for any protocol; didn't see support for protocol x except PCEP.
    Dimitri> the proposal from Lou makes sense
    JL> we try to solve simple problems; not sure we should de-correlate the 2 sections
    Adrian> You can look at rsvp at transport protocol
    Lou> Application protocol is a better term
    JL> I'm not sure we can de-correlate the 2
    Adrian> we need to remodel the pcep document
    JL> we don't have the state machine; it will be added
    Adrian> follow the RFC that explains how to write protocols in following the list
    Andrew Dolganow> most of the comments were for pcep protocol to fix
    Adrian> if we have an option on the table that fits all of what I said on my slide, 
    that would be great
    Igor> if we're talking about encryption and authentication, we should be able to 
    change the transport without the information we carry
    Dimitri> we are all in agreement that we want to work on the solution. e.g. udp vs tcp? 
    if we look at the protocol needed in a modular way, we can then make decisions on each module 
    JL> we do that already
    Adrian> both requirements and solution need to be restructured?
    Dimitri> requirement document could have been written another way but focus is solution
    Next steps
    Adrian> Consensus?  Who would be upset if we chose to progress PCEP with the necessary 
    restructuring and recasting that we have  discussed?  
    Adrian> Does anyone want to ask a different question?
    Adrian> To be confirmed on the list.
    7) Inter-area PCECP requirement draft (Jean-Louis Le Roux - 10mn)
    See slide for content.
    JL> Need working group feedback.  Will produce shorter version for end of November; 
    move generic requirements to generic I-D.  
    Richard> you talk about FRR. Can you make the draft consider GMPLS as well?
    JL> yes
    JP> by how much are you willing to reduce the draft?
    JL> target is reduce to 10 pages
    JP> Thanks, please only keep the inter-area specific aspects and move other requirements 
    in the generic requirement ID
    Dimitri> are these requirements related to the procedure that you will follow? 
    Are you going to be path-coupled or decoupled?
    JP> decoupled.  
    Dimitri> you're expecting that you will get the whole path, not a partial path. 
    It has been suggested to use this or that pce if you're going to compute the path
    JP> you raise a good point. please open up the discussion on the list.
    JP> Is this a good basis to start the discussion?
    Substantial number of people raised their hand in support.
    Next steps
    JP> I see large support and will take it to the list of course 
    8) Inter-AS/Provider PCE requirement draft (Nabil Bitar - 10mn)
    See slides for content
    Richard> language from RFC 2119 is used very liberally. 
    JP> we need to split that ID
    1. Pieces that relate to Inter-domain PCE discovery requirements
    2. Quite a few sections relate to applicability, not requirements
    Dimitri> are we going to put inter-as and inter-provider or not in the discovery?
    JP> it should cover both; Nabil and JL would discuss things on the mailing list
    JP> can we ask for an applicability ID ? Good time to start working on it?
    JL> yes
    JP> can you look at your draft and integrate applicability sections in this ID ?
    JL> yes
    JP> keep some in this document
    JP> some could be incorporated in the generic id
    Nabil> we decided to be exhaustive then move things to appropriate sections, IDs
    JP> Please talk to Lou about policy
    Lou> framework should consider all requirements
    Dimitri> in inter-as, especially inter-provider, it's difficult to block resources to successfully set up a path
    JP> we should probably consider it in an applicability ID
    Nabil> there is a requirement for CAC?
    Dimitri> yes, but we need to make sure that all pieces fit
    Nabil> some of these issues relate to path computation requirements and don't have a home right now
    Next Steps
    JP> Too early for WG document adoption.
    JP proposed to split the documents in multiple pieces:
    - Inter-AS PCE discovery (see also with JL)
    - Inter-AS policy (see framework ID with Lou)
    	- Inter-AS PCECP requirements (should stay in this document)
    	- Applicability statement
    9) Discussion on inter-layer deployment scenario, similarities with inter-area/AS, 
    application specific requirements
    draft-oki-pce-inter-layer-req-00.txt (Eiji Oki - 10mn)
    See slides for content
    JP> who read the draft?
    About 20 people raised their hand
    JP> who supports it becoming a WG draft?
    About the same number
    JP> good consensus; we'll take it to the list
    10) Cost object
    draft-dolganow-pce-cost-object-00.txt (Andrew Dolganow - 10mn)
    See slides for content
    JL> good to separate rsvp processing and pcep processing.  We have in ccamp another draft 
    that is similar in purpose but for the backward direction. may need to put things together
    Igor> I object to this work; you may need to come up with a huge number of elements 
    Andrew> in most implementations, there is a desire to achieve an optimal path based on cost metrics. 
    Lou> you have cost as part of rsvp and pcep (separate). what's the purpose of it in RSVP ? 
    Andrew> you need it for path optimization
    Lou> having accumulated cost doesn't help you
    Andrew> it's out of scope
    JP> take it to the list
    Lou> we don't define things without use
    JP> any work about RSVP belongs to CCAMP, not in the PCE WG.
    Andrew> an example application is to refuse a connection if the cost goes too high
    JP> a lot of work to be done
    11) Next Steps (JP - 10mn)
    Final: next steps:
    Finalize the PCE architecture ID (with policy) and issue a WG LC
    Select a PCECP
    JL will respin the PCE discovery ID (with small update to cover policy and inter-domain) 
    followed by incremental WG LC
    Confirm the use of IGP as one PCE discovery technique 
    PCECP generic requirements - JL will respin.  
    PCEP inter-area specific - good consensus to adopt as WG document to be confirmed on the mailing list. 
    JL will then respin
    PCEP inter-layer document - good consensus to adopt as WG document be confirmed on the mailing list. 


    PCE WG Milestone update (Chairs)
    PCE Policy Architecture - Lou
    Path Computation Policy (Igor)
    Discussion on the PCE Discovery protocol (JL)
    PCECP discussion and next steps
    Inter-area PCECP requirement draft (JL)
    Inter-AS/Provider PCE requirement draft (Nabil)
    Discussion on inter-layer deployment scenario (Eiji)
    Cost object (Andrew)