Fwd: WG Action: Path Computation Element (pce)

[JP Vasseur <jvasseur@cisco.com>]

FYI,

JP.

Begin forwarded message:

> From: The IESG <iesg-secretary@ietf.org>
> Date: January 12, 2005 3:39:31 PM EST
> To: IETF-Announce@ietf.org
> Cc: pce@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, JP Vasseur <jvasseur@cisco.com>
> Subject: WG Action: Path Computation Element (pce)
>
> A new IETF working group has been formed in the Routing Area. For additional 
> information, please contact the Area Directors or the WG Chairs.
>
> Path Computation Element (pce)
> ================================
>
> Current Status: Active Working Group
>
> Chair(s):
> Adrian Farrel <adrian@olddog.co.uk>
> JP Vasseur <jvasseur@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 IESG to be
> considered as Informational RFC
>
> Feb 06: Evaluate WG progress, recharter or close.