--- 1/draft-ietf-cdni-use-cases-04.txt 2012-05-28 12:14:49.345427327 +0200 +++ 2/draft-ietf-cdni-use-cases-05.txt 2012-05-28 12:14:49.381425620 +0200 @@ -1,161 +1,148 @@ Internet Engineering Task Force G. Bertrand, Ed. Internet-Draft E. Stephan Intended status: Informational France Telecom - Orange -Expires: September 27, 2012 G. Watson - T. Burbridge +Expires: November 24, 2012 T. Burbridge P. Eardley BT K. Ma - Azuki Systems - March 26, 2012 + Azuki Systems, Inc. + G. Watson + Alcatel-Lucent (Velocix) + May 23, 2012 Use Cases for Content Delivery Network Interconnection - draft-ietf-cdni-use-cases-04 + draft-ietf-cdni-use-cases-05 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 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. + definition of the requirements to be supported by CDN Interconnection + (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 September 27, 2012. + This Internet-Draft will expire on November 24, 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 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. - Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5 - 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7 - 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7 - 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 7 - 2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 8 - 2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8 - 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 + 1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 4 + 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 6 + 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 6 + 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 6 + 2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 7 + 2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 9 - 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.2.1. Failure of Content Delivery Resources . . . . . . . . 10 + 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2.1. Failure of Content Delivery Resources . . . . . . . . 9 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 + 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 10 + 4.1. Device and Network Technology Extension . . . . . . . . . 10 + 4.2. Technology and Vendor Interoperability . . . . . . . . . . 11 + 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 11 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 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. Content Service Providers' Delivery Policies . . . . 13 + A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 13 + A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15 + A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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 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]. + definition of the requirements (as documented in + [I-D.ietf-cdni-requirements]) to be supported by the set of CDN + Interconnection (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) - Then, the document highlights the need for interoperability to - exchange and enforce content delivery policies (Section 5). + Then, the document highlights the need for interoperability in order + to exchange and enforce content delivery policies (Section 5). 1.1. Terminology We adopt the terminology described in [I-D.ietf-cdni-problem-statement], [I-D.davie-cdni-framework], [RFC3466], and [RFC3568]. We extend this terminology with the following terms. Access CDN: - 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 piece of content to the End User. - In particular, the Delivering CDN can be an Access CDN. + A CDN that includes Surrogates in the same administrative network as + the end-user. Such CDN can use accurate information on the End + User's network context to provide valued-added Content Delivery + Services to Content Service Providers. 1.2. Abbreviations 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 @@ -170,99 +157,109 @@ 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 (decreased round-trip-time between the user and the - delivery server) and better robustness, + lower latency (decreased round-trip-time and higher throughput + between the user and the delivery server) and better robustness + (ability to use multiple delivery servers), o reduce the network operator's costs; for instance, lower delivery cost (reduced bandwidth usage) for cacheable content, - 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. + o reduce the Content Service Provider's (CSP) internal costs, such + as datacenter capacity, space, and electricity consumption, as + popular content is delivered externally through the CDN rather + than through the CSP's own servers. 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 overcome this restriction: the interconnected CDNs should be able to collectively behave as a single delivery infrastructure. - 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. + An example is depicted in Figure 1, where 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. + Independently, 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. + When a given User Agent requests content from CSP-1, CDN-A may + consider that delivery by CDN-B is appropriate, for instance, because + CDN-B is an Access CDN and the user is directly attached to it. + Through the CDN Interconnection arrangements put in place between + CDN-A and CDN-B (as a result of the CDN Interconnection agreement + established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can + redirect the request to CDN-B and the content is actually delivered + to the User Agent by 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, + needs to make one business agreement and one technical arrangement 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'. + agreement and technical arrangement with CDN Provider 'B'. +-------+ +-------+ | CSP-1 | | CSP-2 | +-------+ +-------+ | | ,--,--,--./ ,--,--,--. ,-' `-. ,-' `-. (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-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. + also reach an agreement with CDN Provider 'A'. However, CSP-2 may + 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. 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: 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, + + o without incurring the cost of deploying and operating Surrogates + and the associated CDN infrastructure that may not be justified in + the corresponding geographic region (e.g., because of relatively + low delivery volume, or conversely because of the high investments + that would be needed to satisfy the high volume). 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 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. @@ -270,83 +267,84 @@ 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 - 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 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. + The previous section describes the case of geographic extension + between CDNs operated by different entities. A large CDN Provider + may have several subsidiaries that also each operate their own CDN + (which may rely on different CDN technologies, see Section 4.2). In + certain circumstances, the CDN Provider needs to make these CDNs + interoperate to provide a consistent service to its customers on the + whole collective footprint. 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 + comes from a third party CSP and that is injected into the ISP's 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: + to the ISP (acting as an Access CDN), the Authoritative CDN, and the + CSP that would make a case for establishing a CDNI agreement. For + example: o Allow the CSP to offer improved QoE and QoE services to - subscribers, for example, QoS and reduced round trip time. + subscribers, for example, reduced content startup time or + increased video quality and resolution of adaptive streaming + content. 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. + access networks 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 moving between different access networks, which may be + located 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. + the WiFi or mobile provider (NSP B), rather than from CDN-A in NSP + A's network. +-------+ |Content| +-------+ | ,--,--,--. ,--,--,--. ,-' NSP A `-. ,-' NSP B `-. ( (CDN-A) )=====( (CDN-B) ) `-. ,-' `-. ,-' `--'--'--' `--'--'--' @@ -376,21 +373,21 @@ 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. + CDN capacity 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 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. @@ -398,25 +395,32 @@ 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 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. - The second option is a use case for CDNI. + partial failure scenarios, a CDN Provider has at least three options: + + 1. if possible, use internal mechanisms to redirect traffic on + surviving equipment, + + 2. depending on traffic management policies, forward some requests + to the CSP's origin servers, and + + 3. redirect some requests toward another CDN, which must be able to + serve the redirected requests. + + The last option is a use case for CDNI. 3.2.2. Content Acquisition Resiliency Source content acquisition may be handled in one of two ways: o CSP origin, where a CDN acquires content directly from the CSP's origin server, or o CDN origin, where a downstream CDN acquires content from a Surrogate within an upstream CDN. @@ -425,63 +429,64 @@ 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 + acquisition from alternate content sources when acquisition failures occur. When normal content acquisition fails, a CDN may need to try - other origin server options, e.g.: + other content source 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, 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. + the selection of content acquisition sources should be considered and + facilitated. 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 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. 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 - session encryption, etc.). + traffic that requires HTTPS [RFC2818]. 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 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. @@ -506,180 +511,145 @@ 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 - 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. + An important aspect common to all the above use cases is that CSPs + typically 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. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations - CDN Interconnection, as described in this document, has a wide - variety of security issues that should be considered. - - In addition to the security considerations within the uCDN and dCDN, - four contexts involve security and trust issues: - - 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. - - 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. - - c. The relationship between the End User and dCDN: the recognition - of right to download predicated on (b) above. - - d. The relationship between the End User and the CSP: the contract - that authorizes the End User to access the content. - - 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 - the CDN interconnection. - - o Client Transparency: where the client device or application which - connects to the CDN must be able to interact with any dCDN using - 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. 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. + Interconnection, and does not analyze the associated threats. Those + are discussed in [I-D.ietf-cdni-problem-statement]. 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.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-04 (work in - progress), March 2012. + Statement", draft-ietf-cdni-problem-statement-06 (work in + progress), May 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. + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + [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: + policies for audiovisual content often combine constraints of varying + levels of complexity and sophistication, e.g.: 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). + o user agent platform constraints (e.g., mobile device platforms, + desktop computer platforms, set-top-box platforms, etc.), - dCDN delegation and Surrogate selection decisions are influenced by - these policies: + o resolution-based constraints (e.g., high definition vs. standard + definition encodings), - o dCDN delegation and/or Surrogates selection may fail if the - availability window for the requested content is not active, + o user agent identification or authorization, - 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 access network constraints (e.g., per NSP), and - 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 geolocation-based constraints (e.g., per country). - o dCDN delegation may fail if the footprint of the dCDN is outside - of the delivery footprint for the requested content, or + CSPs may use sophisticated policies in accordance to their business + model. However, the enforcement of those policies does not + necessarily require that the delivery network understand the policy + rationales or how policies apply to specific content assets. Content + delivery policies may indeed be distilled into simple rules which can + be commonly enforced across all dCDNs. These rules may influence + dCDN delegation and Surrogate selection decisions, for instance, to + ensure that the specific rules (e.g. time-window, geo-blocking, pre- + authorization validation) can indeed be enforced by the delivering + CDN. In turn, this can guarantee to the CSP that content license + violations can be prevented, including prevention of premature access + to pre-positioned content or enforcement of geo-blocking policies. - o Surrogate selection may fail if the footprint of the current CDN - is outside of the delivery footprint for the requested content. + +-----+ + | CSP | Policies driven by business (e.g., available + +-----+ only in UK and only from July 1st to September 1st) + \ + \ Translate policies into + \simple rules (e.g., provide an authorization token) + \ + V + +-----+ + | CDN | Apply simple rules (e.g., check an + +-----+ authorization token and enforce geoblocking) + \ + \ Distribute simple rules + V + +-----+ + | CDN | Apply simple rules + +-----+ - These policy considerations permit preventing premature access to - pre-positioned content, preventing content licensing violations, and - enforcing geo-blocking policies. + Figure 3 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.). @@ -712,42 +682,42 @@ Phone: +33 1 45 29 89 46 Email: gilles.bertrand@orange.com Stephan Emile France Telecom - Orange 2 avenue Pierre Marzin Lannion F-22307 France Email: emile.stephan@orange.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 - Kevin Ma - Azuki Systems + + Kevin J. Ma + Azuki Systems, Inc. 43 Nagog Park Acton, MA 01720 USA - Phone: +1 978 844 5100 + Phone: +1 978-844-5100 Email: kevin.ma@azukisystems.com + + Grant Watson + Alcatel-Lucent (Velocix) + 3 Ely Road + Milton, Cambridge CB24 6AA + UK + + Email: gwatson@velocix.com