IETF Internet Draft PCE Working Group Jerry Ash (AT&T) Proposed Status: Informational Editor Expires:
November 2005January 2006 J.L. Le Roux (France Telecom) Editor MayJuly 2005 draft-ietf-pce-comm-protocol-gen-reqs-00.txtdraft-ietf-pce-comm-protocol-gen-reqs-01.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 November 26, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Constraint-based path computation is a fundamental building block for traffic engineering systems such as multiprotocol label switching (MPLS) and generalized multiprotocol label switching (GMPLS) networks. Path computation in large, multi-domain or multi-layer networks is highly complex and may require special computational components and cooperation between the different network domains. There are multiple components in the Path Computation Element (PCE)- based path computation model, including PCE discovery and the PCE communication protocol.The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to PCEs.Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Overview of PCE Communication Protocol . . .(PCEP) . . . . . . . . . . 4 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 58 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 8 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 6 6.1.2 PCC-PCE8 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 PCE-PCE CommunicationResponses . . . . . . . . . . . 7 6.1.3. 10 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 7 6.1.411 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 8 6.1.511 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 8 6.1.611 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . . 8 6.1.712 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 8 6.1.812 6.1.13 Communication Overhead Minimization . . . . . . . . . . 9 6.1.912 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . . 9 6.1.1012 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 9 6.2 Deployment Support Requirements13 6.1.16 Constraints . . . . . . . . . . . . . . . 10 6.2.1 Support for Various Service Provider Environments and Applications. . . . . . 13 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 1014 6.2.1 Support for Different Service Provider Environments . . 14 6.2.2 ConfidentialityPolicy Support . . . . . . . . . . . . . . . . . . . . 1014 6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 1014 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 1014 6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 1015 6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 1115 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 1115 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 1116 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 1216 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 1216 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 1216 12. Informational References . . . . . . . . . . . . . . . . . . . . 1317 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 14.17 Intellectual Property ConsiderationsStatement . . . . . . . . . . . . . . 14 1. Contributors This document is the result. . . . 18 Disclaimer of the PCE Working Group PCE communication protocol requirements designValidity . . . . . . . . . . . . . . . . . . . . . . . 18 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Contributors This document is the result of the PCE Working Group PCE communication protocol (PCEP) requirements design team joint effort. The following are the design team member authors that contributed to the present document: Jerry Ash (AT&T) Alia Atlas (Avici) 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 The path computation element (PCE) capability[PCE-ARCH] supports requests for path computation issued by a path computation client (PCC), which may be co-located'composite' (co-located) or remote'external' (remote) from a PCE. When the PCC is remoteexternal from the PCE, a request/response communicationscommunication 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 discoverknow the location of the PCE, asPCE: 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, whichPCC. The path computation request will normally include the source, destination,source and destination of the paths to be computed, and a set of constraints.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, where the PCE communications protocol solution MUST satisfy these requirements.PCEP. Application-specific requirements are beyond the scope of this document, and will be addressed in separate documents. 4. Terminology Domain: any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include IGP areas, Autonomous Systems (ASs), multiple ASs within a service provider network, or multiple ASs across multiple service provider networks. GMPLS: generalized multiprotocol label switchingGeneralized Multiprotocol Label Switching LSP: MPLS Label Switched Path. MPLS: multiprotocol label switching PCC: Path Computation Client: any client application requesting a Path computation to be performed by the PCE. PCE: Path Computation Element: an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints (see further description in [PCE-ARCH]). TED: Traffic Engineering Database, which contains the topology and resource information of the network or network segment used by a PCE. TE LSP: Traffic Engineering MPLS Label Switched Path. See [PCE-ARCH] for further definitions of terms. 5. Overview of PCE Communication Protocol (PCEP) In the PCE model, path computation requests are issued by a PCC to a PCE that may be co-locatedcomposite (co-located) or situated at a remote site.external (remote). If the PCC and PCE are not co-locatedcomposite, a request/response communicationscommunication protocol is required to carry the request and return the response. If the PCC and PCE are co-locatedcomposite, a communicationscommunication 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 PCE Communications Protocol.PCEP. A path computation request issued by the PCC will includeincludes a specification of the path(s) needed. The information supplied will includeincludes, at a minimumminimum, the source and destination for the path(s),paths, but may also include a set of further requirements (known as constraints) as described in Section 6. The response from the PCE may be positive in which case it will include the paths that have been computed. If the computation fails or cannot be performed, a negative response is required with an indication of the type of and reason(s) for thefailure. A negative response may also 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. That is, the PCE SHOULD provide sufficient information for the PCC to know whether it has to relax constraints or query another PCE. Arequest/response protocol is also required for a PCE to communicate path computation requests to another PCE and for thethat 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 communications.communication. [PCE-ARCH] describes four models of PCE: composite, external, multiple PCE path computationcomputation, and multiple PCE path computation with inter-PCE communication. In all cases except the composite PCE model, a communication protocolPCEP is required. The requirements defined in this document thereforeare applicable to all models described in the [PCE-ARCH] except the composite PCE model. 6. PCE Communication Protocol Generic Requirements [This paragraph to be deleted after successful completion and before publication as an RFC.] The designers of a PCE communication protocolPCEP MUST take the requirements set out in this document and discuss them widely within the IETF and particularly within the Applications Area to determine whether a suitable protocol already exists. The results of this investigation MUST be published on the PCE mailing list. 6.1 Basic Protocol Requirements 6.1.1 Client-Server CommunicationThe following is a summary of the requirements in Section 6: Requirement Necessity Ref. ------------------------------------------------------------------ Commonality of PCC-PCE and PCE-PCE communication is by nature client-server based. The communication protocolCommunication MUST allow for a PCC or a PCE to send a path6.1.1 Client-Server Communication MUST 6.1.2 Support PCC/PCE request message to a PCE, and for a PCE to reply with arequest 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 Support path reoptimization & inclusion of a previously computed path MUST 6.1.4 Allow to select/prefer from advertised list of standard objective functions/options MUST 6.1.4 Allow to customize objective function/options MUST 6.1.4 Request a less-constrained path MAY 6.1.4 Support request for less-constrained path, including constraint-relaxation policy's SHOULD 6.1.4 Support Path Computation Responses MUST 6.1.5 Negative response support reasons for failure, constraints to relax to achieve positive result, less-constrained path reflecting constraint-relaxation policy's SHOULD 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 PCEP itself or transport protocol MUST 6.1.8 Allow detection & recovery of lost messages to occur quickly & not impede operation of PCEP MUST 6.1.8 Handle overload situations without significant decrease in performance, e.g., through throttling of requests MUST 6.1.8 Provide acknowledged message delivery with retransmission, in order message delivery or facility to restore order, message corruption detection, flow control & back-pressure to throttle requests, rapid partner failure detection, informed rapidly of failure of PCE-PCC connection MUST 6.1.8 Functionality added to PCEP if transport protocol provides it SHOULD NOT 6.1.8 Secure Message Exchange (provided by PCEP or transport protocol MUST 6.1.9 Support mechanisms to prevent spoofing (e.g., authentication), snooping (e.g., encryption), DOS attacks MUST 6.1.9 Request Prioritization MUST 6.1.10 Unsolicited Notifications SHOULD 6.1.11 Allow Asynchronous Communication MUST 6.1.12 PCC Has to Wait for Response Before Making Another Request MUST NOT 6.1.12 Allow order of responses differ from order of Requests MUST 6.1.12 Communication Overhead Minimization SHOULD 6.1.13 Give particular attention to message size SHOULD 6.1.13 Extensibility without requiring modifications to the protocol MUST 6.1.14 Easily extensible to support intra-area, inter-area, inter-AS intra provider, inter-AS inter-provider, multi-layer path & virtual network topology path computation MUST 6.1.14 Easily extensible to support future applications not in scope (e.g., P2MP path computations) SHOULD 6.1.14 Scalability at least linearly with increase in number of PCCs, PCEs, PCCs communicating with a single PCE, PCEs communicated to by a single PCC, PCEs communicated to by another PCE, domains, path requests, handling bursts of requests MUST 6.1.15 Support Path Computation Constraints MUST 6.1.16 Support 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 6.1 Basic Protocol Requirements 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication A single protocol MUST be defined for PCC-PCE and PCE-PCE communication. A PCE requesting a path from another PCE can be considered as a PCC. 6.1.2 Client-Server Communication PCC-PCE and PCE-PCE communication is by nature client-server based. The PCEP 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 toto 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). There is no requirement to maintain a session or association between communicating PCC and PCE, nor between communicating PCEs. The request/response exchange defines a limited association between requester and responder. 6.1.3 Transport The PCEP may utilize an existing transport protocol or operate directly over IP. If a transport protocol is used, it may be used to satisfy some requirements stated in other sections of this document (for example, reliability and security). If a transport protocol is used, it MUST NOT limit the size of the message used by the PCEP. Where requirements expressed in this document match the function of existing transport protocols, consideration MUST be given to the use of those protocols. 6.1.4 Path Computation Requests The request message MUST include, at least, a source and a destination. The message MUST support the inclusion of a set of one or more path constraints, such as the requested bandwidth or resources (hops, affinities, etc.) to include/exclude (e.g., a PCC requests the PCE to exclude points of failure in the computation of the new path if an LSP setup fails). The actual inclusion of constraints is a choice for the PCC issuing the request. A list of core constraints that MUST be supported by the PCEP is supplied in Section 6.1.16. Specification of constraints must be future-proofed as described in Section 6.1.14. The path computation request message MUST support TE LSP path reoptimization and the requesting PCCinclusion of a previously computed path. This will help ensure optimal routing of a reoptimized path, since it will allow the PCE to avoid double bandwidth accounting and help reduce blocking issues. The requester MUST be allowed to select or PCE, onceprefer from an advertised list or minimal subset of standard objective functions and functional options. The requester SHOULD also be able to select a vendor-specific or experimental objective function or functional option. Furthermore, the path has been computed. In additionrequester MUST be allowed to customize the objective function/options in use. That is, individual objective functions will often have parameters to this request-response model, there maybe cases where there is unsolicited communicationset in the request from PCC to PCE. Specification of objective functions and objective function parameters is required in the protocol extensibility specified in Section 6.1.14. If a PCC selects an objective function that the PCE does not support, the PCE response MUST be negative. Note that a PCC MAY send a request that is based on the set of TE parameters carried by the MPLS/GMPLS LSP setup signaling protocol, and as long as those parameters are satisfied, the PCC MAY not care about which objective function is used. Also, the PCE MAY execute objective functions not advertised to the PCC, for example, policy based routing path computation for load balancing instructed by the management plane. As also discussed in Section 6.1.5 (Path Computation Responses), a PCC MAY request a less-constrained TE LSP path, and the path computation request MAY include one or more constraint-relaxation policy's. The Request message SHOULD support the PCE to PCC (see Requirement 6.1.6).inclusion of a request for a less-constrained path, including one or more constraint-relaxation policy's. 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. 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-explicitnon-simple abstract node. See RFC 3209 for the definition of strict hop, loose hop, and abstract node. It MUST be possible to send multiple path computation requests, correlated or not, within the same path request message. There are various motivations for doing so (optimality, path diversity, etc.). It MUST be possible to limit by configuration the number of requests that can be carried within a single message. The transport protocol MUST allow sending unlimited size messages, but MUST be able to limit message size, to avoid a big message from unduly delaying a small message. Maximum message size MAY be negotiated at session initialization. If the number of correlated requests exceeds the maximum message size, then separate messages MAY be sent with an indication that they are correlated. The path request message MUST include, at least, a source and a destination, and MAY include a set of one or more path constraints, such as 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 path request message MUST support the ability to prefer/customize various path computation objective functions, policies and optimization criteria. For example, a PCC may be aware of and would like to choose from among various objective functions that a PCE may offer, and the PCE communication protocol SHOULD allow this to be specified per path computation request. This capability to prefer certain objective functions depends on the fact thathop, and abstract node. A positive response from the PCE advertises this towill include the paths that have been computed. When a PCCPath satisfying the constraints cannot be found, or thatif the PCC requests one of a set of objective functions defined as a minimal subset that MUSTcomputation fails or cannot be supported by any PCE. The requesterperformed, a negative response MUST be allowed to select from the advertised list or minimal subsetsent. This response MAY include further details of standard objective functionsthe reason(s) for the failure, and functional options. The requester SHOULD alsopotentially advice about which constraints might be ablerelaxed to select a vendor-specific or experimental objective function or functional option. Furthermore, the requester MUSTbe allowedmore likely to customizeachieve a positive result. Optionally the objective function/options in use. That is, individual objective functions will often have parameters toPCE MAY provide a less-constrained path taking into account one or more relaxation policy's that could potentially be set inprovided by the request fromPCC to PCE. Specification of objective functions and objective function parameters is requiredin the protocol extensibility specifiedrequest. As discussed in Section 6.1.9. If a PCC selects an objective function that the PCE does not support, the PCE response MUST be negative. Note that6.1.4, a PCC MAY send aoptionally request that is based on the set ofa less-constrained TE parameters carried by the MPLS/GMPLSLSP setup signaling protocol,path, and as long as those parameters are satisfied,the PCCpath computation request MAY not care about which objective function is used. Also,also include one or more constraint-relaxation policy's. Hence the PCE MAY execute objective functions not advertised toResponse message SHOULD support the inclusion of the reasons for a failure, and the inclusion of less-constrained path. The Request message SHOULD support the PCC, for example, policy based routing path computationinclusion of a request for load balancing instructed by the management plane.a less-constrained path, including one or more constraint-relaxation policy's. 6.1.6 Cancellation of Pending Requests A PCC or PCE MUST be able to cancel a pending request. The path response message6.1.7 Multiple Requests and Responses It MUST allow returning various elements including, at least,be possible to send multiple path computation requests, correlated or not, within the computed path.same request message. There are various motivations for doing so (optimality, path diversity, etc.). It MUST be possible to limit by configuration 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 pathresponse message, corresponding either to the same request (e.g. load balancing) or to distinct requestsrequests, correlated or not, of the same pathrequest message or distinct pathrequest messages. 6.1.2 PCC-PCE and PCE-PCE Communication A single protocolIt MUST be defined for PCC-PCEpossible to provide "continuation correlation" where all related requests or computed paths cannot fit within one message. Maximum acceptable message sizes and PCE-PCE communication. A PCE requestingthe maximum number of requests per message supported by a path from anotherPCE canMAY form part of PCE capabilities advertisement [PCE-DISC-REQ], or MAY be consideredexchanged 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. 6.1.3PCC 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 PCE communication protocolPCEP MUST run on topinclude reliability. This may form part of the protocol itself or may be achieved by the selection of a reliablesuitable transport protocol.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 communication protocol. Here the PCE communication protocol includes a number of application-specific capabilities, all of which run on top of a common, reliable transport protocol layer.PCEP. In some particularcases (e.g. after link failure), a large number of PCCs may simultaneously send a requestrequests to a PCE, leading potentiallyto a potential saturation of request buffers onthe PCEs. The PCE communicationPCEP or the transport protocol it uses MUST properly handle such overload situations without a significant decrease in performance, such as through throttling of such requests. The PCE communication-protocolPCEP or the transport protocol it uses MUST provide: - acknowledgedAcknowledged message delivery with retransmission, as discussed in Section 6.1.1retransmission. - inIn order message delivery. For the set of requests between a given PCC and a PCE, the ordering is already there relying on the reliable transport layer. For requests between a set of PCCs and a given PCE, the ordering of responses SHOULD be based ondelivery or the PCE's own handling policy, as wellfacility (such as message numbering) to restore the priorityorder of the requests.received messages. - messageMessage corruption detectiondetection. - flowFlow control and back-pressure, as specified above with the throttling of requests. These requirements SHOULD be satisfied by an existing reliable transport protocol, and functionality SHOULD only be added where the transport protocol does not provide it (e.g., rapid partner failure detection). With regard to the rapid- Rapid partner failure detection, the PCCdetection. The PCC/PCE MUST be informed of the failure of any failed PCE (or PCE connection) when itPCE/PCC or PCC-PCE connection rapidly after the failure happens. 6.1.4Functionality SHOULD NOT be added to the PCEP where the chosen transport protocol already provides it. 6.1.9 Secure Message Exchange The PCC-PCE and PCE-PCE communication MUST be secure. In particular, it MUST support mechanisms to prevent spoofing (e.g., authentication), snooping (e.g., encryption) and DOS attacks. 6.1.5 Request Prioritization The communication protocol MUST support the notion of request priority, allowing a PCC to specify the degree of urgency of a particular request.This is used to serve some requests before others, and would require global prioritization. That is, a request from one PCC can have a higher priority than a request from another PCC to the same PCE. However, there is no intention or need for a PCE to preempt (i.e., discard) a given request from one PCC if it receives a higher-priority request from another PCC; the PCE just delays the lower-priority request. If, for example, the PCE is processing a low priority request that will take extended computation time (e.g., for full re-optimization of 1000 protected LSPs through a complex algorithm), it is RECOMMENDED that the low priority request to set up a new LSPfunction may be suspended/interrupted untilprovided by the high priority request can be completed.transport protocol or directly by the PCEP. 6.1.10 Request Prioritization The PCE must consider, however, in additionPCEP MUST allow a PCC to specify the priority of the path computations, thea computation request. This priority is used by a PCE policy based on its system resources, configurations, etc. That is, the handling ofto service high priority on therequests before lower priority requests considering all requests received and queued by a single PCE is not entirely in the purviewfrom all PCCs. Implementation of the PCE communication protocol design. Thepriority-based activity within a PCE communication protocol design MUST consider whether request if starvation can occur for particular priorities, whether thatis acceptable,subject to implementation and how thatlocal policy. This application processing is handled. 6.1.6out of scope of the PCEP. 6.1.11 Unsolicited Notifications The PCE communication protocol SHOULD support unsolicited notifications from PCE to PCC or from PCE to PCE. That is, thenormal operational mode is for the PCC to make path computation requests to the PCE. This requirement includes cases of PCEs computing paths without being asked by a PCC,PCE, and for the PCE sending thoseto respond. The PCEP SHOULD support unsolicited pathsnotifications from PCE to PCCs. This could also includePCC, PCE overload notifications. 6.1.7to PCE, or PCC to PCE. This requirement facilitates the unsolicited communication of information, updated paths, and alerts between PCCs and PCEs and between PCEs. 6.1.12 Asynchronous Communication The PCC-PCE protocol MUST allow for asynchronous communication. A clientPCC MUST NOT have to wait for a response tobefore it can make another request. Also itIt MUST also be possible to have the order of someresponses differ from the order of theirthe corresponding requests. This may occur, for instance, when path request messages have distinctdifferent priorities (see Requirement 6.1.5). 22.214.171.124.10). 6.1.13 Communication Overhead Minimization The request and response messages SHOULD be designed so that the communication overhead is minimized. Particular attention SHOULD be given to the message size. Other considerations in overhead minimization include the following: - the number of messages exchanged to arrive at a computation answer - the amount of background messages used by the protocol or its transport protocol to keep thealive any session upor association between the PCE and PCC - the processing cost at the PCE (or PCC) associated with requests/responses. 6.1.9request/response messages (as distinct from processing the computation requests themselves). 6.1.14 Extensibility The PCE communication protocolPCEP MUST provide a way for introduction of new path computation constraints, diversity types, objective functions, optimization methods and parameters, etc., without requiring modifications in the protocol. In particular, the PCE communication protocol SHOULD allow supporting future applications not currently in the scope of the PCE working group, such as, for instance, P2MPthe introduction of new path computations.computation constraints, diversity types, objective functions, optimization methods and parameters, etc., without requiring modifications in the protocol. The communication protocolPCEP MUST allow supportingbe easily extensible to support various PCE based applications that have been currently identified and MAY be identified in the future, such as:including: - intra-area path computation - inter-area path computation - inter-AS intra provider and inter-AS inter-provider path computation -The PCEP 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 computationcomputation/reconfiguration. The PCEP 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, etc. Note that application specific requirements are out of the scope of this document and will be addressed in separate requirements documents. 126.96.36.199.15 Scalability The PCE communication protocolPCEP MUST scale wellwell, at least as good as linearly, with an increase of any of the following parameters: - number of PCCs - number of PCEs - number of PCCs communicating with a single PCE - number of PCEs communicated to by a single PCC - number of PCEs communicated to by another PCE. - TED size (number of links/nodes, which may drive up path computation time)PCE - number of domains - number of path requests - handling bursts of requestsrequests. Bursts of requests may arise, for example, after a network outage when multiple recomputations are requested as a result.requested. It is RECOMMENDED that the protocol handle the congestion in a graceful way so that it does not unduly impact the rest of the network, and so that it does not gate the ability of the PCE to perform computation. 6.1.16 Constraints This section provides a list of generic constraints that MUST be supported by the PCEP. Other constraints may be added to service specific applications as identified by separate application-specific requirements documents. Note that the absence of a constraint in this list does not mean that that constraint must not be supported. Note also that the provisions of Section 6.1.14 mean that new constraints can be added to this list without impacting the protocol. Here is the list of generic constraints that MUST be supported: o MPLS-TE and GMPLS generic constraints: - Bandwidth - Affinities inclusion/exclusion - Link, Node, SRLG inclusion/exclusion - Maximum end-to-end delay metrics - Hop Count o MPLS-TE specific constraints - Class-Type o GMPLS specific constraints - Switching Type, Encoding Type - Protection type o TBD 6.2 Deployment Support Requirements 6.2.1 Support for VariousDifferent Service Provider Environments and ApplicationsThe communication protocolPCEP MUST operate in various different service provider network environments, where the IPenvironments that utilize an IP-based control plane is deployed,plane, such as - MPLS-TE and GMPLS 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 Confidentiality The communication protocol MUST allow minimizing the amount of topological information exchanged between a PCC and PCE, and between PCEs. This issingle and multiple PCE path computation Definitions of particular importance in inter-PCE communication, where the PCEs are located in distinct service-provider domains. For example, the protocol design SHOULD enable policies tocentralized, distributed, single, and multiple PCE path computation can be implemented such that domain-specific topology information is excluded on inter-PCE, inter-domain communication. 6.2.3found in [PCE-ARCH]. 6.2.2 Policy Support The communication protocolPCEP 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 communication protocolPCEP requirements. Furthermore, the communication protocolPCEP MUST allow for the notification of a policy violation. Actual policies, configuration of policies, and applicability of policies are out of scope. 6.3 Detection & Recovery Requirements 6.3.1 Aliveness Detection The PCE communication protocolPCEP MUST allow a PCC to check the liveliness of PCEs it is using for path computationcomputation, and a PCE to check the liveliness of PCCs it is serving. The PCE communication protocolPCEP MUST provide partner failure detection. Depending on the design,solution, this requirement MAY be met by the PCE communication protocolPCEP design or the transport protocol design. 6.3.2 PCC/PCE Failure Response Appropriate PCC and PCE procedures MUST be defined to deal with PCE and PCC failures. A PCC MUSTmust be able to clear any pending request to a PCE. That is, the PCC MAY cancel a previously-made path computation request toPCE so that it is no longer waiting for a PCE. Similarly,response. Clearing a PCE MUST be able to clearpending requestsrequest does not imply any message exchange; this differs from a PCC, for instance, when it detects the failure of the requesting PCC or when its buffer of requests is full.pending request cancellation (Section 6.1.6), which requires message exchange. It is RECOMMENDED that a PCC select another PCE upon detection of PCE failure or unreachability of a PCE but note that PCE selection procedure are out of the scope of this document. Similarly, a PCE must be able to clear pending requests from a PCC, for instance, when it detects the failure of the requesting PCC or when its buffer of requests is full. Clearing a pending request does not imply any message exchange. It is assumed that the underlying reliable communicationaliveness detection mechanism (see Section 6.3.1) ensures reciprocal knowledge of PCE and PCC liveness. Therefore it NOT possible for the PCC/PCE to believe that the PCE/PCC is unreachable, but not vice versa.6.3.3 Protocol Recovery Information distributed in asynchronous/unsolicited messages SHOULD be allowed toMAY persist at the recipient in the event of the failure of the sender or of the communicationscommunication channel. Upon recovery, the communications protocolCommunication Protocol MUST support resynchronization of information and requests between the sender and the receiver, and this SHOULD be arranged so as to minimize repeat data transfer. For example, the communication protocolPCEP SHOULD allow a PCE to respond to computation requests issued before the failure without the requests being re-issued. Similarly, a stateful PCE SHOULD be able to resynchronize and recover states (e.g., LSP status, paths, etc.) after a restart. Recovery would require the PCE communication protocol to support recovery of state information in the PCE. This would be of particular importance when local PCE recovery is not supported or fails.7. Security Considerations The impact of the use of a PCE-based architecturePCEP MUST be considered in the light of the impact that it has on the security of the existing routing and signaling protocols and techniques in use within the network. There is unlikely to be any impact on intra-domain security, but an increase in inter-domain information flows and the facilitation of inter-domain path establishment may increase the vulnerability to security attacks. Of particular relevance are the implications for confidentiality inherent in a PCE-based architecturePCEP 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 a non-localan external PCE (that is, not co-resident with the PCC)does introduce additional security issues. Most notable amongst these are: - interception of PCE requests or responses - impersonation of PCE - falsification of TE information - denial of service attacks on PCE or PCE communication mechanisms It is expected that PCE solutionsthe PCEP will address these issues in detail using authentication and security techniques. See also Section 6.1.9. 8. Manageability Considerations Manageability of the PCE communication protocolPCEP 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 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) Adrian Farrel, Thomas Morin, and JP Vasseur for their review and suggestions. 11. Normative References [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation Element (PCE) Architecture", work in progress. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 12. Informational References [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path Computation Element (PCE) Discovery," work in progress. [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. 13. Authors' Addresses Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 Email: email@example.com Alia K. Atlas Avici Systems, Inc. 101 Billerica Avenue N. Billerica, MA 01862, USA Phone: +1 978 964 2070 Email: firstname.lastname@example.org Arthi Ayyangar Juniper Networks, Inc. 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA Email: email@example.com Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 Email: firstname.lastname@example.org Igor Bryskin Independent Consultant Email: email@example.com Dean Cheng Cisco Systems Inc. 3700 Cisco Way San Jose CA 95134 USA Phone: +1 408 527 0677 Email: firstname.lastname@example.org Durga Gangisetti MCI Email: email@example.com Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 Email: firstname.lastname@example.org Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, FRANCE Email: email@example.com Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585, JAPAN Email: firstname.lastname@example.org Raymond Zhang BT INFONET Services Corporation 2160 E. Grand Ave. El Segundo, CA 90245 USA Email: Raymond_zhang@bt.infonet.com 14.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 email@example.com. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). 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.