Network Working Group E. Stephan Internet-Draft S. Ellouze Intended status: Standards Track France Telecom Orange Expires: September 6, 2012 March 05, 2012 ALTO extensions for CDNi draft-stephan-cdni-alto-session-ext-00 Abstract The selection of a downstream CDN by an upstream CDN is based on multi-dimensional criteria such as the number of hops, the performance of the connections between the user-agent and downstream CDNs and the availability of downstream CDNs resources. Various protocols, such as BGP or ALTO, may be used by an upstream CDN to collect footprints and interconnection preferences of downstream CDNs. This draft introduces several extensions to the ALTO protocol for CDN interconnection. Requirements Language 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 6, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Stephan & Ellouze Expires September 6, 2012 [Page 1] Internet-Draft CDNi ALTO extensions March 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Stephan & Ellouze Expires September 6, 2012 [Page 2] Internet-Draft CDNi ALTO extensions March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. ALTO Client-Server session . . . . . . . . . . . . . . . . 5 2.2. PID Stability . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. dCDN Traffic Optimization . . . . . . . . . . . . . . . . 6 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. CDNi ALTO Session . . . . . . . . . . . . . . . . . . . . 6 3.2. PID stability with legacy BGP . . . . . . . . . . . . . . 7 3.3. Interface Scalability . . . . . . . . . . . . . . . . . . 7 3.3.1. PIDs filters Setting . . . . . . . . . . . . . . . . . 7 3.3.2. PIDs Summary . . . . . . . . . . . . . . . . . . . . . 8 3.3.3. PID Details . . . . . . . . . . . . . . . . . . . . . 8 3.3.4. Incremental Updates . . . . . . . . . . . . . . . . . 8 3.4. dCDN traffic Optimization . . . . . . . . . . . . . . . . 9 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Information Service Specification . . . . . . . . . . . . . . 12 6.1. Session Initialization . . . . . . . . . . . . . . . . . . 12 6.2. Update . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Information Service Call Flows . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Stephan & Ellouze Expires September 6, 2012 [Page 3] Internet-Draft CDNi ALTO extensions March 2012 1. Introduction The selection of a downstream CDN by an upstream CDN is based on multi-dimensional criteria such as the number of hops, the performance of the connections between the user-agent and downstream CDNs and the availability of downstream CDNs resources. Various protocols, such as BGP or ALTO, may be used by an upstream CDN to collect footprints and interconnection preferences of downstream CDNs. This draft introduces several extensions to the ALTO protocol for CDN interconnection. This draft focuses on the CDNi interconnections between an upstream CDN and a set of downstream CDNs willing to control the exposition and the exchange of footprint information. It applies to CDNi use cases ([I-D.ietf-cdni-use-cases]) and CDN use cases ( [I-D.jenkins-alto-cdn-use-cases]). 1.1. Terminology The reader must be familiar with the terminology given by the drafts [I-D.ietf-cdni-problem-statement], and [I-D.ietf-cdni-requirements] , and [I-D.ietf-alto-protocol]. The following abbreviations are recalled: - dCDN : downstream CDN; - uCDN : upstream CDN; - PID : Provider-defined Network Location Identifier; - NSP : Network Service Provider (e.g. ISP connecting End User to Internet); ALTO Client-Server session: The logical association between an ALTO Client and an ALTO server which maintains the context across the connections of the client to the server. 2. Motivations Currently the ALTO protocol is designed for the communication of network information to internet applications including untrusted ones. In the context of a CDN interconnection (CDNi) there is a certain level of trust, at least enough to mount a subset of the Stephan & Ellouze Expires September 6, 2012 [Page 4] Internet-Draft CDNi ALTO extensions March 2012 interfaces depicted in [I-D.ietf-cdni-problem-statement]. There are CDNi situations like Inter-Affiliates Interconnection (see section 2.2 [I-D.ietf-cdni-use-cases] where topology hiding [RFC5693] is not absolutely required. 2.1. ALTO Client-Server session ALTO is a client-server protocol. Currently the ALTO specifications do not specify the parameters of the session. [I-D.ietf-alto-protocol] only indicates concerns for authentication, content protection and encryption. Cookies are ignored. The configuration of the ALTO interface between an uCDN and a dCDN requires the exchange of session parameters between the two CDNs operators. This can be performed either out-of-band or through the CDNi Control interface. In both cases the setting of a CDNi ALTO session requires an agreement between the 2 CDNs operators and a technical description of the session configuration (addresses, URL, authentication methods, etc.), of the information which can be exchanged (PID filtering, level of details of the maps) and on the way the information is exchanged (update procedure, scale of time of the update ). 2.2. PID Stability Currently to mitigate the risks of providing ALTO information to untrusted ALTO clients ( [I-D.ietf-alto-protocol], section 12.1), it is usual to ALTO servers to scramble the prefixes among the PIDs to avoid reverse engineering. This may lead to PID content overlapping. Such nondeterministic semantics may be unusable by a request routing function of a uCDN, or may lead to suboptimal decision. . 2.3. Scalability As illustrated by the figure 1 an uCDN could be interconnected with several dCDNs. It may receive an important amount of information leading to the uCDN failure ([I-D.ietf-alto-deployments], section 10). The CDNi ALTO interface should provide a scalable information exchange framework to match uCDN ALTO client resources constraints. A dCDN should be able to dimension the information resources it dedicates to uCDNs. For instance, an uCDN may not want to receive the very last detailed level of the network map of all the dCDNs it is interconnected with; similarly it may not want to receive all the update information. This will be even worse when the maps will include multi-cost ( [I-D.randriamasy-alto-multi-cost] and [I-D.marocco-alto-next] section 3.2). Stephan & Ellouze Expires September 6, 2012 [Page 5] Internet-Draft CDNi ALTO extensions March 2012 ------------------------ | | | uCDN | | ALTO Client | ------------------------ ^ ^ ^ / | \ detailed network and cost maps / | \ / | \ ----------- ----------- ----------- | dCDN A | | dCDN B | | dCDN C | | ALTO | | ALTO | | ALTO | | Server | | Server | | Server | ----------- ----------- ----------- Figure 1: uCDN ALTO interconnection 2.4. dCDN Traffic Optimization Considering that ALTO is about traffic optimization at the application level, in the context of a CDNi interconnection between an uCDN and a dCDN, ALTO is capable of covering the exchange of information from dCDN to uCDN, allowing for the optimization of the delivery at the uCDN side only. In contrast, exchanging information the other way around for allowing delivery optimization at the dCDN level is not addressed yet. Indeed a dCDN is subject to rival uCDNs requesting resources based on information exposed by the dCDN. By exposing their constraints and their needs, the uCDNs requirements are better addressed by dCDNs through a smart resource provisioning and sharing. 3. Proposal 3.1. CDNi ALTO Session The session between uCDNs and dCDNs should reflect the agreements and expectancies between them. A minimal configuration of the session is required for ensuring an efficient initialization of the interface, for decreasing the service time, increasing the interoperability and improving the security. Interoperability: The session configuration parameters must avoid the case allowed in section 7.6.3 of [I-D.ietf-alto-protocol] where several entries in Stephan & Ellouze Expires September 6, 2012 [Page 6] Internet-Draft CDNi ALTO extensions March 2012 the directory match an Information Resource using a HTTP POST or a HTTP GET. Additional session parameters should be specified to avoid such situations (see section 7.6.4.1of [I-D.ietf-alto-protocol]). One proposal consists in including PID filters in the session parameters: The dCDN ALTO server generates an URI entry for each of these filters in the resource directory. The uCDN ALTO client downloads the content attached to these URIs using HTTP GET queries. Discussion: This work on the session configuration may be coupled with the specification of the update service [I-D.marocco-alto-next] as both require the memorization of session parameters like the coordinates of the dCDN ALTO clients. 3.2. PID stability with legacy BGP As described in section 4.1of [I-D.previdi-cdni-footprint-advertisement] a CDN acquires most of the footprint information from legacy BGP. The NSP may use part of the community tags carried by its legacy internal BGP to filter and gather the prefixes in stable groups (see section 5.1.7 of [I-D.ietf-alto-deployments]) that may then used by its internal CDN [I-D.jenkins-alto-cdn-use-cases] . The NSP CDN acting as a dCDN ALTO server may filter and send these stable groups to uCDN ALTO clients according to its policies and with respect to the peering agreement between The NSP CDN and each uCDN. 3.3. Interface Scalability The ALTO data must be customized to reduce the amount of exchanged information for scalability and responsiveness. 3.3.1. PIDs filters Setting The amount of information to be parsed impacts directly the performance of uCDN Request Routing function. The selection of the PIDs of interest is needed by an uCDN to limit the quantity of information to download from each dCDN. As an example an uCDN does not want to download all the PIDs when it needs only the PIDs managed directly by each dCDN NSP (e.g. user-agent IPv4 on-net prefixes). Discussion: As given by section 7.2.2. of [I-D.ietf-alto-protocol] this can already be achieved using POST querying the ALTO Map Filtering Service. The drawback is that it requires carrying the filter Stephan & Ellouze Expires September 6, 2012 [Page 7] Internet-Draft CDNi ALTO extensions March 2012 parameters in-band in each POST query. An uCDN should be able to configure filters that apply during all the duration of the ALTO connection and to have the resulting information addressable directly through a simple GET of an URI in the dCDN ALTO server. The proposal consists in having PID filters at the session level. There are two options: The filters are agreed by uCDN and dCDN operators and set in the configuration of the session; Filters are dynamically configured during the session by an uCDN ALTO client. It requires the creation of a 'PIDs filters Setting' service in the dCDN ALTO server. 3.3.2. PIDs Summary The level of information details exchanged between a dCDN ALTO server and a uCDN ALTO client must be customizable in order to decrease the amount of exchanged data while providing the required information. uCDN may not need the full details of each map. It may also need to reduce the exchange of useless information. An uCDN ALTO client should be allowed to get only the summary of the maps. This can be achieved by using additional session parameters giving the level of detail of the maps. This covers the situation where the very detail of PIDs are available on other existing interfaces of a dCDN and where an uCDN and a dCDN agree to not duplicate the works. 3.3.3. PID Details An uCDN may need the detailed information of a sub set of PIDs of interest. An uCDN ALTO client queries the detail of a PID in dCDN ALTO server using the ALTO Map Filtering Service [I-D.ietf-alto-protocol]. 3.3.4. Incremental Updates In a way to avoid flooding uCDN with useless information each dCDN ALTO server should limit the incremental update according to the session configuration and the restrictions made by each uCDN ALTO client (filters, time scale, etc.). Stephan & Ellouze Expires September 6, 2012 [Page 8] Internet-Draft CDNi ALTO extensions March 2012 3.4. dCDN traffic Optimization An uCDN may provide dCDN with high level constraints like previsions of the amount of traffic that uCDN will or may have to deliver. Based on the raw description of each uCDN constraints, dCDN NSPs should be able to improve their network provisioning and optimize resource usage while enhancing the QoS. This benefits directly to all uCDNs because the cost map provided by dCDN will reflect uCDNs constraints instead of providing a better-than-nothing generic cost map agnostic to the different uCDNs constraints. To preserve its know-how an uCDN is not entitled to expose the detail of its constraints. The solution proposed by this draft consists in grouping uCDN constraints information at the PID level to provide complementary information on the PIDs provided by dCDN. This information benefits to all interconnected CDNs as it allows for a smarter resources utilization leading to a better QoE at comparable costs. This can be achieved with a new ALTO Service based on a POST request. 4. Framework The framework is PID centric. It supports session parameters. It reduces the number of POST messages by including fully-defined filtered maps as URI in the resource directory and provides better scalability regarding the amount of data to clients and servers. It adds a first service allowing uCDN to configure filters which apply to all uCDN queries and dCDN updates. The second service created allows uCDNs to complement PID information with high level constraints. The third service, already in the roadmap of ALTO, allows the push of map updates by an ALTO server. Following is the summary of the services. Stephan & Ellouze Expires September 6, 2012 [Page 9] Internet-Draft CDNi ALTO extensions March 2012 uCDN ALTO Client dCDN ALTO Server | | | server capabilities options | |<--------------------------------------------------| (a) | | ... ... | | | PIDs filters setting | |-------------------------------------------------->| (b) | | ... ... | | | PIDs summary | |<--------------------------------------------------| (c) | | ... ... | | | PID details | |<--------------------------------------------------| (d) | | ... ... | | |-------------------------------------------------->| (e) | uCDN constraints on dCDN PIDs | | | ... ... | | | Matrix of cost | |<--------------------------------------------------| (f) | | ... ... | | | updates | |<--------------------------------------------------| (g) | | | | Figure 2: Extension framework (a) The uCDN ALTO client gets the dCDN ALTO server capabilities (GET directory). (b) The uCDN ALTO client adds PIDs filtering (e.g. IPv4 only, PID of interest ...). (c) The uCDN ALTO client downloads PIDs summary. (d) The uCDN ALTO client downloads detailed information of one PID. Stephan & Ellouze Expires September 6, 2012 [Page 10] Internet-Draft CDNi ALTO extensions March 2012 (e) The uCDN ALTO client complements dCDN network map entries with its constraints. (f) The uCDN ALTO client downloads the cost map. (g) The dCDN ALTO server updates the information. An update includes either the information that has changed or a list of indication of the information which has changed. The mode used is given by the session parameters. As an example, an update of the network map may includes only the list of the PID updated since the previous version of the network map. 5. Requirements This section proposes a first set of requirements. Requirements for ALTO: The ALTO server must indicate the support of the CDNi services in its Information resource Directory: - CDNi PID filtering service; - Constraints upload service; - Update service; Requirements for CDNi: A dCDN ALTO server must reject any message received from an untrusted CDNi uCDN ALTO client. A dCDN ALTO server must support the filter setting service when the initialization of the session does not support PID filters configuration. A dCDN ALTO server must support the exchange of summarized network maps. A dCDN ALTO server may support the constraints upload service. A dCDN ALTO server may support the update service. A uCDN ALTO client may support the update service. Stephan & Ellouze Expires September 6, 2012 [Page 11] Internet-Draft CDNi ALTO extensions March 2012 6. Information Service Specification This section specifies the session initialization and the additionnal information services defined for interconnecting an uCDN ALTO client to an dCDN ALTO server. Each information service will be described in a next version of this document. 6.1. Session Initialization The agreement between uCDN and dCDN operators specifies the initial values of the parameters of the ALTO sessions. Following are the parameters of the session: - PID_filters: The list of PID filters of this session (e.g. ipv4, on-net...). - network_map_level_of_details: The default level of details of the network maps. - costmap_level_of_details: The default level of details of the cost maps. - Update_heartbeat: The time scale of the update. 6.2. Update This is already drafted in [I-D.pbryan-json-patch], discussed [I-D.schwan-alto-incr-updates]and envisionned by [I-D.marocco-alto-next] the ALTO WG. 7. Information Service Call Flows This section describes the interworking between a dCDN ALTO server and an uCDN ALTO client. The call flow of each service will be described in a next version of this document. 8. IANA Considerations This document will request the registration of the media type corresponding to each new information service introduced. Stephan & Ellouze Expires September 6, 2012 [Page 12] Internet-Draft CDNi ALTO extensions March 2012 9. Security Considerations [Editor Note: This section needs more works] Despite the ALTO session is set up between CDNi entities the usage of the ALTO services by the client may stress the server. Consequently the volume and the number of these messages may affect the availability and the performance of the ALTO server. An uCDN ALTO client sets up the session parameters to control the amount of information downloaded from a dCDN ALTO server. Nevertheless the uCDN ALTO client should protect itself from the download of huge network map. The new information services do not introduce deep privacy concerns because they tend to reduce the information exchanged. Nevertheless this point requires more investigation. 10. Acknowledgments Part of this work is funded by the EU FP7 Envision and Ocean projects. The authors would like to thank Christian Jacquenet for its feedbacks on preliminary versions of this document 11. References 11.1. Normative References [I-D.ietf-alto-protocol] Penno, R., Alimi, R., and Y. Yang, "ALTO Protocol", draft-ietf-alto-protocol-10 (work in progress), October 2011. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni-requirements-02 (work in progress), December 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Stephan & Ellouze Expires September 6, 2012 [Page 13] Internet-Draft CDNi ALTO extensions March 2012 11.2. Informative References [I-D.ietf-alto-deployments] Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO Deployment Considerations", draft-ietf-alto-deployments-04 (work in progress), March 2012. [I-D.ietf-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", draft-ietf-cdni-problem-statement-03 (work in progress), January 2012. [I-D.ietf-cdni-use-cases] Gilles, B., Watson, G., Ma, K., Eardley, P., Emile, S., and T. Burbridge, "Use Cases for Content Delivery Network Interconnection", draft-ietf-cdni-use-cases-03 (work in progress), January 2012. [I-D.jenkins-alto-cdn-use-cases] Previdi, S., Watson, G., Medved, J., Bitar, N., and B. Niven-Jenkins, "Use Cases for ALTO within CDNs", draft-jenkins-alto-cdn-use-cases-02 (work in progress), December 2011. [I-D.marocco-alto-next] Marocco, E. and V. Gurbani, "Extending the Application- Layer Traffic Optimization (ALTO) Protocol", draft-marocco-alto-next-00 (work in progress), January 2012. [I-D.medved-alto-svr-apis] Medved, J., Ward, D., Peterson, J., Woundy, R., and D. McDysan, "ALTO Network-Server and Server-Server APIs", draft-medved-alto-svr-apis-00 (work in progress), March 2011. [I-D.pbryan-json-patch] Bryan, P., "JSON Patch", draft-pbryan-json-patch-04 (work in progress), December 2011. [I-D.penno-alto-cdn] Penno, R., Medved, J., Alimi, R., Yang, R., and S. Previdi, "ALTO and Content Delivery Networks", draft-penno-alto-cdn-03 (work in progress), March 2011. [I-D.previdi-cdni-footprint-advertisement] Previdi, S., Faucheur, F., Faucheur, F., and J. Medved, Stephan & Ellouze Expires September 6, 2012 [Page 14] Internet-Draft CDNi ALTO extensions March 2012 "CDNI Footprint Advertisement", draft-previdi-cdni-footprint-advertisement-00 (work in progress), October 2011. [I-D.randriamasy-alto-multi-cost] Randriamasy, S. and N. Schwan, "Multi-Cost ALTO", draft-randriamasy-alto-multi-cost-05 (work in progress), October 2011. [I-D.schwan-alto-incr-updates] Schwan, N. and B. Roome, "ALTO Incremental Updates", draft-schwan-alto-incr-updates-00 (work in progress), December 2011. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. Authors' Addresses Emile Stephan France Telecom Orange 2 avenue Pierre Marzin Lannion F-22307 France Email: emile.stephan@orange-ftgroup.com Selim Ellouze France Telecom Orange 2 avenue Pierre Marzin Lannion F-22307 France Email: selim.ellouze@orange-ftgroup.com Stephan & Ellouze Expires September 6, 2012 [Page 15]