--- 1/draft-ietf-cdni-use-cases-00.txt 2011-12-21 12:13:58.082670609 +0100 +++ 2/draft-ietf-cdni-use-cases-01.txt 2011-12-21 12:13:58.122671200 +0100 @@ -1,57 +1,54 @@ Internet Engineering Task Force G. Bertrand, Ed. Internet-Draft E. Stephan Intended status: Informational France Telecom - Orange -Expires: March 25, 2012 G. Watson +Expires: June 23, 2012 G. Watson T. Burbridge P. Eardley BT K. Ma Azuki Systems - September 22, 2011 + December 21, 2011 Use Cases for Content Delivery Network Interconnection - draft-ietf-cdni-use-cases-00 + draft-ietf-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. It can be used - to provide guidance to the CDNI WG about the interconnection - arrangements to be supported and to validate the requirements of the - various CDNI interfaces. - - This document describes a number of use cases that motivate CDN - Interconnection. It represents a work in progress and may be - extended later to cover additional use-cases. + 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. It can be used to provide + guidance to the CDNI WG about the interconnection arrangements to be + supported and to validate the requirements of the various CDNI + interfaces. 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 March 25, 2012. + This Internet-Draft will expire on June 23, 2012. 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 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 @@ -67,243 +64,232 @@ 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 + 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5 - 1.4. The Need for CDNI Standards . . . . . . . . . . . . . . . 7 + 1.4. The Need for CDN Interconnection Standards . . . . . . . . 6 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 8 - 2.3. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8 - 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 8 - 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.2.1. Failure of Content Delivery Resources . . . . . . . . 9 - 3.2.2. Failure of Content Acquisition . . . . . . . . . . . . 9 - 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 9 - 4.1. Device and Network Technology Extension . . . . . . . . . 10 - 4.2. Technology and Vendor Interoperability . . . . . . . . . . 10 - 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 11 - 5. Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1. Content Availability . . . . . . . . . . . . . . . . . . . 11 - 5.1.1. Geo-location Restrictions . . . . . . . . . . . . . . 11 - 5.1.2. Temporal Restrictions . . . . . . . . . . . . . . . . 12 - 5.1.3. Content Encoding Restrictions . . . . . . . . . . . . 12 + 2.3. Mastering Incoming Traffic . . . . . . . . . . . . . . . . 8 + 2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8 + 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 10 + 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2.1. Failure of Content Delivery Resources . . . . . . . . 10 + 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10 + 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11 + 4.1. Device and Network Technology Extension . . . . . . . . . 11 + 4.2. Technology and Vendor Interoperability . . . . . . . . . . 12 + 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12 + 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 13 + 5.1. Content Availability . . . . . . . . . . . . . . . . . . . 13 5.2. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.3. Secure Access . . . . . . . . . . . . . . . . . . . . . . 13 - 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 + 5.3. Secure Access . . . . . . . . . . . . . . . . . . . . . . 14 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction 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. It can be used - to provide guidance to the CDNI WG about the interconnection - arrangements to be supported and to validate the requirements of the - various CDNI interfaces. - - This document describes a number of use cases that motivate CDN - Interconnection. It represents a work in progress and may be - extended later to cover additional use-cases. + 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. It can be used to provide + guidance to the CDNI WG about the interconnection arrangements to be + supported and to validate the requirements of the various CDNI + interfaces. This document identifies the main motivations for a CDN Provider to interconnect its CDN: o CDN Footprint Extension Use Cases (Section 2) o CDN Offload Use Cases (Section 3) o CDN Capability Use Cases (Section 4) Then, the document highlights the need for interoperability to exchange and enforce content delivery policies (Section 5). 1.1. Terminology We adopt the terminology described in - [I-D.ietf-cdni-problem-statement], [RFC3466], and [RFC3568], except - for the terms defined below. - - Authoritative CDN (aCDN): - - A CDN provider contracted by the CSP for delivery of content by its - CDN or by its downstream CDNs. + [I-D.ietf-cdni-problem-statement], [I-D.davie-cdni-framework], + [RFC3466], and [RFC3568]. 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. + A CDN that is directly connected to the End User's access. An Access + CDN may have specific information about the End User and the network, + for instance, 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. - - [Ed. Note: Definition of recursive and iterative request routing - should be added to [I-D.davie-cdni-framework].] - - CDN Interconnection: - - 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). - - CDN peering: A business relation between two CDN providers based on - one or more CDN Interconnections. + The CDN that delivers the requested piece of content to the End User. + In particular, the delivering CDN can be an Access CDN. 1.2. Abbreviations - [Ed. Note: List of abbreviations to be updated later] + o CDN: Content Delivery Network also known as Content Distribution + Network o CSP: Content Service Provider o dCDN: downstream CDN + o DNS: Domain Name System + + o DRM: Digital Rights Management + + o EU: End User + + o ISP: Internet Service Provider o NSP: Network Service Provider o QoE: Quality of Experience o QoS: Quality of Service - o SLA: Service Level Agreement - o uCDN: upstream CDN - o UA: User Agent - - o UE: User Equipment - - o VoD: Video on Demand + o URL: Uniform Resource Locator o WiFi: Wireless Fidelity 1.3. Rationale for Multi-CDN Systems Content Delivery Networks (CDNs) are used to deliver content because they can: o improve the experience for the End User; for instance delivery has - lower latency and better robustness, + lower latency (decreased round-trip-time between the user and the + delivery server) and better robustness, - o reduce the operator's costs; for instance lower delivery cost - (reduced bandwidth usage) for cacheable content, + o reduce the network operator's costs; for instance, lower delivery + cost (reduced bandwidth usage) for cacheable content, - o reduce the Content Service Provider costs, such as datacenter - capacity, space, and electricity consumption. + o reduce the Content Service Provider's (CSP) costs, such as + datacenter capacity, space, and electricity consumption, as + popular content is delivered through the CDN rather than through + the CSP's servers. - Indeed, many network service providers and enterprise service + Indeed, many Network Service Providers (NSPs) and enterprise service providers are deploying or have deployed their own CDNs. Despite the potential benefits of interconnecting CDNs, today each CDN is a - standalone network. The objective of CDN interconnection is to + standalone network. The objective of CDN Interconnection is to overcome this restriction: the interconnected CDNs should be able to collectively behave as a single delivery infrastructure. - Let's take an example, as depicted in Figure 1. Two CDN Providers - establish a CDN Interconnection. The Content Service Provider CSP-1 - reaches an agreement with CDN Provider A for the delivery of its - content. CDN Provider A and CDN Provider B agree to interconnect - their CDNs. When a User Agent that is connected to CDN Provider B's - network requests Content from CSP-1, the Content is actually - delivered from CDN-B, because handling of requests for CSP-1's - Content has been delegated as part of the CDN Interconnection - agreement. The End User benefits through a better quality of - experience, because the Content is delivered from a nearby Surrogate. - CDN Provider A benefits because it doesn't need to deploy such an - extensive CDN, whilst CDN Provider B receives some compensation for - the delivery. CSP-1 benefits because it only needs to make one - business agreement and one physical connection, with CDN Provider A, - but its End Users get a service quality as though CSP-1 had also gone - to the trouble of making a business agreement with CDN Provider B. + An example is depicted in Figure 1. Two CDN Providers establish a + CDN Interconnection. The Content Service Provider CSP-1 reaches an + agreement with CDN Provider 'A' for the delivery of its content. CDN + Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs. + + When a User Agent requests content from CSP-1, CDN-A considers that + delivery by CDN-B is appropriate, for instance, because CDN-B is an + Access CDN and the user is directly attached to it. CDN-A has + delegated the handling of requests for CSP-1's content through the + CDN Interconnection agreement, thus, the content is actually + delivered from CDN-B. + + The End User benefits from this arrangement through a better Quality + of Experience (QoE), because the content is delivered from a nearby + Surrogate. CDN Provider 'A' benefits because it does not need to + deploy such an extensive CDN, whilst CDN Provider 'B' may receive + some compensation for the delivery. CSP-1 benefits because it only + needs to make one business agreement and one physical connection, + with CDN Provider 'A', but its End Users get a service quality as + though CSP-1 had also gone to the trouble of making a business + agreement with CDN Provider 'B'. +-------+ +-------+ | CSP-1 | | CSP-2 | +-------+ +-------+ | | - ,--,--,--. ,--,--,--. + ,--,--,--./ ,--,--,--. ,-' `-. ,-' `-. - ( CDN Provider A )=====( CDN Provider B ) + (CDN Provider 'A')=====(CDN Provider 'B') `-. (CDN-A) ,-' `-. (CDN-B) ,-' `--'--'--' `--'--'--' | +------------+ | User Agent | +------------+ === CDN Interconnection Figure 1 - To extend the example, another Content Service Provider, CSP-3, may - also reach an agreement with CDN Provider A. But it does not want its - Content to be distributed by CDN Provider B, for example, CSP-3 may - not have distribution rights in the country where CDN Provider B - operates. This example illustrates that policy considerations are an - important part of CDNI. + To extend the example, another Content Service Provider, CSP-2, may + also reach an agreement with CDN Provider 'A'. But it does not want + its content to be distributed by CDN Provider B; for example, CSP-2 + may not have distribution rights in the country where CDN Provider + 'B' operates. This example illustrates that policy considerations + are an important part of CDNI. -1.4. The Need for CDNI Standards +1.4. The Need for CDN Interconnection Standards + + The problem statement draft [I-D.ietf-cdni-problem-statement] + describes extensively the CDNI problem space and explains why CDNI + standards are required. Existing CDN interfaces are proprietary and have often been designed - for intra-CDN/intra-domain operations. So an external CDN typically - cannot use them, especially if the two CDNs rely on different - implementations. Nevertheless, [I-D.bertrand-cdni-experiments] shows - that some level of CDN interconnection can be achieved experimentally - without standardized interfaces between the CDNs. However, the - methods used in these experiments are hardly usable in an operational - context, because they suffer from several limitations in terms of - functionalities, scalability, and security level. + for intra-CDN/intra-domain operations. Consequently, an external CDN + typically cannot use these interfaces, especially if the two CDNs to + be interconnected rely on different implementations. Nevertheless, + [I-D.bertrand-cdni-experiments] shows that some level of CDN + Interconnection can be achieved experimentally without standardized + interfaces between the CDNs. However, the methods used in these + experiments are hardly usable in an operational context, because they + suffer from several limitations in terms of functionalities, + scalability, and security level. - The aim of IETF CDNI WG's solution is therefore to overcome such + The aim of IETF CDNI WG's solution is, therefore, to overcome such shortcomings; a full list of requirements is being developed in [I-D.ietf-cdni-requirements]. 2. Footprint Extension Use Cases - Footprint extension is expected to be a major use case for CDN - interconnection. + Footprint extension is expected to be the major use case for CDN + Interconnection. 2.1. Geographic Extension In this use case, the CDN Provider wants to extend the geographic distribution that it can offer to its CSPs: o without compromising the quality of delivery, o without incurring additional transit and other network costs that would result from serving content from geographically or - topologically remote surrogates. + topologically remote Surrogates. If there are several CDN Providers that have a geographically limited - footprint (e.g., restricted to one country), or do not serve all end- - users in a geographic area, then interconnecting their CDNs enables - CDN Providers to provide their services beyond their own footprint. + footprint (e.g., restricted to one country), or do not serve all End + Users in a geographic area, then interconnecting their CDNs enables + these CDN Providers to provide their services beyond their own + footprint. As an example, suppose a French CSP wants to distribute its TV programs to End Users located in France and various countries in North Africa. It asks a French CDN Provider to deliver the content. - The French CDN Provider's network only covers France, so it makes an agreement with another CDN Provider that covers North Africa. Overall, from the CSP's perspective the French CDN Provider provides a CDN service for both France and North Africa. In addition to video, this use case applies to other types of content such as automatic software updates (browser updates, operating system patches, virus database update, etc). 2.2. Inter-Affiliates Interconnection @@ -307,298 +293,357 @@ patches, virus database update, etc). 2.2. Inter-Affiliates Interconnection In the previous section, we have described the case of geographic extension between CDNs operated by different entities. A large CDN Provider may also operate CDNs from several subsidiaries (which may rely on different CDN solutions, see Section 4.2). In certain circumstances, the CDN Provider needs to make its CDNs interoperate to provide a consistent service to its customers on its whole - footprint. + footprint. For example, the CDN Provider might want to expose a + single set of interfaces to the CSPs. -2.3. Nomadic Users +2.3. Mastering Incoming Traffic - 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 nomadic users to maintain access - with consistent quality of experience, rather than to allow all - residents within a region access to the content. + Consider an ISP carrying to its subscribers a lot of content that + comes from a third party CSP and that is injected into the access + network by an Authoritative CDN Provider. There are mutual benefits + to the Access CDN, the Authoritative CDN, and the CSP that would make + a case for establishing a CDNI agreement. For example: - [Ed. Note: expand on which CDNs need to be interconnected to address - the use case (ie with CDN of "home NSP" interconnected to CDN of - visited NSP). Add a picture for clarifying the text. Use the term - "TV everywhere"?] + o Allow the CSP to offer improved QoE and QoE services to + subscribers, for example, QoS and reduced round trip time. - This use case covers situations like users moving between different - CDN Providers within the same geographic region, or users switching - between different devices, as discussed in Section 4. + o Allow the Authoritative CDN to reduce hardware capacity and + footprint, by using the ISP caching and delivery capacity. + + o Allow the ISP to reduce traffic load on some segments of the + network by caching inside of the ISP network. + + o Allow the ISP to influence and/or control the traffic ingestion + points. + + o Allow the ISP to derive some incremental revenue for transport of + the traffic and to monetize QoE services. + +2.4. Nomadic Users + + In this scenario, a CSP wishes to allow End Users who move between + CDNs to continue to access their content. The motivation of this + case is to allow nomadic End Users to maintain access to content with + a consistent QoE, across a range of devices and/or geographic + regions. + + This use case covers situations like: + + o End Users moving between different CDN Providers, which may reside + within the same geographic region or different geographic regions, + + o End Users switching between different devices or delivery + technologies, as discussed in Section 4. + + The term "Nomadic" does not necessarily relate to geographic roaming. + + Consider the following example, illustrated in Figure 2: End User A + has subscription to a broadband service from NSP A, her "home NSP". + NSP A hosts CDN-A. Ordinarily, when End User A accesses content via + NSP A (her "home NSP") the content is delivered from CDN-A, which in + this example is within NSP A's network. + + However, while End User A is not connected to NSP A's network, for + example, because it is connected to a WiFi provider or mobile + network, End User A can also access the same content. In this case, + End User A may benefit from accessing the same content but delivered + by an alternate CDN (CDN-B), in this case, hosted in the network of + the WiFi or mobile provider, rather than from CDN-A in NSP A's + network. + + +-------+ + |Content| + +-------+ + | + ,--,--,--. ,--,--,--. + ,-' NSP A `-. ,-' NSP B `-. + ( (CDN-A) )=====( (CDN-B) ) + `-. ,-' `-. ,-' + `--'--'--' `--'--'--' + | | + +------------+ +---------------+ + + EU A (home)| | EU A (nomadic)| + +------------+ +---------------+ + === CDN Interconnection + + Figure 2 + + The alternate CDN (CDN-B) is allowed to distribute the content of CSP + A to End User A; however, no other End Users in the region of CDN B + are allowed to retrieve the content unless they too have such an + agreement for nomadic access to content. + + Depending on CSP's content delivery policies (see Section 5.1), a + user moving to a different geographic region may be subject to geo- + blocking content delivery restrictions. In this case, he/she may not + be allowed to access some pieces of content. 3. Offload Use Cases 3.1. Overload Handling and Dimensioning - A CDN is likely to be dimensioned to support the prime-time traffic. - However, unexpected spikes in content popularity may drive load - beyond the expected peak. The prime recurrent time peaks of content - distribution may differ between two CDNs. Taking advantage of the - different traffic peak times, a CDN may interconnect with another CDN - to increase its effective capacity during the peak of traffic. This - brings dimensioning savings to the CDNs as they can use the resources - of each other during their respective peaks of activity.. + A CDN is likely to be dimensioned to support an expected maximum + traffic load. However, unexpected spikes in content popularity + (flash crowd) may drive load beyond the expected peak. The prime + recurrent time peaks of content distribution may differ between two + CDNs. Taking advantage of the different traffic peak times, a CDN + may interconnect with another CDN to increase its effective capacity + during the peak of traffic. This brings dimensioning savings to the + CDNs as they can use the resources of each other during their + respective peaks of activity. Offload also applies to planned situations where a CDN Provider needs CDN capacities in a particular region during a short period of time. For example, a CDN can offload traffic to another CDN during a specific maintenance operation or for covering the distribution of a special event. For instance, consider a TV-channel which has exclusive distribution rights on a major event, such as a - celebrities' wedding, or a major sport competitions. The CDNs that + celebrities' wedding, or a major sport competition. The CDNs that the TV-channel uses for delivering the content related to this event are likely to experience a flash crowd during the event and to need offloading traffic, while other CDNs will support a more usual - traffic load and be able to handle the offloaded traffic load. + traffic load and be able to handle the offloaded traffic. + + In this use case, the Delivering CDN on which requests are offloaded + should be able to handle the offloaded requests. Therefore, the uCDN + might require information on the dCDNs to be aware of the amount of + traffic it can offload to every dCDN. 3.2. Resiliency 3.2.1. Failure of Content Delivery Resources It is important for CDNs to be able to guarantee service continuity during partial failures (e.g., failure of some Surrogates). In - partial failure scenarios, a CDN Provider could redirect some - requests towards another CDN, which must be able to serve the - redirected requests or, depending on traffic management policies, to - forward these requests to the CSP's origin server. + partial failure scenarios, a CDN Provider has at least two options: + (1) depending on traffic management policies, forward some requests + to the CSP's origin servers, and (2) redirect some requests toward + another CDN, which must be able to serve the redirected requests. -3.2.2. Failure of Content Acquisition +3.2.2. Content Acquisition Resiliency - Source content acquisition is typically handled in one of two ways: + Source content acquisition may be handled in one of two ways: - o CDN origin, where a downstream CDN acquires content from an - upstream CDN, and the authoritative CDN acquires content from an - origin server of the CSP, or + o CSP origin, where a CDN acquires content directly from the CSP's + origin server, or - o Other origin, where the CDNs acquire content directly from an - origin server outside the uCDN. + o CDN origin, where a downstream CDN acquires content from a + Surrogate within an upstream CDN. - Resiliency may be required against failure to ingest content. If a - CDN is unable to retrieve the content, it may be that the CSP's - origin server is inaccessible to only this CDN, in which case - redirection of the end-users to an alternative CDN may circumvent the - problem. A CSP may also choose to specify one or more backup origin - servers. + The ability to support content acquisition resiliency, is an + important use case for interconnected CDNs. When the content + acquisition source fails, the CDN might switch to another content + acquisition source. Similarly, when several content acquisition + sources are available, a CDN might balance the load between these + multiple sources. + + Though other server and/or DNS load balancing techniques may be + employed in the network, interconnected CDNs may have a better + understanding of origin server availability and be better equipped to + both distribute load between origin servers and attempt content + acquisition from alternate origin servers when acquisition failures + occur. When normal content acquisition fails, a CDN may need to try + other origin server options, e.g.: + + o an upstream CDN may acquire content from an alternate CSP origin + server, + + o a downstream CDN may acquire content from an alternate Surrogate + within an upstream CDN, as directed by the upstream CDN's request + routing interface, + + o a downstream CDN may acquire content from an alternate upstream + CDN, or + + o a downstream CDN may acquire content directly from the CSP's + origin server. + + Though content acquisition protocols are beyond the scope of CDNI, + the selection of content acquisition sources should be considered. 4. CDN Capability Use Cases + 4.1. Device and Network Technology Extension In this use case, the CDN Provider may have the right geographic footprint, but may wish to extend the supported range of devices and - User Agents or the range of supported delivery technologies. In this + User Agents or the supported range of delivery technologies. In this case, a CDN Provider may interconnect with a CDN that offers services: - o that its own CDN is not able to support or, - - o that the CDN provider is not willing to provide. + o that the CDN Provider is not willing to provide or, + o that its own CDN is not able to support The following examples illustrate this use case: 1. CDN-A cannot support a specific delivery protocol. For instance, CDN-A may interconnect with CDN-B to serve a proportion of its traffic that requires HTTPS. CDN-A may use CDN-B's footprint (which may overlap with its own) to deliver HTTPS without needing to deploy its own infrastructure. This case could also be true of other formats, delivery protocols (RTMP, RTSP, etc.) and - features (specific forms of tokenization, per session encryption, - etc.). + features (specific forms of authorization such as tokens, per + session encryption, etc.). 2. CDN-A has footprint covering traditional fixed line broadband and wants to extend coverage to mobile devices. In this case, CDN-A may contract and interconnect with CDN-B who has both: * physical footprint inside the mobile network, * the ability to deliver content over a protocol that is - required by specific mobile devices and not supported by - CDN-A. - - In this case also it may be that CDN-B provides other features - related to adapting the content. + required by specific mobile devices. - These cases can apply to many CDN features that a given CDN provider + These cases can apply to many CDN features that a given CDN Provider may not be able to support or not be willing to invest in, and thus, - that the CDN provider would delegate to another CDN. + that the CDN Provider would delegate to another CDN. 4.2. Technology and Vendor Interoperability A CDN Provider may deploy a new CDN to run alongside its existing CDN, as a simple way of migrating its CDN service to a new - technology. A CDN Provider may have a multi-vendor strategy for its - CDN deployment. A CDN Provider may want to deploy a separate CDN for - a particular CSP or a specific network. In all these circumstances, - CDNI benefits the CDN Provider, as it simplifies or automates some - inter-CDN operations (e.g., migrating the request routing function - progressively). + technology. In addition, a CDN Provider may have a multi-vendor + strategy for its CDN deployment. Finally, a CDN Provider may want to + deploy a separate CDN for a particular CSP or a specific network. In + all these circumstances, CDNI benefits the CDN Provider, as it + simplifies or automates some inter-CDN operations (e.g., migrating + the request routing function progressively). 4.3. QoE and QoS Improvement Some CSPs are willing to pay a premium for enhanced delivery of - Content to their End Users. In some cases, even if the CDN Provider - could deliver the content to the end users, it cannot meet the CSP's - service level requirements. So, it makes a CDN Interconnection - agreement with another CDN Provider that can provide the expected - quality of experience to the end-user, for instance an Access CDN - able to deliver content from Surrogates located closer to the end- - user. + content to their End Users. In some cases, even if the CDN Provider + could deliver the content to the End Users, it cannot meet the CSP's + service level requirements. As a result, the CDN Provider may + establish a CDN Interconnection agreement with another CDN Provider + that can provide the expected QoE to the End User, e.g., via an + Access CDN able to deliver content from Surrogates located closer to + the End User and with the required service level. -5. Policy Enforcement +5. Enforcement of Content Delivery Policy - For the interconnection use cases described in previous sections, the - delegation of content delivery may be dependent upon the ability to - delegate delivery policy enforcement as well. CSPs may rely on the - ability to place delivery restriction on sets of content, which are - provided by existing CDNs. While the ability to support these - features across interconnected CDNs is desirable, that may not always - be feasible. It is important to be able to detect or define when - these features cannot be enforced. + CSPs commonly require the ability to place delivery restriction on + sets of content, which are provided by existing CDNs. The ability to + support such delivery restrictions across interconnected CDNs is + desirable, but depends on the capabilities of the involved CDNs. + Thus, it is important to be able to detect and define when these + features cannot be enforced. 5.1. Content Availability - The content distribution policies that a CSP attaches to a content - asset depend on many criteria. For instance, distribution policies + The content distribution policies that a CSP attaches to a piece of + content depend on many criteria. For instance, distribution policies for audiovisual content often combine: o temporal constraints (e.g., available for 24 hours, available 28 days after DVD release, etc.), o resolution-based constraints (e.g., high definition vs. standard definition), and o geolocation-based constraints (e.g., per country). -5.1.1. Geo-location Restrictions - - "Geo-blocking" rules may specify: + CSPs may require from their CDN Providers that they translate some of + the above requirements into content delivery policies for their CDNs. + For instance, CDNs might implement "geo-blocking" rules specifying: - o the geographic regions where content can be delivered from (i.e. + o the geographic regions from where content can be delivered (i.e., the location of the Surrogates), or - o geographic locations where content can be delivered to (i.e., the + o geographic locations to which content can be delivered (i.e., the location of the End Users). - If a default value of "geo-blocking rules not supported" is set, the - CSP may wish to deny all access to the content, or blacklist specific - dCDNs which lack support for these features. - -5.1.2. Temporal Restrictions - - Time-based rules may specify: - - o an activation time (i.e., the time when the content should become - available for delivery), - - o a deactivation time (i.e., time after which the content should no - longer be delivered), or - - o an expiration time (i.e., the time at which the content files - should be expunged from all CDN storage). - - If a default value of "time-based rules not supported" is set, the - CSP may wish to deny all access to the content, or blacklist specific - dCDNs which lack support for these features. - -5.1.3. Content Encoding Restrictions - - [Ed. Note: Section to be removed? reworded?] - - Encoding-based rules may specify: - - o a subset of encodings deliverable to specific devices, - - o a subset of encodings deliverable though a specific NSP, or - - o a subset of encodings deliverable to users based on a subscription - or quality of service levels. - - [Ed. Note: FLF The first bullet only makes sense if the solution - supports transcoding/transrating, which I don't know if it will be - supported in Initial scope. The last bullet does not make sense to - me as we do not want the CDNs to be aware of any user subscription - levels (ie only CSP is aware of user subscription level)."] - - If a default value of "encoding-based rules not supported" is set, - the CSP may wish to deny all access to the content, or blacklist - specific dCDNs which lack support for these features. + Similarly, an uCDN might implement some temporal constraints on + content availability. For example, it could restrict access to pre- + positioned content prior to the opening of the availability window or + disable the delivery of content from the dCDNs (e.g., through + purging) after the availability window has closed. 5.2. Branding - There are situations where one CDN Provider cannot or does not want - to operate all the functions of a uCDN, e.g., a CDN exchange, which - handles request routing (and possibly log retrieval) but delegates - all content delivery to the surrogates of other dCDNs. Preserving - the branding of the CSP throughout delivery is often important to the - CSP. CSPs may desire to offer content services under their own name, - even when the associated CDN service involves other CDSPs. The CSP - may request that the name of the CDSPs does not appear in the URLs - and may wish to specify a specific brand related tag to appear in the - URLs. Similarly, in offload situations, the uCDN might want to offer - CDN services under its own branding. + Preserving the branding of the CSP throughout delivery is often + important to the CSP. CSPs may desire to offer content services + under their own name, even when the associated CDN service involves + other CDN Providers. The CSP may request that the name of the CDN + Providers does not appear in the URLs and may wish to specify a + specific brand related tag to appear in the URLs. The CSP may wish + to forbid the delivery of its content by specific dCDNs that lack + support for such branding preservation features. - If a default value of "branding rules not supported" is set, the CSP - may wish to deny all access to the content, or blacklist specific - dCDNs which lack support for these features. + Similar restrictions may exist when the uCDN wants to offer CDN + services under its own branding even if dCDNs are involved. + Conversely, a CDN Provider might not want the brand of a CDN Exchange + to be visible, even if the CDN Exchange is involved in the content + delivery call flow. 5.3. Secure Access Many protocols exist for delivering content to End Users. CSPs may often wish to dictate a specific protocol or set of protocols which are acceptable for delivery of their content, especially in the case where content protection or user authentication is required (e.g., - must use HTTPS and not HTTP, or must use URL hashing, etc.). + must use HTTPS, or must use URL hashing, etc.). - If a default value of "secure access rules not supported" is set, the - CSP may wish to deny all access to the content, or blacklist specific - dCDNs which lack support for these features. + The CSP may wish to blacklist specific dCDNs which lack support for + these secure access features. -6. Open issues +6. Acknowledgments - The section about nomadic users must be clarified + The authors would like to thank Kent Leung, Francois Le Faucheur, Ben + Niven-Jenkins, and Scott Wainner for lively discussions, as well as + for their reviews and comments on the mailing list. - The section about Content Encoding Restrictions requires a - discussion: must the CDN enforce such restrictions? + They also thank the contributors of the EU FP7 OCEAN and ETICS + projects for valuable inputs. -7. Contributors +7. IANA Considerations - [Ed. Note: long list of co-authors. As per current practice, you - would want to split that into "editors" and "contributors".] + This memo includes no request to IANA. - The following people have strongly contributed to this - specification's content: +8. Security Considerations -8. Acknowledgments + CDN Interconnection, as described in this document, has a wide + variety of security issues that should be considered. - The authors would like to thank Kent Leung, Francois Le Faucheur and - Ben Niven-Jenkins for lively discussions, as well as for their - reviews and comments on the mailing list. + In addition to the security considerations within the uCDN and dCDN, + four contexts involve security and trust issues: - They also thank the contributors of the EU FP7 OCEAN and ETICS - projects for valuable inputs. + a. The relationship between the CSP and the uCDN: the main contract + arrangement for distribution, which authorizes the uCDN to + acquire content on CSP's origin servers and to deliver it, + potentially with content delivery restrictions. -9. IANA Considerations + b. The relationship between the uCDN and dCDN: the transitive trust + relationship that extends the contract defined in (a) above and + that authorizes the dCDN to acquire content on uCDN's or CSP's + origin servers and to deliver it, potentially with content + delivery restrictions. - This memo includes no request to IANA. + c. The relationship between the End User and dCDN: the recognition + of right to download predicated on (b) above. -10. Security Considerations + d. The relationship between the End User and the CSP: the contract + that authorizes the End User to access to the content. - CDN Interconnection, as described in this document, has a wide - variety of security issues that should be considered. The security - issues fall into three general categories: + CDNI should enable the four parties (CSP, uCDN, dCDN, End User) to + negotiate a security method or a method for confirming authorization + along the chain of trust (CSP -> uCDN -> dCDN -> End User). + + The security issues fall into three general categories: o CSP Trust: where the CSP may have negotiated service level agreements for delivery quality of service with the uCDN, and/or configured distribution policies (e.g., geo-restrictions, availability windows, or other licensing restrictions), which it assumes will be upheld by dCDNs to which the uCDN delegates requests. Furthermore, billing and accounting information must be aggregated from dCDNs with which the CSP may have no direct business relationship. These situations where trust is delegated must be handled in a secure fashion to ensure CSP confidence in @@ -609,68 +654,57 @@ its existing security and DRM protocols (e.g., cookies, certificate-based authentication, custom DRM protocols, URL signing algorithms, etc.) in a transparent fashion. o CDN Infrastructure Protection: where the dCDNs must be able to identify and validate delegated requests, in order to prevent unauthorized use of the network and to be able to properly bill for delivered content. A dCDN may not wish to advertise that it has access to or is carrying content for the uCDN or CSP, especially if that information may be used to enhance denial of - service attacks. In general, CDNI interfaces and protocols should + service attacks. CDNI interfaces and protocols should attempt to minimize overhead for dCDNs. This document focuses on the motivational use cases for CDN Interconnection, and does not analyze these threats in detail. -11. References +9. References -11.1. Normative References +9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. -11.2. Informative References +9.2. Informative References [I-D.bertrand-cdni-experiments] Bertrand, G., Faucheur, F., and L. Peterson, "Content Distribution Network Interconnection (CDNI) Experiments", draft-bertrand-cdni-experiments-01 (work in progress), August 2011. [I-D.davie-cdni-framework] Davie, B. and L. Peterson, "Framework for CDN - Interconnection", draft-davie-cdni-framework-00 (work in - progress), July 2011. + Interconnection", draft-davie-cdni-framework-01 (work in + progress), October 2011. [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-00 (work in - progress), September 2011. + Statement", draft-ietf-cdni-problem-statement-01 (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-00 (work in progress), - September 2011. - - [I-D.ma-cdni-publisher-use-cases] - Nair, R. and K. Ma, "Content Distribution Network - Interconnection (CDNI) Publisher Use", - draft-ma-cdni-publisher-use-cases-00 (work in progress), - March 2011. - - [I-D.watson-cdni-use-cases] - Watson, G., "CDN Interconnect Use Cases", - draft-watson-cdni-use-cases-00 (work in progress), - January 2011. + draft-ietf-cdni-requirements-02 (work in progress), + December 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. Authors' Addresses