Internet Engineering Task Force G. Bertrand Internet-Draft E. Stephan Intended status: Informational France Telecom - Orange Expires: August 1, 2011 G. Watson T. Burbridge P. Eardley BT January 28, 2011 Use Cases for Content Distribution Network Interconnection draft-bertrand-cdni-use-cases-01 Abstract Content Delivery Networks (CDNs) are commonly used for improving the footprint and the end-user experience of a content delivery service, at a reasonable cost. This document outlines real world use-cases (not technical solutions) for interconnecting CDNs. The intention is to motivate CDN Interconnection and to support the case for formation of a Working Group, which would work on the definition of standardized, inter-operable method(s) for interconnecting CDNs. 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 August 1, 2011. Copyright 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 Bertrand, et al. Expires August 1, 2011 [Page 1] Internet-Draft CDNI Use Cases January 2011 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. Bertrand, et al. Expires August 1, 2011 [Page 2] Internet-Draft CDNI Use Cases January 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 2. High Level Use Cases for Multi-CDN Systems . . . . . . . . . . 7 2.1. Footprint Extension Use Cases . . . . . . . . . . . . . . 8 2.1.1. Geographic Extension . . . . . . . . . . . . . . . . . 8 2.1.2. Country to Country Interconnection . . . . . . . . . . 8 2.1.3. Nomadic Users . . . . . . . . . . . . . . . . . . . . 8 2.1.4. Geo-blocking . . . . . . . . . . . . . . . . . . . . . 9 2.1.5. Device and Network Technology Extension . . . . . . . 9 2.2. Offload Use Cases . . . . . . . . . . . . . . . . . . . . 10 2.2.1. Overload Handling and Dimensioning . . . . . . . . . . 10 2.2.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Technology and Vendor Interoperability . . . . . . . . . . 12 2.4. QoE and QoS improvement . . . . . . . . . . . . . . . . . 12 2.4.1. NSP CDSP Use Case . . . . . . . . . . . . . . . . . . 12 3. Experiments with Existing CDN Solutions and Lessons Learned . 12 3.1. France Telecom-Orange Experiments . . . . . . . . . . . . 12 3.2. Gaps in Existing Solutions and Need for Specifications . . 14 4. Discussion on Priorities for the Proposed Charter . . . . . . 14 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. CDN Interconnection Patterns . . . . . . . . . . . . 16 A.1. Single CDN . . . . . . . . . . . . . . . . . . . . . . . . 16 A.2. Dual CDN with Direct Content Delivery . . . . . . . . . . 17 A.3. Intermediary CDN . . . . . . . . . . . . . . . . . . . . . 19 A.3.1. Option A - Recursive . . . . . . . . . . . . . . . . . 19 A.3.2. Option B - Iterative . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Bertrand, et al. Expires August 1, 2011 [Page 3] Internet-Draft CDNI Use Cases January 2011 1. Introduction This document now merges input from [I-D.watson-cdni-use-cases]. Content Delivery Networks (CDNs) are commonly used for improving the footprint and the end-user experience of a content delivery service, at a reasonable cost. This document outlines real world use-cases (not technical solutions) for interconnecting CDNs. The intention is to motivate CDN Interconnection and to support the case for formation of a Working Group, which would work on the definition of standardized, inter-operable method(s) for interconnecting CDNs. There are many possible combinations for the relationships between the different parties (Network Service Provider (NSP), Content Delivery Service Provider (CDSP), Content Service Provider (CSP), etc.) involved in end-to-end content delivery. However, in the context of interconnecting CDNs the key relationships are listed below. o How the CSP interacts with the CDN to publish and deliver content. o How the End User interacts with the interconnected CDNs to request and receive content. o How the different CDSPs, operating their CDNs, interact with one another to deliver the CSP's content to the End User. Section 2 describes a number of use cases that motivate CDN Interconnection. We also briefly describe some experiments with existing CDN solutions (Section 4). 1.1. Terminology Except for the terms defined below, we adopt the terminology described in [RFC3466], [RFC3568], and [RFC3570]. Problem statement draft [I-D.jenkins-cdni-problem-statement]defines a set of terms. Below we recall only the terms used in the memo. Content Service Provider (CSP): Provides Content Services to Users. A CSP may own the content made available as part of the Content Service, or may license content rights from another party. Content Service: The service offered by a CSP. The Content Service encompasses the Bertrand, et al. Expires August 1, 2011 [Page 4] Internet-Draft CDNI Use Cases January 2011 complete service which may be wider than just the delivery of items of Content, e.g. the Content Service also includes any middle-ware, key distribution, program guide, etc. which may not require any direct interaction with the CDN. Content Distribution Network (CDN) / Content Delivery Network (CDN): A type of network in which the components are arranged for more effective delivery of content to User Agents. Content Delivery Service Set of services offered to CSPs for delivering their contents through a single Content Delivery Network or interconnections of Content Delivery Networks. CDN Service Provider (CDSP): An administrative entity who operates a CDN over a NSP or over the Internet. Authoritative CDN (aCDN): The CDSP contracted by the CSP for delivery of content by this CDN or by its downstream CDNs. Downstream CDN (dCDN): A CDSP which is contracted by an aCDN to achieve the delivery of content to users. Access CDN A CDN that is connected to the end-user's access and has information about the end-user's profile and access capabilities. Delivering CDN The CDN that delivers the requested content asset to the end-user. In particular, the delivering CDN can be an access CDN. CDN Interconnection (CDNI): Relationship between two CDNs that enables a CDN to provide content delivery services on behalf of another CDN. It relies on a set of interfaces over which two CDNs communicate in order to achieve the delivery of content to end-users by one CDN (the downstream CDN) on behalf of another CDN (the upstream CDN). Bertrand, et al. Expires August 1, 2011 [Page 5] Internet-Draft CDNI Use Cases January 2011 CDN peering: A business relation between two CDSPs based on one or more CDN interconnections. Recursive request routing: Recursive: Where a process is repeated, but embedded within the original process. In the case of Request Routing, this means that the initial request received by the Authoritative CDN is processed downstream from one CDN to another and that the responses are send back upstream to the Authoritative CDN which then replies to the initial request. Iterative request routing Iterative: Where a process is repeated multiple times to make progress towards a goal. In the case of Request Routing, this means that the initial request is received by the Authoritative CDN, which replies it with a redirection directive to a dowstream CDN. When the end-user sends its request to the downstream CDN, the same process is repeated, until the request arrives to the delivering CDN. 1.2. Abbreviations [Ed. Note: List of abbreviations to be updated later and sorted alphabetically] o ISP o NSP o STB o PC o QoS o QoE o SLA o VoD o WiFi o 3G Bertrand, et al. Expires August 1, 2011 [Page 6] Internet-Draft CDNI Use Cases January 2011 2. High Level Use Cases for Multi-CDN Systems The prevalent use cases for CDNI are presented according to a CDSP's main motivation for interconnecting its CDN. They are classified according to their level of priority for the CDSP: o CDN Footprint Extension Use Cases o CDN Offload Use Cases o Technology and vendor interoperability o QoE and QoS improvement "CSPs have a desire to be able to get (some of their) content to very large number of users and/or over many/all geographies and/or with a high quality of experience, all without having to maintain direct business relationships with many different CDN providers" [draft-jenkins-cdni-problem-statement]. In order to minimize the number of direct business relationships between a CSP and a set of interconnected CDNs, it is assumed that a CSP will only be required/ desire to have a direct relationship with a single CDN, although relationships with more than one CDN are not precluded. A CDN selected by the CSP is referred to as an "Authoritative CDN" in this document. When receiving requests from User Agents, the Authoritative CDN will select an appropriate Surrogate in its own CDN or will decide to delegate the delivery to another CDN, to which a CDN interconnection can be established. The CDNI model enables Content Delivery Networks to collaborate, allowing Content Delivery Service Providers to offer consistent delivery services throughout the CDN Interconnection The CDNI model helps enables Content Delivery Networks that collaborate to provide Content Service Providers with delivery services throughout CDN Interconnections. Let's take an example. CDSP-A and CDSP-B respectively operate CDN-A and CDN-B. They establish a CDN peering for building the CDN interconnections from CDN-A to CDN-B and from CDN-B to CDN-A. The content service provider CSP-A reaches an agreement with CDSP-A. CDSP-A services rely on the CDN-A and on the interconnection from CDN-A to CDN-B. Meanwhile, the content service provider CSP-B reaches an agreement with CDSP-B. These services rely on the CDN-A and on the interconnection from CDN-A to CDN-B. [Ed. Note: Figure to be added to help the reader understand the Bertrand, et al. Expires August 1, 2011 [Page 7] Internet-Draft CDNI Use Cases January 2011 example] 2.1. Footprint Extension Use Cases Footprint extension is a major use case for CDN interconnection. 2.1.1. Geographic Extension In this use case, the CDSP is concerned with extending the geographic distribution that it can offer to the CSP without overly compromising the quality of delivery and without attracting transit and other network costs by serving from geographically or topologically remote surrogates. For example, several CDSPs have a geographically limited footprint (e.g., a country), or do not serve all end-users in a geographic area. Interconnecting CDNs enables CDSPs to provide their services beyond their own footprint by relying on other CDNs. As an example, a French CSP that distributes TV series wants to distribute them to end-users located in various countries in Europe and North Africa. It asks a French CDSP to deliver the series to several countries. The French CDSP makes an agreement with an external CDSP that covers North Africa , so that overall the French CDSP provides a CDN service for both France and North Africa. This use case applies to other types of contents such as automatic software updates (browser updates, operating system patches, or virus database update, etc). 2.1.2. Country to Country Interconnection There is a specific scenario where a large content delivery service provider (CDSP) operates the CDNs of a set of subsidiaries from different countries. These CDNs can rely on different CDN solutions. Such a situation may occur due to independent regional operations, or through mergers and acquisitions. In certain circumstances, the CDSP needs to make its CDNs interoperate to provide a consistent service to its customers on its whole footprint. [Ed. Note: FIGURE TO BE INCLUDED Figure 1 2.1.3. Nomadic Users Another scenario is nomadic situation. In this scenario a CSP wishes to allow users who move to other geographic regions to continue to access their content. The motivation in this case is to allow Bertrand, et al. Expires August 1, 2011 [Page 8] Internet-Draft CDNI Use Cases January 2011 nomadic users to maintain access, rather than to allow all residents within a region access to the content. 2.1.4. Geo-blocking Currently, the distribution of some content is restricted. For instance, distribution rights for audiovisual content are often negotiated per country. The selection of the Authoritative CDN is influenced by policies which may include "geo-blocking" rules that specify o the geographic regions where content can be delivered from (i.e. the location of the Surrogates), o geographic locations where content can be delivered to (i.e. the location of the End Users), o or quality of service policies specifying how the content is to be delivered. Hence, the exchange through the CDN interconnection of information for controlling the footprint of the delivery is an important use case. 2.1.5. Device and Network Technology Extension In this use case the CDSP may have the geographic and end-user coverage that it requires, but wishes to support the delivery of content to alternative end devices. These devices may sit on remote networks (such as smartphones connected to a mobile network) and may also require unique delivery capabilities in the CDN. In this case the CDSP may federate with another CDSP that offers service to these devices. As depicted in Figure 2, an end-user can use its tablet to download a VoD through WiFi (1) from CDN1 and then switch to 3G network (2), which is served by CDN2. The end user should be able to reach the selected VoD content through any access network technology. Consequently, every considered CDN must have access to this VoD content. One way to proceed consists in having an ingestion interface among the CDNs to access the content. Replication of the requested VoD content in the CDN serving the terminal (a) enables controlling the QoS (e.g. screen size, bitrate) of the VoD distribution to the terminal used by the end-user. In another situation, the serving of the VoD without replication (b) will save storage resources. The end-user's experience improves thanks to an increase of the number of situations where the end-user can access Bertrand, et al. Expires August 1, 2011 [Page 9] Internet-Draft CDNI Use Cases January 2011 the service. -------------- -------------- / CDN1 \ / CDN2 \ | Fixed | | Mobile | | ,---. | | ,---. | +---+ | . ) | (a) | . ) | |CSP|****| |`---'| |''''`---------.....>|`---'| | +---+ | | | -.. Acquisition | | | | | ( ) | `-.._ | ( ) | | `---' | `-.. | `---' | |,------------.| (b) ``-._ |,------------.| ||Delivery || `->. Delivery || \`------------'/ \`------------'/ ----------+--- -----*--+----- : * | : * | +........+ +--------+ : Tablet : (1) | Tablet |(2) +........+ +--------+ Figure 2: Fixed-Mobile CDN Inter-connection .: This use case is similar to use case in Section 2.3. 2.2. Offload Use Cases Offload is a major use case of CDN interconnection. 2.2.1. Overload Handling and Dimensioning The support of prime-time traffic load requires over-dimensioning the CDN capacity. In addition unexpected spikes in content popularity may drive load beyond the expected peak. As prime time and peaks of content distribution may differ between two CDNs, a CDN may interconnect with another CDN to increase its effective peak capacity. Similarly, two CDNs may benefit from dimensioning savings by using the resources of each other during their peaks of activity. The profile of activity peaks (time, duration ...) differ not only from a country to another but also according to the kind of CDNs. Therefore, CDN interconnect will be required since the additional capacity is likely to be provided by alternative technology. Offload also applies to planned situation where a CDSP needs CDN capacities in a particular region during a short period of time. For Bertrand, et al. Expires August 1, 2011 [Page 10] Internet-Draft CDNI Use Cases January 2011 example, during a specific maintenance operation or for covering the distribution of a special event, such as an international sport competition. 2.2.2. Resiliency It is important for CDNs to be able to guarantee service continuity during partial failures (e.g., failure of a set of surrogates). In partial failure scenarios, a CDSP could redirect some requests toward another CDN. This downstream CDN must be able to serve the redirected requests or, depending on traffic management policies, to forward these requests to the CSP origin server. Resiliency may also be required against failure to ingest content from the CSP. In these cases the content may be available from another CDSP. -------------- -------------- / CDN1 \ / CDN2 \ | ,---. | | ,---. | +---+ | . ) | | . ) | |CSP|*******| |`---'| |__________________| |`---'| | +---+ | | | | Acquisition | | | | | ( ) | | ( ) | | `---' | | `---' | |+-----------+ | |,------------.| ||Req-Routing| | .|Delivery || \+-----------+ / \`------------'/ ------------ .-'----------- | .-' | --------------- > .-' | Redirect .-' | .-' | .-' | .-' | .-' | .-' +-----+ | User| +-----+ Figure 3: Example of CDN Interconnection for failure resiliency Bertrand, et al. Expires August 1, 2011 [Page 11] Internet-Draft CDNI Use Cases January 2011 2.3. Technology and Vendor Interoperability ISPs have deployed platforms per service or per network technology. They are deploying CDNs or enhancing existing platforms to CDN. It is desirable in certain circumstances to share the content or the resources among these internal CDNs. A CDSP may wish to operate a multi-vendor strategy for its CDN. Currently, operating a single controller for such multi-vendor CDNs is problematic. This problem can be alleviated by a CDN interconnection that allows the automation of some operations among these CDNs. 2.4. QoE and QoS improvement Some existing CDNs make the decision to work with ISPs to deploy surrogates closer to the end users. Compared to alternatives such as adding capacity at major peering points, this method offers better experience to the end users. Some CSPs are willing to pay a premium for such enhanced service rather than just using the CDSP to mitigate their server and network access costs. Improved experience may be provided by closer proximity to the end users. It could also involve network characteristics, such as provisioning or QoS, and specific delivery techniques such as encoding for constant Quality of Experience. 2.4.1. NSP CDSP Use Case In a interconnection use case, CDSP-A is likely to offer an SLA to the CSP including performance or other quality metrics. If it cannot meet the SLA it will push content via the interconnection to a CDSP-B with CDN capabilities that are in a position to guaranty the SLA, and redirect users appropriately to CDSP-B. CDSP-A may not be able to, or may not wish to deploy its own CDN capabilities to meet the SLA requirements for only a subset of its CSP customers. The ability to offer stringent delivery quality SLAs is a differentiator against other CDSPs and can be sold as a premium service. Although this use case has similarities to extending geographic reach, in this case it is expected that the CDSP does have a CDN deployed which could effectively serve content to the end-users, but wishes to increase experience for specific CSPs. 3. Experiments with Existing CDN Solutions and Lessons Learned 3.1. France Telecom-Orange Experiments As depicted in Figure 1, we have interconnected two CDNs (CDN A and CDN B) operated by different subsidiaries of a large CDSP. The CDNs Bertrand, et al. Expires August 1, 2011 [Page 12] Internet-Draft CDNI Use Cases January 2011 cover two different countries, henceforth referred to as Country A and Country B and they rely on CDN solutions from two different equipment vendors (Vendor A and Vendor B). The CDNI experiment supported the services of two CSPs (CSP A and CSP B). +-------+ : +-------+ | CSP A | : | CSP B | +------- : +------- | : | ,--,--,--. : ,--,--,--. ,-' CDN A `-. : ,-' CDN B `-. ( (Vendor A) )==:==( (Vendor B) ) `-. ,-' : `-. ,-' `--'--'--' : `--'--'--' : COUNTRY A : COUNTRY B === CDN Interconnect Experiment configuration Figure 1 We have run several experiments in the configuration represented in Figure 2. In these experiments, CSP A has an agreement with CDSP A for content delivery to end-users located in Country A and Country B. However, CDSP A operates a CDN (CDN A), whose footprint does not include country B. Therefore, CDSP A has an agreement with CDSP B, so that CDN A can delegate to CDN B the delivery of some content. More specifically, CDN A is allowed to delegate to CDN B the handling of requests sent by end-users located in Country B for CSP A's content. When CDN A receives a content request related to CSP A and from an end-user in Country B, it redirects the end-user to the appropriate content on CDN B. If CDN B does not have a local copy of the requested content yet (cache miss), CDN B ingests the content from CDN A (or from the CSP's origin servers, depending on the test scenario); if CDN A also does not have a local copy of the requested content, it requests this asset from the CSP's origin servers before sending the asset to CDN B. Bertrand, et al. Expires August 1, 2011 [Page 13] Internet-Draft CDNI Use Cases January 2011 +-------+ : | CSP A | : +-------+ : | : ,--,--,--. : ,--,--,--. ,-' CDN A `-. : ,-' CDN B `-. ( (Vendor A) )==:==( (Vendor B) ) `-. CDSP A ,-' : `-. CDSP B ,-' `--'--'--' : `--'--'--' : | : +------+ : | EU B | : +------+ : COUNTRY A : COUNTRY B === CDN Interconnect Test scenario with heterogeneous solutions Figure 2 3.2. Gaps in Existing Solutions and Need for Specifications Our experiments have shown that the current CDN technologies suffer from the following limitations. o The content management policies must be defined manually, so that the end-user's request triggers content delivery from the most appropriate CDN (e.g., a CDN in the country of the end-user, or a CDN that serves the type of files requested by the end-user). o The target URLs for the request redirection must also be defined manually, so that the authoritative CDN provides to the end-user a valid URI on the downstream CDN. o The content ingestion from an upstream CDN worked only in pull mode. To address more sophisticated scenarios, we consider that common interfaces are required for request routing among interconnected CDNs and for the exchange of content distribution metadata. 4. Discussion on Priorities for the Proposed Charter This section will be worked out later according to the discussions on Bertrand, et al. Expires August 1, 2011 [Page 14] Internet-Draft CDNI Use Cases January 2011 the mailing list. 5. Acknowledgments The authors would like to thank Francois Le Faucheur and Ben Niven- Jenkins for lively discussions. They also thank the contributors of the EU FP7 OCEAN and ETICS projects for valuable inputs. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations CDN interconnect, as described in this document, has a wide variety of security issues that should be considered. For example, every interconnected CDN should be able to assess if it must serve a delegated request or if this request is delegated by a non-allowed CDN. The CDNs should also be protected so as to avoid being overwhelmed by delegated requests. This document focuses on the motivational use cases for CDN interconnect, and therefore, does not analyze the threats in detail. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.jenkins-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", draft-jenkins-cdni-problem-statement-01 (work in progress), January 2011. [I-D.lefaucheur-cdni-requirements] Faucheur, F., Viveganandhan, M., Watson, G., and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-lefaucheur-cdni-requirements-00 (work Bertrand, et al. Expires August 1, 2011 [Page 15] Internet-Draft CDNI Use Cases January 2011 in progress), January 2011. [I-D.watson-cdni-use-cases] Watson, G., "CDN Interconnect Use Cases", draft-watson-cdni-use-cases-00 (work in progress), January 2011. [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003. [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known Content Network (CN) Request-Routing Mechanisms", RFC 3568, July 2003. [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003. Appendix A. CDN Interconnection Patterns In this section we attempt to pull out the generic CDN interconnection patterns that may result from the use cases detailed previously. We find little difference between the use cases in the generic interconnection patterns that occur, and these are presented below. However, differences do occur due to the the business concerns of the different parties operating the components in each use case. This will result in different technical requirements at a more detailed level (for example in reporting and accounting mechanisms). A.1. Single CDN This section outlines an illustrative model for content delivery via a single CDN where there is no interconnection with other CDNs. It does not describe all the details and variations but rather the high level interactions between the different Actors (CSP, CDN, End User) which can be used as a point of comparison with the CDN Interconnection patterns described in subsequent sections. Bertrand, et al. Expires August 1, 2011 [Page 16] Internet-Draft CDNI Use Cases January 2011 +-------+ | CSP-1 | +-------+ | ,---------. ,-' `-. ( CDN-A ) `-. ,-' `---------' | ,---------. ,-' 0 or `-. ( more other ) `-. networks ,-' / `---------' \ / \ ,---------. ,---------. ,-' `-. ,-' `-. ( NSP-X ) ( NSP-Y ) `-. ,-' `-. ,-' `---------' `---------' | | +-------+ +-------+ | UA-X | | UA-Y | +-------+ +-------+ A.2. Dual CDN with Direct Content Delivery Taking the above use cases into account the base pattern for CDN Interconnection is shown in the diagram below. To simplify the diagram the cloud showing "zero or more other networks" has been excluded and NSPs are shown as though they are directly attached to CDNs. This is not intended to imply any direct relationships or to exclude the case where one or more networks may exist between the NSP illustrated and the CDN. Bertrand, et al. Expires August 1, 2011 [Page 17] Internet-Draft CDNI Use Cases January 2011 +-------+ | CSP-1 | +-------+ | ,---------. ,---------. ,-' `-. ,-' `-. ( CDN-A )==I==( CDN-B ) `-. ,-' /`-. ,-' `---------' / `---------' | ___/ | | / | ,---------. / ,---------. ,-' `-. ,-' `-. ( NSP-X ) ( NSP-Y ) `-. ,-' `-. ,-' `---------' `---------' | | +-------+ +-------+ | UA-X | | UA-Y | +-------+ +-------+ ==I== CDN Intercon As shown in the diagram CSP-1 maintains a direct relationship with CDN-A and so CDN-A is the Authoritative CDN for CSP-1. CDN-A maintains a CDN Interconnect with CDN-B. CDN-A may decide to delegate to CDN-B the delivery of contentto a UA/NSP. How CDN-A makes such a decision is out of scope for this document, although the motivations for doing so are captured in the above use cases. Let us assume that an End User, at User Agent Y, wishes to use CSP-1's service and that CDN-A decides to delegate the delivery of the content to CDN-B and that CDN-B is willing to perform the delegated delivery. In order for EU-Y to receive content the following illustrative interactions occur: 1. UA-Y selects a piece of content (as directed by EU-Y) from CSP-1's service. 2. CSP-1 returns a URL, URL-A, for the selected content which resolve to the Request Router in CDN-A, the Authoritative CDN for CSP-1. 3. CDN-A's Request Router makes a decision to delegate the delivery to CDN-B. 4. CDN-A makes a request to CDN-B to deliver the content on behalf of CDN-A and CDN-B responds with details of how CDN-A's Request Router should respond to the request. Bertrand, et al. Expires August 1, 2011 [Page 18] Internet-Draft CDNI Use Cases January 2011 5. CDN-A's Request Router returns the appropriate response to UA-Y or another device acting on its behalf (such as a DNS resolver). 6. UA-Y will connect to CDN-B and request the content. At this point there are several possible variations: a. The content request is directed to the Request Router of CDN-B. In this manner the UA can be iteratively passed between CDNs. The Request Router of CDN-B may identify a surrogate in CDN-B, or may identify another CDN (as elaborated in the Intermediary Pattern below). b. The content request is directed to a surrogate in CDN-B. 7. UA-Y receives the content from the surrogate in CDN-B. Again there are a couple of options: a. The content already exists in the chosen surrogate and is delivered to the UA. b. The content is not stored within the chosen surrogate and is dynamically transferred to the surrogate and sequentially delivered to the UA. 8. CDN-B may link the content to URL-B. In this manner another service may use URL-B to preferentially serve the content from CDN-B directly rather than being directed through CDN-A. A.3. Intermediary CDN This use case extends the dual CDN pattern by allowing CDN-B to accept a delegated content delivery from CDN-A and then delegate the delivery to CDN-C. There are a couple of options for this pattern. A.3.1. Option A - Recursive Steps 1 to 3 proceed as for the dual CDN pattern. 4. CDN-A makes a request to CDN-B to deliver the content on behalf of CDN-A. CDN-B instead decides to delegate this request to CDN-C, as permiited by its CDN peering agreement with CDN-A. Thus, the Request Router of CDN-B refers the request to the Request Router of CDN-C. CDN-C responds to CDN-B and in turn CDN-A's Request Router with details of how to respond to UA-Y Steps 5 to 8 proceed as for the dual CDN pattern with the exception that CDN-B is replaced by CDN-C. Bertrand, et al. Expires August 1, 2011 [Page 19] Internet-Draft CDNI Use Cases January 2011 A.3.2. Option B - Iterative Steps 1 to 5 proceed as for the dual CDN pattern. 6. UA-Y will connect to CDN-B and request the content. The content request is directed to the Request Router of CDN-B. The Request Router of CDN-B identifies that the request should be serviced by CDN-C. The pattern then proceeds from step 4 of the dual CDN pattern with CDN-A replaced by CDN-B and CDN-B replaced by CDN-C. +-------+ | CSP-1 | +-------+ | ,---------. ,---------. ,---------. ,-' `-. ,-' `-. ,-' `-. ( CDN-A )====( CDN-B )====( CDN-C ) `-. ,-' `-. ,-' `-. ,-' `---------' `---------' `---------' | | ,---------. ,-' `-. ( NSP-Z ) `-. ,-' `---------' | +-------+ | UA-Z | +-------+ ==== CDN Interconnect Bertrand, et al. Expires August 1, 2011 [Page 20] Internet-Draft CDNI Use Cases January 2011 Authors' Addresses Gilles Bertrand France Telecom - Orange 38-40 rue du General Leclerc Issy les moulineaux, 92130 FR Phone: +33 1 45 29 89 46 Email: gilles.bertrand@orange-ftgroup.com Stephan Emile France Telecom - Orange 2 avenue Pierre Marzin Lannion F-22307 France Email: emile.stephan@orange-ftgroup.com Grant Watson BT pp GDC 1 PP14, Orion Building, Adastral Park, Martlesham Ipswich, IP5 3RE UK Email: grant.watson@bt.com Trevor Burbridge BT B54 Room 70, Adastral Park, Martlesham Ipswich, IP5 3RE UK Email: trevor.burbridge@bt.com Philip Eardley BT B54 Room 77, Adastral Park, Martlesham Ipswich, IP5 3RE UK Email: philip.eardley@bt.com Bertrand, et al. Expires August 1, 2011 [Page 21]