2.5.8 Path Computation Element (pce)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-17

Chair(s):

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
Element
(PCE) based architecture for the computation of paths for MPLS and
GMPLS
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
domain
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
the
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
PCEs.
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
path
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
involving
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
WGs.

- 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:

Feb 05  Submit first draft of PCE architecture document
Feb 05  Submit first draft of PCE discovery requirements and protocol extensions documents
Apr 05  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

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Path Computation Element (PCE) Working Group - 03/07/2005 - IETF-62 - Minneapolis

Thanks to Jaudelice De Oliveira and Zafar Ali for having taken the minutes.

CHAIR REPORT
------------------------

Work group established, WG should concentrate on first milestones: G/MPLS TE and Simple configurations (Inter-area TE) first

Milestones have very aggressive timeline

Applications for PCE: Encouraged to continue to work on applications for PCE (though out of scope for the moment). Not to expect to become WG document, but encouraged to work on future applications.

Work in progress to be presented today:

- Draft on PCE architecture
- Draft on PCE discovery requirements and protocol extensions
- Draft on PCE communication

Immediate next work:

Draft on PCE communication protocol specification
Draft on PCE discovery protocol
Draft on objective metrics

End of chair report
-------------------

Question from audience on objective metrics: Metrics to evaluate PCE.

JP gave a few examples of metrics of interest:
E.g., How fast you can respond to topology changes, etc.


First presentation: draft-ash-pce-architecture-01.txt, Jerry Ash
----------------------------------------------------------------------------

Drafts discusses terminology, assumptions, motivation, architectural considerations, security & confidentiality and evaluation metrics.

Issued raised on the list - already responded (text added to several sections with respect to every comment)

added to 6.4: PCE should advertise capabilities
added to 6.6: Path computation request include if near-disjoint paths acceptable
added to 6.7: TED information can include info from sources other than IGP
added to 6.8: elaborate on advantages of stateful PCE & pitfalls of using stateful PCE in a distributed PCE environment
added to 7: Further metrics proposed to evaluate PCE solutions


next steps: propose draft as PCE WG draft

Questions raised:
------------------
Question: Concern raised on how feasible is the considered approach (stateful PCE).

An element performing optimal computational might take infinite time to do so. Concern about delegating the distributed control plane responsibility to PCE.

Question on possibility of unsolicited requests
PCC-to PCE request/PCE-PCC reply or also unsolicited requests possible?

PCE-PCE communication: communicating paths exchange only or other is it possible to communicate other info as well?

Are there specific requirements on response time of PCE? (for global optimization)

JP: will be part of the evaluation metrics.

Kireeti: need to be careful with pce, not trying global optimal solution stateful x stateless: can't keep all info on lsps (costly)

Dimtri asked a question on stateful vs. stateless PCE in the document; how feasible is stateful PCE? Is it reasonable to assume stateful PCE?

Jerry: yes for some applications.

Dimitri: Is this can be assumed manageable? Given control to PCE that is otherwise done by a distributed control plan.

JP added: It’s applicable for some applications requiring global optimization.

Kireeti: (Global Optimality) is NOT a good target. Stateful PCE provides lot of complexity, while nice- not feasible.

Dimitri: Concerning global optimization, raises issue about the trigger and maintenance of this process (responsibility) that is now pulled outside of the local node and delegated to a third party -> therefore there is now a system impact in terms of performance of the global system

JP: Evaluation Metric is to be used for this purpose.

Dimitri: but these are not evaluation metrics in terms of computation results these are specific metrics for evaluating the correct behaviour of the system

JP agreed on the fact that it is out of the scope to make algorithmic evaluation.

Igor: Similar comments for stateful vs. stateless.

Adrian: ITU-T also requires similar functionality. Liaison Statement to ITU-T is completed. We think SG-15 would be a good start.

J. Sadler: Yes, there is similar work pursued at ITU-T. G7715 on ITU-T has similar function.

JP Polled the audience for the Architecture document.

JP: Majority in favor it as a WG document. We will confirm at the mailing list.


Second presentation: draft-leroux-pce-discovery-reqs.txt, Jean-Louis
------------------------------------------------------------------------------------
PCE Discovery requirements

The draft addresses PCE discovery within and across domain(s).

Remaining issues:

Address comments received in the next version

* Need to improve security particularly for Inter-AS PCE discovery
* Discovery of dynamic parameters such as the PCE CPU state
* PCE aliveness detection

Consensus for a WG doc?


Questions raised:
---------------------

Kiretti: Discovery of PCEs: better rely on PCC-PCE communication?

comment2: If there is a need, routing is a better place than signalling.

JP reminded that the document is just identifying requirements but not solutions.

Confusion on slide showing ABR acting as PCEs (PCEs seem not needed). How did the 60 seconds rule was defined? Need to include how that was decided.

Dimitri: Are we not already overloading the PCEs? Need to define the right level of abstraction... It is an open question. Needs further discussion. Correct architecture design is required to address the overload problem before hand.

Adrian: Reminder that the draft is in its first version.

Kireeti: Re: flooding dynamic state of the PCE, if PCE discovery includes CPU load factor, it will complicate the PCC system.

Dimitri: you haven’t design the system and are worried about the overloaded system. General problem of the overload should be solved at the root (architecture). The sense in which i used the term architecture is not exactly the same as the one used per this doc. here i do refer to the set of the protocol mechanisms and underlying operations - not the global framework architecture

Tony Li: As far as process is concerned, start off with a good requirement document, enumerate minimum set of requirements. What you got right now is iteration from the solution space. Focus on minimal requirements and what is the basic problem we are trying to solve.

Adrian: This was only first revision of the document.

Igor: We need to advertise backup PCE, why backup PCE and not load-balanced.

