IETF Internet Draft PCE Working Group Jerry Ash (AT&T) Proposed Status: Informational Editor Expires: October 2005 J.L. Le Roux (France Telecom) Editor April 2005 draft-ash-pce-comm-protocol-gen-reqs-00.txt PCE Communication Protocol Generic Requirements Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Abstract Constraint-based path computation is a fundamental building block for traffic engineering systems such as MPLS and 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. This document specifies generic requirements for a PCE communication protocol. Subsequent documents will specify application-specific requirements for the PCE communication protocol. PCE Design Team [Page 1] Internet Draft PCE Communication Protocol Generic Reqmnts April 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 . . . . . . . . . . . . . 4 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 5 6.1.1 Client-Server Communication . . . . . . . . . . . . . . 6 6.1.2 PCC-PCE and PCE-PCE Communication . . . . . . . . . . . 6 6.1.3 Reliable Message Exchange . . . . . . . . . . . . . . . 6 6.1.4 Secure Message Exchange . . . . . . . . . . . . . . . . 6 6.1.5 Request Prioritization . . . . . . . . . . . . . . . . 6 6.1.6 Unsolicited Notifications . . . . . . . . . . . . . . . 6 6.1.7 Asynchronous Communication . . . . . . . . . . . . . . 6 6.1.8 Communication Overhead Minimization . . . . . . . . . . 7 6.1.9 Extensibility . . . . . . . . . . . . . . . . . . . . . 7 6.1.10 Scalability . . . . . . . . . . . . . . . . . . . . . 7 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 7 6.2.1 Support for Various Service Provider Environments and Applications . . . . . . . . . . . . . . . . . . . . . 7 6.2.2 Confidentiality . . . . . . . . . . . . . . . . . . . . 8 6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 8 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 8 6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 8 6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Intellectual Property Considerations . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 10 12. Informational References . . . . . . . . . . . . . . . . . . . . 10 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 12 PCE Design Team [Page 2] Internet Draft PCE Communication Protocol Generic Reqmnts April 2005 1. Contributors This document is the result of the PCE Working Group PCE communication protocol 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 [PCE-ARCH] defines an architecture where Path Computation Elements (PCE) service path computation requests sent by Path Computation Clients (PCCs). This requires a communication protocol in order for PCCs to send path computation requests to PCEs and for PCEs to reply with the computed paths. This document lists a set of generic requirements for the PCE communication protocol. It is intended that protocol solutions will satisfy these requirements. Application-specific requirements are beyond the scope of this document, and will be addressed in separate documents. 4. Terminology CSPF: Constraint-based Shortest Path First. 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. LER: Label Edge Router. LSDB: Link State Database. LSP: Label Switched Path. PCE Design Team [Page 3] Internet Draft PCE Communication Protocol Generic Reqmnts April 2005 LSR: Label Switching Router. PCC: Path Computation Client : any client application requesting a path computation to be performed by the Path Computation Element. 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 A PCE might co-locate with a PCC or reside elsewhere. In the latter case, a PCC would discover and select a PCE using a PCE discovery mechanism, which is out of the scope of this document. Requirements for PCE discovery are documented in [PCE-DISC-REQ]. Population of the TED used by the PCE is also out of scope of the PCE communication protocol. Once a PCC has selected a PCE, and provided that the PCE is not local to the PCC, a request/response protocol is required for the PCC to communicate the path computation requests to the PCE and for the PCE to return the path computation response. The path computation request may include a set of constraints, such as source, destination, bandwidth required, etc. In case of a positive response from the PCE, one or more paths would be returned to the requesting node. In the event of a failure to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure, and potentially advice about which constraints might be relaxed to be more likely to achieve a positive result. 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-explicit abstract node. See RFC 3209 for the definition of strict hop, loose hop, and abstract node. A request/response protocol is also required for a PCE to communicate path computation requests to another PCE and for the PCE to return the path computation response. [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 PCE Design Team [Page 4] Internet Draft PCE Communication Protocol Generic Reqmnts April 2005 communication protocol is required. The requirements defined in this document therefore are applicable to all models described in the [PCE-ARCH] except the composite PCE model. 6. PCE Communication Protocol Generic Requirements 6.1 Basic Protocol Requirements 6.1.1 Client-Server Communication PCC-PCE and PCE-PCE communication is by nature client-server based. The communication protocol MUST allow for a PCC or a PCE to send a path request message to a PCE, and for a PCE to reply with a path response message to the requesting PCC or PCE, once the path has been computed. In addition to this request-response model, there may be cases where there is unsolicited communication from the PCE to PCC (see Requirement 6.1.6). The protocol MUST be capable of returning any explicit path that would be acceptable for use in RSVP-TE for MPLS and GMPLS LSPs when suitably encoded in an Explicit Route Object. 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.). The path request message MUST include a set of path constraints, including, at least, a source, a destination, and one or more 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 algorithms, policies and optimization criteria. For example, a PCC may be aware of and would like to choose from among various algorithms 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 algorithms depends on the fact that the PCE advertises this to a PCC. A PCC or PCE MUST be able to cancel a pending request. The path response message MUST allow returning various elements including, at least, the computed path. It MUST be possible to return multiple paths within the same path response message, corresponding either to the same request (e.g. load balancing) or to distinct requests of the same path request message or distinct path request messages. It MUST be possible to return multiple paths within the same path response message, or to respond either to the same request or distinct requests of a given path request message. PCE Design Team [Page 5] Internet Draft PCE Communication Protocol Generic Reqmnts April 2005 6.1.2 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.3 Reliable Message Exchange The PCE communication protocol MUST run on top of a reliable transport protocol. 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. In some particular cases (e.g. link failure), a large number of PCCs may simultaneously send a request to a PCE, leading potentially to a saturation of request buffers on PCEs. The PCE communication protocol MUST properly handle such overload situations without a significant decrease in performance, such as through throttling of such requests. 6.1.4 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. 6.1.6 Unsolicited Notifications The PCE communication protocol SHOULD support unsolicited notifications from PCE to PCC or from PCE to PCE. 6.1.7 Asynchronous Communication The PCC-PCE protocol MUST allow for asynchronous communication. A client MUST NOT have to wait for a response to make another request. Also it MUST be possible to have the order of some responses differ from the order of their corresponding requests. This may occur, for instance, when path request messages have distinct priorities (see Requirement 6.1.5). PCE Design Team [Page 6] Internet Draft PCE Communication Protocol Generic Reqmnts April 2005 6.1.8 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. 6.1.9 Extensibility The PCE communication protocol SHOULD provide a way for introduction of new path computation constraints, diversity types, objective functions, 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, P2MP path computations. 6.1.10 Scalability The PCE communication protocol MUST scale well with an increase of any of the following parameters: - number of PCCs - number of PCEs - TED size (number of links/nodes) - number of domains - number of path requests 6.2 Deployment Support Requirements 6.2.1 Support for Various Service Provider Environments and Applications The communication protocol MUST operate in various service provider network environments, 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]. The communication protocol MUST allow supporting various PCE based applications that have been currently identified, such as: - intra-area path computation - inter-area path computation - inter-AS intra provider and inter-AS inter-provider path computation - multi-layer and virtual network topology computation Note that application specific requirements are out of the scope of this document and will be addressed in separate requirements documents. PCE Design Team [Page 7] Internet Draft PCE Communication Protocol Generic Reqmnts April 2005 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 is of particular importance in inter-PCE communication, where the PCEs are located in distinct service-provider domains. 6.2.3 Policy Support The communication protocol 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. A PCC may be aware of and would like to choose from among various policies 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 policies depends on the fact that the PCE advertises this to a PCC. Similarly, the PCE communication protocol MUST be able to convey parameters, constraints, etc. that would control policies in the PCE or PCC. However, specific policy parameter details are left to application-specific communication protocol requirements. Furthermore, the communication protocol 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 protocol 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. 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. Similarly, a PCE MUST be able to clear pending requests from a PCC when it detects the failure of the requesting PCC. 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. 6.3.3 Protocol Recovery The communication protocol SHOULD allow a stateful PCE to resynchronize and recover states (e.g., LSP status, paths, etc.) after a restart. Recovery would entail some PCC-PCE cooperation to recover state information in the PCE, and hence communication protocol needs to PCE Design Team [Page 8] Internet Draft PCE Communication Protocol Generic Reqmnts April 2005 support that. 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 architecture 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 architecture 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-local 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 solutions will address these issues in detail using authentication and security techniques. 8. IANA Considerations This document makes no requests for IANA action. 9. 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. 10. Intellectual Property Considerations 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 PCE Design Team [Page 9] Internet Draft PCE Communication Protocol Generic Reqmnts April 2005 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. 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: gash@att.com PCE Design Team [Page 10] Internet Draft PCE Communication Protocol Generic Reqmnts April 2005 Alia K. Atlas Avici Systems, Inc. 101 Billerica Avenue N. Billerica, MA 01862, USA Phone: +1 978 964 2070 Email: aatlas@avici.com Arthi Ayyangar Juniper Networks, Inc. 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA Email: arthi@juniper.net Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 Email: nabil.bitar@verizon.com Igor Bryskin Independent Consultant Email: i_bryskin@yahoo.com Dean Cheng Cisco Systems Inc. 3700 Cisco Way San Jose CA 95134 USA Phone: +1 408 527 0677 Email: dcheng@cisco.com Durga Gangisetti MCI Email: durga.gangisetti@mci.com Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 Email: ke-kumaki@kddi.com Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, FRANCE Email: jeanlouis.leroux@francetelecom.com Eiji Oki NTT Midori-cho 3-9-11 PCE Design Team [Page 11] Internet Draft PCE Communication Protocol Generic Reqmnts April 2005 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 14. Full 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. 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 12]