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


                                                        September 2005



         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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 26, 2005. March 20, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


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

1. Contributors

   This document is the result of the PCE Working Group PCE
   communication protocol (PCEP)
   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 (Avici) (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",
   document are to be interpreted as described in RFC 2119 [RFC2119].

3. Introduction

   The path computation element

   A Path Computation Element (PCE) [PCE-ARCH] supports requests for
   path computation issued by a path computation client 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 issued by the
   PCC.  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.  The PCE response includes the
   computed paths or the reason for a failed computation.

   This document lists a set of generic requirements for the PCEP. PCE
   Communication Protocol (PCECP).  Application-specific requirements
   are beyond the scope of this document, and will be addressed in
   separate documents.

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 Multiprotocol Multi-Protocol Label Switching

   LSP: MPLS Label Switched Path.

   MPLS: multiprotocol label switching Multi-Protocol Label Switching

   PCC: Path Computation Client: any client application requesting a
   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 Label Switched Path.

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

5. Overview of PCE Communication Protocol (PCEP) (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, a request/response
   communication protocol is required to carry the request and return
   the response.  If the PCC and PCE are composite, 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 PCEP. 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 PCEP PCECP is required.  The requirements defined in this document are
   applicable to all models described in the [PCE-ARCH] except the
   composite PCE model. [PCE-ARCH].

6. PCE Communication Protocol Generic Requirements

   [This paragraph to be deleted after successful completion and before
   publication as an RFC.]

   The designers of a PCEP MUST take the requirements set out in this
   document and discuss them widely within the IETF and particularly
   within the Applications Area to determine whether a suitable protocol
   already exists. The results of this investigation MUST be published
   on the PCE mailing list.

   The following is a summary of the requirements in Section 6:

   Requirement                                       Necessity  Ref.
   Commonality of PCC-PCE and PCE-PCE Communication communication  MUST       6.1.1
   Client-Server Communication
   Client-server communication                       MUST       6.1.2
   Support PCC/PCE request message to request path
   computation                                       MUST       6.1.2
   Support PCE response message with computed path   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 existing transport protocol                MAY        6.1.3
   Transport protocol satisfy reliability & security
   requirements                                      MAY        6.1.3
   Transport Protocol Limits Size protocol limits size of Message message         MUST NOT   6.1.3
   Support Path Computation Requests path computation requests                 MUST       6.1.4
   include source & destination
   support path constraints (e.g., bandwidth, hops,
   affinities) to include/exclude                    MUST       6.1.4
   Support path reoptimization & inclusion of a
   previously computed path                          MUST       6.1.4
   Allow to select/prefer from advertised list of
   standard objective functions/options              MUST       6.1.4
   Allow to customize objective function/options     MUST       6.1.4
   Request a less-constrained path                   MAY        6.1.4
   Support request for less-constrained path,
   including constraint-relaxation policy's          SHOULD     6.1.4
   Support Path Computation Responses path computation responses                MUST       6.1.5
   Negative response support reasons for failure,
   constraints to relax to achieve positive result,
   less-constrained path reflecting
   constraint-relaxation policy's result   SHOULD     6.1.5
   Cancellation of Pending Requests pending requests                  MUST       6.1.6
   Multiple Requests requests and Responses 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 or computed paths cannot fit within one
   message                                           MUST       6.1.7
   Maximum message size & maximum number of requests
   per message exchanged through PCE messages to PCC,
   or indicated in request message                   MAY        6.1.7
   Reliable Message Exchange message exchange (achieved by PCEP PCECP
   itself or transport protocol                      MUST       6.1.8
   Allow detection & recovery of lost messages to
   occur quickly & not impede operation of PCEP PCECP     MUST       6.1.8
   Handle overload situations without significant
   decrease in performance, e.g., through throttling
   of requests                                       MUST       6.1.8
   Provide acknowledged message delivery with
   retransmission, in order message delivery or
   facility to restore order, message corruption
   detection, flow control & back-pressure to
   throttle requests, rapid partner failure
   detection, informed rapidly of failure of PCE-PCC
   connection                                        MUST       6.1.8
   Functionality added to PCEP PCECP if transport protocol
   provides it                                       SHOULD NOT 6.1.8
   Secure Message Exchange message exchange (provided by PCEP 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 prioritization                            MUST       6.1.10
   Unsolicited Notifications notifications                         SHOULD     6.1.11
   Allow Asynchronous Communication asynchronous communication                  MUST       6.1.12
   PCC Has has to Wait wait for Response Before Making
   Another Request 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 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 path computation constraints              MUST       6.1.16
   Support Different Service Provider Environments 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 support for policies to accept/reject
   requests, PCC to determine reason for rejection,
   notification of policy violation                  MUST       6.2.2
   Aliveness Detection detection of PCCs/PCEs, partner failure
   detection                                         MUST       6.3.1
   PCC/PCE Failure Response failure response procedures defined for
   PCE/PCC failures, PCC able to clear pending
   Request                                           MUST
   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                                      must       6.3.2
   Protocol Recovery 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

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

   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).

   There is no requirement to maintain a session or association between
   communicating PCC and PCE, nor between communicating PCEs.  The
   request/response exchange defines a limited association between
   requester and responder.

6.1.3 Transport

   The PCEP 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 PCEP. 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.  The message MUST support  However, there is no assumption that the inclusion of 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, such as 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 PCEP PCECP is supplied in Section 6.1.16.
   Specification of constraints must be future-proofed as described in
   Section 6.1.14.

   The path computation request message MUST support TE LSP 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.

   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 of a set of
   paths.  In case of unsynchronized path computation, this can be, for
   example, the path cost or the residual bandwidth on the most loaded
   path link.  In case of synchronized path computation, this can be,
   for example, the global bandwidth consumption or the residual
   bandwidth on the most loaded network link.

   The 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
   objective function/options in
   use.  That is, individual objective functions will often have
   parameters to be set in the request from PCC to PCE.  Specification
   of objective functions and objective
   function parameters is required in the
   protocol extensibility specified in Section 6.1.14.

   If a PCC selects an objective function that the PCE does not support,
   the PCE response MUST be negative.

   Note that a PCC MAY send a request that is based on the set of TE
   parameters carried by the MPLS/GMPLS LSP setup signaling protocol,
   and as long as those parameters are satisfied, the PCC MAY not care
   about which objective function is used.  Also, the PCE MAY execute
   additional objective functions not advertised to explicitly requested by the PCC, for example, PCC.
   This might include policy based routing path computation for load
   balancing instructed by the management plane.

   As also discussed in Section 6.1.5 (Path Computation Responses), a  The PCC MAY MUST NOT be
   allowed to request or cause a less-constrained TE LSP path, and the path computation request MAY include one or more constraint-relaxation
   policy's.  The Request message SHOULD support to fail because it does not
   wish the inclusion of PCE to apply a
   request for specific objective function.  Allowing such
   behavior would constitute a less-constrained path, including one or more
   constraint-relaxation policy's. security risk.

6.1.5 Path Computation Responses

   The response message MUST allow returning various elements including,
   at least, the computed path(s).

   The protocol MUST be capable of returning any explicit path that
   would be acceptable for use for MPLS and GMPLS LSPs once converted to
   an Explicit Route Object for use in RSVP-TE signaling.  In addition,
   anything that can be expressed in an Explicit Route Object MUST be
   capable of being returned in the computed path.  Note that the
   resultant path(s) may be made up of a set of strict or loose hops, or
   any combination of strict and loose hops.  Moreover, a 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 will include the paths that have
   been computed.  When a Path path satisfying the constraints cannot be
   found, or if the computation fails or cannot be performed, a
   negative response MUST be sent.  This response MAY include further
   details of the reason(s) for the failure, and potentially advice
   about which constraints might be relaxed to be more likely to achieve
   a positive result.  Optionally the PCE MAY provide a
   less-constrained path taking into account one

6.1.6 Cancellation of Pending Requests

   A PCC or more relaxation
   policy's that could potentially PCE MUST be provided by the PCC in the
   request.  As discussed in Section 6.1.4, able to cancel a pending request, using an
   appropriate notification between PCECP peers.  A PCC MAY optionally that has sent a
   request to a less-constrained TE LSP path, PCE and no longer needs a response, for instance,
   because it received a satisfactory answer from another PCE, MUST be
   able to notify the path computation
   request MAY also include one or more constraint-relaxation policy's.

   Hence the Response message SHOULD support PCE that it must clear the inclusion of request (i.e. stop the
   reasons for a failure,
   computation, if already started, and clear the inclusion of less-constrained path.
   The Request message SHOULD support the inclusion of context).  Similarly,
   a PCE that received a request for from a
   less-constrained path, including one or more constraint-relaxation

6.1.6 Cancellation of Pending Requests

   A PCC or PCE that it cannot serve, for
   example, due to congestion, MUST be able to cancel a pending request. notify the PCC, that the
   request will not be served.

6.1.7 Multiple Requests and Responses

   It MUST be possible to send multiple path computation requests,
   correlated or not, within the same request message. There are
   various motivations for doing so (optimality, path diversity, etc.).
   It MUST be possible to limit by configuration of both PCCs and PCEs
   the number of requests that can be carried within a single message.

   Similarly, it MUST be possible to return multiple computed paths
   within the same response message, corresponding either to the same
   request (e.g. load balancing) or to distinct requests, correlated or
   not, of the same request message or distinct request messages.

   It MUST be possible to provide "continuation correlation" where all
   related requests or computed paths cannot fit within one message.

   Maximum acceptable message sizes and the maximum number of requests
   per message supported by a PCE MAY form part of 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 and the maximum number of computed
   paths per message supported by a PCC MAY be indicated in the request

   An implementation MAY choose to limit message size to avoid a big
   message from unduly delaying a small message.

6.1.8 Reliable Message Exchange

   The PCEP PCECP MUST include reliability. This may form part of the
   protocol itself or may be achieved by the selection of a suitable
   transport protocol (see Section 6.1.3).

   In particular, it MUST allow for the detection and recovery of lost
   messages to occur quickly and not impede the operation of the PCEP. PCECP.

   In some cases (e.g. after link failure), a large number of PCCs may
   simultaneously send requests to a PCE, leading to a potential
   saturation of the PCEs.  The PCEP PCECP or the transport protocol it uses
   MUST properly handle such overload situations without a significant
   decrease in performance, situations, such as through
   throttling of such requests.  For example, a PCE MUST be able to limit the
   rate of incoming request messages to a manageable rate by notifying
   PCCs and/or peering PCEs.

   The PCEP 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) to restore the order of received messages.
   - Message corruption detection.
   - Flow control and back-pressure, as specified above with the
     throttling of requests.
   - Rapid partner failure detection. The PCC/PCE MUST be informed of
     the failure of any

   - Rapid PCE/PCC or PCC-PCE connection rapidly failure detection after
     failure happens.

   If it is necessary to add functions to PCECP to overcome shortcomings
   in the chosen transport mechanisms, these functions SHOULD be based
   on and re-use where possible techniques developed in other protocols
   to overcome the same shortcomings.  Functionality SHOULD NOT be added
   to the PCEP PCECP where the chosen transport protocol already provides it.

6.1.9 Secure Message Exchange

   The PCC-PCE and PCE-PCE communication protocol MUST be secure. include
   provisions to improve the security of the exchanges between the
   entities.  In particular,  it MUST support mechanisms to prevent
   spoofing (e.g., authentication), snooping (e.g., encryption) and DOS attacks.
   attacks (e.g., rate limiting, no promiscuous listening).

   This function may be provided by the transport protocol or directly
   by the PCEP. PCECP.

   See Section 7 for further discussion of security considerations.

6.1.10 Request Prioritization

   The PCEP PCECP MUST allow a PCC to specify the priority of a computation
   request. This priority is MAY be used by a PCE to service high priority
   requests before lower priority requests considering all requests
   received and queued by a single PCE from all PCCs.

   Implementation of priority-based activity within a PCE is subject to
   implementation and local policy. This application processing is out
   of scope of the PCEP. PCECP.

6.1.11 Unsolicited Notifications

   The normal operational mode is for the PCC to make path computation
   requests to the PCE, and for the PCE to respond.

   The PCEP PCECP SHOULD support unsolicited notifications from PCE to PCC,
   PCE to PCE, or PCC to PCE.  This requirement facilitates the
   unsolicited communication of information, updated paths, 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 MUST NOT have to wait for a response before it can make another

   It MUST also be possible to have the order of responses differ from
   the order 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 that the
   communication overhead is minimized.  Particular attention SHOULD be
   given to  In particular, the message size.  Other considerations in overhead
   minimization include the following:

   - per
   message should be minimized, and the number of messages bytes exchanged to
   arrive at a computation answer should be minimized.  Note that
   compression techniques are not required. Other considerations in
   overhead minimization include the following:

   - the amount of background messages used by the protocol or its
     transport protocol to keep alive any session or association
     between the PCE and PCC
   - the processing cost at the PCE (or PCC) associated with
     request/response messages (as distinct from processing the
     computation requests themselves).

6.1.14 Extensibility

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

   The PCEP PCECP MUST be easily extensible to support various PCE based
   applications that have been currently identified including:

   - intra-area path computation
   - inter-area path computation
   - inter-AS intra provider and inter-AS inter-provider path

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

   The PCEP PCECP SHOULD also be easily extensible to support future
   applications not currently in the scope of the PCE working group,
   such as, for instance, P2MP path computations, multi-hop pseudowire
   path computation, etc.

   Note that application specific requirements are out of the scope of
   this document and will be addressed in separate requirements

6.1.15 Scalability

   The PCEP PCECP MUST scale well, at least as good as linearly, with an
   increase of any of the following parameters: parameters (note, minimum order of
   magnitude estimates of what the PCECP should support are given in

   - number of PCCs (1000/domain)
   - number of PCEs (100/domain)
   - number of PCCs communicating with a single PCE (1000)
   - number of PCEs communicated to by a single PCC (100)
   - number of PCEs communicated to by another PCE (100)
   - number of domains (20)
   - number of path requests request messages (average of 10/second/PCE)
   - handling bursts of requests.

   Bursts of requests may arise, for (burst of 100/second/PCE within a 10-
     second interval).

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

   Bursts of requests may arise, for example, after a network outage
   when multiple recomputations are requested. It is RECOMMENDED that
   the protocol 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 to perform computation.

6.1.16 Constraints

   This section provides a list of generic constraints that MUST be
   supported by the PCEP. PCECP. Other constraints may be added to service
   specific applications as identified by separate application-specific
   requirements documents.

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

   Here is 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 delay metrics
     - Hop Count
     - Maximum end-to-end TE metric (cost)
     - Multiple disjoint path computation to allow path protection
   o MPLS-TE specific constraints
     - Class-Type Class-type
     - Local protection
     - Node protection
     - Bandwidth protection

   o GMPLS specific constraints
     - Switching Type, Encoding Type type, encoding type
     - Protection Link protection type

   o TBD

   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 the mandatory and desired
   exclusion approach in [EXCLUDE-ROUTE].

6.2 Deployment Support Requirements

6.2.1 Support for Different Service Provider Environments

   The PCEP PCECP MUST operate in various different service provider network
   environments that utilize an IP-based control plane, such as including

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

   - centralized and distributed PCE path computation
   - single and multiple PCE path computation

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

6.2.2 Policy Support

   The PCEP PCECP MUST allow for policies to accept/reject requests, and
   include the ability for a PCE to reject requests with sufficient
   detail to allow the PCC to determine the reason for rejection or
   failure.  For example, filtering could be required for intra-AS PCE
   path computation such that all requests are rejected that come from
   another AS.  However, specific policy details are left to
   application-specific PCEP PCECP requirements.  Furthermore, the PCEP PCECP MUST
   allow for the notification of a policy violation. Actual policies,
   configuration of policies, and applicability of policies are out of

   Note that work on supported policy models and the corresponding
   requirements/implications is being undertaken as a separate work item
   in the PCE working group.

6.3 Detection & Recovery Requirements

6.3.1 Aliveness Detection

   The PCEP PCECP MUST allow a PCC to check the liveliness of PCEs it is
   using for path computation, and a PCE to check the liveliness of
   PCCs it is serving.  This includes detection of PCE liveness before a
   PCE is used for computation. i.e. during PCE selection.  A PCC should
   be aware of PCE liveness at all times.  The PCEP PCECP MUST provide
   partner failure detection.

   Depending on

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

   Note that the solution, this requirement MAY PCE or PCC software component can be met by lost without
   losing the PCEP
   design connection or the transport end-point, when a transport
   protocol design. 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 to clear any pending request to
   a PCE so that it is no longer waiting for a response.  Clearing a
   pending request does 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 scope of this document.

   Similarly, a PCE must be able to clear pending requests from a PCC,
   for instance, when it detects the failure of the requesting PCC or
   when its buffer of requests is full.  Clearing a pending request does
   not imply any message exchange.

   It is assumed that the aliveness detection mechanism (see Section
   6.3.1) ensures reciprocal knowledge of PCE and PCC liveness.

6.3.3 Protocol Recovery

   Information distributed in asynchronous/unsolicited messages MAY
   persist at the recipient in the event of the failure of the sender or
   of the communication channel. Upon recovery, the Communication
   Protocol MUST support resynchronization of information and requests
   between the sender and the receiver, and this SHOULD be arranged so
   as to minimize repeat data transfer.

   For example,

   The response to a computation request issued before the PCEP 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 allow a PCE to respond to computation requests
   issued before the failure without the requests being re-issued.

   Similarly, a stateful PCE SHOULD be able to resynchronize and recover
   states (e.g., LSP status, paths, etc.) after a restart.

7. Security Considerations

   The impact of the use of a PCEP 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.  There
   Intra-domain security is unlikely 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 be any impact a real PCE, and
   spoofing responses.  Some protection here depends on intra-domain security, but an the PCE
   discovery process (if it uses the IGP it relies on IGP security).  An
   increase in inter-domain information flows may increase the
   vulnerability to security attacks, and the facilitation of
   inter-domain path establishment may increase the vulnerability to impact of these security attacks.

   Of particular relevance are the implications for confidentiality
   inherent in a PCEP 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
   additional security issues.  Most notable amongst these are:

   - interception of PCE requests or responses
   - impersonation of PCE
   - falsification of TE information or PCC
   - denial of service attacks on PCE or PCE communication mechanisms

   It is expected that the PCEP PCECP will address these issues in detail
   using authentication authentication, encryption and security DoS protection techniques.  See
   also Section 6.1.9.

8. Manageability Considerations

   Manageability of the PCEP PCECP MUST address the following considerations:

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

   It is expected that PCECP operations will be modeled and controlled
   through appropriate MIB modules.  Statistics gathering will form an
   important part of the operation of the PCECP. The operator must be
   able to determine PCECP historical interactions and success rate of
   requests.  Similarly, it is important for an operator to be able to
   determine PCECP load and whether an individual PCC is responsible for
   a disproportionate amount of the load. It will also be important to
   be able 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 rate limit the requests that
   a PCC sends to a PCE, and a PCE should be able to report impending
   congestion (according to a configured threshold) both to the operator
   and to its PCCs.

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

   [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.

13. Authors' Addresses

   Jerry Ash
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1-(732)-420-4578
   Alia K. Atlas
   Avici Systems,
   Google Inc.
   101 Billerica Avenue
   N. Billerica, MA 01862, USA
   Phone: +1 978 964 2070
   1600 Amphitheatre Parkway
   Mountain View, CA  94043

   Arthi Ayyangar
   Juniper Networks, Inc.
   1194 N.Mathilda Ave
   Sunnyvale, CA 94089 USA

   Nabil Bitar
   40 Sylvan Road
   Waltham, MA 02145

   Igor Bryskin
   Independent Consultant

   Dean Cheng
   Cisco Systems Inc.
   3700 Cisco Way
   San Jose CA 95134 USA
   Phone: +1 408 527 0677

   Durga Gangisetti

   Kenji Kumaki
   KDDI Corporation
   Garden Air Tower
   Iidabashi, Chiyoda-ku,
   Tokyo 102-8460, JAPAN
   Phone: +81-3-6678-3103

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex, FRANCE

   Eiji Oki
   Midori-cho 3-9-11
   Musashino-shi, Tokyo 180-8585, JAPAN

   Raymond Zhang
   BT INFONET Services Corporation
   2160 E. Grand Ave.
   El Segundo, CA 90245 USA

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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.