Jean-Louis: The SP thinks that having a dedicated backup could also be useful. But this is optional.

JP: Few sensitive topics like advertisement of dynamic capability needs more discussion on the mailing list.

Richard Rabbat: Not all ABR are PCE in your Figure.

Jean-Louis: It is just an example case used for illustration purpose only.

Richard Rabbat: How did you come up with 60 second requirement?

Jean-Louis: There are number of SP on the ID and we think 60 sec is a good target. Will provide more details on this.

Dimitri: Does these requirements covers inter-AS case?

Jean-Louis: Yes.

Dimitri: Today, overloading cases may occur as part of a label switch router - and we just start discussions concerning the overload problems - as we have after several years of active work the conditions where the (distributed) overload occurs, therefore should we worry about PCE overload instead of focusing on the right level of detail at this point in time. We need to make sure that right level of details are provided in the document. The basic stuff like, how to find reachable addresses is not there in the document. We don’t have basic stuff in the document.

Jean-Louis: No reachability stuff is detailed in the document. There is mention of domain ID-es: area-ID & AS number.

JP: This is not a flushed out version. Thanks to DT for their effort in putting this together. Requires more discussion in the mailing list before asking to adopt this ID as a WG document.


Third presentation: draft-ash-pce-comm-protocol-reqs-00, Jerry Ash
-----------------------------------------------------------------------------------------------
PCE/PCE Communication requirements (PCC-PCE & PCE-PCE)

Various issues raised on the list: for example extensive discussions about re-use of RSVP object encodings


Questions raised:
-------------------------

Arthi: Is there a requirement of unsolicited PCE to PCC communication.

Zafar: Yes, there are cases where unsolicited PCE to PCC communication is required.

Many: Is it suitabe to list candidates on this documents?

JP: candidates are out of the scope of this protocol. Document is a very first cut.

Kireeti: Stateless x stateful. There are needs and there are benefits.

Comment: Contradiction, scalability reqirements.

Dimitri: on QOS/ CAC in the slides, do you also expect PCE to make decision that is related to the forwarding plan?

Jerry: The intension was to mention requirement to include some QOS parameters in the PCC-PCE messages.

JP: clarified that the intention was to include possibility of QoS considerations in path computation.

JP/ Jerry: I.e., Path Computation Constraints related parameters.

Kireeti: On GR of PCE: When it comes to GR, there is a huge difference between stateful and stateless PCE. Recommend to put it in an applicability statement.

JP: Yes, complexity analysis is meant for this purpose.

Adrian/ JP: Estimates some work to flush-out details. It’s a huge list of requirements. We want to handle simple problem first. Candidate protocols are not considered or within scope.

Zafar: Relationship with other WG-es.

Adrian: Initial thought is to get such input from CCAMP. E.g., GMPLS usage of PCE, inter-domain stuff is example of cases where input from CCAMP is needed.

Dimitri: what about the reachability of PCE location(s) for non-IP terminating nodes.

Adrian: GMPLS requirements from CCAMP.

Conclusion: Needs more discussion on the list. This document will be the basis of the work.

Other discussions:
---------------------------
CCAMP was to provide areas where PCE would be useful. There is already a draft on the GMPLS use of PCE.

JP mentioned that many of the drafts were posted recently and did not have a slot in this meeting mostly because the focus was on the main documents and to flesh out the requirements.

JP/ Adrian: Many of the drafts were put in and right now we are flushing out first milestone. Other applications will be addressed later. Charter at present does not include candidate (solutions). Questions like what layer PCE should work on? Should PCC-PCE be based on a reliable transport? TCP is reliable, is it a candidate? are among the question charter addresses.

Discussion on statement on the requirement of reliability.

Dimitri: The biggest question is if we can use RSVP for PCC-PCE communication.

Zafar: It’s funny that when we talk about IGP-es, people settle with what we have today, and when it comes to signaling we tend to have such a large diversion. In my opinion signaling is a very small piece of the overall architecture and we should make use of what we have today.

Dimitri: But RSVP is designed for end-to-end (session) signaling and not a PCC-PCE client-server exchange. Instead, what about considering communication relying on the transport layer (TCP)

Zafar: Let’s be clear on what we mean here. We are talking about use of RSVP for encoding. At the transport level we can still rely on TCP.

Kireeti: Not for RSVP as PCC-PCE protocol. It’s not defined for this purpose.

Zafar: We know that PCC is going to signal using RSVP-TE, why not provide information encoded in RSVP format to minimize useless copying of the data (from one format to the other).

Kireeti: Not all objects are defined for RSVP today.

Zafar: The new objects can be defined. There are also other applications for the use of the objects require by PCE.

Dimitri: considering these objects on the PCE does not provide more rationale for considering RSVP as communication protocol between the PCC and the PCE

Kireeti: Well, this is convoluted; we don’t have support for all so let’s extend RSVP, which is not designed for this purpose.

Mathew: PCC-PCE is a client server protocol. We’ve a lot of other client server based protocols. I recommend taking a look at such protocols.

Concern/Comment on RSVP usage and PCC-PCE communication

JP: Mention discussion of the design team on using RSVP encoding without using RSVP itself

JP: Opinions about future candidates are welcome and the final coomunication will of course be the result of the WG consensus

* Comment/confusion on PCC being a node/client
* Comment agreeing with Dimitri
* Constraint that you can communicate using RSVP today. Agreeing with Dimitri that we should first specify the needs/requirements.
* Comment on not excluding options that are not available today

Conclusion: To Continue on the mailing list

Dimitri: Question on the discovery of the PCE (possibility of proliferation mechanism for PCE discovery).

JP and Adrian.

Slides

Agenda
Path Computation Element (PCE) Architecture
Requirements for PCE Discovery
PCE Communications Protocol Requirements