Internet Engineering Task Force Th. Zahariadis, Ed. Internet Draft Synelixis Intended Status: Informational Y. Le Louedec Expires: April 26, 2012 Orange Labs Ch. Timmerer UNI-KLU S. Spirou Intracom D. Griffin UCL October 24, 2011 Catalogue of Advanced Use Cases for Content Delivery Network Interconnection draft-fmn-cdni-advanced-use-cases-00 Abstract The purpose of this draft is to complement the current CDNi WG use- cases with a catalogue of advanced, longer-term CDN interconnection use cases. The work has been the contribution of six European Commission (EC) co-funded projects, which are part of the EC Future Media networks (FMN) cluster. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html FMN Expires April 26, 2012 [Page 1] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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. FMN Expires April 26, 2012 [Page 2] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 2 Advanced/Long-term CDNi Use Cases . . . . . . . . . . . . . . . 5 2.1 Use Case 1: Caching-CDN interconnection . . . . . . . . . . 5 2.2 Use Case 2: CDN-CDN interconnections at large scale . . . . 6 2.3 Use Case 3: Dynamic adaptive streaming over HTTP in multi-CDNs . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Use Case 4: Dynamic expansion of CDN capacity and geographical reach . . . . . . . . . . . . . . . . . . . . . 8 3 Relationship between CDNI and Information-Centric Networking . 9 4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 List of Contributors . . . . . . . . . . . . . . . . . . . 12 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1 Normative References . . . . . . . . . . . . . . . . . . . 12 5.2 Informative reference . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 FMN Expires April 26, 2012 [Page 3] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 1 Introduction The purpose of this draft is to complement the current CDNi Work Group short-term use-cases with a catalogue of advanced, longer-term CDN interconnection use cases. The proposed catalogue of use cases is coming from or inspired by work in the European Commission (EC) Future Media Network (FMN) cluster research projects. Though they are beyond the current short-term objectives of the CDNi WG, the proposed use cases could drive future work in the CDNi WG, especially in case of WG re-chartering (once the present goals will be reached). The use cases are derived from ongoing research work in six EC co-funded projects where concrete design, implementation and evaluation work is being undertaken to validate the approaches. Moreover, this draft compares CDNs with Information-Centric Networking (ICN) which have similar goals and use cases. We discuss here this relation for the benefit of people and organizations working in these areas. 1.1 Terminology 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 RFC2119 [RFC2119]. The present document reuses terminology defined by CDNi WG documents [I-D.ietf-cdni-problem-statement], [I-D.ietf-cdni-use-cases] and [I- D.ietf-cdni-requirements]". 1.2 Abbreviations [Ed. Note: List of abbreviations to be updated later] o CSP: Content Service Provider o dCDN: downstream CDN o FMN: Future Media Networks o ICN: Information-Centric Networking o NSP: Network Service Provider o QoE: Quality of Experience o SLA: Service Level Agreement o uCDN: upstream CDN FMN Expires April 26, 2012 [Page 4] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 o MPD: Media Presentation Description o DASH: Dynamic Adaptive Streaming over HTTP 2 Advanced/Long-term CDNi Use Cases This draft includes four advanced CDNi use cases. The first use case introduces a Caching-CDN interconnection that put emphasis on the in- the network caching mechanism. As CDNi WG mainly targets interconnection between two CDNs, the second use case extends this use case to large-scale CDNs. The third use case introduces support of dynamic adaptive streaming over HTTP (DASH) in a multi-CDNs context, which may be today's most promising video distribution method as it overcomes limitations posed by firewalls and promises efficient distribution utilizing CDNs and network caching resources. Finally, the forth use case proposes the dynamic expansion of CDN capacity and geographical reach. 2.1 Use Case 1: Caching-CDN interconnection Some telecom operators and NSP deploy caching servers, a.k.a. "transparent caching" servers, in their IP networks in order to cache content by CDNs over Internet, with as goal to relax and balance the load on their IP networks. Today in most situations the two overlay networks - the upstream CDN (uCDN) and the downstream CDN (dCDN) set of transparent caching servers - run independently from each other. There is no specific interconnection interface between the two overlay networks. There could be some interest to set up interfaces between these overlay networks (of course on condition that their owners get the right business incentives for). Here are two illustrations of the potential benefits (this is not an exhaustive list): - Setting up a "logging interface" between the two overlay networks could be beneficial for providing the uCDN (and beyond the Content Service Providers, CSP) with useful logging, monitoring, reporting data. - Setting up a "CDN metadata interface" between the two overlay networks could be beneficial for allowing the uCDN to request that a given content file be purged from, or invalidated in, any downstream caching server. The current charter of the CDNi WG states "the WG will not define FMN Expires April 26, 2012 [Page 5] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 support for transparent caching across CDNs". The first priority is indeed to meet the goals and milestones specified in the current charter. This use case proposal aims at recommending that this "caching-cdn interconnection" use case be considered in case of WG re-chartering (once the present goals will be reached). The first difference with the present cdn-cdn interconnection model addressed by the CDNi WG is that there is no request routing interface in this "caching-cdn interconnection" use case. Then different sub-cases can be envisioned, depending on which CDNi interfaces are leveraged (with or without logging interface, with or without CDNI metadata interface, etc.). In a first approach, this "caching-cdn interconnection" use case could therefore be considered as a sub-case of the current CDNi WG's cdn-cdn interconnection model. Note. Once such specific interfaces are set up between the uCDN and the dCDN set of transparent caching servers, the latter ones cannot be any more considered as fully transparent, at least from the viewpoint of the uCDN. This should call for a slight evolution of the terminology. 2.2 Use Case 2: CDN-CDN interconnections at large scale The current focus of the CDNi WG is on the interconnection between two CDNs. The purpose here would be to investigate situations where (possibly much) more than two CDNs are involved in a CDN federation. As stated by the Amplification Principle defined in [RFC3439] "there do exist non-linearities which do not occur at small to medium scale, but occur at large scale". As a result, the number of involved CDNs could impact on the requirements and constraints, especially in terms of scalability, and therefore on the conceivable technical options to ensure interconnection. As an illustration of the amplification principle application in CDNi, the initial considerations, and potential issues, about request routing in CDN interconnect scenarios presented in [I-D.stiemerling- cdni-routing-cons] could be even more critical in large scale CDN federations. This would possibly lead to the definition of specific sub cases corresponding to cdn-cdn interconnections at large scale. Yet the FMN Expires April 26, 2012 [Page 6] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 first priority (and prerequisite before investigating such large scale use cases) is to meet the goals and milestones specified in the current charter, i.e. to specify adequate interfaces for interconnecting two CDNs. So this proposal aims at recommending that this "cdn-cdn interconnections at large scale" use case be considered in case of WG re-chartering (once the present goals will be reached). 2.3 Use Case 3: Dynamic adaptive streaming over HTTP in multi-CDNs The ever-growing video traffic on the Internet requires more efficient content distribution mechanisms. Compared to existing RTP/RTSP-based streaming or HTTP progressive download, Dynamic Adaptive Streaming over HTTP (DASH) enables stateless communication between a client and the corresponding server, better content adaptability and support for live media services [Stockhammer2011]. Intrinsic characteristic of DASH is the content fragmentation into various representations comprising segments (or sub-segments) of different encodings of one or several media components. These components/segments are transferred, along with content metadata descriptors referred to as media presentation description (MPD), to the origin servers. Using MPD, clients request the segments utilizing HTTP GET or partial GET requests. DASH is considered as a promising solution for efficient and high- quality delivery of streaming services over the Internet and is currently standardized as 3GP-DASH, MPEG-DASH, and OIPF HAS. It supports among others, re-use of existing technologies (codecs, containers, etc.), deployment on top of HTTP-CDNs, re-use of HTTP origin and cache/proxy servers, re-use of existing media play-out engines, as well as on-demand, live and time-shifted delivery. For example, DASH may be exploited within specific CDNs enabling clients to retrieve content hosted by given surrogates, taking into account the scale, the coverage and the reliability of HTTP-based CDN systems. Additionally, DASH can be also utilized as a delivery solution in a CDN Interconnect environment, enabling content acquisition among different providers. In such a case, a content service provider (e.g., CSP-1 in the following figure) will first ingest the prepared content into CDN-A, so that each surrogate can act as a DASH server offering the streaming service to the requesting End-User, acting as DASH client, connected with a different CDN (e.g., CDN-B). Towards this, CDN Interconnection requires interfaces among CDNs to be capable of facilitating their collaboration besides ensuring content streaming efficiently. FMN Expires April 26, 2012 [Page 7] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 +-------+ +-------+ | CSP-1 | | CSP-2 | +-------+ +-------+ | | ,--,--,--. ,--,--,--. ,-' `-. ,-' `-. ( CDN Provider A )=====( CDN Provider B ) `-. (CDN-A) ,-'-------`-. (CDN-B) ,-' `--'--'--' | `--'--'--' | | | | DASH DASH +------------+ | User Agent/| | DASH Client| +------------+ === CDN Interconnection In other words, in an interconnected CDN environment the definition of a control interface is required, which will enable DASH clients to acquire specific information from a hosting CDN over multiple-CDNs. Towards these, the anticipated interface must be able of providing/delivering: - The Media Presentation Description that contains metadata to construct appropriate HTTP-URLs to access segments and to provide the streaming service to the user. - The Number of source surrogates: one or multiple (content segments can be acquired from multiple sources). - The location of source surrogates: e.g., locality-aware capabilities for choosing the nearest source(s), as a matter of geographical (internal or external) or network-based metrics (e.g., using latency or cost-based metrics). - Delivery protocols: Definition of the delivery protocols used for the delivery of segments. - Additional metadata for content delivery (e.g., metadata for content-aware networks). 2.4 Use Case 4: Dynamic expansion of CDN capacity and geographical reach ISPs may offer a set of specialized network services which may be invoked by their customers, including CDN providers, with appropriate prior agreements and possible payments. The network service of most relevance to this use case is the provision of caching resources located within the ISP. A CDN provider making use of such a service FMN Expires April 26, 2012 [Page 8] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 may invoke new caching resources within a local or remote ISP to dynamically create new CDN surrogate nodes. The newly created resources are provided by the network provider but under the control of the CDN provider. This is an alternative way of dealing with increased load on a CDN, and a CDN provider who is able to invoke dynamic nodes is therefore able to expand dynamically to accommodate increased traffic demand or extend geographical reach. Such a CDN provider could a) advertise its elasticity to upstream CDNs which could simplify/enhance its resource-routing algorithm decisions, or b) advertise its new capabilities dynamically as it expands/contracts. These announcements could be made part of the CDNi control interface interactions and contributions could be made on the protocol extensions to announce capabilities dynamically and also to propose elasticity metrics. 3 Relationship between CDNI and Information-Centric Networking CDN interconnection has similar goals and use cases to Information- Centric Networking (ICN). We discuss here this relation for the benefit of people and organizations working in these areas. We start with a very brief description of CDNs and ICN in order to have a common understanding. We then discuss similarities and differences in terms of objectives, technical approach, deployment and business models. Finally, we explore the possibility of interaction and coexistence of ICN and CDN in a future Internet. CDNs are real working systems, while ICN is still at the research stage. It is important to note that our analysis is based on the state of ICN research and the assumption that ICN will meet its design goals. A CDN is a privately owned overlay network that aims to optimize delivery of content from (Content Service Providers) CSPs to End Users. CDNs are independent of each other. Optimization is in terms of performance, availability and cost. CDNs operate by serving content to User Agents from managed caches - called surrogates - at the edge of the network. CDNs may also use reserved network resources. The CDN provider collaborates with NSPs on surrogate placement and network resource reservation. The deployment, extension and (part of) the operation of CDNs are centrally managed. To maintain transparency for End Users, normal content locators (e.g., URLs) are used to access content. However, the CDN treats those locators as simple content identifiers when selecting a surrogate, in effect, decoupling the locator from the content location. ICN shares many of the goals of CDNs. Optimization of delivery with ICN usually entails caching, QoS-aware routing and traffic differentiation, to various degrees. Unlike CDNs, ICN aims at FMN Expires April 26, 2012 [Page 9] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 operating natively at the NSP level (although operation as an overlay is also possible). An NSP deploys ICN-enabled elements (mainly routers) with minimal planning in terms of content demand. The ICN reach grows with each new ICN-enabled NSP, without any central management. For content access, ICN uses explicit content identifiers that are independent from the content location. A main objective of both CDNs and ICN is the effective delivery of content from CSPs to End Users. ICN also aims at accommodating End Users as small CSPs, i.e., End Users who want to share content. The decoupling of content identifiers from the content location is an explicit goal in ICN, while in CDN this is a by-product. The main elements of a CDN are a set of content servers and a request redirection system. The content servers are carefully placed to be close to the User Agents and can be populated prior to any requests based on foreseen demand. An End User requests content with a normal URL, which triggers a part of the redirection system that resides at the seeming location of the content. The redirection system selects a content server based on criteria aiming to optimize some aspect of the delivery task. The selected content server then delivers the requested content to the User Agent. In ICN, any edge router with storage capabilities can act as a content server, which is populated based on actual demand. Alternatively, or in addition, QoS-aware routing and traffic differentiation techniques are used to establish a path from the content source to the User Agent. Content is requested with a dedicated identifier. This identifier can be used to route the request to the content source or to an intermediate content server, while constructing the path. Alternatively, the identifier can be used as an index in a directory system to retrieve content metadata. The metadata are then used to setup a path from the content source to the User Agent. A CDN constitutes an administrative domain, whereas in ICN an administrative domain can be as granular as an ICN router. When viewed in terms of administrative domains, CDN interconnection resembles the interconnection of ICN elements/domains. As such, request routing in CDNI and in ICN presents similar technical challenges. Following this thinking, the Content Distribution Metadata and CDNI Metadata of CDNI become related to the content metadata that are used in ICN to establish a path. A CDN is deployed as an overlay with all its elements independent from NSPs and belonging to the same CDN Provider. The CDN Provider works closely with the CSP in order to ingest and place content. There's also close collaboration between the CDN Provider and the FMN Expires April 26, 2012 [Page 10] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 NSPs for server placement and reservation of resources. Once the CDN is operational, any unforeseen change in CSP requirements, network conditions or End User demand will force the CDN Provider to re- design the deployment. To avoid this, CDNs are designed with over- provisioning and redundancy. On the other hand, ICN is deployed as NSP infrastructure. Each NSP owns and independently manages the ICN elements in its domain. There's no "ICN Provider" to oversee the deployment of ICN. The system grows as each NSP becomes ICN-enabled. In order to use ICN, CSPs need to provide content source servers and content metadata. ICN is designed with flexibility in mind, which permits coping with many unforeseen events. In a typical business case for CDNs, a CDN is deployed in and NSP domain and the NSP acts both as a CDN Provider and a (sole) CSP. NSPs use this model to offer content services, such as IPTV, to their End Users and so to differentiate their business. In another model for CDNs, a CDN Provider agrees with several NSPs to deploy content servers and reserve resources in their domain. The CDN Provider then sells content delivery services to interested CSPs. The ICN business model is very similar to that for connectivity services. An NSP deploys ICN in its domain and makes transit or peering agreements with other ICN-enabled NSPs. The NSP then offers content delivery services to CSPs. It is also possible for the NSP to offer content consumption services to its End Users. In a future Internet where ICN is deployed by some NSPs, it would be difficult to meet end-to-end the ICN performance goals, because of the "holes" between ICN domains. In such a case, CDNs can act as overlay bridges, because they might already have content close to the downstream ICN domain. In essence, from the ICN point of view, CDN Providers would become CSPs. However, the incentive for the CDN Provider is unclear, as such a move could undermine its own content delivery service. Borrowing from the motivation for CDNI, a CDN Provider who wants to extend its reach, instead of interfacing with a neighboring CDN, could interface with an ICN-enabled NSP. This is of course a scenario that only market forces and time can validate. 4 Acknowledgements This draft has been produced by the Future Media Networks (FMN) cluster of the Networked Media Systems FP7 projects. The work leading to these results has received funding from the European Union's Seventh Framework Programme (FP7/2007-2013) in(alphabetic order): ALICANTE (FP7-ICT-248652; http://www.ict-alicante.eu/), COAST (FP7-ICT-248036; http://www.coast-fp7.eu/), COMET (FP7-ICT-248784; http://www.comet-project.org/), ENVISION (FP7-ICT-248565; http://www.envision-project.org/), FMN Expires April 26, 2012 [Page 11] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 NEXTMEDIA (FP7-ICT-249065; http://www.fi-nextmedia.eu/) and OCEAN (FP7-ICT-248775; http://www.ict-ocean.eu/). 4.1 List of Contributors Andrzej Beben, Warsaw University of Technology, Poland; Christian Timmerer, UNI-KLU, Austria; David Florez Rodriguez, Telefonica R&D, Spain; David Griffin, Yiannis Psaras, Raul Landa, UCL, UK; Daniel Negru, Labri, France; Evangelos Pallis, Petros Anapliotis, TEIC, Greece; George Xilouris, DEMOKRITOS, Greece; Isidro Laso, European Commission, Belgium (on a personal basis); Klaus Satzke, Alcatel-Lucent Bell Labs, Germany; Michalis Georgiadis, PrimeTel, Cyprus; Ning Wang, University of Surrey, UK; Spiros Spirou, Intracom Telecom, Greece; Theodore Zahariadis (editor), Synelixis, Greece; Yannick Le Louedec, Orange Labs, France; Yiping Chen, Daniel Negru, CNRS-LaBRI, France. 5 References 5.1 Normative References [RFC3439] R. Bush, D. Meyer, "Internet Architectural Guidelines," RFC 3439, http://www.ietf.org/rfc/rfc3439.txt (updates RFC 1958), December 2002. [I-D.ietf-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., FMN Expires April 26, 2012 [Page 12] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", draft-ietf- cdni-problem-statement-00 (work progress), September 2011. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni-requirements-00 (work in progress), September 2011. [I-D.ietf-cdni-use-cases] Bertrand, G., Stephan, E., Watson, G., Burbridge, T., Ma, K., "Use Cases for Content Delivery Network Interconnection", draft-ietf-cdni-use-cases-00 (work in progress), September 2011. 5.2 Informative reference [I-D.stiemerling-cdni-routing-cons] Stiemerling, M., "Considerations on Request Routing for CDNI", draft-stiemerling-cdni- routing-cons-00, July 2011 [Stockhammer2011] T. Stockhammer, "Dynamic adaptive streaming over HTTP: standards and design principles", ACM Proceedings of the second annual ACM conference on Multimedia systems, 2011. [3GP-DASH] ETSI TS 126 247 v10.0.0 (2011-06) Universal Mobile Telecommunications System (UMTS); LTE; Transparent end-to- end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP- DASH) (3GPP TS 26.247 version 10.0.0 Release 10). FMN Expires April 26, 2012 [Page 13] Internet Draft draft-fmn-cdni-advanced-use-cases-00 October 2011 Authors' Addresses Yannick Le Louedec Orange Labs, France Email: yannick.lelouedec@orange.com Christian Timmerer UNI-KLU, Austria Email: christian.timmerer@itec.uni-klu.ac.at Spiros Spirou Intracom, Greece Email: spis@intracom.com David Griffin UCL, UK Email: dgriffin@ee.ucl.ac.uk Theodore Zahariadis Synelixis, Greece Email: zahariad@synelixis.com FMN Expires April 26, 2012 [Page 14]