Network Working Group M. Boucadair (Ed.) Internet Draft P. Morand (Ed.) France Telecom R&D Document: draft-boucadair-pce-discovery-00.txt October 2004 Category: Informational Path Computation Service discovery via Border Gateway Protocol < draft-boucadair-pce-discovery-00.txt > Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667 [RFC3667]. 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 become aware will be disclosed, in accordance with RFC 3668 [RFC3668]. 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 April 2005. Abstract This drafts aims at describing a simple mechanism that will ease discovery of Autonomous Systems supporting inter-domain MPLS-based constrained tunnels service (this service is also denoted by Path Computation Service (PCSv)) managed by distinct Internet Network Providers (INP). Particularly, this draft describes how Border Gateway Protocol (BGP) is used to announce Path Computation Service unique identifiers Boucadair (Ed.) Informational - Expires April 2005 [Page 1] Internet Draft PCE Discovery via Border Gateway October 2004 Protocol across the Internet in order for other PCEs to be able to discover a path towards every AS supporting this Path Computation Service. Table of Contents 1. Contributors................................................2 2. Terminology.................................................2 3. Introduction................................................3 3.1. General.....................................................3 3.2. Structure of the draft......................................4 4. Conventions used in this document...........................4 5. PCE discovery within a single domain........................4 6. Overview of the service approach............................5 7. Service Advertisement and Discovery.........................6 8. Why PCE discovery is needed.................................7 9. Solution for PCSv discovery.................................7 10. Summary of overall operations...............................8 11. IANA Considerations.........................................9 12. Security Considerations.....................................9 13. References..................................................9 14. Acknowledgments............................................10 15. Author's Addresses.........................................10 1. Contributors o Hamid Asgari (Thales Research and Technology) o Panagiotis Georgatsos (Algonet) o David Griffin (University College London) o Micheal Howarth (University of Surrey) o Noel Cantenot (France Telecom) 2. Terminology This memo makes use of the following terms: o Path Computation Element (PCE): an entity that is responsible for computing/finding inter/intra domain LSPs. This entity can simultaneously act as client and a server. Several PCEs can be deployed in a given AS. o Path Computation Client (PCC): a PCE acting as a client. This entity is responsible for issuing path computation requests that fulfill the Service Management constraints for the establishment of inter/intra domain LSPs. Boucadair (Ed.) Informational - Expires April 2005 [Page 2] Internet Draft PCE Discovery via Border Gateway October 2004 Protocol o Path Computation Server (PCS): a PCE acting as a server. This entity is responsible for handling path computation requests including neighboring PCC constraints. o High-level service: is the service using a PCE-based system as an underlying infrastructure (an inter-domain QoS VPNs service for instance) o High-level service customer: is a customer that subscribes to a High-level service. o pSLS: A provider SLS is an SLS established between two Internet Network Providers (INP) with the purpose of extending the geographical span of their service offers. o SLS Management: this includes service ordering (i.e establishing contracts between peers) and invocation (i.e committing resources before traffic can be admitted) o Q-BGP: QoS-inferred BGP. A modified BGP protocol that takes into account QoS information as input for its route selection process. o Domain: within this draft it denotes an Autonomous system. 3. Introduction 3.1. General Recently, several proposals describing the use of a Path Computation Element (PCE) as additional element to the IP networks have been submitted to the IETF. The main objective of introducing a PCE element is to ease computation of constrained paths in sophisticated schemes like inter-domain (both in intra-provider or inter-provider) and then driving the establishment of inter-domain LSPs. A framework for establishing and controlling Multi-Protocol Label Switching Protocol (MPLS) and Generalized MPLS (GMPLS) Label Switching Paths (LSPs) in multi-domain networks has been defined in [CCAMP-FWRK]. Note that the notion of domain in this framework draft encloses Interior Gateway Protocol (IGP) areas and Autonomous System (AS) contrary to the current draft that restricts the notion of domain to a single AS. Another draft that proposes a solution to compute inter-domain constrained-LSPs has been recently submitted to the IETF [INTERAS- PCE]. This draft takes into account the inter-provider specific service considerations. In addition, draft [INTERAS-PCP] describes a new protocol allowing communication between two PCEs located in Boucadair (Ed.) Informational - Expires April 2005 [Page 3] Internet Draft PCE Discovery via Border Gateway October 2004 Protocol different domains in order to compute inter-domain paths satisfying a set of QoS constraints. All aforementioned drafts require a Path Computation Service (PCSv) discovery function that will allow discovery of remote ASs supporting this type of service together with theirs associated capabilities in term of QoS capabilities, inter-domain bandwidth, IP prefixes, etc. Discovery of such capabilities could be passive and be restricted to a simple service advertisement (like web-pages). PCSv locations and associated capabilities discovery depends on providers search. We will refer to this method as passive discovery method. It is evident that passive method allows finding remote PCSv locations and their associated capabilities, but this information is not usable alone within a distributed PCE architecture, when a set of end-to-end constraints must be satisfied. Therefore, computation of end-to-end constraints must be achieved based on all advertised individual PCE capabilities. The knowledge of the PCE path is then mandatory in order to deduce the end-to-end capabilities. In this draft, we present a simple method that allows discovery of remote PCSv with their associated capabilities. This method will also help the PCE decision-making process to choose the next PCE to contact in order to optimize paths towards a given destination. 3.2. Structure of the draft This draft is structured as follows: o Section 5 gives an overview of the service approach; o Section 6 argues on the need of PCSv discovery functions; o Section 7 presents a solution proposal for PCSv discovery. 4. 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]. 5. PCE discovery within a single domain Within a single domain, discovery of PCSv location and capabilities could be achieved for instance thanks to the activation of the Service Location Protocol (SLP, [RFC2608]). This protocol allows discovery of activated services that uses client/service architecture. SLP defines the same framework for all services. Boucadair (Ed.) Informational - Expires April 2005 [Page 4] Internet Draft PCE Discovery via Border Gateway October 2004 Protocol Note that the problem of end-to-end capabilities described in the introduction doesn't apply here since only one INP manages all deployed PCEs. In order to use SLP as a means to discover PCSvs, a PCE Service Type Template SHOULD be defined. 6. Overview of the service approach Neighboring domains establish pSLSs (a pSLS is an enhanced SLS agreement. SLS template is defined in [SLS]) between themselves in order to have appropriate rights to request establishment of LSPs. An inter-domain routing protocol runs between the domains (for instance Border Gateway Protocol (BGP, [RFC1771])). The LSP creation request is propagated downstream to appropriate PCEs. The requests include the AS's ASBR and the tail-end address of LSP. This procedure is repeated until the request reaches the destination PCE. +--------High Level Service Agreement--------+ | | v v <----AS1-----> <----AS2-----> <----AS3-----> ' ' ' ' ' ' ' '<-pSLS->' '<- pSLS->' ' ' ' ' ' ' ' +------------+ +------------+ +------------+ | PCE | | PCE | | PCE | | | | | | | | +------+ | | +------+ | | +------+ | | | PCC | | | | PCC | | | | PCC | | | | |<-|--\ | | |<-|--\ | | | | | +--/\--+ | | | +--/\--+ | | | +--/\--+ | | || | |PCP | || | |PCP | || | | || | | | || | | | || | | +--\/--+ | | | +--\/--+ | | | +--\/--+ | | | PCS | | \-----|->| PCS | | \------|->| PCS | | | | | | | | | | | | | | | +------+ | | +------+ | | +------+ | +------------+ +------------+ +------------+ Figure 1: Service Overview After authenticating the identity of LSP originating PCE, the destination PCE send a reply message back to the downstream domain's PCE accepting the request and include the LSP loose path (destination, ASBR) addresses in the message. The next downstream domain's PCE does the same adding its own relevant ASBR addresses to the LSP loose path. The originating PCE inserts its intra-domain path Boucadair (Ed.) Informational - Expires April 2005 [Page 5] Internet Draft PCE Discovery via Border Gateway October 2004 Protocol and it initializes an RSVP reservation request for LSP establishment using the LSP loose path. At the service/application level (in order to differentiate this service from extending scope of IP connectivity service, we will denote it as high level service), when originating AS wants to establish an LSP to a destination ASs, there MUST be an agreement between the two ASs (Service providers using these ASs as IP connectivity networks). 7. Service Advertisement and Discovery Within this draft, we make a difference between the Service Advertisement and Discovery (SAD) and PCSv discovery function. SAD is a function that is achieved before establishing a service agreement between two peers. The SAD operation consists mainly at advertising/learning from/to the rest of the Internet the capabilities supported by a given AS in term of offered services (like Inter-domain LSP establishment service). PCSv advertisement is conditioned by the existence of a pSLS between two peers. AS1 ' AS2 ' +----------------------+ ' |Service Advertisement |<---'-------------------\ +----------------------+ ' | ' | +----------v-----------+ | Service Discovery | +----------------------+ ' | ' | +----------v-----------+ | Service Planning | +----------------------+ | +----------------------+ ' +----------v-----------+ |Service Negotiation |<---'------->|Service Negotiation | +----------------------+ ' +----------------------+ Figure 2: Service Advertisement and Discovery Local Service Discovery block is responsible for finding remote offered services that is an essential input for Service Planning block. This functional block is responsible for choosing from discovered offered services the ones that will be used in order to build it own services. Thus, a negotiation process SHOULD start and an SLS MAY be agreed between the two parties. Boucadair (Ed.) Informational - Expires April 2005 [Page 6] Internet Draft PCE Discovery via Border Gateway October 2004 Protocol During service negotiation between two Service Providers, they MAY exchange their PCE reachability information and associated capabilities. Theses capabilities could include the following: o Supported Computation algorithms o Types of Constraints (e.g. QoS) o Set of attributes for a given constraint (one-way delay, one-way delay variationà) o Support of P2MP path computation techniques, As a consequence each INP has a full knowledge of the PCE capabilities of its adjacent providers. 8. Why PCE discovery is needed Path Computation elements are responsible for finding inter-domain paths satisfying a set of constraints (like QoS performance guarantees) to establish inter-domain constraint-based LSPs. The computation of this path is distributed and needs PCEs from different domains to communicate. Communication between two PCE entities is enabled thanks to PCE Communication Protocol (PCP) [INTERAS-PCP]. When receiving a request from the "High-Level" Service Management to compute/find/establish an LSP towards a given tail-end address, the local PCE has to determine the next PCE to contact. In the worst case, local PCE can contact all its neighboring PCEs that are known to Service Management System. Nevertheless, it has no criteria to choose between those PCEs the next PCE to be contacted in order to send its LSP computation request. The risk of a request failure is then important. In order to help the PCE decision-making process to choose the next PCE to be contacted, local PCE need to discover remote PCSvs reachable beyond the immediate neighbor PCEs. This information will help the next hop PCE decision or at least PCE need to access to intra and inter-domain Routing Information Bases in order to check the reachability status if tail-end address is propagated via routing protocols. 9. Solution for PCSv discovery Within this draft, we assume that during service negotiation phase between two peers, they MUST exchange IP addresses of their PCE(s). SLS Management Systems of the two peers MUST store this information. In order to help the PCE computation process, routing information MUST be made available for the PCE. Thus, reachability information associated with capabilities (like QoS intra and/or inter-domain capabilities) SHOULD be propagated in the routing level. In the case Boucadair (Ed.) Informational - Expires April 2005 [Page 7] Internet Draft PCE Discovery via Border Gateway October 2004 Protocol of QoS-based service, each potential tail-end address SHOULD be announced in all offered QoS Class plans (i.e. as many as used DSCP values). As a consequence, routing tables size will drastically increase. From this perspective, instead of announcing all potential tail-end addresses in BGP, only an identifier needs to be announced. It is called the Path Computation Service Identifier (PCSID). This particular BGP announcement is identified by a well-known community value (to be defined be IANA) and is represented by a routable IP address, which can be different from the real IP address of the PCE. As a consequence, this particular route SHOULD NOT be installed in the Forwarding Information Base (FIB) since this PCSID is not necessarily the IP address of the PCE. BGP announcements of PCSID will ease to discover the set of remote ASs supporting the inter-AS MPLS-based constrained tunnels service together with their associated end-to-end capabilities for reaching them. In order to compute a path towards a specific domain supporting this inter-AS MPLS-based constrained tunnels service, the local PCE chooses a route that serves the PCSID of that domain and extracts from the AS_PATH attribute the AS number of the next hop ASBR. Then, the local PCE queries its SLS Management system and gets back the PCE's IP address of the next neighboring PCE to contact. Finally, the local PCE forms and forwards a path computation request to this next PCE. The process is iteratively repeated until the request reaches the PCE of the target AS identified by its PCSID. This solution decreases the number of BGP announcements that are reduced to one announcement per PCE. 10. Summary of overall operations o An AS can announce a given prefix in several QoS plans; each of these QoS plans being identified by a unique Diffserv Code Point (DSCP) value per inter-domain link. o Each non-best effort announcement contains a set of QoS parameters values that characterizes the end-to-end QoS that will be experienced to reach a given prefix (we refer to this end-to-end QoS as aggregated QoS). o The way aggregated QoS values are computed is out of the scope of this document. o Adjacent ASs agree on the DSCP values to use in order to signal a given QoS class per inter-domain link (we will refer to this DSCP values as inter-domain DSCP). Boucadair (Ed.) Informational - Expires April 2005 [Page 8] Internet Draft PCE Discovery via Border Gateway October 2004 Protocol o Every AS has the freedom to bind an inter-domain DSCP value to a local DSCP value, which identifies its local QoS class. o An AS supporting the inter-domain MPLS-based QoS tunnels service, owns a Path Computation Service Identifier(s) (PCSID), which is a routable IP address. This IP address is not necessarily the IP address(es) of the PCE(s) of the domain. These PCSIDs are announced on a per DSCP plan basis, by an inter-domain routing protocol, together with their aggregated QoS values. o Remote ASs can discover ASs supporting the inter-domain MPLS- based QoS tunnels service by learning inter-domain routing protocol announcements that serve PCSIDs. These announcements provide the local AS with the end-to-end QoS characteristics of the path towards any prefix of the remote AS owning the PCSID. 11. IANA Considerations The solution proposed in this draft uses a well-know community attribute value that SHOULD be attributed by IANA [RFC2434] in order to facilitate recognition of BGP announcements that announce PCSv and associated capabilities. 12. Security Considerations This additional draft does not change the underlying security issues in the existing BGP-4 protocol specification [RFC2385]. 13. References [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, February 2004 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3668, February 2004 [CCAMP-FWRK] Farrel, A., Vasseur, JP., Ayyangar, A., "A Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter- domain-framework-00.txt, August 2004 [INTERAS-PCE] Boucadair, M., Morand, P., "A Solution for providing inter-AS QoS tunnels", draft-boucadair-pce-interas-00.txt, October 2004 [INTERAS-PCP] Boucadair M., Morand P. and al., "Inter-AS PCE Communication Protocol", draft-boucadair-pcp-interas-00.txt, October 2004 Boucadair (Ed.) Informational - Expires April 2005 [Page 9] Internet Draft PCE Discovery via Border Gateway October 2004 Protocol [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, version 2", RFC 2608, July 1999 [SLS] Goderis D., T'Joens Y., Jacquenet C., Memenios G., Pavlou G., Egan R., Griffin D., Georgatsos P., Georgiadis L., Heuven P.V., "Service Level Specification Semantics and parameters", draft- tequila-sls-02.txt, Work in progress. [RFC1771] Rekhter, Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 [RFC2385] Heffernan, A., "Protection of BGP sessions via the TCP MD5 Signature Option", RFC 2385, August 1998 14. Acknowledgments Part of this work is funded by the European Commission, within the context of the MESCAL (Management of End-to-End Quality of Service Across the Internet At Large, http://www.mescal.org) project, which is itself part of the IST (Information Society Technologies) research program. The authors would also like to thank all the partners of the MESCAL project for the fruitful discussions. 15. Author's Addresses Mohamed Boucadair France Telecom R & D 42, rue des Coutures BP 6243 14066 Caen Cedex 4 France Phone: +33 2 31 75 92 31 Email: mohamed.boucadair@francetelecom.com Pierrick Morand France Telecom R & D 42, rue des Coutures BP 6243 14066 Caen Cedex 4 Boucadair (Ed.) Informational - Expires April 2005 [Page 10] Internet Draft PCE Discovery via Border Gateway October 2004 Protocol France Email: pierick.morand@francetelecom.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTSOR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNETENGINEERING 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 (2004). 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. Boucadair (Ed.) Informational - Expires April 2005 [Page 11]