PCE Working Group JL Le Roux France Telecom Internet Draft Paul Mabey Qwest Raymond Zhang Infonet Eiji Oki NTT Ting Wo Chung Bell Canada Category: Informational Expires: August 2005 February 2005 Requirements for Path Computation Element (PCE) Discovery draft-leroux-pce-discovery-reqs-00.txt Status of this Memo 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. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Le Roux et al. [Page 1] Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005 Abstract This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with their capabilities. It is intended that solutions that specify procedures and protocol extensions for such PCE discovery satisfy these requirements. 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. Table of Contents 1. Terminology.................................................3 2. Introduction................................................3 3. Problem Statement and Requirements overview.................4 3.1. Problem Statement...........................................4 3.2. Requirements overview.......................................5 4. Examples of application scenarios...........................5 5. Detailed Requirements.......................................5 5.1. Discovery of PCE location...................................5 5.2. Discovery of PCE capabilities...............................6 5.3. Discovery of Backup PCEs....................................7 5.4. Scope of PCE Discovery......................................7 5.5. PCE Information Synchronization.............................7 5.6. Detecting PCE Liveliness....................................8 5.7. PCE Selection...............................................8 5.8. Scalability.................................................8 6. Security Considerations.....................................8 7. Intellectual Property Statement.............................9 7.1. IPR Disclosure Acknowledgement..............................9 8. Acknowledgments.............................................9 9. References..................................................9 10. Authors' Addresses:.........................................9 Le Roux et al. [Page 2] Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005 1. Terminology Terminology used in this document LSR: Label Switch Router. PCC: Path Computation Client: any client application requesting a path computation to be performed by a 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 or topology, and applying computational constraints. IGP Area: OSPF Area or ISIS level Intra-area TE LSP: TE LSP whose path does not cross area boundaries. Inter-area TE LSP: A TE LSP whose path transits at least through two different IGP areas. Inter-AS MPLS TE LSP: A TE LSP whose path transits at least through two different ASes or sub-ASes (BGP confederations). Domain: IGP Area or Autonomous System 2. Introduction The PCE Architecture [PCE-ARCH] defines a Path Computation Element (PCE) as an entity capable of computing TE-LSPs paths satisfying a set of constraints. The PCE function can be located on a router, a LSR or a dedicated network server. A PCE serves TE-LSP path computation requests sent by Path Computation Clients (PCC). A Path Computation Client (PCC) can be an LSR or a PCE. Note that in this document the notion of PCC encompasses PCEs acting as PCCs when requesting a TE-LSP path computation of another PCE. The PCE architecture has various applications, such as CPU intensive path computation, inter-domain path computation or backup path computation. The PCE architecture requires, of course, that PCCs be aware of the location of one or more PCEs in its domain, and also potentially of some relevant PCEs in other domains (in the context of inter-domain path computation), along with their capabilities. Le Roux et al. [Page 3] Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005 In that context it would be highly desirable to define a mechanism for automatic and dynamic PCE discovery, which would allow PCCs, to automatically discover a set of PCEs along with their capabilities, and to dynamically detect new PCEs or any modification of the PCE capabilities. This includes the discovery by a PCE of a set of PCEs in its domain and in other domains, which is highly required for inter-domain path computation implying inter-PCE communication. This document lists a set of functional requirements for such an automatic and dynamic PCE discovery mechanism. The problem statement is pointed out in section 3. Section 4 illustrates several applications scenarios. Finally detailed requirements are addressed in section 5. It is intended that solutions that specify procedures and protocol extensions for such PCE discovery satisfy these requirements. There is no intent neither to specify solution specific requirements nor to make any assumption on the protocol(s) that could be used for the discovery. Note that requirements listed in this document apply equally to MPLS- TE and GMPLS capable PCEs. Note that current version of this document does not make any distinction between PCC-PCE discovery and PCE-PCE discovery. This may be addressed in future revisions. 3. Problem Statement and Requirements overview 3.1. Problem Statement A routing domain may in practice comprise of multiple PCEs: -Path computation load may be balanced among a set of PCEs, for scalability purposes; -There can be several PCEs with distinct path computation capabilities (P2P, P2MP, backup੠and distinct computation scopes (intra-area, inter-area, inter-AS, inter-layer); -For redundancy purpose primary and backup PCEs may be used. In order to allow for efficient PCE selection by PCCs and efficient load balancing of requests, a PCC must have knowledge of the location of PCEs in its domain, along with their capabilities, and also potentially of some relevant PCEs in other domains (for inter-domain path computation purpose). Such PCE information could be learnt manually by configuring, on each PCC, a set of PCEs along with their capabilities and scopes. Such manual configuration approach may be sufficient, and even desired in some particular situations, but it obviously faces several limitations: Le Roux et al. [Page 4] Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005 -This may imply a huge configuration overhead; -This would not allow detecting that a new PCE is alive or that an existing PCE disappears, or when there is a change in PCE capabilities. Furthermore, as with any manual configuration approach, this may lead to undesirable configuration errors. Hence, an automatic PCE discovery mechanism allowing a PCC to automatically discover a set of PCEs and their capabilities is highly required. 3.2. Requirements overview A PCE discovery mechanism compliant with this document MUST allow a PCC to automatically discover a set of PCEs in its domain and also, potentially, PCEs of other domains that are relevant for inter-domain path computation purpose. The discovery procedure MUST also allow learning information about a set of PCE capabilities. A PCE discovery mechanism compliant with this draft MUST allow PCCs to dynamically discover that a new PCE has been activated or that a PCE capability has changed. A PCE Discovery mechanism SHOULD also allow PCCs to dynamically discover that a PCE is no longer alive. Note that such PCE liveliness information can also be obtained thanks to a PCC-PCE communication protocol. 4. Examples of application scenarios This section will be completed in next revisions of this document. 5. Detailed Requirements 5.1. Discovery of PCE location The PCE Discovery mechanism MUST allow advertising, for a given PCE, the IP address to be used to reach the PCE. This address will typically be a loop-back address that is always reachable, (provided that the PCE node is not isolated). Le Roux et al. [Page 5] Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005 5.2. Discovery of PCE capabilities In case there are several PCEs available, a PCC has to select an appropriate PCE. For that purpose the PCE Discovery mechanism MUST allow advertising, some PCE path computation capabilities, such as: -The type of path than can be computed: P2P, P2MP, Primary, Backupࠠ -The capability to handle multiple path constraints. -The capability to handle computation of multiple paths in a single pass, i.e. when a PCE can compute more than one path obeying a set of specified constraints, in a synchronized manner. -The capability to support computation of diverse paths. -The capability to support path computation request prioritization. The notion of request priority allows a PCC to specify the degree of urgency of a particular request. -The capability to act as stateful PCE. -GMPLS specific path computation capabilities such as -The switching capabilities supported (PSC, L2SC, TDM, LSC, FSC); -The list of link and path constraints supported (delay, polarization, optical power੻ -The capability to support inter-layer path computation; -The capability to support lower-layer path setup control; -The capability to support path computation in a domain made of MPLS and GMPLS capable nodes. -Intra/Inter domain capabilities -The supported path computation scopes: intra-area, inter- area or Inter-AS. That is the capability to compute or take part into the computation of intra area, inter area or inter-AS TE LSPs. -The identifiers of the domain(s) (area IDs, AS numbers੠where the PCE can compute paths. -The PCE capacity in terms of computation power. This could be used to ensure weighted load balancing of requests in case PCEs do not have the same capacity. Such information regarding PCE capabilities could then be used by a PCC to select an appropriate PCE among a list of candidate PCEs, and to ensure efficient load balancing of path computation reqests among PCEs. Le Roux et al. [Page 6] Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005 5.3. Discovery of Backup PCEs In case of PCE failure, a PCC has to select another PCE. It could be useful in various situations, to indicate a set of one or more backup PCEs, to be selected in case a given PCE fails. Hence the PCE Discovery mechanism SHOULD allow advertising, for a given PCE, the location of one or more backup PCEs. 5.4. Scope of PCE Discovery The PCE Discovery mechanism MUST allow controlling the scope of PCE information discovery (IGP Area, AS, set of AS) on a per PCE basis. In other words it MUST allow controlling to which PCC or group of PCCs the information related to a PCE will be advertised. The choice for the discovery scope of a given PCE MUST include the followings: -All PCCs in a single IGP area -All PCCs in a set of adjacent IGP areas -All PCCs in a single AS -All PCCs in a group of ASs -A set of one or more PCCs in a set of one or more ASs Particularly this also implies that the PCE Discovery mechanism MUST allow for the discovery of PCE information across IGP areas and across AS boundaries. Note that it MUST be possible to deactivate PCE discovery on a per PCE basis. 5.5. PCE Information Synchronization The PCE discovery mechanism MUST allow a PCC to detect any change in the information related to a PCE (e.g. capability modifications). Also it MUST be possible to dynamically detect new PCEs. The delay for such detection MUST be beyond 60s. Note that PCE capabilities are expected to be quite stable and not to change frequently. Le Roux et al. [Page 7] Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005 5.6. Detecting PCE Liveliness The PCE discovery mechanism SHOULD allow a PCC detecting when a PCE is no longer alive. This allows a PCC to rapidily switch to another PCE (for instance a pre defined backup PCE), and thus minimizes path computation service disruption. Note that such PCE liveliness information could also be obtained thanks to a PCC-PCE communication protocol. In case PCE discovery is used for PCE liveliness detection, the delay for PCE failure detection SHOULD be of the order of several seconds, and MUST not go beyond 60 seconds. 5.7. PCE Selection A PCC may have to select among a set of candidate PCEs having the same capabilities. A specific PCE selection algorithm SHOULD be defined in order to ensure consistency in load balancing behavior and avoid all PCC sending all the requests to only one PCE. The precise requirements and mechanisms for this function are out of the scope of this document. It is expected that this requirement will be covered in another document. 5.8. Scalability The PCE discovery mechanism MUST be designed to scale well with an increase of any of the following parameters: -Number of PCCs; -Number of PCEs; -Number of IGP Areas in the discovery scope; -Number of ASs in the discovery scope. Particularly, in case routing protocols (IGP, BGP) are extended to support PCE discovery, the extensions MUST not cause a degradation of routing protocol performances. 6. Security Considerations PCE discovery and particularly inter-AS PCE discovery may raise new security issues that will be addressed in future revisions of this document. Le Roux et al. [Page 8] Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005 7. 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.. 7.1. IPR Disclosure Acknowledgement 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. 8. Acknowledgments We would like to thank Benoit Fondeviole, Thomas Morin, Emile Stephan and Jean-Philippe Vasseur, for their useful comments and suggestions. 9. References [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation Element (PCE) Architecture", draft-ash-pce-architecture-00.txt, work in progress. 10. Authors' Addresses: Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@francetelecom.com Le Roux et al. [Page 9] Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005 Paul Mabey Qwest Communications 950 17th Street, Denver, CO 80202, USA Email: pmabey@qwest.com Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA Email: raymond_zhang@infonet.com Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585, Japan Email: oki.eiji@lab.ntt.co.jp Ting Wo Chung Bell Canada 181 Bay Street, Suite 350 Toronto, Ontario, Canada, M5J 2T3 Email: ting_wo.chung@bell.ca 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. Le Roux et al. [Page 10]