IETF Internet Draft PCE Working Group                 Jerry Ash (AT&T)
Proposed Status: Informational                                  Editor
Expires: June August 2006                     J.L. Le Roux (France Telecom)
                                                                Editor

                                                         December 2005

           draft-ietf-pce-comm-protocol-gen-reqs-03.txt

                                                         February 2006

           draft-ietf-pce-comm-protocol-gen-reqs-04.txt

         PCE Communication Protocol Generic Requirements

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 20, August 1, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005). (2006).

Abstract

   The PCE model is described in the "PCE Architecture" document and
   facilitates path computation requests from Path Computation Clients
   (PCCs) to Path Computation Elements (PCEs).  This document specifies
   generic requirements for a communication protocol between PCCs and
   PCEs, and also between PCEs where cooperation between PCEs is
   desirable.  Subsequent documents will specify application-specific
   requirements for the PCE communication protocol.

Table of Contents

1. Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2
2. Conventions used in this document . . . . . . . . . . . . . . . . 3
3. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Overview of PCE Communication Protocol (PCECP)  . . . . . . . . . 5 3
6. PCE Communication Protocol Generic Requirements . . . . . . . . . 6 4
   6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 8 5
       6.1.1 Commonality of PCC-PCE and PCE-PCE Communication  . . . 8 5
       6.1.2 Client-Server Communication . . . . . . . . . . . . . . 8 5
       6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 8 5
       6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8 6
       6.1.5 Path Computation Responses  . . . . . . . . . . . . . . 9 7
       6.1.6 Cancellation of Pending Requests  . . . . . . . . . . . 10 8
       6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 10 8
       6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 11 8
       6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11 9
       6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 12 9
       6.1.11 Unsolicited Notifications  . . . . . . . . . . . . . . 12 10
       6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 12 10
       6.1.13 Communication Overhead Minimization  . . . . . . . . . 12 10
       6.1.14 Extensibility  . . . . . . . . . . . . . . . . . . . . 13 10
       6.1.15 Scalability  . . . . . . . . . . . . . . . . . . . . . 13 11
       6.1.16 Constraints  . . . . . . . . . . . . . . . . . . . . . 14 11
       6.1.17 Objective Functions Supported  . . . . . . . . . . . . 15 12
   6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 15 13
       6.2.1 Support for Different Service Provider Environments . . 15 13
       6.2.2 Policy Support  . . . . . . . . . . . . . . . . . . . . 15 13
   6.3 Aliveness Detection & Recovery Requirements . . . . . . . . . . . . . . 16 13
       6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 16 13
       6.3.2 PCC/PCE Failure Response Protocol Recovery . . . . . . . . . . . . . . . 16 . . . . 14
       6.3.3 Protocol Recovery LSP Rerouting & Reoptimization  . . . . . . . . . . . . 14
   6.4 Requirements Summary  . . . . . . . 16
       6.3.4 LSP Rerouting & Reoptimization . . . . . . . . . . . . 17 . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Manageability Considerations  . . . . . . . . . . . . . . . . . . 18 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 19 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 18
11. Normative References . . . . . . . . . . . . . . . . . . . . . . 19 18
12. Informational References . . . . . . . . . . . . . . . . . . . . 19 18
13. Authors' & Contributors' Addresses . . . . . . . . . . . . . . . 20 19
Intellectual Property Statement  . . . . . . . . . . . . . . . . . . 21 20
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 21
Copyright Statement  . . . . . . . . . . . . . . . . . . . . . . . . 22 21

1. Contributors

   This document is the result of the PCE Working Group PCE
   Communication Protocol (PCECP) requirements design team joint effort.
   The following are the design team member authors that contributed to
   the present document:

   Jerry Ash (AT&T)
   Alia Atlas (Google, Inc.)
   Arthi Ayyangar (Juniper)
   Nabil Bitar (Verizon)
   Igor Bryskin (Independent Consultant)
   Dean Cheng (Cisco)
   Durga Gangisetti (MCI)
   Kenji Kumaki (KDDI)
   Jean-Louis Le Roux (France Telecom)
   Eiji Oki (NTT)
   Raymond Zhang (BT Infonet)

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3. Introduction

   A Path Computation Element (PCE) [PCE-ARCH] supports requests for
   path computation issued by a Path Computation Client (PCC), which may
   be 'composite' (co-located) or 'external' (remote) from a PCE.  When
   the PCC is external from the PCE, a request/response communication
   protocol is required to carry the path computation request and return
   the response.  In order for the PCC and PCE to communicate, the PCC
   must know the location of the PCE: PCE discovery is described in
   [PCE-DISC-REQ].

   The PCE operates on a network graph in order to compute paths based
   on the path computation request request(s) issued by the
   PCC. PCC(s).  The path
   computation request will normally include the source and destination of the
   paths to be computed, and a set of constraints to be applied during the computation.
   computation, and may also include an objective function.  The PCE
   response includes the computed paths or the reason for a failed
   computation.

   This document lists a set of generic requirements for the PCE
   Communication Protocol (PCECP). PCECP.
   Application-specific requirements are beyond the scope of this
   document, and will be addressed in separate documents.  For example,
   application-specific communication protocol requirements are given in
   [PCECP-INTER-AREA] and [PCECP-INTER-LAYER] for inter-area and
   inter-layer PCE applications, respectively.

4. Terminology

   Domain: any collection of network elements within a common sphere of
   address management or path computational responsibility.  Examples of
   domains include IGP areas, Autonomous Systems (ASs), multiple ASs
   within a service provider network, or multiple ASs across multiple
   service provider networks.

   GMPLS: Generalized Multi-Protocol Label Switching

   LSP: MPLS MPLS/GMPLS Label Switched Path. Path

   LSR: Label Switch Router

   MPLS: Multi-Protocol Label Switching

   PCC: Path Computation Client: any client application requesting a
   Path
   path computation to be performed by the PCE.

   PCE: Path Computation Element: an entity (component, application or
   network node) that is capable of computing a network path or route
   based on a network graph and applying computational constraints (see
   further description in [PCE-ARCH]).

   TED: Traffic Engineering Database, which contains the topology and
   resource information of the network or network segment used by a PCE.

   TE LSP: Traffic Engineering MPLS (G)MPLS Label Switched Path.

   See [PCE-ARCH] for further definitions of terms.

5. Overview of PCE Communication Protocol (PCECP)

   In the PCE model, path computation requests are issued by a PCC
   to a PCE that may be composite (co-located) or external (remote).  If
   the PCC and PCE are not composite, co-located, a request/response communication
   protocol is required to carry the request and return the response.
   If the PCC and PCE are composite, co-located, a communication protocol is not
   required, but implementations may choose to utilize a protocol for
   exchanges between the components.

   In order that a PCC and PCE can communicate, the PCC must know the
   location of the PCE. This can be configured or discovered. The PCE
   discovery mechanism is out of scope of this document, but
   requirements are documented in [PCE-DISC-REQ].

   The PCE operates on a network graph built from the TED in order to
   compute paths. The mechanism by which the TED is populated is out of
   scope for the PCECP.

   A path computation request issued by the PCC includes a specification
   of the path(s) needed. The information supplied includes, at a
   minimum, the source and destination for the paths, but may also
   include a set of further requirements (known as constraints) as
   described in Section 6.

   The response from the PCE may be positive in which case it will
   include the paths that have been computed. If the computation fails
   or cannot be performed, a negative response is required with an
   indication of the type of failure.

   A request/response protocol is also required for a PCE to communicate
   path computation requests to another PCE and for that PCE to return
   the path computation response. As described in [PCE-ARCH], there is
   no reason to assume that two different protocols are needed, and this
   document assumes that a single protocol will satisfy all requirements
   for PCC-PCE and PCE-PCE communication.

   [PCE-ARCH] describes four models of PCE: composite, external,
   multiple PCE path computation, and multiple PCE path computation with
   inter-PCE communication. In all cases except the composite PCE model,
   a PCECP is required.  The requirements defined in this document are
   applicable to all models described in the [PCE-ARCH].

