IETF Internet Draft PCE Working Group Jerry Ash (AT&T) Proposed Status: Informational Editor Expires: June 2006 J.L. Le Roux (France Telecom) Editor December 2005 draft-ietf-pce-comm-protocol-gen-reqs-03.txt PCE Communication Protocol Generic Requirements Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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. PCE Design Team [Page 1] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 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 (PCECP) . . . . . . . . . 5 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 6 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 8 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 8 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 8 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 8 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 9 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 10 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 10 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 11 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 12 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 12 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 12 6.1.13 Communication Overhead Minimization . . . . . . . . . 12 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 13 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 13 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 14 6.1.17 Objective Functions Supported . . . . . . . . . . . . 15 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 15 6.2.1 Support for Different Service Provider Environments . . 15 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 15 6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 16 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 16 6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 16 6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 16 6.3.4 LSP Rerouting & Reoptimization . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 19 12. Informational References . . . . . . . . . . . . . . . . . . . . 19 13. Authors' & Contributors' Addresses . . . . . . . . . . . . . . . 20 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 21 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 21 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 22 PCE Design Team [Page 2] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 1. Contributors This document is the result of the PCE Working Group PCE Communication Protocol (PCECP) requirements design team joint effort. The following are the design team member authors that contributed to the present document: Jerry Ash (AT&T) Alia Atlas (Google, Inc.) Arthi Ayyangar (Juniper) Nabil Bitar (Verizon) Igor Bryskin (Independent Consultant) Dean Cheng (Cisco) Durga Gangisetti (MCI) Kenji Kumaki (KDDI) Jean-Louis Le Roux (France Telecom) Eiji Oki (NTT) Raymond Zhang (BT Infonet) 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Introduction A Path Computation Element (PCE) [PCE-ARCH] supports requests for path computation issued by a Path Computation Client (PCC), which may be 'composite' (co-located) or 'external' (remote) from a PCE. When the PCC is external from the PCE, a request/response communication protocol is required to carry the path computation request and return the response. In order for the PCC and PCE to communicate, the PCC must know the location of the PCE: PCE discovery is described in [PCE-DISC-REQ]. The PCE operates on a network graph in order to compute paths based on the path computation request 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 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 PCE Design Team [Page 3] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 within a service provider network, or multiple ASs across multiple service provider networks. GMPLS: Generalized Multi-Protocol Label Switching LSP: MPLS Label Switched Path. 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 [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 (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 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 PCE Design Team [Page 4] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 or cannot be performed, a negative response is required with an indication of the type of failure. A request/response protocol is also required for a PCE to communicate path computation requests to another PCE and for that PCE to return the path computation response. As described in [PCE-ARCH], there is no reason to assume that two different protocols are needed, and this document assumes that a single protocol will satisfy all requirements for PCC-PCE and PCE-PCE communication. [PCE-ARCH] describes four models of PCE: composite, external, multiple PCE path computation, and multiple PCE path computation with inter-PCE communication. In all cases except the composite PCE model, a PCECP is required. The requirements defined in this document are applicable to all models described in the [PCE-ARCH]. 6. PCE Communication Protocol Generic Requirements The following is a summary of the requirements in Section 6: Requirement Necessity Ref. ------------------------------------------------------------------ Commonality of PCC-PCE and PCE-PCE communication MUST 6.1.1 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 MAY 6.1.3 Transport protocol satisfy reliability & security requirements MAY 6.1.3 Transport protocol limits size of message MUST NOT 6.1.3 Support path computation requests MUST 6.1.4 include source & destination support path constraints (e.g., bandwidth, hops, affinities) to include/exclude 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 Allow indicating the metric type (IGP or TE) to be used for shortest path selection MUST 6.1.4 Allow indicating the set of aggregate path attributes required in response message MUST 6.1.4 Allow indicating if load-balancing is allowed MUST 6.1.4 Support path computation responses MUST 6.1.5 Negative response support reasons for failure, constraints to relax to achieve positive result SHOULD 6.1.5 Support inclusion of set of aggregate path attributes MUST 6.1.5 Support inclusion of set of computed paths of a PCE Design Team [Page 5] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 load-balancing path group, as well as their respective bandwidth MUST 6.1.5 Cancellation of pending requests MUST 6.1.6 Multiple requests and responses MUST 6.1.7 Limit by configuration number of requests within a 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 (achieved by PCECP itself or transport protocol MUST 6.1.8 Allow detection & recovery of lost messages to occur quickly & not impede operation of 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 PCECP if transport protocol provides it SHOULD NOT 6.1.8 Secure message exchange (provided by PCECP or transport protocol MUST 6.1.9 Support mechanisms to prevent spoofing (e.g., authentication), snooping (e.g., encryption), DOS attacks MUST 6.1.9 Request prioritization MUST 6.1.10 Unsolicited notifications SHOULD 6.1.11 Allow asynchronous communication MUST 6.1.12 PCC has to wait for response before making another request MUST NOT 6.1.12 Allow order of responses differ from order of requests MUST 6.1.12 Communication overhead minimization SHOULD 6.1.13 Give particular attention to message size SHOULD 6.1.13 Extensibility without requiring modifications to the protocol MUST 6.1.14 Easily extensible to support intra-area, inter-area, inter-AS intra provider, inter-AS inter-provider, multi-layer path & virtual network topology path computation MUST 6.1.14 Easily extensible to support future applications not in scope (e.g., P2MP path computations) SHOULD 6.1.14 PCE Design Team [Page 6] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 Scalability at least linearly with increase in number of PCCs, PCEs, PCCs communicating with a single PCE, PCEs communicated to by a single PCC, PCEs communicated to by another PCE, domains, path requests, handling bursts of requests MUST 6.1.15 Support path computation constraints MUST 6.1.16 Support "unsynchronized" & "synchronized" objective functions MUST 6.1.17 Support different service provider environments (e.g., MPLS-TE and GMPLS networks, centralized & distributed PCE path computation, single & multiple PCE path computation) MUST 6.2.1 Policy support for policies to accept/reject requests, PCC to determine reason for rejection, notification of policy violation MUST 6.2.2 Aliveness detection of PCCs/PCEs, partner failure detection MUST 6.3.1 PCC/PCE failure response procedures defined for PCE/PCC failures, PCC able to clear pending request must 6.3.2 PCC select another PCE upon detection of PCE failure MUST 6.3.2 PCE able to clear pending requests from a PCC (e.g. when it detects PCC failure or request buffer full) must 6.3.2 Protocol recovery support resynchronization of information & requests between sender & receiver MUST 6.3.3 Minimize repeat data transfer, allow PCE to respond to computation requests issued before failure without requests being re-issued SHOULD 6.3.3 Stateful PCE able to resynchronize/recover states (e.g., LSP status, paths) after restart SHOULD 6.3.3 Allow indicating if computation is for LSP restoration (support inclusion of previously computed path & failed element) MUST 6.3.4 Support inclusion in response message of upper bound of a random waiting time for further requests MAY 6.3.4 Support path reoptimization & inclusion of a previously computed path MUST 6.3.4 6.1 Basic Protocol Requirements 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication A single protocol MUST be defined for PCC-PCE and PCE-PCE communication. A PCE requesting a path from another PCE can be considered as a PCC. PCE Design Team [Page 7] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 6.1.2 Client-Server Communication PCC-PCE and PCE-PCE communication is by nature client-server based. The PCECP MUST allow for a PCC or a PCE to send a request message to a PCE to request path computation, and for a PCE to reply with a response message to the requesting PCC or PCE, once the path has been computed. In addition to this request-response mode, there may be cases where there is unsolicited communication from the PCE to PCC (see Requirement 6.1.6). 6.1.3 Transport The PCECP may utilize an existing transport protocol or operate directly over IP. If a transport protocol is used, it may be used to satisfy some requirements stated in other sections of this document (for example, reliability and security). If a transport protocol is used, it MUST NOT limit the size of the message used by the PCECP. Where requirements expressed in this document match the function of existing transport protocols, consideration MUST be given to the use of those protocols. 6.1.4 Path Computation Requests The request message MUST include, at least, a source and a destination. However, there is no assumption that the receiving PCE has the complete source/destination domain topology, particularly in the multiple PCE path computation model [PCE-ARCH]. In the latter case, the PCE may have incomplete topological information for multiple domains. The message MUST support the inclusion of a set of one or more path constraints, including the requested bandwidth or resources (hops, affinities, etc.) to include/exclude (e.g., a PCC requests the PCE to exclude points of failure in the computation of the new path if an LSP setup fails). The actual inclusion of constraints is a choice for the PCC issuing the request. A list of core constraints that MUST be supported by the PCECP is supplied in Section 6.1.16. Specification of constraints must be future-proofed as described in Section 6.1.14. The requester MUST be allowed to select or prefer from an advertised list or minimal subset of standard objective functions and functional options. An objective function is used by the PCE to compute a path metric in order to select the best candidate paths (e.g., minimum hop PCE Design Team [Page 8] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 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. A list of core objective functions that MUST be supported by the PCECP is supplied in Section 6.1.17. Specification of objective functions MUST be future-proofed as described in Section 6.1.14. The shortest path selection may rely either on the TE metric or on the IGP metric [METRIC]. Hence the PCECP request message MUST allow indicating the metric type (IGP or TE) to be used for shortest path selection. It MUST also allow indicating the set of aggregate path attributes (hop-count, cumulated TE-metric, cumulated IGP-Metric) that are required in the PCECP response message. The request message MUST allow indicating if load-balancing is allowed or not. It MUST also include the maximum number of paths in a load-balancing path group, and the minimum path bandwidth in a load-balancing path group. The requester SHOULD also be able to select a vendor-specific or experimental objective function or functional option. Furthermore, 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. Specification of objective functions and objective parameters is required in the protocol extensibility specified in Section 6.1.14. 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 explicitly requested by the PCC. This might include policy based routing path computation for load balancing instructed by the management plane. The PCC MUST NOT be allowed to request or cause a computation to fail because it does not wish the PCE to apply a specific objective function. Allowing such behavior would constitute a 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, PCE Design Team [Page 9] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 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 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. The PCECP response message MUST support the inclusion of a set of aggregate path attributes. 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 bandwidth. 6.1.6 Cancellation of Pending Requests A PCC or PCE MUST be able to cancel a pending request, using an appropriate notification between PCECP peers. A PCC that has sent a request to a PCE and no longer needs a response, for instance, because it received a satisfactory answer from another PCE, MUST be able to notify the PCE that it must clear the request (i.e. stop the computation, if already started, and clear the context). Similarly, a PCE that received a request from a PCC that it cannot serve, for example, due to congestion, MUST be able to 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 PCE Design Team [Page 10] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 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 message. 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 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 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 PCECP or the transport protocol it uses MUST properly handle such overload situations, such as through throttling of 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 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. - Rapid PCE/PCC or PCC-PCE connection 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 PCECP where the chosen transport protocol already provides it. 6.1.9 Secure Message Exchange The PCC-PCE and PCE-PCE communication protocol MUST include provisions to improve the security of the exchanges between the PCE Design Team [Page 11] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 entities. In particular, it MUST support mechanisms to prevent spoofing (e.g., authentication), snooping (e.g., encryption) and DOS attacks (e.g., rate limiting, no promiscuous listening). This function may be provided by the transport protocol or directly by the PCECP. See Section 7 for further discussion of security considerations. 6.1.10 Request Prioritization The PCECP MUST allow a PCC to specify the priority of a computation request. This priority 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 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 PCECP SHOULD support unsolicited notifications from PCE to PCC, PCE to PCE, or PCC to PCE. This requirement facilitates the unsolicited communication of information and alerts between PCCs and PCEs and between PCEs. 6.1.12 Asynchronous Communication The PCC-PCE protocol MUST allow for asynchronous communication. A PCC MUST NOT have to wait for a response 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 6.1.10). 6.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 message should be minimized, and the number of 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: PCE Design Team [Page 12] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 - 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 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 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 computation The 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 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 documents. 6.1.15 Scalability The PCECP MUST scale well, at least as good as linearly, with an increase of any of the following parameters (note, minimum order of magnitude estimates of what the PCECP should support are given in parenthesis): - number of PCCs (1000/domain) - number of PCEs (100/domain) - number of PCCs communicating with a 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 request messages (average of 10/second/PCE) - handling bursts of requests (burst of 100/second/PCE within a 10- second interval). PCE Design Team [Page 13] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 Note that path requests can be bundled in path request messages, for example, 10 path 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. 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 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 IGP metric - Hop Count - Maximum end-to-end TE metric - Multiple disjoint path computation to allow path protection o MPLS-TE specific constraints - Class-type - Local protection - Node protection - Bandwidth protection o GMPLS specific constraints - Switching type, encoding type - Link protection type Regarding affinities inclusion/exclusion, note the three categories used in [RSVP-TE]: exclude-any, include-any, include-all. Regarding link, node, SRLG inclusion/exclusion, note the mandatory and desired exclusion approach in [EXCLUDE-ROUTE]. PCE Design Team [Page 14] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 6.1.17 Objective Functions Supported This section provides a list of generic objective functions that MUST be supported by the PCECP. Other objectives functions MAY be added to service specific applications as identified by separate application-specific requirements documents. Note that the absence of an objective function in this list does not mean that the objective function may not be supported. Note also that the provisions of Section 6.1.14 mean that new objective functions MAY be added to this list without impacting the protocol. The PCECP MUST support the following "unsynchronized" objective functions: o Minimum cost path (shortest path) o Least loaded path (widest path) o To be determined Also the PCECP MUST support the following "synchronized" objective functions: o Minimize aggregate bandwidth consumption on all links o Maximize the residual bandwidth on the most loaded link. O Minimize the cumulative cost of a set of diverse paths. 6.2 Deployment Support Requirements 6.2.1 Support for Different Service Provider Environments The PCECP MUST operate in various different service provider network environments that utilize an IP-based control plane, including - MPLS-TE and GMPLS networks - packet and non-packet networks - centralized 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 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 PCECP requirements. Furthermore, the PCECP MUST PCE Design Team [Page 15] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 allow for the notification of a policy violation. 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. 6.3 Detection & Recovery Requirements 6.3.1 Aliveness Detection The 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 PCECP MUST provide partner failure detection. The aliveness detection mechanism MUST ensure reciprocal knowledge of PCE and PCC liveness. Note that the PCE or PCC software component can be lost without losing the connection or the transport end-point, when a transport protocol is used. 6.3.2 PCC/PCE Failure Response Appropriate PCC and PCE procedures MUST be defined to deal with PCE and PCC failures. A PCC must be able 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. 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. PCE Design Team [Page 16] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 The response to a computation request issued before the PCC is restarted will not be helpful and could be a waste of effort. Thus it is better to allow the request to be re-issued in shorthand (e.g. by request number) if the PCC remembers that it had previously issued it and is still interested in the response. The PCECP SHOULD allow a PCE to respond to computation requests issued before the failure without the requests being re-issued. 6.3.4 LSP Rerouting & Reoptimization Upon LSP failure, due to link, node or SRLG failure, a head-end LSR may send a request to the PCE so as to reroute the LSP over an alternate path. So as to ease the computation such request should include the previous path and the failed element (if it can be identified). Hence the request message MUST allow indicating if the computation is for an LSP restoration, and MUST support the inclusion of the previously computed path as well as the failed element. Note that the old path is actually useful only if the old LSP is not torn down yet. This is up to the PCC to decide if it includes the old path or not. Note that a network failure may impact a large number of LSPs. A potentially large number of PCCs, are going to simultaneously send a request to the PCE. Some jittering may be used on PCCs so as to delay a request to the PCE, under network failure condition. The PCECP MAY support the inclusion, in a response message to a PCC, of an upper bound of a random waiting time to be used for further requests to the PCE (e.g. the PCC will wait for a random value between 0 and the upper bound before sending another request). This upper bound would depend on the level of congestion of the PCE. 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. 7. Security Considerations The impact of the use of a PCECP MUST be considered in the light of the impact that it has on the security of the existing routing and signaling protocols and techniques in use within the network. Intra-domain security is impacted since there is a new interface, protocol and element in the network. Any host in the network could impersonate a PCC, and receive detailed information on network paths. Any host could also impersonate a PCE, both gathering information about the network before passing the request on to a real PCE, and PCE Design Team [Page 17] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 spoofing responses. Some protection here depends on 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 may increase the impact of these security attacks. Of particular relevance are the implications for confidentiality inherent in a PCECP for multi-domain networks. It is not necessarily the case that a multi-domain PCE solution will compromise security, but solutions MUST examine their impacts in this area. Applicability statements for particular combinations of signaling, routing and path computation techniques are expected to contain detailed security sections. It should be observed that the use of an external PCE does introduce additional security issues. Most notable amongst these are: - interception of PCE requests or responses - impersonation of PCE or PCC - denial of service attacks on PCE or PCE communication mechanisms It is expected that the PCECP will address these issues in detail using authentication, encryption and DoS protection techniques. See also Section 6.1.9. 8. Manageability Considerations Manageability of the PCECP MUST address the following considerations: - 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 PCE Design Team [Page 18] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 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 [METRIC] Le Faucheur, F., et. al., "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 2004. [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path Computation Element (PCE) Discovery," work in progress. [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. PCE Design Team [Page 19] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 13. Authors' & Contributors' Addresses Jerry Ash (Editor) AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 Email: gash@att.com Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, FRANCE Email: jeanlouis.leroux@francetelecom.com Alia K. Atlas Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 Email: akatlas@alum.mit.edu Arthi Ayyangar Juniper Networks, Inc. 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA Email: arthi@juniper.net Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 Email: nabil.bitar@verizon.com Igor Bryskin Independent Consultant Email: i_bryskin@yahoo.com Dean Cheng Cisco Systems Inc. 3700 Cisco Way San Jose CA 95134 USA Phone: +1 408 527 0677 Email: dcheng@cisco.com Durga Gangisetti MCI Email: durga.gangisetti@mci.com Kenji Kumaki KDDI Corporation PCE Design Team [Page 20] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 Email: ke-kumaki@kddi.com Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585, JAPAN Email: oki.eiji@lab.ntt.co.jp Raymond Zhang BT INFONET Services Corporation 2160 E. Grand Ave. El Segundo, CA 90245 USA Email: Raymond_zhang@bt.infonet.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. PCE Design Team [Page 21] Internet Draft PCE Communication Protocol Generic Reqmnts Dec 2005 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. PCE Design Team [Page 22]