draft-ietf-cdni-use-cases-04.txt   draft-ietf-cdni-use-cases-05.txt 
Internet Engineering Task Force G. Bertrand, Ed. Internet Engineering Task Force G. Bertrand, Ed.
Internet-Draft E. Stephan Internet-Draft E. Stephan
Intended status: Informational France Telecom - Orange Intended status: Informational France Telecom - Orange
Expires: September 27, 2012 G. Watson Expires: November 24, 2012 T. Burbridge
T. Burbridge
P. Eardley P. Eardley
BT BT
K. Ma K. Ma
Azuki Systems Azuki Systems, Inc.
March 26, 2012 G. Watson
Alcatel-Lucent (Velocix)
May 23, 2012
Use Cases for Content Delivery Network Interconnection Use Cases for Content Delivery Network Interconnection
draft-ietf-cdni-use-cases-04 draft-ietf-cdni-use-cases-05
Abstract Abstract
Content Delivery Networks (CDNs) are commonly used for improving the Content Delivery Networks (CDNs) are commonly used for improving the
End User experience of a content delivery service, at a reasonable End User experience of a content delivery service, at a reasonable
cost. This document focuses on use cases that correspond to cost. This document focuses on use cases that correspond to
identified industry needs and that are expected to be realized once identified industry needs and that are expected to be realized once
open interfaces and protocols supporting interconnection of CDNs are open interfaces and protocols supporting interconnection of CDNs are
specified and implemented. The document can be used to guide the 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 Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5 1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 4
2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 6
2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 6
2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 7 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 6
2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 8 2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 7
2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 7
3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 9 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 9
3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Failure of Content Delivery Resources . . . . . . . . 10 3.2.1. Failure of Content Delivery Resources . . . . . . . . 9
3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10
4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 10
4.1. Device and Network Technology Extension . . . . . . . . . 11 4.1. Device and Network Technology Extension . . . . . . . . . 10
4.2. Technology and Vendor Interoperability . . . . . . . . . . 12 4.2. Technology and Vendor Interoperability . . . . . . . . . . 11
4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 11
5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Content Service Providers' Delivery Policies . . . . 15 Appendix A. Content Service Providers' Delivery Policies . . . . 13
A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 15 A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 13
A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 16 A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15
A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 16 A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Content Delivery Networks (CDNs) are commonly used for improving the Content Delivery Networks (CDNs) are commonly used for improving the
End User experience of a content delivery service, at a reasonable End User experience of a content delivery service, at a reasonable
cost. This document focuses on use cases that correspond to cost. This document focuses on use cases that correspond to
identified industry needs and that are expected to be realized once identified industry needs and that are expected to be realized once
open interfaces and protocols supporting interconnection of CDNs are open interfaces and protocols supporting interconnection of CDNs are
specified and implemented. The document can be used to guide the specified and implemented. The document can be used to guide the
definition of the requirements to be supported by the various CDNI definition of the requirements (as documented in
interfaces defined in [I-D.ietf-cdni-problem-statement]. [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 This document identifies the main motivations for a CDN Provider to
interconnect its CDN: interconnect its CDN:
o CDN Footprint Extension Use Cases (Section 2) o CDN Footprint Extension Use Cases (Section 2)
o CDN Offload Use Cases (Section 3) o CDN Offload Use Cases (Section 3)
o CDN Capability Use Cases (Section 4) o CDN Capability Use Cases (Section 4)
Then, the document highlights the need for interoperability to Then, the document highlights the need for interoperability in order
exchange and enforce content delivery policies (Section 5). to exchange and enforce content delivery policies (Section 5).
1.1. Terminology 1.1. Terminology
We adopt the terminology described in We adopt the terminology described in
[I-D.ietf-cdni-problem-statement], [I-D.davie-cdni-framework], [I-D.ietf-cdni-problem-statement], [I-D.davie-cdni-framework],
[RFC3466], and [RFC3568]. [RFC3466], and [RFC3568].
We extend this terminology with the following terms. We extend this terminology with the following terms.
Access CDN: Access CDN:
A CDN that is directly connected to the End User's access. An Access A CDN that includes Surrogates in the same administrative network as
CDN may have specific information about the End User and the network, the end-user. Such CDN can use accurate information on the End
for instance, End User's profile and access capabilities. User's network context to provide valued-added Content Delivery
Services to Content Service Providers.
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.
1.2. Abbreviations 1.2. Abbreviations
o CDN: Content Delivery Network also known as Content Distribution o CDN: Content Delivery Network also known as Content Distribution
Network Network
o CSP: Content Service Provider o CSP: Content Service Provider
o dCDN: downstream CDN o dCDN: downstream CDN
o DNS: Domain Name System o DNS: Domain Name System
o DRM: Digital Rights Management o DRM: Digital Rights Management
o EU: End User o EU: End User
o ISP: Internet Service Provider o ISP: Internet Service Provider
skipping to change at page 5, line 35 skipping to change at page 4, line 32
o URL: Uniform Resource Locator o URL: Uniform Resource Locator
o WiFi: Wireless Fidelity o WiFi: Wireless Fidelity
1.3. Rationale for Multi-CDN Systems 1.3. Rationale for Multi-CDN Systems
Content Delivery Networks (CDNs) are used to deliver content because Content Delivery Networks (CDNs) are used to deliver content because
they can: they can:
o improve the experience for the End User; for instance delivery has o improve the experience for the End User; for instance delivery has
lower latency (decreased round-trip-time between the user and the lower latency (decreased round-trip-time and higher throughput
delivery server) and better robustness, 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 o reduce the network operator's costs; for instance, lower delivery
cost (reduced bandwidth usage) for cacheable content, cost (reduced bandwidth usage) for cacheable content,
o reduce the Content Service Provider's (CSP) costs, such as o reduce the Content Service Provider's (CSP) internal costs, such
datacenter capacity, space, and electricity consumption, as as datacenter capacity, space, and electricity consumption, as
popular content is delivered through the CDN rather than through popular content is delivered externally through the CDN rather
the CSP's servers. than through the CSP's own servers.
Indeed, many Network Service Providers (NSPs) and enterprise service Indeed, many Network Service Providers (NSPs) and enterprise service
providers are deploying or have deployed their own CDNs. Despite the providers are deploying or have deployed their own CDNs. Despite the
potential benefits of interconnecting CDNs, today each CDN is a 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 overcome this restriction: the interconnected CDNs should be able to
collectively behave as a single delivery infrastructure. collectively behave as a single delivery infrastructure.
An example is depicted in Figure 1. Two CDN Providers establish a An example is depicted in Figure 1, where two CDN Providers establish
CDN Interconnection. The Content Service Provider CSP-1 reaches an a CDN Interconnection. The Content Service Provider CSP-1 reaches an
agreement with CDN Provider 'A' for the delivery of its content. CDN agreement with CDN Provider 'A' for the delivery of its content.
Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs. 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 When a given User Agent requests content from CSP-1, CDN-A may
delivery by CDN-B is appropriate, for instance, because CDN-B is an consider that delivery by CDN-B is appropriate, for instance, because
Access CDN and the user is directly attached to it. CDN-A has CDN-B is an Access CDN and the user is directly attached to it.
delegated the handling of requests for CSP-1's content through the Through the CDN Interconnection arrangements put in place between
CDN Interconnection agreement, thus, the content is actually CDN-A and CDN-B (as a result of the CDN Interconnection agreement
delivered from CDN-B. 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 The End User benefits from this arrangement through a better Quality
of Experience (QoE), because the content is delivered from a nearby of Experience (QoE), because the content is delivered from a nearby
Surrogate. CDN Provider 'A' benefits because it does not need to Surrogate. CDN Provider 'A' benefits because it does not need to
deploy such an extensive CDN, whilst CDN Provider 'B' may receive deploy such an extensive CDN, whilst CDN Provider 'B' may receive
some compensation for the delivery. CSP-1 benefits because it only 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 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 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 | | CSP-1 | | CSP-2 |
+-------+ +-------+ +-------+ +-------+
| | | |
,--,--,--./ ,--,--,--. ,--,--,--./ ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
(CDN Provider 'A')=====(CDN Provider 'B') (CDN Provider 'A')=====(CDN Provider 'B')
`-. (CDN-A) ,-' `-. (CDN-B) ,-' `-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
| |
+------------+ +------------+
| User Agent | | User Agent |
+------------+ +------------+
=== CDN Interconnection === CDN Interconnection
Figure 1 Figure 1
To extend the example, another Content Service Provider, CSP-2, may To extend the example, another Content Service Provider, CSP-2, may
also reach an agreement with CDN Provider 'A'. But it does not want also reach an agreement with CDN Provider 'A'. However, CSP-2 may
its content to be distributed by CDN Provider B; for example, CSP-2 not want its content to be distributed by CDN Provider B; for
may not have distribution rights in the country where CDN Provider example, CSP-2 may not have distribution rights in the country where
'B' operates. This example illustrates that policy considerations CDN Provider 'B' operates. This example illustrates that policy
are an important part of CDNI. considerations are an important part of CDNI.
2. Footprint Extension Use Cases 2. Footprint Extension Use Cases
Footprint extension is expected to be a major use case for CDN Footprint extension is expected to be a major use case for CDN
Interconnection. Interconnection.
2.1. Geographic Extension 2.1. Geographic Extension
In this use case, the CDN Provider wants to extend the geographic In this use case, the CDN Provider wants to extend the geographic
distribution that it can offer to its CSPs: distribution that it can offer to its CSPs:
o without compromising the quality of delivery, o without compromising the quality of delivery,
o without incurring additional transit and other network costs that o without incurring additional transit and other network costs that
would result from serving content from geographically or 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 If there are several CDN Providers that have a geographically limited
footprint (e.g., restricted to one country), or do not serve all End footprint (e.g., restricted to one country), or do not serve all End
Users in a geographic area, then interconnecting their CDNs enables Users in a geographic area, then interconnecting their CDNs enables
these CDN Providers to provide their services beyond their own these CDN Providers to provide their services beyond their own
footprint. footprint.
As an example, suppose a French CSP wants to distribute its TV As an example, suppose a French CSP wants to distribute its TV
programs to End Users located in France and various countries in programs to End Users located in France and various countries in
North Africa. It asks a French CDN Provider to deliver the content. North Africa. It asks a French CDN Provider to deliver the content.
skipping to change at page 7, line 41 skipping to change at page 6, line 48
agreement with another CDN Provider that covers North Africa. agreement with another CDN Provider that covers North Africa.
Overall, from the CSP's perspective the French CDN Provider provides Overall, from the CSP's perspective the French CDN Provider provides
a CDN service for both France and North Africa. a CDN service for both France and North Africa.
In addition to video, this use case applies to other types of content In addition to video, this use case applies to other types of content
such as automatic software updates (browser updates, operating system such as automatic software updates (browser updates, operating system
patches, virus database update, etc). patches, virus database update, etc).
2.2. Inter-Affiliates Interconnection 2.2. Inter-Affiliates Interconnection
In the previous section, we have described the case of geographic The previous section describes the case of geographic extension
extension between CDNs operated by different entities. A large CDN between CDNs operated by different entities. A large CDN Provider
Provider may also operate CDNs from several subsidiaries (which may may have several subsidiaries that also each operate their own CDN
rely on different CDN technologies, see Section 4.2). In certain (which may rely on different CDN technologies, see Section 4.2). In
circumstances, the CDN Provider needs to make its CDNs interoperate certain circumstances, the CDN Provider needs to make these CDNs
to provide a consistent service to its customers on its whole interoperate to provide a consistent service to its customers on the
footprint. For example, the CDN Provider might want to expose a whole collective footprint.
single set of interfaces to the CSPs.
2.3. ISP Handling of Third-Party Content 2.3. ISP Handling of Third-Party Content
Consider an ISP carrying to its subscribers a lot of content that 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 network by an Authoritative CDN Provider. There are mutual benefits
to the Access CDN, the Authoritative CDN, and the CSP that would make to the ISP (acting as an Access CDN), the Authoritative CDN, and the
a case for establishing a CDNI agreement. For example: 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 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 o Allow the Authoritative CDN to reduce hardware capacity and
footprint, by using the ISP caching and delivery capacity. footprint, by using the ISP caching and delivery capacity.
o Allow the ISP to reduce traffic load on some segments of the o Allow the ISP to reduce traffic load on some segments of the
network by caching inside of the ISP network. network by caching inside of the ISP network.
o Allow the ISP to influence and/or control the traffic ingestion o Allow the ISP to influence and/or control the traffic ingestion
points. points.
o Allow the ISP to derive some incremental revenue for transport of o Allow the ISP to derive some incremental revenue for transport of
the traffic and to monetize QoE services. the traffic and to monetize QoE services.
2.4. Nomadic Users 2.4. Nomadic Users
In this scenario, a CSP wishes to allow End Users who move between In this scenario, a CSP wishes to allow End Users who move between
CDNs to continue to access their content. The motivation of this access networks to continue to access their content. The motivation
case is to allow nomadic End Users to maintain access to content with of this case is to allow nomadic End Users to maintain access to
a consistent QoE, across a range of devices and/or geographic content with a consistent QoE, across a range of devices and/or
regions. geographic regions.
This use case covers situations like: This use case covers situations like:
o End Users moving between different CDN Providers, which may reside o End Users moving between different access networks, which may be
within the same geographic region or different geographic regions, located within the same geographic region or different geographic
regions,
o End Users switching between different devices or delivery o End Users switching between different devices or delivery
technologies, as discussed in Section 4. 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 Consider the following example, illustrated in Figure 2: End User A
has subscription to a broadband service from NSP A, her "home NSP". 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 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 NSP A (her "home NSP") the content is delivered from CDN-A, which in
this example is within NSP A's network. this example is within NSP A's network.
However, while End User A is not connected to NSP A's network, for 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 example, because it is connected to a WiFi provider or mobile
network, End User A can also access the same content. In this case, 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 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 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 the WiFi or mobile provider (NSP B), rather than from CDN-A in NSP
network. A's network.
+-------+ +-------+
|Content| |Content|
+-------+ +-------+
| |
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' NSP A `-. ,-' NSP B `-. ,-' NSP A `-. ,-' NSP B `-.
( (CDN-A) )=====( (CDN-B) ) ( (CDN-A) )=====( (CDN-B) )
`-. ,-' `-. ,-' `-. ,-' `-. ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
skipping to change at page 10, line 8 skipping to change at page 9, line 17
traffic load. However, unexpected spikes in content popularity traffic load. However, unexpected spikes in content popularity
(flash crowd) may drive load beyond the expected peak. The prime (flash crowd) may drive load beyond the expected peak. The prime
recurrent time peaks of content distribution may differ between two recurrent time peaks of content distribution may differ between two
CDNs. Taking advantage of the different traffic peak times, a CDN CDNs. Taking advantage of the different traffic peak times, a CDN
may interconnect with another CDN to increase its effective capacity may interconnect with another CDN to increase its effective capacity
during the peak of traffic. This brings dimensioning savings to the during the peak of traffic. This brings dimensioning savings to the
CDNs as they can use the resources of each other during their CDNs as they can use the resources of each other during their
respective peaks of activity. respective peaks of activity.
Offload also applies to planned situations where a CDN Provider needs 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 For example, a CDN can offload traffic to another CDN during a
specific maintenance operation or for covering the distribution of a specific maintenance operation or for covering the distribution of a
special event. For instance, consider a TV-channel which has special event. For instance, consider a TV-channel which has
exclusive distribution rights on a major event, such as a exclusive distribution rights on a major event, such as a
celebrities' wedding, or a major sport competition. 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 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 are likely to experience a flash crowd during the event and to need
offloading traffic, while other CDNs will support a more usual offloading traffic, while other CDNs will support a more usual
traffic load and be able to handle the offloaded traffic. traffic load and be able to handle the offloaded traffic.
skipping to change at page 10, line 30 skipping to change at page 9, line 39
should be able to handle the offloaded requests. Therefore, the uCDN should be able to handle the offloaded requests. Therefore, the uCDN
might require information on the dCDNs to be aware of the amount of might require information on the dCDNs to be aware of the amount of
traffic it can offload to every dCDN. traffic it can offload to every dCDN.
3.2. Resiliency 3.2. Resiliency
3.2.1. Failure of Content Delivery Resources 3.2.1. Failure of Content Delivery Resources
It is important for CDNs to be able to guarantee service continuity It is important for CDNs to be able to guarantee service continuity
during partial failures (e.g., failure of some Surrogates). In during partial failures (e.g., failure of some Surrogates). In
partial failure scenarios, a CDN Provider has at least two options: partial failure scenarios, a CDN Provider has at least three options:
(1) depending on traffic management policies, forward some requests
to the CSP's origin servers, and (2) redirect some requests toward 1. if possible, use internal mechanisms to redirect traffic on
another CDN, which must be able to serve the redirected requests. surviving equipment,
The second option is a use case for CDNI.
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 3.2.2. Content Acquisition Resiliency
Source content acquisition may be handled in one of two ways: Source content acquisition may be handled in one of two ways:
o CSP origin, where a CDN acquires content directly from the CSP's o CSP origin, where a CDN acquires content directly from the CSP's
origin server, or origin server, or
o CDN origin, where a downstream CDN acquires content from a o CDN origin, where a downstream CDN acquires content from a
Surrogate within an upstream CDN. Surrogate within an upstream CDN.
skipping to change at page 11, line 9 skipping to change at page 10, line 26
important use case for interconnected CDNs. When the content important use case for interconnected CDNs. When the content
acquisition source fails, the CDN might switch to another content acquisition source fails, the CDN might switch to another content
acquisition source. Similarly, when several content acquisition acquisition source. Similarly, when several content acquisition
sources are available, a CDN might balance the load between these sources are available, a CDN might balance the load between these
multiple sources. multiple sources.
Though other server and/or DNS load balancing techniques may be Though other server and/or DNS load balancing techniques may be
employed in the network, interconnected CDNs may have a better employed in the network, interconnected CDNs may have a better
understanding of origin server availability and be better equipped to understanding of origin server availability and be better equipped to
both distribute load between origin servers and attempt content 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 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 o an upstream CDN may acquire content from an alternate CSP origin
server, server,
o a downstream CDN may acquire content from an alternate Surrogate o a downstream CDN may acquire content from an alternate Surrogate
within an upstream CDN, within an upstream CDN,
o a downstream CDN may acquire content from an alternate upstream o a downstream CDN may acquire content from an alternate upstream
CDN, or CDN, or
o a downstream CDN may acquire content directly from the CSP's o a downstream CDN may acquire content directly from the CSP's
origin server. origin server.
Though content acquisition protocols are beyond the scope of CDNI, 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. CDN Capability Use Cases
4.1. Device and Network Technology Extension 4.1. Device and Network Technology Extension
In this use case, the CDN Provider may have the right geographic In this use case, the CDN Provider may have the right geographic
footprint, but may wish to extend the supported range of devices and footprint, but may wish to extend the supported range of devices and
User Agents or the supported range of 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 case, a CDN Provider may interconnect with a CDN that offers
services: services:
o that the CDN Provider is not willing to provide or, 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: The following examples illustrate this use case:
1. CDN-A cannot support a specific delivery protocol. For instance, 1. CDN-A cannot support a specific delivery protocol. For instance,
CDN-A may interconnect with CDN-B to serve a proportion of its 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 traffic that requires HTTPS [RFC2818]. CDN-A may use CDN-B's
(which may overlap with its own) to deliver HTTPS without needing footprint (which may overlap with its own) to deliver HTTPS
to deploy its own infrastructure. This case could also be true without needing to deploy its own infrastructure. This case
of other formats, delivery protocols (RTMP, RTSP, etc.) and could also be true of other formats, delivery protocols (RTMP,
features (specific forms of authorization such as tokens, per RTSP, etc.) and features (specific forms of authorization such as
session encryption, etc.). tokens, per session encryption, etc.).
2. CDN-A has footprint covering traditional fixed line broadband and 2. CDN-A has footprint covering traditional fixed line broadband and
wants to extend coverage to mobile devices. In this case, CDN-A wants to extend coverage to mobile devices. In this case, CDN-A
may contract and interconnect with CDN-B who has both: may contract and interconnect with CDN-B who has both:
* physical footprint inside the mobile network, * physical footprint inside the mobile network,
* the ability to deliver content over a protocol that is * the ability to deliver content over a protocol that is
required by specific mobile devices. required by specific mobile devices.
skipping to change at page 12, line 42 skipping to change at page 12, line 12
content to their End Users. In some cases, even if the CDN Provider 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 could deliver the content to the End Users, it cannot meet the CSP's
service level requirements. As a result, the CDN Provider may service level requirements. As a result, the CDN Provider may
establish a CDN Interconnection agreement with another CDN Provider establish a CDN Interconnection agreement with another CDN Provider
that can provide the expected QoE to the End User, e.g., via an 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 Access CDN able to deliver content from Surrogates located closer to
the End User and with the required service level. the End User and with the required service level.
5. Enforcement of Content Delivery Policy 5. Enforcement of Content Delivery Policy
An important aspect of the above use cases is that CSPs commonly want An important aspect common to all the above use cases is that CSPs
to enforce content delivery policies. A CSP may want to define typically want to enforce content delivery policies. A CSP may want
content delivery policies that specify when, how, and/or to whom the to define content delivery policies that specify when, how, and/or to
CDN delivers content. These policies apply to all interconnected whom the CDN delivers content. These policies apply to all
CDNs (uCDNs and dCDNs) in the same or similar way that a CSP can interconnected CDNs (uCDNs and dCDNs) in the same or similar way that
define content delivery policies for content delivered by a single, a CSP can define content delivery policies for content delivered by a
non-interconnected CDN. Appendix A provides examples of CSP defined single, non-interconnected CDN. Appendix A provides examples of CSP
policies. defined policies.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Kent Leung, Francois Le Faucheur, Ben The authors would like to thank Kent Leung, Francois Le Faucheur, Ben
Niven-Jenkins, and Scott Wainner for lively discussions, as well as Niven-Jenkins, and Scott Wainner for lively discussions, as well as
for their reviews and comments on the mailing list. for their reviews and comments on the mailing list.
They also thank the contributors of the EU FP7 OCEAN and ETICS They also thank the contributors of the EU FP7 OCEAN and ETICS
projects for valuable inputs. projects for valuable inputs.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 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 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. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[I-D.davie-cdni-framework] [I-D.davie-cdni-framework]
Davie, B. and L. Peterson, "Framework for CDN Davie, B. and L. Peterson, "Framework for CDN
Interconnection", draft-davie-cdni-framework-01 (work in Interconnection", draft-davie-cdni-framework-01 (work in
progress), October 2011. progress), October 2011.
[I-D.ietf-cdni-problem-statement] [I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", draft-ietf-cdni-problem-statement-04 (work in Statement", draft-ietf-cdni-problem-statement-06 (work in
progress), March 2012. progress), May 2012.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", Interconnection (CDNI) Requirements",
draft-ietf-cdni-requirements-02 (work in progress), draft-ietf-cdni-requirements-02 (work in progress),
December 2011. December 2011.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466, for Content Internetworking (CDI)", RFC 3466,
February 2003. February 2003.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms", Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003. RFC 3568, July 2003.
Appendix A. Content Service Providers' Delivery Policies Appendix A. Content Service Providers' Delivery Policies
CSPs commonly apply different delivery policies to given sets of CSPs commonly apply different delivery policies to given sets of
content assets delivered through CDNs. Interconnected CDNs need to content assets delivered through CDNs. Interconnected CDNs need to
support these policies. This annex presents examples of CSPs' support these policies. This annex presents examples of CSPs'
delivery policies and their consequences on CDNI operations. delivery policies and their consequences on CDNI operations.
A.1. Content Delivery Policy Enforcement A.1. Content Delivery Policy Enforcement
The content distribution policies that a CSP attaches to a content The content distribution policies that a CSP attaches to a content
asset may depend on many criteria. For instance, distribution 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 o temporal constraints (e.g., available for 24 hours, available 28
days after DVD release, etc.), days after DVD release, etc.),
o resolution-based constraints (e.g., high definition vs. standard o user agent platform constraints (e.g., mobile device platforms,
definition), and desktop computer platforms, set-top-box platforms, etc.),
o geolocation-based constraints (e.g., per country).
dCDN delegation and Surrogate selection decisions are influenced by o resolution-based constraints (e.g., high definition vs. standard
these policies: definition encodings),
o dCDN delegation and/or Surrogates selection may fail if the o user agent identification or authorization,
availability window for the requested content is not active,
o dCDN delegation may fail if the content resolution has been o access network constraints (e.g., per NSP), and
specified by the CSP as being too high for distribution via the
dCDN,
o Surrogate selection may fail if the content resolution has been o geolocation-based constraints (e.g., per country).
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 CSPs may use sophisticated policies in accordance to their business
of the delivery footprint for the requested content, or 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 Figure 3
pre-positioned content, preventing content licensing violations, and
enforcing geo-blocking policies.
A.2. Secure Access A.2. Secure Access
Many protocols exist for delivering content to End Users. CSPs may Many protocols exist for delivering content to End Users. CSPs may
dictate a specific protocol or set of protocols which are acceptable dictate a specific protocol or set of protocols which are acceptable
for delivery of their content, especially in the case where content for delivery of their content, especially in the case where content
protection or user authentication is required (e.g., must use HTTPS). protection or user authentication is required (e.g., must use HTTPS).
CSPs may also perform per-request authentication/authorization CSPs may also perform per-request authentication/authorization
decision and then have the CDNs enforce that decision (e.g., must decision and then have the CDNs enforce that decision (e.g., must
validate URL signing, etc.). validate URL signing, etc.).
skipping to change at page 17, line 23 skipping to change at page 16, line 4
Phone: +33 1 45 29 89 46 Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange.com Email: gilles.bertrand@orange.com
Stephan Emile Stephan Emile
France Telecom - Orange France Telecom - Orange
2 avenue Pierre Marzin 2 avenue Pierre Marzin
Lannion F-22307 Lannion F-22307
France France
Email: emile.stephan@orange.com 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 Trevor Burbridge
BT BT
B54 Room 70, Adastral Park, Martlesham B54 Room 70, Adastral Park, Martlesham
Ipswich, IP5 3RE Ipswich, IP5 3RE
UK UK
Email: trevor.burbridge@bt.com Email: trevor.burbridge@bt.com
Philip Eardley Philip Eardley
BT BT
B54 Room 77, Adastral Park, Martlesham B54 Room 77, Adastral Park, Martlesham
Ipswich, IP5 3RE Ipswich, IP5 3RE
UK UK
Email: philip.eardley@bt.com Email: philip.eardley@bt.com
Kevin Ma
Azuki Systems Kevin J. Ma
Azuki Systems, Inc.
43 Nagog Park 43 Nagog Park
Acton, MA 01720 Acton, MA 01720
USA USA
Phone: +1 978 844 5100 Phone: +1 978-844-5100
Email: kevin.ma@azukisystems.com Email: kevin.ma@azukisystems.com
Grant Watson
Alcatel-Lucent (Velocix)
3 Ely Road
Milton, Cambridge CB24 6AA
UK
Email: gwatson@velocix.com
 End of changes. 55 change blocks. 
221 lines changed or deleted 184 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/