IETF Internet Draft PCE Working Group Jerry Ash (AT&T) Proposed Status: Informational Editor Expires: August 2005 February 2005 draft-ash-pce-comm-protocol-reqs-00.txt Path Computation Element (PCE) Communiation Protocol Requirements 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. 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. This document specifies the communication protocol requirements for a Path Computation Element (PCE)-based model. PCE Design Team [Page 1] Internet Draft PCE Communication Protocol Requirements February 2005 Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. PCE Communication Protocol Application Examples . . . . . . . . . 4 5.1. External PCE . . . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Multiple PCE Path Computation . . . . . . . . . . . . . . . 5 5.3. Multiple PCE Path Computation with Inter-PCE Communication . 5 6. PCE Communication Protocol Requirements . . . . . . . . . . . . . 6 7. Protocol Design Considerations. . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Intellectual Property Considerations . . . . . . . . . . . . . . 9 12. Normative References . . . . . . . . . . . . . . . . . . . . . . 10 13. Informational References . . . . . . . . . . . . . . . . . . . . 10 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 12 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) Igor Bryskin Dean Cheng (Cisco) Durga Gangisetti (MCI) Kenji Kumaki (KDDI) Jean-Louis Le Roux (France Telecom) Eiji Oki (NTT) Raymond Zhang (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. Terminology CSPF: Constraint-based Shortest Path First. LER: Label Edge Router. LSDB: Link State Database. LSP: Label Switched Path. LSR: Label Switching Router. PCE Design Team [Page 2] Internet Draft PCE Communication Protocol Requirements February 2005 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 Section 4 and [PCE-ARCH]). TED: Traffic Engineering Database, which contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means. TE LSP: Traffic Engineering MPLS Label Switched Path. 4. Definitions Path Computation Element (PCE): an entity that is capable of computing a network path or route based on a network graph, and incorporating computational constraints. The PCE entity is an application that can be located within a network node or component, on an out-of-network server, etc. For example, a PCE would be able to compute the path of a TE LSP by operating on the TED and considering the bandwidth and other constraints applicable to the TE LSP service request (see further description in [PCE-ARCH]). 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. However, domains of computational responsibility may also exist as sub-domains of areas or ASs. Inter-domain path computation: may involve the correlation of topology and routing information between domains. Inter-layer path computation: refers to the use of PCE where multiple layers are involved and when the objective is to perform path computation at one or multiple layers while taking into account topology and resource information at these layers. Single PCE path computation: a single PCE is used to compute a given path in a domain. Multiple PCE path computation: multiple PCEs are used to compute a given path in a domain. Centralized computation model: refers to a model whereby all paths in a domain are computed by a single, centralized PCE. Distributed computation model: refers to the computation of paths in a domain being shared among multiple PCEs. Explicit PCE path: the full explicit path from start to destination, made of a list of strict hops PCE Design Team [Page 3] Internet Draft PCE Communication Protocol Requirements February 2005 Strict/Loose PCE path: a mix of strict and loose hops comprising of at least one loose hop representing the destination), where a hop may be an abstract node such as an AS. Note, paths that span multiple domains may be computed using the distributed model with a PCE responsible for each domain, or the centralized model by defining a domain that encompasses all of the other domains. From these definitions, a centralized computation model inherently uses single PCE path computation. However, a distributed computation model could use either single PCE path computation or multiple PCE path computations. There would be no such thing as a centralized model that uses multiple PCE path computations. 5. PCE Communication Protocol Application Examples Once the 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 requirements, such as source, destination, bandwidth required, etc., as listed in Section 6. 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. 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. The path computation request may include a significant set of requirements including those defined above. In case of a positive response from the PCE, one or more paths would be returned to the requesting PCE. 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. The following sections illustrate the applications of the PCE communication protocol. 5.1. External PCE Figure 1 shows PCE support that is external from the requesting network element. A service request is received by the head-end node and before it can signal to establish the service it uses the PCE communication protocol to make a request to the external PCE for a path to be computed. The PCE makes the computation using the TED and returns a PCE Design Team [Page 4] Internet Draft PCE Communication Protocol Requirements February 2005 response. ---------- | ----- | | | TED |<-+------------> | ----- | TED synchronization | | | mechanism (for example, routing protocol) | | | | v | | ----- | | | PCE | | | ----- | ---------- ^ | Request/ | Response v Service ---------- Signaling ---------- Request| Head-End | Protocol | Adjacent | ---->| Node |<---------->| Node | ---------- ---------- Figure 1. External PCE Node 5.2. Multiple PCE Path Computation Figure 2 illustrates how multiple PCE path computations may be performed along the path of a signaled service. As in the previous example, the head-end PCC uses the PCE communication protocol to make a request to an external PCE, but the path that is returned is such that the next network element finds it necessary to perform further computation. It consults another PCE using the PCE communication protocol (request/response) to establish the next hop in the path. ---------- ---------- | | | | | PCE | | PCE | | | | | | ----- | | ----- | | | TED | | | | TED | | | ----- | | ----- | ---------- ---------- ^ ^ | Request/ | Request/ | Response | Response v v Service ---------- Signaling ------------- Signaling ------------ Request| Head-End | Protocol |Intermediate | Protocol |Intermediate| ---->| Node |<---------->| Node |<--------->| Node | ---------- ------------- ------------ Figure 2. Multiple PCE Path Computation 5.3. Multiple PCE Path Computation with Inter-PCE Communication The PCE in Section 5.2 was not able to supply a full path for the PCE Design Team [Page 5] Internet Draft PCE Communication Protocol Requirements February 2005 requested service and this resulted in the adjacent node needing to make its own computation request. As illustrated in Figure 3, the same problem is solved by introducing inter-PCE communication and cooperation between PCEs so that the PCE consulted by the head-end network node makes a request of another PCE to help with the computation. ---------- ---------- | | Inter-PCE Request/Response | | | PCE |<--------------------------------->| PCE | | | | | | ----- | | ----- | | | TED | | | | TED | | | ----- | | ----- | ---------- ---------- ^ | Request/ | Response v Service ---------- Signaling ---------- Signaling ---------- Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | ---->| Node |<---------->| Node |<---------->| Node | ---------- ---------- ---------- Figure 3. Multiple PCE Path Computation with Inter-PCE Communication Multiple PCE path computation with inter-PCE communication involves coordination between distributed PCEs such that the result of the computation performed by one PCE depends on information supplied by other PCEs. Note that a PCC cannot see the difference between centralized computation, and multiple PCE path computation with inter-PCE communication. That is, the PCC network node or component that requests the computation makes a single request and receives a full or partial path in response, but the response is actually achieved through the coordinated, cooperative efforts of more than one PCE. 6. PCE Communication Protocol Requirements PCE communication protocol protocol MUST support: R1. communication between PCC-PCE & PCE-PCE in (G)MPLS networks R1.1 one protocol for both cases R2. reliable message exchange R2.1 reliable transport R2.2 request-response message exchange R3. security of PCC-PCE & PCE-PCE messages R3.1 encryption for some data fields, prevent snooping R3.2 authentication, prevent spoofing R3.2 DoS protection R4. confidentiality of PCE communication messages, possibly across multiple domains R4.1 little coordination of SP internal topology R4.2 use loose routes R4.3 replace ERO segment with cookie - entry point to domain consults local PCE using cookie to retrieve next ERO segment PCE Design Team [Page 6] Internet Draft PCE Communication Protocol Requirements February 2005 R5. protocol recovery procedures R5.1 graceful restart for stateful PCE R6. scale well with the following R6.1 number of PCCs R6.2 number of PCEs R6.3 TED size (number of links/nodes) R6.4 number of domains R7. minimize communication overhead R8. PCE communication protocol SHOULD support collection of TE information R8.1 LSP traffic volume, LSP route R9. operation in various SP/networking environments R9.1 IP-MPLS, GMPLS, & optical networks R9.2 P2P path computation R9.3 intra/inter-domain & inter-layer path computation R9.4 inter-layer reconfiguration & path setup/release - path computation triggered by higher-layer PCC, PCE, or lower-layer PCC o PCE optionally triggers inter-layer path computation based on traffic/topology change or failure - lower-layer path established/released if necessary o use (optional) support setup/release request/reply messages R9.5 centralized & distributed computation model R9.6 single & multiple PCE path computation R9.7 external PCE node R9.8 stateful & stateless PCEs R9.9 synchronized & non-synchronized PCE R10. PCC-PCE & PCE-PCE path request message MUST support carrying various constraints including (but not limited to): R10.1 path source/destination R10.2 bandwidth & QoS parameters (e.g., hop count, delay, preemption priority, etc.) R10.3 diversity, SRLGs, optical impairments, wavelengh continuity R10.4 maximum number of paths acceptable R10.5 number of disjoint paths required - if near-disjoint paths acceptable R10.6 loose path to be expanded R10.7 minimum bandwidth of returned path R10.8 path previously returned (useful for stateless PCEs) R10.9 link/node protection capability - multiple correlated paths for protection R10.10 loose path to be expanded R10.11 resources (links/nodes), resource affinities & SRLGs to use/avoid - exclusions o unsorted list of links/nodes/SRLGs that must not appear in the resulting path(s) - inclusions o sorted list of links/nodes that must appear in resulting path(s) in specified order o strict & loose inclusions - specify if additional links can appear in resulting path(s) - sharables o unsorted list of links that must not be excluded in resulting path(s) because of insufficient resources PCE Design Team [Page 7] Internet Draft PCE Communication Protocol Requirements February 2005 R10.12 switching type, encoding type, GPID R10.13 switching capabilities to be included/excluded from the path R10.14 carrying multiple requests, correlated or not R11. PCC-PCE & PCE-PCE path request message MUST support ability to prefer/customize various path computation algorithms & policies R11.1 shortest intra/inter-domain TE paths - not require full graph to compute shortest/diverse path - recursive CSPF computation R11.2 reoptimization for intra/inter-domain TE paths R11.3 complex routing requiring high CPU & memory - multiple constraints, e.g. bounded delay minimum cost path R11.4 backup path computation R11.5 QoS CAC R12. PCE-PCC & PCE-PCE path response message MUST support returning various objects including (but not limited to): R12.1 primary & alternate P2P paths R12.2 explicit or strict/loose routing path R12.3 primary & backup path (for FRR) R12.4 less-constrained path (if cannot find path satisfying all constraints) R12.5 indication of PCE inability to support service/constraint - specify services/constraints PCE can support R12.6 a cookie, in case path must be hidden 7. Protocol Design Considerations The PCE communication protocol SHOULD account for future extensions not currently in PCE WG scope, such as P2MP paths. The PCC-PCE communication protocol SHOULD reuse as far as possible existing objects used by existing signaling protocols to encode path constraints and routes, in order to avoid costly object conversions. New objects must be defined only when necessary. For instance the EROs should be reused to encode the computed path in a Path Response message. For instance, it would be highly useful to reuse the ERO to encode the computed path in a Path Response message. Current PCE communication protocol alternatives include the following: o RSVP-TE extensions - http://www.watersprings.org/pub/id/draft-vasseur-mpls-computation -rsvp-05.txt o TCP extensions - http://www.watersprings.org/pub/id/draft-lee-mpls-path-request -04.txt o LDP extensions o BGP extensions o PCE --><-- GMPLS controller - draft-oki-ccamp-gtep-01.txt 8. 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 PCE Design Team [Page 8] Internet Draft PCE Communication Protocol Requirements February 2005 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 effects 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. 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 and JP Vasseur for their review and suggestions. 11. 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 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. PCE Design Team [Page 9] Internet Draft PCE Communication Protocol Requirements February 2005 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. 12. Normative References [PCE-ARCH] Farrel, Vasseur, Ash, "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. 13. Informational References [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999. [RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC2547, March 1999. [RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [INTER-AREA] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", draft-ietf-tewg- interarea-mpls-te-req-03.txt, November 2004 (work in progress). [INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic Engineering requirements", draft-ietf-tewg-interas-mpls-te-req-09.txt, September 2004 (work in progress). [MRN] Papadimitriou, D., et. al., "Generalized MPLS Architecture for Multi-Region Networks,"draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, February 2004 (work in progress). PCE Design Team [Page 10] Internet Draft PCE Communication Protocol Requirements February 2005 14. 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 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 Igor Bryskin 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 E-mail: 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 Musashino-shi, Tokyo 180-8585, JAPAN Email: oki.eiji@lab.ntt.co.jp PCE Design Team [Page 11] Internet Draft PCE Communication Protocol Requirements February 2005 Raymond Zhang INFONET Services Corporation 2160 E. Grand Ave. El Segundo, CA 90245 USA Email: Raymond_zhang@infonet.com 15. 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]