    Network Working Group                                        J. Ash, Ed.
    Request for Comments: 4657                                          AT&T
    Category: Informational                                J.L. Le Roux, Ed.
                                                              France Telecom
                                                              September 2006

             Path Computation Element (PCE) Communication Protocol
                              Generic Requirements

    Status of This Memo

       This memo provides information for the Internet community.  It does
       not specify an Internet standard of any kind.  Distribution of this
       memo is unlimited.

    Copyright Notice

       Copyright (C) The Internet Society (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. Introduction ....................................................2
       2. Conventions Used in This Document ...............................3
       3. Terminology .....................................................3
       4. Overview of PCE Communication Protocol (PCECP) ..................4
       5. PCE Communication Protocol Generic Requirements .................5
          5.1. Basic Protocol Requirements ................................5
               5.1.1. Commonality of PCC-PCE and PCE-PCE Communication ....5
               5.1.2. Client-Server Communication .........................5
               5.1.3. Transport ...........................................5
               5.1.4. Path Computation Requests ...........................5
               5.1.5. Path Computation Responses ..........................7
               5.1.6. Cancellation of Pending Requests ....................7
               5.1.7. Multiple Requests and Responses .....................8
               5.1.8. Reliable Message Exchange ...........................8
               5.1.9. Secure Message Exchange .............................9

    Ash & Le Roux                Informational                      [Page 1]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

               5.1.10. Request Prioritization ............................10
               5.1.11. Unsolicited Notifications .........................10
               5.1.12. Asynchronous Communication ........................10
               5.1.13. Communication Overhead Minimization ...............10
               5.1.14. Extensibility .....................................11
               5.1.15. Scalability .......................................11
               5.1.16. Constraints .......................................12
               5.1.17. Objective Functions Supported .....................13
          5.2. Deployment Support Requirements ...........................13
               5.2.1. Support for Different Service Provider
                      Environments .......................................13
               5.2.2. Policy Support .....................................14
          5.3. Aliveness Detection & Recovery Requirements ...............14
               5.3.1. Aliveness Detection ................................14
               5.3.2. Protocol Recovery ..................................14
               5.3.3. LSP Rerouting & Reoptimization .....................14
       6. Security Considerations ........................................15
       7. Manageability Considerations ...................................16
       8. Contributors ...................................................17
       9. Acknowledgements ...............................................18
       10. References ....................................................19
          10.1. Normative References .....................................19
          10.2. Informative References ...................................19

    1.  Introduction

       A Path Computation Element (PCE) [RFC4655] 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(s) issued by the PCC(s).  The path
       computation request will include the source and destination of the
       paths to be computed and a set of constraints to be applied during
       the computation, and it may also include an objective function.  The
       PCE response includes the computed paths or the reason for a failed
       computation.

    Ash & Le Roux                Informational                      [Page 2]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       This document lists a set of generic requirements for the PCE
       Communication Protocol (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.

    2.  Conventions Used in This Document

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

    3.  Terminology

       Domain: Any collection of network elements within a common sphere of
       address management or path computational responsibility.  Examples of
       domains include Interior Gateway Protocol (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/GMPLS Label Switched Path

       LSR: Label Switch Router

       MPLS: 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 [RFC4655]).

       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 (G)MPLS Label Switched Path.

       See [RFC4655] for further definitions of terms.

    Ash & Le Roux                Informational                      [Page 3]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

    4.  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 co-located, a request/response communication
       protocol is required to carry the request and return the response.
       If the PCC and PCE are co-located, a communication protocol is not
       required, but implementations may choose to utilize a protocol for
       exchanges between the components.

       In order for a PCC and PCE to 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 5.

       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 [RFC4655], 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.

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

    Ash & Le Roux                Informational                      [Page 4]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

    5.  PCE Communication Protocol Generic Requirements

    5.1.  Basic Protocol Requirements

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

    5.1.2.  Client-Server Communication

       PCC-PCE communication is by nature client-server based.  The PCECP
       MUST allow a PCC 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 once the path has been computed.

       In addition to this request-response mode, there are cases where
       there is unsolicited communication from the PCE to the PCC (see
       Section 5.1.11).

    5.1.3.  Transport

       The PCECP SHOULD utilize an existing transport protocol that supports
       congestion control.  This transport protocol may also be used to
       satisfy some requirements in other sections of this document, such as
       reliability.  The PCECP SHOULD be defined for one transport protocol
       only in order to ensure interoperability.  The transport protocol
       MUST NOT limit the size of the message used by the PCECP.

    5.1.4.  Path Computation Requests

       The path computation request message MUST include at least the source
       and destination.  Note that the path computation request is for an
       LSP or LSP segment, and the source and destination supplied are the
       start and end of the computation being requested (i.e., of the LSP
       segment).

    Ash & Le Roux                Informational                      [Page 5]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       The path computation request message MUST support the inclusion of a
       set of one or more path constraints, including but not limited to the
       requested bandwidth or resources (hops, affinities, etc.) to
       include/exclude.  For example, a PCC may request the PCE to exclude
       points of failure in the computation of 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 is supplied in Section 5.1.16.  Specification
       of constraints MUST be future-proofed as described in Section 5.1.14.

       The requester MUST be allowed to select from or prefer an advertised
       list or minimal subset of standard objective functions and functional
       options.  An objective function is used by the PCE to process
       constraints to 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 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 5.1.17.  Specification of objective
       functions MUST be future-proofed as described in Section 5.1.14.

       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 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 5.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 the
       PCC to indicate the metric type (IGP or TE) to be used for shortest
       path selection.  Note that other metric types may be specified in the
       future.

    Ash & Le Roux                Informational                      [Page 6]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       There may be cases where a single path cannot fit a given bandwidth
       request, while a set of paths could be combined to fit the request.
       Such path combination to serve a given request is called load-
       balancing.  The request message MUST allow the PCC to indicate if
       load-balancing is allowed.  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 request message MUST
       allow specification of the degree of disjointness of the members of
       the load-balancing group.

    5.1.5.  Path Computation Responses

       The path computation response message MUST allow the PCE to return
       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 [RFC3209] for the
       definition of strict hop, loose hop, and abstract node.

       A positive response from the PCE MUST include the paths that have
       been computed.  A positive PCECP computation response MUST support
       the inclusion of a set of attributes of the computed path, such as
       the path costs (e.g., cumulative link TE metrics and cumulative link
       IGP metrics) and the computed bandwidth.  The latter is useful when a
       single path cannot serve the requested bandwidth and load balancing
       is applied.

       When a 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 MAY include advice about which constraints might be
       relaxed to be more likely to achieve a positive result.

       The PCECP response message MUST support the inclusion of the set of
       computed paths of a load-balancing path group, as well as their
       respective bandwidths.

    5.1.6.  Cancellation of Pending Requests

       A PCC MUST be able to cancel a pending request using an appropriate
       message.  A PCC that has sent a request to a PCE and no longer needs
       a response, for instance, because it no longer wants to set up the

    Ash & Le Roux                Informational                      [Page 7]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       associated service, MUST be able to notify the PCE that it can clear
       the request (i.e., stop the computation if already started, and clear
       the context).  The PCE may also wish to cancel a pending request
       because of some congested state.

    5.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 (e.g.,
       requesting disjoint paths) or uncorrelated (requesting paths for
       unrelated services).  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., multiple suited paths, paths of a load-balancing path
       group) 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 and
       are carried in a sequence of correlated messages.

       The PCE MUST inform the PCC of its capabilities.  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.

       It MUST be 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 possible to limit the message size by configuration on
       PCCs and PCEs.

    5.1.8.  Reliable Message Exchange

       The PCECP MUST support reliable transmission of PCECP packets.  This
       may form part of the protocol itself or may be achieved by the
       selection of a suitable transport protocol (see Section 5.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 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

    Ash & Le Roux                Informational                      [Page 8]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       saturation of the PCEs.  The PCECP MUST support indication of
       congestion state and rate limitation state.  This should enable, for
       example, a PCE to limit the rate of incoming request messages if the
       request rate is too high.

       The PCECP or its transport protocol MUST provide the following:

       - Detection and report of lost or corrupted messages
       - Automatic attempts to retransmit lost messages without reference to
         the application
       - Handling of out-of-order messages
       - Handling of duplicate messages
       - Flow control and back-pressure to enable throttling of requests and
         responses
       - Rapid PCECP communication failure detection
       - Distinction between partner failure and communication channel
         failure after the PCECP communication is recovered

       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 MUST NOT be added
       to the PCECP where the chosen transport protocol already provides it.

    5.1.9.  Secure Message Exchange

       The PCC-PCE communication protocol MUST include provisions to ensure
       the security of the exchanges between the entities.  In particular,
       it MUST support mechanisms to prevent spoofing (e.g.,
       authentication), snooping (e.g., preservation of confidentiality of
       information through techniques such as encryption), and Denial of
       Service (DoS) attacks (e.g., packet filtering, rate limiting, no
       promiscuous listening).  Once a PCC is identified and authenticated,
       it has the same privileges as all other PCCs.

       To ensure confidentiality, the PCECP SHOULD allow local policy to be
       configured on the PCE to not provide explicit path(s).  If a PCC
       requests an explicit path when this is not allowed, the PCE MUST
       return an error message to the requesting PCC and the pending path
       computation request MUST be discarded.

       Authorization requirements [RFC3127] include reject capability,
       reauthorization on demand, support for access rules and filters, and
       unsolicited disconnect.

    Ash & Le Roux                Informational                      [Page 9]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       IP addresses are used to identify PCCs and PCEs.  Where the PCC-PCE
       communication takes place entirely within one limited domain, the use
       of a private address space that is not available to customer systems
       MAY be used to help protect the information exchange, but other
       mechanisms MUST also be available.

       These functions may be provided by the transport protocol or directly
       by the PCECP.  See Section 6 for further discussion of security
       considerations.

    5.1.10.  Request Prioritization

       The PCECP MUST allow a PCC to specify the priority of a computation
       request.

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

    5.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 PCECP MUST support unsolicited notifications from PCE to PCC, or
       PCC to PCE.  This requirement facilitates the unsolicited
       communication of information and alerts between PCCs and PCEs.  As
       specified in Section 5.1.8, these notification messages must be
       supported by a reliable transmission protocol.  The PCECP MAY also
       support response messages to the unsolicited notification messages.

    5.1.12.  Asynchronous Communication

       The PCC-PCE protocol MUST allow for asynchronous communication.  A
       PCC MUST NOT have to wait for a response to one request before it can
       make another request.

       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 5.1.10).  A consequent requirement is that path
       computation responses MUST include a direct correlation to the
       associated request.

    5.1.13.  Communication Overhead Minimization

       The request and response messages SHOULD be designed so that the
       communication overhead is minimized.  In particular, the overhead per

    Ash & Le Roux                Informational                     [Page 10]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       message SHOULD be minimized, and the number of bytes exchanged to
       arrive at a computation answer SHOULD be minimized.  Other
       considerations in overhead minimization include the following:

       - the number 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)

    5.1.14.  Extensibility

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

       For example, the PCECP MUST be extensible to support various PCE-
       based applications, such as the following:

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

       The PCECP MUST support the requirements specified in the
       application-specific requirements documents.  The PCECP MUST also
       allow extensions as more PCE applications will be introduced in the
       future.

       The PCECP SHOULD also be extensible to support future applications
       not currently in the scope of the PCE working group, such as, for
       instance, point-to-multipoint 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
       documents.

    5.1.15.  Scalability

       The PCECP MUST scale well, at least as good as linearly, with an
       increase of any of the following parameters.  Minimum order of
       magnitude estimates of what the PCECP should support are given in
       parenthesis (note: these are requirements on the PCECP, not on the
       PCE):

    Ash & Le Roux                Informational                     [Page 11]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       - 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 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 to perform computation.

    5.1.16.  Constraints

       This section provides a list of generic constraints that MUST be
       supported by the PCECP.  Other constraints may be added to service
       specific applications as identified by separate application-specific
       requirements documents.  Note that the provisions of Section 5.1.14
       mean that new constraints can be added to this list without impacting
       the protocol to a level that requires major protocol changes.

       The set of supported generic constraints MUST include at least the
       following:

       o MPLS-TE and GMPLS generic constraints:
         - Bandwidth
         - Affinities inclusion/exclusion
         - Link, Node, Shared Risk Link Group (SRLG) inclusion/exclusion
         - Maximum end-to-end IGP metric
         - Maximum hop count
         - Maximum end-to-end TE metric
         - Degree of paths disjointness (Link, Node, SRLG)

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

    Ash & Le Roux                Informational                     [Page 12]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

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

    5.1.17.  Objective Functions Supported

       This section provides a list of generic objective functions that MUST
       be supported by the PCECP.  Other objective functions MAY be added to
       service specific applications as identified by separate application-
       specific requirements documents.  Note that the provisions of Section
       5.1.14 mean that new objective functions MAY be added to this list
       without impacting the protocol.

       The PCECP MUST support at least the following "unsynchronized"
       functions:

       - Minimum cost path with respect to a specified metric
         (shortest path)
       - Least loaded path
       - Maximum available bandwidth path

       Also, the PCECP MUST support at least the following "synchronized"
       objective functions:

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

    5.2.  Deployment Support Requirements

    5.2.1.  Support for Different Service Provider Environments

       The PCECP must at least support the following environments:

       - MPLS-TE and GMPLS networks
       - Packet and non-packet networks
       - Centralized and distributed PCE path computation
       - Single and multiple PCE path computation

       For example, PCECP is possibly applicable to packet networks (e.g.,
       IP networks), non-packet networks (e.g., time-division multiplexed
       (TDM) transport), and perhaps to multi-layer GMPLS control plane
       environments.  Definitions of centralized, distributed, single, and
       multiple PCE path computation can be found in [RFC4655].

    Ash & Le Roux                Informational                     [Page 13]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

    5.2.2.  Policy Support

       The PCECP MUST allow for the use of policies to accept/reject
       requests.  It MUST include the ability for a PCE to supply sufficient
       detail when it rejects a request for policy reasons to allow the PCC
       to determine the reason for rejection or failure.  For example,
       filtering could be required for a PCE that serves one domain (perhaps
       an AS) such that all requests that come from another domain (AS) are
       rejected.  However, specific policy details are left to application-
       specific PCECP requirements.  Actual policies, configuration of
       policies, and applicability of policies are out of scope.

       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.

       PCECP messages MUST be able to carry transparent policy information.

    5.3.  Aliveness Detection & Recovery Requirements

    5.3.1.  Aliveness Detection

       The PCECP MUST allow a PCC/PCE to

       - check the liveliness of the PCC-PCE communication,
       - rapidly detect PCC-PCE communication failure (indifferently to
         partner failure or connectivity failure), and
       - 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
       PCE and PCC liveness.

    5.3.2.  Protocol Recovery

       In the event of the failure of a sender or of the communication
       channel, the PCECP, upon recovery, MUST support resynchronization of
       information (e.g., PCE congestion status) and requests between the
       sender and the receiver; this SHOULD be arranged so as to minimize
       repeat data transfer.

    5.3.3.  LSP Rerouting & Reoptimization

       If an LSP fails owing to the failure of a link or node that it
       traverses, a new computation request may be made to a PCE in order to
       repair the LSP.  Since the PCC cannot know that the PCE's TED has
       been updated to reflect the failure network information, it is useful
       to include this information in the new path computation request.

    Ash & Le Roux                Informational                     [Page 14]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       Also, in order to re-use the resources used by the old LSP, it may be
       advantageous to indicate the route of the old LSP as part of the new
       path computation request.

       Hence the path computation request message MUST allow an indication
       of whether the computation is for LSP restoration, and it MUST
       support the inclusion of the previously computed path as well as the
       identity of the failed element.  Note that the old path might only be
       useful if the old LSP has not yet been torn down.  The PCE MAY choose
       to take failure indication information carried in a given request
       into account when handling subsequent requests.  This should be
       driven by local policy decision.

       Note that a network failure may impact a large number of LSPs.  In
       this case, a potentially large number of PCCs will simultaneously
       send requests to the PCE.  The PCECP MUST properly handle such
       overload situations, such as, for instance, through throttling of
       requests as set forth in Section 5.1.8.

       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.

    6.  Security Considerations

       Key management MUST be provided by the PCECP to provide for the
       authenticity and integrity of PCECP messages.  This will allow
       protecting against PCE or PCC impersonation and also against message
       content falsification.

       The impact of the use of a PCECP MUST be considered in 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 (see [PCE-DISC-REQ]).  An increase in
       inter-domain information flows may increase the vulnerability to
       security attacks, and the facilitation of inter-domain 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

    Ash & Le Roux                Informational                     [Page 15]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       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 introduces
       additional security issues.  Most notable among these are the
       following:

       - Interception of PCE requests or responses
       - Impersonation of PCE or PCC
       - DoS attacks on PCEs or PCCs

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

       There are security implications of allowing arbitrary objective
       functions, as discussed in Section 5.1.17, and the PCECP MUST allow
       mitigating the risk of, for example, a PCC using complex objectives
       to intentionally drive a PCE into resource exhaustion.

    7.  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, Operations
         Administration and Maintenance (OAM), etc.)
       - Configuration implications for the protocol

       PCECP operations MUST be modeled and controlled through appropriate
       MIB modules.  There are enough specific differences between PCCs and
       PCEs to lead to the need of defining separate MIB modules.
       Statistics gathering will form an important part of the operation of
       the PCECP.  The MIB modules MUST provide information that will allow
       an operator to determine PCECP historical interactions and the
       success rate of requests.  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
       MUST be 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.

    Ash & Le Roux                Informational                     [Page 16]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       The new MIB modules should also be used to provide notifications
       (traps) when thresholds are crossed or when important events occur.
       For example, the MIB module may support indication of exceeding the
       congestion state threshold or rate limitation state.

       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.

       The PCECP MUST support indication of congestion state and rate
       limitation state, and MAY allow the operator to control such a
       function.

    8.  Contributors

       This document is the result of the PCE Working Group PCECP
       requirements design team joint effort.  In addition to the
       authors/editors listed in the "Authors' Addresses" section, the
       following are the design team members who contributed to the
       document:

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

       Arthi Ayyangar
       Nuova Systems,
       2600 San Tomas Expressway
       Santa Clara, CA 95051
       EMail: arthi@nuovasystems.com

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

       Igor Bryskin
       Independent Consultant
       EMail: i_bryskin@yahoo.com

    Ash & Le Roux                Informational                     [Page 17]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

       Dean Cheng
       Cisco Systems, Inc.
       3700 Cisco Way
       San Jose CA 95134 USA
       Phone:  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: 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

    9.  Acknowledgements

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

    Ash & Le Roux                Informational                     [Page 18]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

    10.  References

    10.1.  Normative References

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

       [RFC4655]           Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
                           Computation Element (PCE)-Based Architecture",
                           RFC 4655, August 2006.

    10.2.  Informative References

       [METRIC]            Le Faucheur, F., Uppili, R., Vedrenne, A.,
                           Merckx, P., and T. Telkamp, "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, J.L., et al., "Requirements for Path
                           Computation Element (PCE) Discovery", Work in
                           Progress.

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

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

       [PCECP-INTER-AS]    Bitar, N., Zhang, R., Kumaki, K., "Inter-AS
                           Requirements for the Path Computation Element
                           Communication Protocol (PCECP)", Work in
                           Progress.

       [RFC3209]           Awduche, D., Berger, L., Gan, D., Li, T.,
                           Srinivasan, V., and G. Swallow, "RSVP-TE:
                           Extensions to RSVP for LSP Tunnels", RFC 3209,
                           December 2001.

       [RFC3127]           Mitton, D., St.Johns, M., Barkley, S., Nelson,
                           D., Patil, B., Stevens, M., and B. Wolff,
                           "Authentication, Authorization, and Accounting:
                           Protocol Evaluation", RFC 3127, June 2001.

    Ash & Le Roux                Informational                     [Page 19]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

    Authors' Addresses

       Jerry Ash (Editor)
       AT&T
       Room MT D5-2A01
       200 Laurel Avenue
       Middletown, NJ 07748, USA

       Phone: (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@orange-ft.com

    Ash & Le Roux                Informational                     [Page 20]

    RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006

    Full Copyright Statement

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

       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.

    Intellectual Property

       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.

    Acknowledgement

       Funding for the RFC Editor function is provided by the IETF
       Administrative Support Activity (IASA).

    Ash & Le Roux                Informational                     [Page 21]