--- 1/draft-ietf-cdni-use-cases-03.txt 2012-03-26 12:13:57.150754689 +0200 +++ 2/draft-ietf-cdni-use-cases-04.txt 2012-03-26 12:13:57.182806717 +0200 @@ -1,53 +1,51 @@ Internet Engineering Task Force G. Bertrand, Ed. Internet-Draft E. Stephan Intended status: Informational France Telecom - Orange -Expires: August 2, 2012 G. Watson +Expires: September 27, 2012 G. Watson T. Burbridge P. Eardley BT K. Ma Azuki Systems - January 30, 2012 + March 26, 2012 Use Cases for Content Delivery Network Interconnection - draft-ietf-cdni-use-cases-03 + draft-ietf-cdni-use-cases-04 Abstract Content Delivery Networks (CDNs) are commonly used for improving 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 focuses on use cases that - correspond to identified industry needs and that are expected to be - realized once a CDN Interconnection (CDNI) solution is available. - This document 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. + cost. This document focuses on use cases that correspond to + identified industry needs and that are expected to be realized once + open interfaces and protocols supporting interconnection of CDNs are + specified and implemented. The document can be used to guide the + definition of the requirements to be supported by 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 August 2, 2012. + This Internet-Draft will expire on September 27, 2012. Copyright Notice Copyright (c) 2012 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 @@ -68,58 +66,57 @@ 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 . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5 - 1.4. The Need for CDN Interconnection Standards . . . . . . . . 7 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7 - 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 8 + 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 7 2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 8 2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8 - 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 10 + 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 + 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 9 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Failure of Content Delivery Resources . . . . . . . . 10 - 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 11 + 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11 - 4.1. Device and Network Technology Extension . . . . . . . . . 12 + 4.1. Device and Network Technology Extension . . . . . . . . . 11 4.2. Technology and Vendor Interoperability . . . . . . . . . . 12 - 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 13 - 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 13 - 5.1. Content Delivery Restrictions . . . . . . . . . . . . . . 13 - 5.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 14 - 5.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12 + 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 + Appendix A. Content Service Providers' Delivery Policies . . . . 15 + A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 15 + A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 16 + A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Content Delivery Networks (CDNs) are commonly used for improving 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 focuses on use cases that - correspond to identified industry needs and that are expected to be - realized once a CDNI solution is available. This document 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. + cost. This document focuses on use cases that correspond to + identified industry needs and that are expected to be realized once + open interfaces and protocols supporting interconnection of CDNs are + specified and implemented. The document can be used to guide the + definition of the requirements to be supported by the various CDNI + interfaces defined in [I-D.ietf-cdni-problem-statement]. 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) @@ -237,41 +234,20 @@ Figure 1 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 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. 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 - 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. 2.1. Geographic Extension In this use case, the CDN Provider wants to extend the geographic distribution that it can offer to its CSPs: @@ -297,21 +273,21 @@ 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 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 + rely on different CDN technologies, 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. For example, the CDN Provider might want to expose a single set of interfaces to the CSPs. 2.3. ISP Handling of Third-Party 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 @@ -376,25 +352,25 @@ `--'--'--' `--'--'--' | | +------------+ +---------------+ + 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 + 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 + Depending on CSP's content delivery policies (see Appendix A.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 an expected maximum traffic load. However, unexpected spikes in content popularity @@ -479,21 +456,21 @@ 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 supported range of delivery technologies. In this case, a CDN Provider may interconnect with a CDN that offers services: o that the CDN Provider is not willing to provide or, - o that its own CDN is not able to support + 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 authorization such as tokens, per @@ -529,87 +506,28 @@ 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. Enforcement of Content Delivery Policy - 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 Delivery Restrictions - - 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). - - 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 geographic locations to which content can be delivered (i.e., the - location of the End Users), or - - o the geographic regions from where content can be delivered (i.e., - the location of the Surrogates). - - 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. 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). CSPs may also wish to perform per-request - authentication/authorization decision and then have the CDNs enforce - that decision (e.g., must validate URL signing, etc.). - - An uCDN needs to be able to exclude dCDNs which lack support for the - secure access features requested by the CSP. - -5.3. 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. For instance, a CSP may desire to ensure that - content is delivered with URIs appearing to the End Users under the - CSP's own domain name, even when the content delivery involves - separate CDN Providers. The CSP may wish to forbid the delivery of - its content by specific dCDNs that lack support for such branding - preservation features. - - Analogous restrictions may exist when the uCDN wants to offer CDN - services under its own branding even if dCDNs are involved. - Similarly, a CDN Provider might not want the brand of an intermediary - in the CDN delegation chain to be visible, even if the intermediary - is involved in the content delivery call flow. + An important aspect of the above use cases is that CSPs commonly want + to enforce content delivery policies. A CSP may want to define + content delivery policies that specify when, how, and/or to whom the + CDN delivers content. These policies apply to all interconnected + CDNs (uCDNs and dCDNs) in the same or similar way that a CSP can + define content delivery policies for content delivered by a single, + non-interconnected CDN. Appendix A provides examples of CSP defined + policies. 6. Acknowledgments 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. They also thank the contributors of the EU FP7 OCEAN and ETICS projects for valuable inputs. @@ -679,51 +597,117 @@ 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 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-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-03 (work in - progress), January 2012. + Statement", draft-ietf-cdni-problem-statement-04 (work in + progress), March 2012. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni-requirements-02 (work in progress), December 2011. [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. +Appendix A. Content Service Providers' Delivery Policies + + CSPs commonly apply different delivery policies to given sets of + content assets delivered through CDNs. Interconnected CDNs need to + support these policies. This annex presents examples of CSPs' + delivery policies and their consequences on CDNI operations. + +A.1. Content Delivery Policy Enforcement + + The content distribution policies that a CSP attaches to a content + asset may 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). + + dCDN delegation and Surrogate selection decisions are influenced by + these policies: + + o dCDN delegation and/or Surrogates selection may fail if the + availability window for the requested content is not active, + + o dCDN delegation may fail if the content resolution has been + specified by the CSP as being too high for distribution via the + dCDN, + + o Surrogate selection may fail if the content resolution has been + specified by the CSP as being too high for distribution via the + current CDN, + + o dCDN delegation may fail if the footprint of the dCDN is outside + of the delivery footprint for the requested content, or + + o Surrogate selection may fail if the footprint of the current CDN + is outside of the delivery footprint for the requested content. + + These policy considerations permit preventing premature access to + pre-positioned content, preventing content licensing violations, and + enforcing geo-blocking policies. + +A.2. Secure Access + + Many protocols exist for delivering content to End Users. CSPs may + 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). + CSPs may also perform per-request authentication/authorization + decision and then have the CDNs enforce that decision (e.g., must + validate URL signing, etc.). + +A.3. 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. For instance, a CSP may desire to ensure that + content is delivered with URIs appearing to the End Users under the + CSP's own domain name, even when the content delivery involves + separate CDN Providers. The CSP may wish to prevent the delivery of + its content by specific dCDNs that lack support for such branding + preservation features. + + Analogous cases exist when the uCDN wants to offer CDN services under + its own branding even if dCDNs are involved. Similarly, a CDN + Provider might wish to restrict the delivery delegation to a chain + that preserves its brand visibility. + Authors' Addresses Gilles Bertrand (editor) 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.com