6. PCE Communication Protocol Generic Requirements

   The following is

   Section 6.4 contains a summary of the requirements in Section 6:

   Requirement                                       Necessity  Ref.
   ------------------------------------------------------------------ this section.

6.1 Basic Protocol Requirements

6.1.1 Commonality of PCC-PCE and PCE-PCE communication Communication

   A single protocol MUST       6.1.1
   Client-server be defined for PCC-PCE and PCE-PCE
   communication.  A PCE requesting a path from another PCE can be
   considered as a PCC, and in the remainder of this document we refer
   to all communications as PCC-PCE regardless of whether they are
   PCC-PCE or PCE-PCE.

6.1.2 Client-Server Communication

   PCC-PCE communication is by nature client-server based.  The PCECP
   MUST       6.1.2
   Support PCC/PCE allow a PCC to send a request message to a PCE to request path
   computation                                       MUST       6.1.2
   Support
   computation, and for a PCE to reply with a response message with computed to the
   requesting PCC once the path   MUST       6.1.2
   Support has been computed.

   In addition to this request-response mode, there are cases where
   there is unsolicited communication PCE-PCC         SHOULD     6.1.2
   Maintain PCC-PCE session                          NON-RQMT   6.1.2
   Use of from the PCE to the PCC (see
   Section 6.1.11).

6.1.3 Transport

   The PCECP may utilize an existing transport protocol                MAY        6.1.3
   Transport or operate
   directly over IP.

   If a transport protocol is used, it MAY be used to satisfy some
   requirements stated in other sections of this document (for example,
   reliability & security and security). Where requirements                                      MAY        6.1.3
   Transport protocol limits size expressed in this
   document match the function of message         MUST NOT   6.1.3
   Support path computation requests                 MUST       6.1.4
   include source & destination
   support path constraints (e.g., bandwidth, hops,
   affinities) to include/exclude existing transport protocols,
   consideration MUST       6.1.4
   Allow be given to select/prefer from advertised list the use of
   standard objective functions/options              MUST       6.1.4
   Allow to customize objective function/options those protocols.

   If a transport protocol is used, it MUST       6.1.4
   Allow indicating NOT limit the metric type (IGP or TE) to
   be size of the
   message used for shortest path selection               MUST       6.1.4
   Allow indicating by the set of aggregate PCECP.

6.1.4 Path Computation Requests

   The path
   attributes required in response computation request message MUST       6.1.4
   Allow indicating if load-balancing is allowed     MUST       6.1.4
   Support include at least the source
   and destination.  Note that the path computation responses                MUST       6.1.5
   Negative response support reasons request is for failure,
   constraints to relax to achieve positive result   SHOULD     6.1.5
   Support inclusion an
   LSP or LSP segment, and the source and destination supplied are the
   start and end of set the computation being requested (i.e. of aggregate the LSP
   segment).

   The path
   attributes computation request message MUST       6.1.5
   Support support the inclusion of a
   set of computed paths of a
   load-balancing one or more path group, as well as their
   respective bandwidth                              MUST       6.1.5
   Cancellation of pending requests                  MUST       6.1.6
   Multiple requests and responses                   MUST       6.1.7
   Limit by configuration number of requests within
   a message                                         MUST       6.1.7
   Support multiple computed paths in response       MUST       6.1.7
   Support "continuation correlation" where related
   requests constraints, including but not limited to the
   requested bandwidth or computed paths cannot fit within one
   message                                           MUST       6.1.7
   Maximum message size & maximum number of requests
   per message exchanged through resources (hops, affinities, etc.) to
   include/exclude.  For example, a PCC may request the PCE messages to PCC,
   or indicated exclude
   points of failure in request message                   MAY        6.1.7
   Reliable message exchange (achieved by PCECP
   itself or transport protocol                      MUST       6.1.8
   Allow detection & recovery the computation of lost messages to
   occur quickly & not impede operation a new path if an LSP setup
   fails.  The actual inclusion of constraints is a choice for the PCC
   issuing the request.  A list of core constraints that must be
   supported by the PCECP     MUST       6.1.8
   Handle overload situations without significant
   decrease is supplied in performance, e.g., through throttling Section 6.1.16. Specification
   of requests constraints MUST       6.1.8
   Provide acknowledged message delivery with
   retransmission, be future-proofed as described in order message delivery Section 6.1.14.

   The requester MUST be allowed to select or prefer from an advertised
   list or
   facility minimal subset of standard objective functions and functional
   options.  An objective function is used by the PCE to restore order, message corruption
   detection, flow control & back-pressure process
   constraints to
   throttle requests, rapid partner failure
   detection, informed rapidly a path computation request when it computes a path in
   order to select the "best" candidate paths (e.g., minimum hop path),
   and corresponds to the optimization criteria used for the computation
   of failure of PCE-PCC
   connection                                        MUST       6.1.8
   Functionality added to PCECP if transport protocol
   provides it                                       SHOULD NOT 6.1.8
   Secure message exchange (provided by PCECP or
   transport protocol                                MUST       6.1.9
   Support mechanisms to prevent spoofing (e.g.,
   authentication), snooping (e.g., encryption),
   DOS attacks                                       MUST       6.1.9
   Request prioritization                            MUST       6.1.10
   Unsolicited notifications                         SHOULD     6.1.11
   Allow asynchronous communication                  MUST       6.1.12
   PCC has to wait for response before making
   another request                                   MUST NOT   6.1.12
   Allow order of responses differ from order of
   requests                                          MUST       6.1.12
   Communication overhead minimization               SHOULD     6.1.13
   Give particular attention to message size         SHOULD     6.1.13
   Extensibility without requiring modifications to
   the protocol                                      MUST       6.1.14
   Easily extensible to support intra-area,
   inter-area, inter-AS intra provider, inter-AS
   inter-provider, multi-layer path & virtual network
   topology path computation                         MUST       6.1.14
   Easily extensible to support future applications
   not in scope (e.g., P2MP path computations)       SHOULD     6.1.14
   Scalability at least linearly with increase in
   number of PCCs, PCEs, PCCs communicating with a
   single PCE, PCEs communicated to by a single PCC,
   PCEs communicated to by another PCE, domains, path
   requests, handling bursts of requests             MUST       6.1.15
   Support path computation constraints              MUST       6.1.16
   Support "unsynchronized" & "synchronized"
   objective functions                               MUST       6.1.17
   Support different service provider environments
   (e.g., MPLS-TE and GMPLS networks, centralized &
   distributed PCE path computation, single &
   multiple PCE path computation)                    MUST       6.2.1
   Policy support for policies to accept/reject
   requests, PCC to determine reason for rejection,
   notification of policy violation                  MUST       6.2.2
   Aliveness detection of PCCs/PCEs, partner failure
   detection                                         MUST       6.3.1
   PCC/PCE failure response procedures defined for
   PCE/PCC failures, PCC able to clear pending
   request                                           must       6.3.2
   PCC select another PCE upon detection of PCE
   failure                                           MUST       6.3.2
   PCE able to clear pending requests from a PCC
   (e.g. when it detects PCC failure or request
   buffer full)                                      must       6.3.2
   Protocol recovery support resynchronization of
   information & requests between sender & receiver  MUST       6.3.3
   Minimize repeat data transfer, allow PCE to
   respond to computation requests issued before
   failure without requests being re-issued          SHOULD     6.3.3
   Stateful PCE able to resynchronize/recover
   states (e.g., LSP status, paths) after restart    SHOULD     6.3.3
   Allow indicating if computation is for LSP
   restoration (support inclusion of previously
   computed path & failed element)                   MUST       6.3.4
   Support inclusion in response message of upper
   bound of a random waiting time for further
   requests                                          MAY        6.3.4
   Support path reoptimization & inclusion of a
   previously computed path                          MUST       6.3.4

6.1 Basic Protocol Requirements

6.1.1 Commonality of PCC-PCE and PCE-PCE Communication

   A single protocol MUST be defined for PCC-PCE and PCE-PCE
   communication.  A PCE requesting a path from another PCE can be
   considered as a PCC.

6.1.2 Client-Server Communication

   PCC-PCE and PCE-PCE communication is by nature client-server based.
   The PCECP MUST allow for a PCC or a PCE to send a request message to
   a PCE to request path computation, and for a PCE to reply with a
   response message to the requesting PCC or PCE, once the path has been
   computed.

   In addition to this request-response mode, there may be cases where
   there is unsolicited communication from the PCE to PCC (see
   Requirement 6.1.6).

6.1.3 Transport

   The PCECP may utilize an existing transport protocol or operate
   directly over IP.

   If a transport protocol is used, it may be used to satisfy some
   requirements stated in other sections of this document (for example,
   reliability and security).

   If a transport protocol is used, it MUST NOT limit the size of the
   message used by the PCECP.

   Where requirements expressed in this document match the function of
   existing transport protocols, consideration MUST be given to the use
   of those protocols.

6.1.4 Path Computation Requests

   The request message MUST include, at least, a source and a
   destination.  However, there is no assumption that the receiving PCE
   has the complete source/destination domain topology, particularly in
   the multiple PCE path computation model [PCE-ARCH].  In the latter
   case, the PCE may have incomplete topological information for
   multiple domains.

   The message MUST support the inclusion of a set of one or more path
   constraints, including the requested bandwidth or resources (hops,
   affinities, etc.) to include/exclude (e.g., a PCC requests the PCE to
   exclude points of failure in the computation of the new path if an
   LSP setup fails).  The actual inclusion of constraints is a choice
   for the PCC issuing the request.  A list of core constraints that
   MUST be supported by the PCECP is supplied in Section 6.1.16.
   Specification of constraints must be future-proofed as described in
   Section 6.1.14.

   The requester MUST be allowed to select or prefer from an advertised
   list or minimal subset of standard objective functions and functional
   options. An objective function is used by the PCE to compute a path
   metric in order to select the best candidate paths (e.g., minimum hop
   path), and corresponds to the optimization criteria used for the
   computation of one path, or the synchronized computation one path, or the synchronized computation of a set of paths.  In
   the case of unsynchronized path computation, this can be, for
   example, the path cost or the residual bandwidth on the most loaded
   path link.  In the case of synchronized path computation, this can
   be, for example, the global bandwidth consumption or the residual
   bandwidth on the most loaded network link.

   A list of core objective functions that MUST be supported by the
   PCECP is supplied in Section 6.1.17. Specification of objective
   functions MUST be future-proofed as described in Section 6.1.14.

   The shortest requester SHOULD also be able to select a vendor-specific or
   experimental objective function or functional option.  Furthermore,
   the requester MUST be allowed to customize the function/options in
   use.  That is, individual objective functions will often have
   parameters to be set in the request from PCC to PCE.  Support for the
   specification of objective functions and objective parameters is
   required in the protocol extensibility specified in Section 6.1.14.

   A request message MAY include TE parameters carried by the MPLS/GMPLS
   LSP setup signaling protocol.  Also, it MUST be possible for the PCE
   to apply additional objective functions.  This might include policy
   based routing path computation for load balancing instructed by the
   management plane.

   Shortest path selection may rely either on the TE metric or on the
   IGP metric [METRIC].  Hence the PCECP request message MUST allow
   indicating the
   PCC to indicate the metric type (IGP or TE) to be used for shortest
   path selection.  It MUST also allow indicating  Note that other metric types may be specified in the
   future.

   There may be cases where a single path cannot fit a given bandwidth
   request, while a set of aggregate path
   attributes (hop-count, cumulated TE-metric, cumulated IGP-Metric)
   that are required in paths could be combined to fit the PCECP response message. request.
   Such path combination to serve a given request is called
   load-balancing. The request message MUST allow indicating the PCC to indicate if
   load-balancing is allowed or not.  It MUST also include the maximum
   number of paths in a load-balancing path group, and the minimum path
   bandwidth in a load-balancing path group.  The requester SHOULD also be able to select a vendor-specific or
   experimental objective function or functional option.  Furthermore, request message MUST
   allow specification of the degree of disjointness of the members of
   the load-balancing group.

6.1.5 Path Computation Responses

   The path computation response message MUST allow the requester PCE to return
   various elements including, at least, the computed path(s).

   The protocol MUST be allowed capable of returning any explicit path that
   would be acceptable for use for MPLS and GMPLS LSPs once converted to customize the function/options
   an Explicit Route Object for use in
   use.  That is, individual objective functions will often have
   parameters to RSVP-TE signaling.  In addition,
   anything that can be set expressed in the request from PCC to PCE.  Specification an Explicit Route Object MUST be
   capable of objective functions and objective parameters is required being returned in the
   protocol extensibility specified in Section 6.1.14. computed path.  Note that the
   resultant path(s) may be made up of a PCC MAY send set of strict or loose hops, or
   any combination of strict and loose hops.  Moreover, a request hop may have
   the form of a non-simple abstract node.  See [RFC 3209] for the
   definition of strict hop, loose hop, and abstract node.

   A positive response from the PCE MUST include the paths that is based on have
   been computed.  A positive PCECP computation response MUST support
   the inclusion of a set of TE
   parameters carried by attributes of the MPLS/GMPLS LSP setup signaling protocol,
   and as long computed path, such as those parameters are satisfied,
   the PCC MAY not care
   about which objective function path costs (e.g., cumulative link TE metrics and cumulative link
   IGP metrics) and the computed bandwidth.  The latter is used.  Also, useful when a
   single path cannot serve the PCE MAY execute
   additional objective functions not explicitly requested by bandwidth and load balancing
   is applied.

   When a path satisfying the constraints cannot be found, or if the PCC.
   computation fails or cannot be performed, a negative response MUST be
   sent.  This might response MAY include policy based routing path computation further details of the reason(s) for load
   balancing instructed by
   the management plane.  The PCC MUST NOT failure, and MAY include advice about which constraints might be
   allowed to request or cause a computation
   relaxed to fail because it does not
   wish the PCE be more likely to apply a specific objective function.  Allowing such
   behavior would constitute achieve a security risk.

6.1.5 Path Computation Responses positive result.

   The PCECP response message MUST allow returning various elements including,
   at least, support the inclusion of the set of
   computed path(s).

   The protocol MUST be capable paths of returning any explicit a load-balancing path that
   would group, as well as their
   respective bandwidths.

6.1.6 Cancellation of Pending Requests

   A PCC MUST be acceptable for use for MPLS and GMPLS LSPs once converted able to
   an Explicit Route Object for use in RSVP-TE signaling.  In addition,
   anything cancel a pending request using a notification
   message.  A PCC that can be expressed in an Explicit Route Object has sent a request to a PCE and no longer needs
   a response, for instance because it no longer wants to set up the
   associated service, MUST be
   capable of being returned in able to notify the computed path.  Note PCE that it can clear
   the
   resultant path(s) request (i.e. stop the computation if already started, and clear
   the context).  The PCE may be made up of also wish to cancel a set pending request
   because of strict or loose hops, some congested state.

6.1.7 Multiple Requests and Responses

   It MUST be possible to send multiple path computation requests
   within the same request message. Such requests may be correlated (for
   example, requesting disjoint paths) or
   any combination uncorrelated (requesting paths
   for unrelated services).  It MUST be possible to limit by
   configuration of strict both PCCs and loose hops.  Moreover, a hop may have PCEs the form number of requests that can
   be carried within a non-simple abstract node.  See RFC 3209 for single message.

   Similarly, it MUST be possible to return multiple computed paths
   within the
   definition of strict hop, loose hop, and abstract node.

   A positive same response from the PCE will include message, corresponding either to the same
   request (e.g. multiple suited paths, paths that have
   been computed.  When of a load balancing path satisfying the constraints cannot be
   found,
   group) or if to distinct requests, correlated or not, of the computation fails same
   request message or cannot distinct request messages.

   It MUST be performed, possible to provide "continuation correlation" where all
   related requests or computed paths cannot fit within one message, and
   are carried in a
   negative response sequence of correlated messages.

   The PCE MUST be sent.  This response inform the PCC of its capabilities.  Maximum acceptable
   message sizes and the maximum number of requests per message
   supported by a PCE MAY include further
   details form part of PCE capabilities advertisement
   [PCE-DISC-REQ], or MAY be exchanged through information messages from
   the reason(s) for PCE as part of the failure, and potentially advice
   about which constraints might protocol described here.

   It MUST be relaxed possible for a PCC to specify, in the request message, the
   maximum acceptable response message sizes and the maximum number of
   computed paths per response message it can support.

   It MUST be more likely possible to achieve
   a positive result. limit the message size by configuration on
   PCCs and PCEs.

6.1.8 Reliable Message Exchange

   The PCECP response message MUST support include reliability. This may form part of the
   protocol itself or may be achieved by the inclusion selection of a set of
   aggregate path attributes.

   The PCECP response message suitable
   transport protocol (see Section 6.1.3).

   In particular, it MUST support allow for the inclusion detection and recovery of lost
   messages to occur quickly and not impede the set of
   computed paths operation of the PCECP.

   In some cases (e.g. after link failure), a load-balancing path group, as well as their
   respective bandwidth.

6.1.6 Cancellation large number of Pending Requests

   A PCC or PCE MUST be able PCCs may
   simultaneously send requests to cancel a pending request, using an
   appropriate notification between PCECP peers.  A PCC that has sent a
   request PCE, leading to a PCE potential
   saturation of the PCEs.  The PCECP MUST support indication of
   congestion state and no longer needs a response, rate limitation state.  This should enable, for instance,
   because it received
   example, a satisfactory answer from another PCE, MUST be
   able PCE to notify limit the PCE that it must clear rate of incoming request messages if the
   request (i.e. stop rate is too high.

   The PCECP MUST provide:

   - Detection and report of lost or corrupted messages
   - Automatic attempts to retransmit lost messages without reference to
     the
   computation, if already started, application
   - Handling of out-of-order messages
   - Handling of duplicate messages
   - Flow control and clear back-pressure to enable throttling of requests and
     responses
   - Rapid PCECP communication failure detection
   - Distinction between partner failure and communication channel
     failure after the context).  Similarly,
   a PCE that received a request from a PCC that PCECP communication is recovered

   If it cannot serve, for
   example, due is necessary to congestion, MUST be able add functions to notify the PCC, that PCECP to overcome shortcomings
   in the
   request will not be served.

6.1.7 Multiple Requests and Responses

   It MUST chosen transport mechanisms, these functions SHOULD be based
   on and re-use where possible techniques developed in other protocols
   to send multiple path computation requests,
   correlated or not, within overcome the same request message. There are
   various motivations for doing so (optimality, path diversity, etc.).
   It shortcomings.  Functionality MUST NOT be possible added
   to limit by configuration of both PCCs and PCEs the number of requests that can be carried within a single message.

   Similarly, it PCECP where the chosen transport protocol already provides it.

6.1.9 Secure Message Exchange

   The PCC-PCE communication protocol MUST be possible include provisions to return multiple computed paths
   within insure
   the same response message, corresponding either to security of the same
   request (e.g. load balancing) or exchanges between the entities.  In particular,
   it MUST support mechanisms to distinct requests, correlated or
   not, of prevent spoofing (e.g.,
   authentication), snooping (e.g., encryption) and DOS attacks (e.g.,
   rate limiting, no promiscuous listening).

   This function may be provided by the same request message transport protocol or distinct request messages.

   It directly
   by the PCECP.

   See Section 7 for further discussion of security considerations.

6.1.10 Request Prioritization

   The PCECP MUST be possible allow a PCC to provide "continuation correlation" where all
   related requests or computed paths cannot fit within one message.

   Maximum acceptable message sizes and specify the maximum number priority of requests
   per message supported by a PCE MAY form part computation
   request.

   Implementation of priority-based activity within a PCE capabilities
   advertisement [PCE-DISC-REQ], or MAY be exchanged through information
   messages from the PCE as part of the protocol described here.

   Maximum acceptable message sizes is subject to
   implementation and the maximum number local policy. This application processing is out
   of computed
   paths per message supported by a PCC MAY be indicated in scope of the PCECP.

6.1.11 Unsolicited Notifications

   The normal operational mode is for the request
   message.

   An implementation MAY choose PCC to limit message size make path computation
   requests to avoid a big
   message from unduly delaying a small message.

6.1.8 Reliable Message Exchange the PCE, and for the PCE to respond.

   The PCECP MUST include reliability. This may form part of the
   protocol itself support unsolicited notifications from PCE to PCC, or may be achieved by
   PCC to PCE.  This requirement facilitates the selection unsolicited
   communication of a suitable
   transport information and alerts between PCCs and PCEs.

6.1.12 Asynchronous Communication

   The PCC-PCE protocol (see Section 6.1.3).

   In particular, it MUST allow for the detection and recovery of lost
   messages asynchronous communication.  A
   PCC MUST NOT have to occur quickly and not impede wait for a response to one request before it can
   make another request.

   It MUST also be possible to have the operation order of responses differ from
   the PCECP.

   In some cases (e.g. after link failure), a large number order of PCCs the corresponding requests. This may
   simultaneously send requests to occur, for
   instance, when path request messages have different priorities (see
   Requirement 6.1.10). A consequent requirement is that path
   computation responses MUST include a PCE, leading direct correlation to a potential
   saturation of the PCEs.
   associated request.

6.1.13 Communication Overhead Minimization

   The PCECP or request and response messages SHOULD be designed so that the transport protocol it uses
   MUST properly handle such overload situations, such as through
   throttling
   communication overhead is minimized.  In particular, the overhead per
   message SHOULD be minimized, and the number of requests.  For example, bytes exchanged to
   arrive at a PCE MUST computation answer SHOULD be able to limit minimized.  Other
   considerations in overhead minimization include the
   rate following:

   - the number of incoming request background messages to a manageable rate used by notifying
   PCCs and/or peering PCEs.

   The PCECP or the transport protocol it uses MUST provide:

   - Acknowledged message delivery with retransmission.
   - In order message delivery or the facility (such as message
     numbering) its
     transport protocol to restore keep alive any session or association
     between the order of received messages.
   - Message corruption detection.
   - Flow control PCE and back-pressure, as specified above PCC
   - the processing cost at the PCE (or PCC) associated with
     request/response messages (as distinct from processing the
     throttling of requests.
   - Rapid partner failure detection.
   - Rapid PCE/PCC or PCC-PCE connection failure detection after
     failure happens.

   If it is necessary to add functions to
     computation requests themselves).

6.1.14 Extensibility

   The PCECP to overcome shortcomings
   in MUST provide a way for the chosen transport mechanisms, these functions SHOULD be based
   on introduction of new path
   computation constraints, diversity types, objective functions,
   optimization methods and re-use where possible techniques developed parameters, etc., without requiring
   major modifications in other protocols
   to overcome the same shortcomings.  Functionality SHOULD NOT protocol.

   The PCECP MUST be added easily extensible to the PCECP where the chosen transport protocol already provides it.

6.1.9 Secure Message Exchange

   The PCC-PCE support various PCE based
   applications that have been currently identified including:

   - intra-area path computation [PCECP-INTER-AREA]
   - inter-area path computation
   - inter-AS intra provider and PCE-PCE communication protocol inter-AS inter-provider path
     computation
   - inter-layer path computation [PCECP-MULTI-LAYER]

   The PCECP MUST include
   provisions to improve the security of support the exchanges between requirements specified in the
   entities.  In particular,  it
   application-specific requirements documents.  The PCECP MUST support mechanisms to prevent
   spoofing (e.g., authentication), snooping (e.g., encryption) and DOS
   attacks (e.g., rate limiting, no promiscuous listening).

   This function may also
   allow extensions as more PCE applications will be provided by introduced in the transport protocol or directly
   by
   future.

   The PCECP SHOULD also be extensible to support future applications
   not currently in the PCECP.

   See Section 7 scope of the PCE working group, such as, for further discussion
   instance, point-to-multipoint path computations, multi-hop pseudowire
   path computation, etc.

   Note that application specific requirements are out of security considerations.

6.1.10 Request Prioritization the scope of
   this document and will be addressed in separate requirements
   documents.

6.1.15 Scalability

   The PCECP MUST allow a PCC to specify scale well, at least as good as linearly, with an
   increase of any of the priority following parameters (note, minimum order of
   magnitude estimates of what the PCECP should support are given in
   parenthesis):

   - number of PCCs (1000/domain)
   - number of PCEs (100/domain)
   - number of PCCs communicating with a computation
   request. This priority MAY be used by a single PCE (1000)
   - number of PCEs communicated to service high priority
   requests before lower priority requests considering all requests
   received and queued by a single PCE from all PCCs.

   Implementation PCC (100)
   - number of priority-based activity domains (20)
   - number of path request messages (average of 10/second/PCE)
   - handling bursts of requests (burst of 100/second/PCE within a 10-
     second interval).

   Note that path requests can be bundled in path request messages, for
   example, 10 PCECP request messages/second may correspond to 100 path
   requests/second.

   Bursts of requests may arise, for example, after a network outage
   when multiple recomputations are requested.  The PCECP MUST handle
   the congestion in a graceful way so that it does not unduly impact
   the rest of the network, and so that it does not gate the ability of
   the PCE is subject to
   implementation and local policy. perform computation.

6.1.16 Constraints

   This application processing is out
   of scope section provides a list of generic constraints that MUST be
   supported by the PCECP.

6.1.11 Unsolicited Notifications

   The normal operational mode is for the PCC to make path computation
   requests Other constraints may be added to service
   specific applications as identified by separate application-specific
   requirements documents.

   Note that the PCE, and for absence of a constraint in this list does not mean that
   the PCE to respond.

   The PCECP SHOULD support unsolicited notifications from PCE to PCC,
   PCE constraint must not be supported.  Note also that the provisions
   of Section 6.1.14 mean that new constraints can be added to PCE, or PCC this list
   without impacting the protocol to PCE.  This requirement facilitates a level that requires major
   protocol changes.

   Here is the
   unsolicited communication list of information and alerts between PCCs and
   PCEs and between PCEs.

6.1.12 Asynchronous Communication

   The PCC-PCE protocol MUST allow for asynchronous communication.  A
   PCC generic constraints that MUST NOT have to wait for be supported:

   o MPLS-TE and GMPLS generic constraints:
     - Bandwidth
     - Affinities inclusion/exclusion
     - Link, Node, SRLG inclusion/exclusion
     - Maximum end-to-end IGP metric
     - Maximum Hop Count
     - Maximum end-to-end TE metric
     - Degree of paths disjointess (Link, Node, SRLG)

   o MPLS-TE specific constraints
     - Class-type
     - Local protection
     - Node protection
     - Bandwidth protection

   o GMPLS specific constraints
     - Switching type, encoding type
     - Link protection type

6.1.17 Objective Functions Supported

   This section provides a response before it can make another
   request.

   It list of generic objective functions that MUST also
   be possible supported by the PCECP.  Other objectives functions MAY be added
   to have the order of responses differ from service specific applications as identified by separate
   application-specific requirements documents.

   Note that the order absence of the corresponding requests. This may occur, for
   instance, when path request messages have different priorities (see
   Requirement 6.1.10).

6.1.13 Communication Overhead Minimization

   The request and response messages SHOULD be designed so an objective function in this list does not
   mean that the
   communication overhead is minimized.  In particular, the overhead per
   message should be minimized, and the number of bytes exchanged to
   arrive at a computation answer should objective function may not be minimized. supported.  Note also
   that
   compression techniques are not required. Other considerations in
   overhead minimization include the following:

   - the amount provisions of background messages used by the protocol or its
     transport protocol Section 6.1.14 mean that new objective
   functions MAY be added to keep alive any session or association
     between this list without impacting the PCE and PCC
   - protocol.

   The PCECP MUST support the processing following "unsynchronized" objective
   functions:

   - Minimum cost at the PCE (or PCC) associated path with
     request/response messages (as distinct from processing respect to a specified metric(shortest path)
   - Least loaded path
   - Maximum available bandwidth path

   Also the
     computation requests themselves).

6.1.14 Extensibility

   The PCECP MUST provide a way for support the introduction of new path
   computation constraints, diversity types, following "synchronized" objective functions,
   optimization methods and parameters, etc., without requiring
   modifications in
   functions:

   - Minimize aggregate bandwidth consumption on all links
   - Maximize the protocol. residual bandwidth on the most loaded link
   - Minimize the cumulative cost of a set of diverse paths.

6.2 Deployment Support Requirements

6.2.1 Support for Different Service Provider Environments

   The PCECP MUST be easily extensible to support operate in various PCE based
   applications different service provider network
   environments that have been currently identified including: utilize an IP-based control plane, including

   - intra-area MPLS-TE and GMPLS networks
   - packet and non-packet networks
   - centralized and distributed PCE path computation
   - inter-area single and multiple PCE path computation
   - inter-AS intra provider

   Definitions of centralized, distributed, single, and inter-AS inter-provider multiple PCE
   path computation can be found in [PCE-ARCH].

6.2.2 Policy Support

   The PCECP MUST also allow extensions as more PCE applications will be
   introduced in the future.  For example, for the protocol may be extended use of policies to support PCE-based multi-layer path computation accept/reject
   requests, and virtual network
   topology computation/reconfiguration.

   The PCECP SHOULD also be easily extensible include the ability for a PCE to support future
   applications not currently in supply sufficient
   detail when it rejects a request for policy reasons to allow the scope of PCC
   to determine the reason for rejection or failure.  For example,
   filtering could be required for a PCE working group, that serves one domain (perhaps
   an AS) such as, for instance, P2MP path computations, multi-hop pseudowire
   path computation, etc.

   Note that application all requests that come from another domain (AS) are
   rejected.  However, specific requirements policy details are out of the scope of
   this document and will be addressed in separate requirements
   documents.

6.1.15 Scalability

   The left to
   application-specific PCECP MUST scale well, at least as good as linearly, with an
   increase of any of the following parameters (note, minimum order requirements.  Actual policies,
   configuration of
   magnitude estimates policies, and applicability of what the PCECP should support policies are given in
   parenthesis):

   - number of PCCs (1000/domain)
   - number of PCEs (100/domain)
   - number out of PCCs communicating with
   scope.

   Note that work on supported policy models and the corresponding
   requirements/implications is being undertaken as a single separate work item
   in the PCE (1000)
   - number of PCEs communicated working group.

   PCECP messages MUST be able to by carry transparent policy information.

6.3 Aliveness Detection & Recovery Requirements

6.3.1 Aliveness Detection

   The PCECP MUST allow a single PCC (100) to

   - number check the liveliness of PCEs communicated the PCC-PCE communication
   - rapidly detect PCC-PCE communication failure (indifferently to by another PCE (100)
     partner failure or connectivity failure),
   - number distinguish PCC/PCE node failures from PCC-PCE connectivity
     failures, after the PCC-PCE communication is recovered.

   The aliveness detection mechanism MUST ensure reciprocal knowledge of domains (20)
   - number
   PCE and PCC liveness.

6.3.2 Protocol Recovery

   In the event of path request messages (average the failure of 10/second/PCE)
   - handling bursts a sender or of the communication
   channel, the PCECP, upon recovery, MUST support resynchronization of
   information and requests (burst between the sender and the receiver, and
   this SHOULD be arranged so as to minimize repeat data transfer.

6.3.3 LSP Rerouting & Reoptimization

   If an LSP fails owing to the failure of 100/second/PCE within a 10-
     second interval).

   Note link or node that path requests can be bundled in path request messages, for
   example, 10 path it
   traverses, a new computation request messages/second may correspond be made to 100 path
   requests/second.

   Bursts of requests may arise, for example, after a network outage
   when multiple recomputations are requested. It is RECOMMENDED that PCE in order to
   repair the protocol handle LSP. Since the congestion in a graceful way so PCC cannot know that it does
   not unduly impact the rest of PCE's TED has been
   updated to reflect the network, and so that failure network information, it does not
   gate the ability of is useful to
   include this information in the PCE new path computation request. Also,
   in order to perform computation.

6.1.16 Constraints

   This section provides a list of generic constraints that MUST be
   supported re-use the resources used by the PCECP. Other constraints old LSP, it may be added
   advantageous to service
   specific applications as identified by separate application-specific
   requirements documents.

   Note that indicate the absence route of a constraint in this list does not mean that
   that constraint must not be supported.  Note also that the provisions old LSP as part of Section 6.1.14 mean that new constraints can be added to this list
   without impacting the protocol.

   Here is new
   path computation request.

   Hence the list of generic constraints that MUST be supported:

   o MPLS-TE and GMPLS generic constraints:
     - Bandwidth
     - Affinities inclusion/exclusion
     - Link, Node, SRLG inclusion/exclusion
     - Maximum end-to-end IGP metric
     - Hop Count
     - Maximum end-to-end TE metric
     - Multiple disjoint path computation to request message MUST allow path protection

   o MPLS-TE specific constraints
     - Class-type
     - Local protection
     - Node protection
     - Bandwidth protection

   o GMPLS specific constraints
     - Switching type, encoding type
     - Link protection type

   Regarding affinities inclusion/exclusion, note the three categories
   used in [RSVP-TE]: exclude-any, include-any, include-all.  Regarding
   link, node, SRLG inclusion/exclusion, note an indication
   of whether the mandatory computation is for LSP restoration, and desired
   exclusion approach in [EXCLUDE-ROUTE].

6.1.17 Objective Functions Supported

   This section provides a list of generic objective functions that MUST
   be supported by support
   the PCECP.  Other objectives functions MAY be added
   to service specific applications inclusion of the previously computed path as well as identified by separate
   application-specific requirements documents.

   Note that the absence identity
   of an objective function in this list does not
   mean the failed element.  Note that the objective function may old path might only be useful
   if the old LSP has not be supported. yet been torn down.

   Note also that the provisions a network failure may impact a large number of Section 6.1.14 mean that new objective
   functions MAY be added to LSPs. In
   this list without impacting case, a potentially large number of PCCs is going to
   simultaneously send requests to the protocol. PCE.  The PCECP MUST support the following "unsynchronized" objective
   functions:

   o Minimum cost path (shortest path)
   o Least loaded properly
   handle such overload situations, such as for instance through
   throttling of requests as set forth in section 6.1.8.

   The path (widest path)
   o To be determined

   Also the PCECP computation request message MUST support TE LSP path
   reoptimization and the following "synchronized" objective
   functions:

   o Minimize aggregate bandwidth consumption on all links
   o Maximize the residual bandwidth on the most loaded link.
   O Minimize the cumulative cost inclusion of a set previously computed path.  This
   will help ensure optimal routing of diverse paths.

6.2 Deployment Support a reoptimized path, since it will
   allow the PCE to avoid double bandwidth accounting and help reduce
   blocking issues.

6.4 Requirements

6.2.1 Support for Different Service Provider Environments Summary

   The PCECP MUST operate following is a summary of the requirements in various different service provider network
   environments that utilize an IP-based control plane, including

   - MPLS-TE and GMPLS networks
   - packet and non-packet networks

   - centralized Section 6:

   Requirement                                       Necessity  Ref.
   ------------------------------------------------------------------
   Commonality of PCC-PCE and distributed PCE PCE-PCE communication  MUST       6.1.1
   Client-server communication                       MUST       6.1.2
   Support PCC/PCE request message to request path
     computation
   - single and multiple                                     MUST       6.1.2
   Support PCE response message with computed path computation

   Definitions   MUST       6.1.2
   Support unsolicited communication PCE-PCC         SHOULD     6.1.2
   Maintain PCC-PCE session                          NON-RQMT   6.1.2
   Use of existing transport protocol                MAY        6.1.3
   Transport protocol satisfy reliability & security
     requirements                                    MAY        6.1.3
   Transport protocol limits size of centralized, distributed, single, and multiple PCE message         MUST NOT   6.1.3
   Support path computation can be found in [PCE-ARCH].

6.2.2 Policy Support

   The PCECP requests                 MUST allow for policies to accept/reject requests, and
   include the ability for a PCE       6.1.4
   Path computation request includes source &
     destination                                     MUST       6.1.4
   Support path constraints (e.g., bandwidth, hops,
     affinities) to reject requests with sufficient
   detail include/exclude                  MUST       6.1.4
   Allow to allow the PCC select/prefer from advertised list of
     standard objective functions/options            MUST       6.1.4
   Allow to determine customize objective function/options     MUST       6.1.4
   Allow indicating the reason for rejection metric type (IGP or
   failure.  For example, filtering could TE) to
     be required used for intra-AS PCE shortest path computation such that all requests are rejected that come from
   another AS.  However, specific policy details are left to
   application-specific PCECP requirements.  Furthermore, selection             MUST       6.1.4
   Allow indicating the PCECP set of path attributes
     required in response message                    MUST
   allow       6.1.4
   Allow indicating if load-balancing is allowed     MUST       6.1.4
   Support path computation responses                MUST       6.1.5
   Negative response support reasons for the notification failure,
     constraints to relax to achieve positive result SHOULD     6.1.5
   Support inclusion of a policy violation. Actual policies,
   configuration set of policies, and applicability path attributes       MUST       6.1.5
   Support inclusion of policies are out set of
   scope.

   Note that work on supported policy models and the corresponding
   requirements/implications is being undertaken computed paths of a
     load-balancing path group, as well as their
     respective bandwidth                            MUST       6.1.5
   Cancellation of pending requests                  MUST       6.1.6
   Multiple requests and responses                   MUST       6.1.7
   Limit by configuration number of requests within
     a separate work item message                                       MUST       6.1.7
   Support multiple computed paths in the PCE working group.

6.3 Detection & Recovery Requirements

6.3.1 Aliveness Detection

   The PCECP response       MUST allow a PCC to check the liveliness       6.1.7
   Support "continuation correlation" where related
     requests or computed paths cannot fit within
     one message                                     MUST       6.1.7
   Maximum message size & maximum number of PCEs it is
   using for path computation, and a requests
     per message exchanged through PCE messages to check the liveliness of
   PCCs it is serving.  This includes
     PCC, or indicated in request message            MAY        6.1.7
   Reliable message exchange (achieved by PCECP
     itself or transport protocol)                   MUST       6.1.8
   Allow detection & recovery of PCE liveness before a
   PCE is used for computation. i.e. during PCE selection.  A PCC should
   be aware lost messages to
     occur quickly & not impede operation of PCE liveness at all times.  The PCECP   MUST       6.1.8
   Handle overload situations without significant
     decrease in performance, e.g., through
     throttling of requests                          MUST       6.1.8
   Detect/report lost/corrupted messages, retransmit
     lost messages, handle out-of-order messages &
     duplicate messages, provide
   partner flow control/
     back-pressure to throttle messages, detect
     PCECP communication failure detection.

   The aliveness detection mechanism           MUST ensure reciprocal knowledge of
   PCE and PCC liveness.

   Note that the PCE       6.1.8
   Functionality added to PCECP if transport
     protocol provides it                            SHOULD NOT 6.1.8
   Secure message exchange (provided by PCECP or
     transport protocol                              MUST       6.1.9
   Support mechanisms to prevent spoofing (e.g.,
     authentication), snooping (e.g., encryption),
     DOS attacks                                     MUST       6.1.9
   Request prioritization                            MUST       6.1.10
   Unsolicited notifications                         SHOULD     6.1.11
   Allow asynchronous communication                  MUST       6.1.12
   PCC software component can be lost has to wait for response before making
     another request                                 MUST NOT   6.1.12
   Allow order of responses differ from order of
     requests                                        MUST       6.1.12
   Communication overhead minimization               SHOULD     6.1.13
   Give particular attention to message size         SHOULD     6.1.13
   Extensibility without
   losing the connection or the transport end-point, when a transport requiring modifications to
     protocol is used.

6.3.2 PCC/PCE Failure Response

   Appropriate PCC and PCE procedures                                        MUST be defined to deal with PCE
   and PCC failures.  A PCC must be able       6.1.14
   Easily extensible to clear any pending request support intra-area,
     inter-area, inter-AS intra provider, inter-AS
     inter-provider, multi-layer path & virtual
     network topology path computation               MUST       6.1.14
   Easily extensible to
   a PCE so that it is no longer waiting for a response.  Clearing a
   pending request does support future applications
     not imply any message exchange; this differs
   from pending request cancellation (Section 6.1.6), which requires
   message exchange.  It is RECOMMENDED that a PCC select another PCE
   upon detection of PCE failure or unreachability of a PCE but note
   that PCE selection procedure are out of the in scope (e.g., point-to-multipoint path
     computations)                                   SHOULD     6.1.14
   Scale at least linearly with number of this document.

   Similarly, a PCE must be able PCCs,
     PCEs, PCCs communicating with single PCE, PCEs
     communicated to clear pending requests from a by single PCC,
   for instance, when it detects the failure of the requesting PCC or
   when its buffer domains, path
     requests, handling bursts of requests is full.  Clearing a pending request does
   not imply any message exchange.

6.3.3 Protocol Recovery

   Information           MUST       6.1.15
   Support path computation constraints              MUST       6.1.16
   Support "unsynchronized" & "synchronized"
     objective functions                             MUST       6.1.17
   Support different service provider environments
     (e.g., MPLS-TE and GMPLS networks, centralized
     & distributed in asynchronous/unsolicited messages MAY
   persist at the recipient in the event of the failure PCE path computation, single &
     multiple PCE path computation)                  MUST       6.2.1
   Policy support for policies to accept/reject
     requests, PCC to determine reason for
     rejection, notification of the sender or policy violation     MUST       6.2.2
   Aliveness detection of the communication channel. Upon recovery, the Communication
   Protocol PCCs/PCEs, PCECP failure
     detection                                       MUST       6.3.1
   Protocol recovery support resynchronization of
     information and & requests between the sender and the receiver, and this SHOULD be arranged so
   as to minimize &
     receiver                                        MUST       6.3.2
   Minimize repeat data transfer.

   The response to a computation request issued before the PCC is
   restarted will not be helpful and could be a waste of effort.  Thus
   it is better to allow the request to be re-issued in shorthand (e.g.
   by request number) if the PCC remembers that it had previously issued
   it and is still interested in the response.

   The PCECP SHOULD transfer, allow a PCE to
     respond to computation requests issued before the
     failure without the requests being re-issued.

6.3.4 LSP Rerouting & Reoptimization

   Upon LSP failure, due to link, node or SRLG failure, a head-end LSR
   may send a request to the PCE so as to reroute the LSP over an
   alternate path. So as to ease the computation such request should
   include the previous path and the failed element (if it can be
   identified).

   Hence the request message MUST allow indicating if the computation is
   for an LSP restoration, and MUST support the inclusion of the
   previously computed path as well as the failed element.  Note that
   the old path is actually useful only if the old LSP is not torn down
   yet.  This is up to the PCC to decide if it includes the old path or
   not.

   Note that a network failure may impact a large number of LSPs. A
   potentially large number of PCCs, are going to simultaneously send a
   request to the PCE. Some jittering may be used on PCCs so as to delay
   a request to the PCE, under network failure condition.

   The PCECP MAY support the inclusion, in a response message to a PCC,
   of an upper bound of a random waiting time to be used for further
   requests to the requests being re-issued        SHOULD     6.3.2
   Stateful PCE (e.g. the PCC will wait able to resynchronize/recover
     states (e.g., LSP status, paths) after restart  SHOULD     6.3.2
   Allow indicating if computation is for a random value
   between 0 and the upper bound before sending another request).  This
   upper bound would depend on the level of congestion LSP
     restoration (support inclusion of the PCE.

   The previously
     computed path computation request message & failed element)                 MUST support TE LSP       6.3.3
   Support path reoptimization and the & inclusion of a
     previously computed path.  This
   will help ensure optimal routing of a reoptimized path, since it will
   allow the PCE to avoid double bandwidth accounting and help reduce
   blocking issues. path                        MUST       6.3.3

7. Security Considerations

   The impact of the use of a PCECP MUST be considered in the light of
   the impact that it has on the security of the existing routing and
   signaling protocols and techniques in use within the network.
   Intra-domain security is impacted since there is a new interface,
   protocol and element in the network.  Any host in the network could
   impersonate a PCC, and receive detailed information on network paths.
   Any host could also impersonate a PCE, both gathering information
   about the network before passing the request on to a real PCE, and
   spoofing responses.  Some protection here depends on the security of
   the PCE discovery process (if it uses the IGP it relies on IGP security). (see [PCE-DISC-REQ]).  An increase in
   inter-domain information flows may increase the vulnerability to
   security attacks, and the facilitation of inter-domain path paths may
   increase the impact of these security attacks.

   Of particular relevance are the implications for confidentiality
   inherent in a PCECP for multi-domain networks.  It is not necessarily
   the case that a multi-domain PCE solution will compromise security,
   but solutions MUST examine their impacts in this area.

   Applicability statements for particular combinations of signaling,
   routing and path computation techniques are expected to contain
   detailed security sections.

   It should be observed that the use of an external PCE does introduce introduces
   additional security issues.  Most notable amongst these are:

   - interception of PCE requests or responses
   - impersonation of PCE or PCC
   - denial of service DoS attacks on PCE PCEs or PCE communication mechanisms

   It is expected that the PCCs

   The PCECP will MUST address these issues in detail using authentication,
   encryption and DoS protection techniques.  See also Section 6.1.9.

8. Manageability Considerations

   Manageability of the PCECP MUST address the following considerations:

   - the need for a MIB module for control and monitoring of PCECP
   - the need for built-in diagnostic tools to test the operation of the
     protocol (e.g., partner failure detection, OAM, etc.)
   - configuration implications for the protocol

   It is expected that

   PCECP operations will MUST be modeled and controlled through appropriate
   MIB modules.  Statistics gathering will form an important part of the
   operation of the PCECP.  The operator must MUST be able to determine PCECP
   historical interactions and the success rate of
   requests. requests using data
   from MIB modules.  Similarly, it is important for an operator to be
   able to determine PCECP and PCE load and whether an individual PCC is
   responsible for a disproportionate amount of the load.  It will also be important to MUST be able
   possible, through use of MIB modules, to record and inspect
   statistics about the PCECP communications, including issues such as
   malformed messages, unauthorized messages and messages discarded
   owing to congestion.

   The new MIB modules should also be used to provide notifications
   (traps) when thresholds are crossed or when important events occur.

   PCECP techniques must enable a PCC to determine the liveness of a PCE
   both before it sends a request and in the period between sending a
   request and receiving a response.

   It is also important for a PCE to know about the liveness of PCCs to
   gain a predictive view of the likely loading of a PCE in the future,
   and to allow a PCE to abandon processing of a received request.

   It should be possible for an operator to

   The PCECP MUST support indication of congestion state and rate limit the requests that
   a PCC sends to a PCE,
   limitation state, and a PCE should be able to report impending
   congestion (according to a configured threshold) both to MAY allow the operator
   and to its PCCs. control such a
   function.

9. IANA Considerations

   This document makes no requests for IANA action.

10. Acknowledgements

   The authors would like to extend their warmest thanks to (in
   alphabetical order) Lou Berger, Adrian Farrel, Thomas Morin, Dimitri
   Papadimitriou, and JP Vasseur for their review and suggestions.

11. Normative References

   [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation
   Element (PCE) Architecture", work in progress.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
   3667, February 2004.

   [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
   Technology", BCP 79, RFC 3668, February 2004.

12. Informational References

   [METRIC] Le Faucheur, F., et. al., "Use of Interior Gateway Protocol
   (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP
   87, RFC 3785, May 2004.

   [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path
   Computation Element (PCE) Discovery," work in progress.

   [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
   Tunnels," RFC 3209, December 2001.

   [PCE-INTER-AREA]  Le Roux, JL, et. al., "PCE Communication Protocol
   (PCECP) specific requirements for Inter-Area (G)MPLS Traffic
   Engineering," work in progress.

   [PCE-INTER-LAYER] Oki, E., et. al., "PCC-PCE Communication
   Requirements for Inter-Layer Traffic Engineering," work in progress.

13. Authors' & Contributors' Addresses

   Jerry Ash (Editor)
   AT&T
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1-(732)-420-4578 (732)-420-4578
   Email: gash@att.com

   Jean-Louis Le Roux (Editor)
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex, FRANCE
   Email: jeanlouis.leroux@francetelecom.com

   Alia K. Atlas
   Google Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   Email: akatlas@alum.mit.edu

   Arthi Ayyangar
   Juniper Networks, Inc.
   1194 N.Mathilda Ave
   Sunnyvale, CA 94089 USA
   Email: arthi@juniper.net

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA 02145
   Email: nabil.bitar@verizon.com

   Igor Bryskin
   Independent Consultant
   Email: i_bryskin@yahoo.com

   Dean Cheng
   Cisco Systems Inc.
   3700 Cisco Way
   San Jose CA 95134 USA
   Phone: +1  408 527 0677
   Email: dcheng@cisco.com
   Durga Gangisetti
   MCI
   Email: durga.gangisetti@mci.com

   Kenji Kumaki
   KDDI Corporation
   Garden Air Tower
   Iidabashi, Chiyoda-ku,
   Tokyo 102-8460, JAPAN
   Phone: +81-3-6678-3103 3-6678-3103
   Email: ke-kumaki@kddi.com

   Eiji Oki
   NTT
   Midori-cho 3-9-11
   Musashino-shi, Tokyo 180-8585, JAPAN
   Email: oki.eiji@lab.ntt.co.jp

   Raymond Zhang
   BT INFONET Services Corporation
   2160 E. Grand Ave.
   El Segundo, CA 90245 USA
   Email: Raymond_zhang@bt.infonet.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005). (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.