draft-ietf-cdni-use-cases-10.txt   rfc6770.txt 
Internet Engineering Task Force G. Bertrand, Ed. Internet Engineering Task Force (IETF) G. Bertrand, Ed.
Internet-Draft E. Stephan Request for Comments: 6770 E. Stephan
Obsoletes: 3570 (if approved) France Telecom - Orange Obsoletes: 3570 France Telecom - Orange
Intended status: Informational T. Burbridge Category: Informational T. Burbridge
Expires: February 10, 2013 P. Eardley ISSN: 2070-1721 P. Eardley
BT BT
K. Ma K. Ma
Azuki Systems, Inc. Azuki Systems, Inc.
G. Watson G. Watson
Alcatel-Lucent (Velocix) Alcatel-Lucent (Velocix)
August 9, 2012 November 2012
Use Cases for Content Delivery Network Interconnection Use Cases for Content Delivery Network Interconnection
draft-ietf-cdni-use-cases-10
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 while keeping cost End User experience of a content delivery service while keeping cost
at a reasonable level. This document focuses on use cases that at a reasonable level. This document focuses on use cases that
correspond to identified industry needs and that are expected to be correspond to identified industry needs and that are expected to be
realized once open interfaces and protocols supporting realized once open interfaces and protocols supporting the
interconnection of CDNs are specified and implemented. The document interconnection of CDNs are specified and implemented. This document
can be used to motivate the definition of the requirements to be can be used to motivate the definition of the requirements to be
supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC
3570. 3570.
Status of this Memo 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 This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on February 10, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6770.
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
skipping to change at page 2, line 24 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Rationale for CDN Interconnection . . . . . . . . . . . . 4 1.3. Rationale for CDN Interconnection . . . . . . . . . . . . 4
2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 6 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 6
2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . 7 2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 7
2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 8
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. Capability Use Cases . . . . . . . . . . . . . . . . . . . . . 11
4.1. Device and Network Technology Extension . . . . . . . . . 11 4.1. Device and Network Technology Extension . . . . . . . . . 11
4.2. Technology and Vendor Interoperability . . . . . . . . . . 12 4.2. Technology and Vendor Interoperability . . . . . . . . . . 12
4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12
5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Content Service Providers' Delivery Policies . . . . 14 Appendix A. Content Service Providers' Delivery Policies . . . . 14
A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 14 A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 14
A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15 A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15
A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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 while keeping cost End User experience of a content delivery service while keeping cost
at a reasonable level. This document focuses on use cases that at a reasonable level. This document focuses on use cases that
correspond to identified industry needs and that are expected to be correspond to identified industry needs and that are expected to be
realized once open interfaces and protocols supporting realized once open interfaces and protocols supporting the
interconnection of CDNs are specified and implemented. The document interconnection of CDNs are specified and implemented. The document
can be used to motivate the definition of the requirements (as can be used to motivate the definition of the requirements (as
documented in [I-D.ietf-cdni-requirements]) to be supported by the documented in [CDNI-REQ]) to be supported by the set of CDN
set of CDN Interconnection (CDNI) interfaces defined in Interconnection (CDNI) interfaces defined in [RFC6707].
[I-D.ietf-cdni-problem-statement].
RFC 3570 described slightly different terminologies and models for [RFC3570] describes slightly different terminologies and models for
"Content Internetworking (CDI)". The present document obsoletes RFC "Content Internetworking (CDI)". This document obsoletes RFC 3570 to
3570 to avoid confusion. avoid confusion.
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 in order Then, the document highlights the need for interoperability in order
to exchange and enforce content delivery policies (Section 5). to exchange and enforce content delivery policies (Section 5).
1.1. Terminology 1.1. Terminology
In this document, the first letter of each CDNI-specific term is In this document, the first letter of each CDNI-specific term is
capitalized. We adopt the terminology described in capitalized. We adopt the terminology described in [RFC6707].
[I-D.ietf-cdni-problem-statement].
We extend this terminology with the following terms. We extend this terminology with the following term:
Access CDN: Access CDN:
A CDN that includes Surrogates in the same administrative network as A CDN that includes Surrogates in the same administrative network as
the end-user. Such CDN can use accurate information on the End the End User. Such a CDN can use accurate information on the End
User's network context to provide valued-added Content Delivery User's network context to provide additional Content Delivery
Services to Content Service Providers. Services to Content Service Providers.
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 EU: End User o EU: End User
o ISP: Internet Service Provider o ISP: Internet Service Provider
o NSP: Network Service Provider o NSP: Network Service Provider
skipping to change at page 4, line 43 skipping to change at page 4, line 38
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 and higher throughput lower latency (decreased round-trip-time and higher throughput
between the user and the delivery server) and better robustness between the user and the delivery server) and better robustness
(ability to use multiple delivery servers), (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) internal o reduce the Content Service Provider's (CSP) internal
infrastructure costs, such as datacenter capacity, space, and infrastructure costs, such as data center capacity, space, and
electricity consumption, as popular content is delivered electricity consumption, as popular content is delivered
externally through the CDN rather than through the CSP's own externally through the CDN rather than through the CSP's own
servers. 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 stand-alone 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, where two CDN Providers establish An example is depicted in Figure 1, where two CDN Providers establish
a 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. agreement with CDN Provider 'A' for the delivery of its content.
Independently, CDN Provider 'A' and CDN Provider 'B' agree to Independently, CDN Provider 'A' and CDN Provider 'B' agree to
interconnect their CDNs. interconnect their CDNs.
When a given User Agent requests content from CSP-1, CDN-A may When a given User Agent requests content from CSP-1, CDN-A may
consider that delivery by CDN-B is appropriate, for instance, because consider that delivery by CDN-B is appropriate, for instance, because
skipping to change at page 5, line 26 skipping to change at page 5, line 21
Through the CDN Interconnection arrangements put in place between Through the CDN Interconnection arrangements put in place between
CDN-A and CDN-B (as a result of the CDN Interconnection agreement 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 established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can
redirect the request to CDN-B and the content is actually delivered redirect the request to CDN-B and the content is actually delivered
to the User Agent by CDN-B. 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, see [RFC6390]), because the content is delivered of Experience (QoE, see [RFC6390]), because the content is delivered
from a nearby Surrogate (e.g., lower latency, bottlenecks avoided). from a nearby Surrogate (e.g., lower latency, bottlenecks avoided).
CDN Provider 'A' benefits because it does not need to deploy such an CDN Provider 'A' benefits because it does not need to deploy such an
extensive CDN, whilst CDN Provider 'B' may receive some compensation extensive CDN, while CDN Provider 'B' may receive some compensation
for the delivery. CSP-1 benefits because it only needs to make one for the delivery. CSP-1 benefits because it only needs to make one
business agreement and one technical arrangement with CDN Provider business agreement and one technical arrangement with CDN Provider
'A', but its End Users get a service quality as though CSP-1 had also 'A', but its End Users get a service quality as though CSP-1 had also
gone to the trouble of making a business agreement and technical gone to the trouble of making a business agreement and technical
arrangement with CDN Provider 'B'. arrangement with CDN Provider 'B'.
+-------+ +-------+ +-------+ +-------+
| CSP-1 | | CSP-2 | | CSP-1 | | CSP-2 |
+-------+ +-------+ +-------+ +-------+
| | | |
skipping to change at page 6, line 22 skipping to change at page 6, line 15
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 o without incurring the cost of deploying and operating Surrogates
and the associated CDN infrastructure that may not be justified in and the associated CDN infrastructure that may not be justified in
the corresponding geographic region (e.g., because of relatively the corresponding geographic region (e.g., because of relatively
low delivery volume, or conversely because of the high investments low delivery volume, or conversely because of the high investments
that would be needed to satisfy the high volume). 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.
The French CDN Provider's network only covers France, so it makes an The French CDN Provider's network only covers France, so it makes an
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
The previous section describes the case of geographic extension The previous section describes the case of geographic extension
between CDNs operated by different entities. A large CDN Provider between CDNs operated by different entities. A large CDN Provider
may have several subsidiaries that also each operate their own CDN may have several subsidiaries that each operate their own CDN (which
(which may rely on different CDN technologies, see Section 4.2). In may rely on different CDN technologies, see Section 4.2). In certain
certain circumstances, the CDN Provider needs to make these CDNs circumstances, the CDN Provider needs to make these CDNs interoperate
interoperate to provide a consistent service to its customers on the to provide consistent service to its customers on the whole
whole collective footprint. collective footprint.
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 ISP's 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 ISP (acting as an Access CDN), the Authoritative CDN, and the 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 CSP that would make a case for establishing a CDNI agreement. For
example: example:
o Allow the CSP to offer improved QoE and QoE services to o allowing the CSP to offer improved QoE and QoE services to
subscribers, for example, reduced content startup time or subscribers, for example, reduced content startup time or
increased video quality and resolution of adaptive streaming increased video quality and resolution of adaptive streaming
content. content.
o Allow the Authoritative CDN to reduce hardware capacity and o allowing 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 allowing 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 ingress o allowing the ISP to influence and/or control the traffic ingress
points. points.
o Allow the ISP to derive some incremental revenue for transport of o allowing the ISP to derive some incremental revenue for transport
the traffic and to monetize QoE services. of 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
access networks to continue to access their content. The motivation access networks to continue to access their content. The motivation
of this case is to allow nomadic End Users to maintain access to 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 content with a consistent QoE across a range of devices and/or
geographic regions. geographic regions.
This use case covers situations like: This use case covers situations like:
o End Users moving between different access networks, which may be o End Users moving between different access networks, which may be
located within the same geographic region or different geographic located within the same geographic region or different geographic
regions, 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.
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 ISP A, her "home ISP". has a subscription to a broadband service from ISP A, her "home ISP".
ISP A hosts CDN-A. Ordinarily, when End User A accesses content via ISP A hosts CDN-A. Ordinarily, when End User A accesses content via
ISP A (her "home ISP") the content is delivered from CDN-A, which in ISP A (her "home ISP"), the content is delivered from CDN-A, which in
this example is within ISP A's network. this example is within ISP A's network.
However, while End User A is not connected to ISP A's network, for However, while End User A is not connected to ISP 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 delivered by
by an alternate CDN (CDN-B), in this case, hosted in the network of an alternate CDN (CDN-B), in this case, hosted in the network of the
the WiFi or mobile provider (ISP B), rather than from CDN-A in ISP WiFi or mobile provider (ISP B), rather than from CDN-A in ISP A's
A's network. network.
+-------+ +-------+
|Content| |Content|
+-------+ +-------+
| |
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' NSP A `-. ,-' NSP B `-. ,-' ISP A `-. ,-' ISP B `-.
( (CDN-A) )=====( (CDN-B) ) ( (CDN-A) )=====( (CDN-B) )
`-. ,-' `-. ,-' `-. ,-' `-. ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
| | | |
+------------+ +---------------+ +------------+ +---------------+
+ EU A (home)| | EU A (nomadic)| + EU A (home)| | EU A (nomadic)|
+------------+ +---------------+ +------------+ +---------------+
=== CDN Interconnection === CDN Interconnection
Figure 2 Figure 2
Though the content of CSP A is not accessible by typical End Users of Though the content of CSP A is not accessible by typical End Users of
CDN-B, End User A is able to gain access to their "home" content CDN-B, End User A is able to gain access to her "home" content (i.e.,
(i.e., the content of CSP A) through the alternate CDN (CDN-B). the content of CSP A) through the alternate CDN (CDN-B).
Depending on CSP's content delivery policies (see Appendix A.1), a Depending on the CSP's content delivery policies (see Appendix A.1),
user moving to a different geographic region may be subject to geo- a user moving to a different geographic region may be subject to geo-
blocking content delivery restrictions. In this case, he/she may not blocking content delivery restrictions. In this case, he/she may not
be allowed to access some pieces of content. be allowed to access some pieces of content.
3. Offload Use Cases 3. Offload Use Cases
3.1. Overload Handling and Dimensioning 3.1. Overload Handling and Dimensioning
A CDN is likely to be dimensioned to support an expected maximum A CDN is likely to be dimensioned to support an expected maximum
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 each other's resources during their respective
respective peaks of activity. peaks of activity.
Offload also applies to planned situations where a CDN Provider needs Offload also applies to planned situations in which a CDN Provider
CDN capacity in a particular region during a short period of time. needs CDN capacity in a particular region during a short period of
For example, a CDN can offload traffic to another CDN during a time. For example, a CDN can offload traffic to another CDN for the
specific maintenance operation or for covering the distribution of a duration of a specific maintenance operation or for the distribution
special event, as in the scenario depicted in Figure 3. For of a special event, as in the scenario depicted in Figure 3. For
instance, consider a TV-channel which is the distributor for a major instance, consider a TV channel that is the distributor for a major
event, such as a celebrities' wedding, or a major sport competition event, such as a celebrity's wedding or a major sport competition,
and this TV-channel has contracted particular CDNs for the delivery. and this TV channel has contracted particular CDNs for the delivery.
The CDNs (CDN-A and CDN-B) that the TV-channel uses for delivering The CDNs (CDN-A and CDN-B) that the TV channel uses for delivering
the content related to this event are likely to experience a flash the content related to this event are likely to experience a flash
crowd during the event and to need offloading traffic, while other crowd during the event and will need to offload traffic, while other
CDNs (CDN-C) will support a more usual traffic load and be able to CDNs (CDN-C) will support a more typical traffic load and be able to
handle the offloaded traffic. handle the offloaded traffic.
In this use case, the Delivering CDN on which requests are offloaded In this use case, the Delivering CDN on which requests are offloaded
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 each dCDN.
+------------+ +------------+
| TV Channel | | TV Channel |
+------------+ +------------+
| \ | \
,-,--,-. \ ,-,--,-. ,-,--,-. ,-,--,-. \ ,-,--,-. ,-,--,-.
,' `. ,' `. ,' CDN-C `. ,' `. ,' `. ,' CDN-C `.
( CDN-A ) ( CDN-B )==( offload ) ( CDN-A ) ( CDN-B )==( offload )
`. ,' `. ,' `. ,' `. ,' `. ,' `. ,'
`-'--'-' `-'--'-' `-'--'-' `-'--'-' `-'--'-' `-'--'-'
skipping to change at page 10, line 13 skipping to change at page 10, line 5
Figure 3 Figure 3
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 three options: partial failure scenarios, a CDN Provider has at least three options:
1. if possible, use internal mechanisms to redirect traffic on 1. if possible, use internal mechanisms to redirect traffic onto
surviving equipment, surviving equipment,
2. depending on traffic management policies, forward some requests 2. depending on traffic management policies, forward some requests
to the CSP's origin servers, and to the CSP's origin servers, and/or
3. redirect some requests toward another CDN, which must be able to 3. redirect some requests toward another CDN, which must be able to
serve the redirected requests. serve the redirected requests.
The last option is a use case for CDNI. 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.
The ability to support content acquisition resiliency, is an The ability to support content acquisition resiliency is an important
important use case for interconnected CDNs. When the content use case for interconnected CDNs. When the content acquisition
acquisition source fails, the CDN might switch to another content source fails, the CDN might switch to another content acquisition
acquisition source. Similarly, when several content acquisition source. Similarly, when several content acquisition sources are
sources are available, a CDN might balance the load between these available, a CDN might balance the load between these multiple
multiple sources. 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
both distribute load between origin servers and attempt content to both distribute load between origin servers and attempt content
acquisition from alternate content sources 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 content source options, e.g.: other content source options, for example:
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 and the selection of content acquisition sources should be considered and
facilitated. facilitated.
4. CDN Capability Use Cases 4. 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: that:
o that the CDN Provider is not willing to provide or, o the CDN Provider is not willing to provide, or
o that its own CDN is not able to support. o 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 [RFC2818]. CDN-A may use CDN-B's traffic that requires HTTPS [RFC2818]. CDN-A may use CDN-B's
footprint (which may overlap with its own) to deliver HTTPS footprint (which may overlap with its own) to deliver HTTPS
without needing to deploy its own infrastructure. This case without needing to deploy its own infrastructure. This case
could also be true of other formats, delivery protocols (RTMP, could also be true of other formats, delivery protocols (e.g.,
RTSP, etc.) and features (specific forms of authorization such as the Real Time Messaging Protocol (RTMP), the Real Time Streaming
tokens, per session encryption, etc.). Protocol (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 2. CDN-A has a footprint covering traditional fixed-line broadband
wants to extend coverage to mobile devices. In this case, CDN-A and wants to extend coverage to mobile devices. In this case,
may contract and interconnect with CDN-B who has both: CDN-A may contract and interconnect with CDN-B, who has both:
* physical footprint inside the mobile network, * a 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.
3. CDN-A only supports IPv4 within its infrastructure but wants to 3. CDN-A only supports IPv4 within its infrastructure but wants to
deliver content over IPv6. CDN-B supports both IPv4 and IPv6 deliver content over IPv6. CDN-B supports both IPv4 and IPv6
within its infrastructure. CDN-A interconnects with CDN-B to within its infrastructure. CDN-A interconnects with CDN-B to
serve out its content over native IPv6 connections. serve out its content over native IPv6 connections.
These cases can apply to many CDN features that a given CDN Provider These cases can apply to many CDN features that a given CDN Provider
may not be able to support or not be willing to invest in, and thus, may not be able to support or not be willing to invest in, and thus,
that the CDN Provider would delegate to another CDN. that the CDN Provider would delegate to another CDN.
4.2. Technology and Vendor Interoperability 4.2. Technology and Vendor Interoperability
A CDN Provider may deploy a new CDN to run alongside its existing A CDN Provider may deploy a new CDN to run alongside its existing CDN
CDN, as a simple way of migrating its CDN service to a new as a simple way of migrating its CDN service to a new technology. In
technology. In addition, a CDN Provider may have a multi-vendor addition, a CDN Provider may have a multi-vendor strategy for its CDN
strategy for its CDN deployment. Finally, a CDN Provider may want to deployment. Finally, a CDN Provider may want to deploy a separate
deploy a separate CDN for a particular CSP or a specific network. In CDN for a particular CSP or a specific network. In all these
all these circumstances, CDNI benefits the CDN Provider, as it circumstances, CDNI benefits the CDN Provider, as it simplifies or
simplifies or automates some inter-CDN operations (e.g., migrating automates some inter-CDN operations (e.g., migrating the request
the request routing function progressively). routing function progressively).
4.3. QoE and QoS Improvement 4.3. QoE and QoS Improvement
Some CSPs are willing to pay a premium for enhanced delivery of Some CSPs are willing to pay a premium for enhanced delivery of
content to their End Users. In some cases, even if the CDN Provider 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 would not meet the
service level requirements. As a result, the CDN Provider may CSP's 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 that is able to deliver content from Surrogates located
the End User and with the required service level. closer to the End User and with the required service level.
5. Enforcement of Content Delivery Policy 5. Enforcement of Content Delivery Policy
An important aspect common to all the above use cases is that CSPs An important aspect common to all the above use cases is that CSPs
typically want to enforce content delivery policies. A CSP may want typically want to enforce content delivery policies. A CSP may want
to define content delivery policies that specify when, how, and/or to to define content delivery policies that specify when, how, and/or to
whom the CDN delivers content. These policies apply to all whom the CDN delivers content. These policies apply to all
interconnected CDNs (uCDNs and dCDNs) in the same or similar way that interconnected CDNs (uCDNs and dCDNs) in the same or similar way that
a CSP can define content delivery policies for content delivered by a a CSP can define content delivery policies for content delivered by a
single, non-interconnected CDN. Appendix A provides examples of CSP single, non-interconnected CDN. Appendix A provides examples of CSP-
defined 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.
Finally, the authors acknowledge the work of the former CDI working Finally, the authors acknowledge the work of the former CDI working
group, which is now obsoleted to avoid confusion. group. This document obsoletes [RFC3570] to avoid confusion.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations 7. Security Considerations
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 the associated threats. Those Interconnection and does not analyze the associated threats. Those
are discussed in [I-D.ietf-cdni-problem-statement]. Appendix A.2 threats are discussed in [RFC6707]. Appendix A.2 of this document
provides example security policies that CSPs might impose on CDNs to provides example security policies that CSPs might impose on CDNs to
mitigate the threats. mitigate the threats.
9. References 8. References
9.1. Normative References 8.1. Normative References
[I-D.ietf-cdni-problem-statement] [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar,
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content "Content Distribution Network Interconnection (CDNI)
Distribution Network Interconnection (CDNI) Problem Problem Statement", RFC 6707, September 2012.
Statement", draft-ietf-cdni-problem-statement-08 (work in
progress), June 2012.
9.2. Informative References 8.2. Informative References
[I-D.ietf-cdni-requirements] [CDNI-REQ] Leung, K. and Y. Lee, "Content Distribution Network
Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", Work in Progress,
Interconnection (CDNI) Requirements", June 2012.
draft-ietf-cdni-requirements-03 (work in progress),
June 2012.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
Performance Metric Development", BCP 170, RFC 6390, Internetworking (CDI) Scenarios", RFC 3570, July 2003.
October 2011.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
October 2011.
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 appendix 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 constraints of varying policies for audiovisual content often combine constraints of varying
levels of complexity and sophistication, e.g.: levels of complexity and sophistication, for example:
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 user agent platform constraints (e.g., mobile device platforms, o user agent platform constraints (e.g., mobile device platforms,
desktop computer platforms, set-top-box platforms, etc.), desktop computer platforms, set-top-box platforms, etc.),
o resolution-based constraints (e.g., high definition vs. standard o resolution-based constraints (e.g., high definition vs. standard
definition encodings), definition encodings),
o user agent identification or authorization, o user agent identification or authorization,
o access network constraints (e.g., per NSP), and o access network constraints (e.g., per NSP), and
o IP geo-blocking constraints (e.g., for a given coverage area). o IP geo-blocking constraints (e.g., for a given coverage area).
CSPs may use sophisticated policies in accordance to their business CSPs may use sophisticated policies in accordance with their business
model. However, the enforcement of those policies does not model. However, the enforcement of those policies does not
necessarily require that the delivery network understand the policy necessarily require that the delivery network understand the policy
rationales or how policies apply to specific content assets. Content rationales or how policies apply to specific content assets. Content
delivery policies may indeed be distilled into simple rules which can delivery policies may be distilled into simple rules that can be
be commonly enforced across all dCDNs. These rules may influence commonly enforced across all dCDNs. These rules may influence dCDN
dCDN delegation and Surrogate selection decisions, for instance, to delegation and Surrogate selection decisions, for instance, to ensure
ensure that the specific rules (e.g. time-window, geo-blocking, pre- that the specific rules (e.g., time-window, geo-blocking, pre-
authorization validation) can indeed be enforced by the delivering authorization validation) can indeed be enforced by the Delivering
CDN. In turn, this can guarantee to the CSP that content delivery CDN. In turn, this can guarantee to the CSP that content delivery
policies are properly applied. policies are properly applied.
+-----+ +-----+
| CSP | Policies driven by business (e.g., available | CSP | Policies driven by business (e.g., available only
+-----+ only in UK and only from July 1st to September 1st) +-----+ in the UK and only from July 1st to September 1st)
\ \
\ Translate policies into \ Translate policies into
\simple rules (e.g., provide an authorization token) \simple rules (e.g., provide an authorization token)
\ \
V V
+-----+ +-----+
| CDN | Apply simple rules (e.g., check an | CDN | Apply simple rules (e.g., check an
+-----+ authorization token and enforce geo-blocking) +-----+ authorization token and enforce geo-blocking)
\ \
\ Distribute simple rules \ Distribute simple rules
V V
+-----+ +-----+
| CDN | Apply simple rules | CDN | Apply simple rules
+-----+ +-----+
Figure 4 Figure 4
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 that are acceptable
for delivery of their content, especially in the case where a secured for delivery of their content, especially in the case where a secured
content transmission is required (e.g., must use HTTPS). CSPs may content transmission is required (e.g., must use HTTPS). CSPs may
also perform per-request authentication/authorization decision and also perform a per-request authentication/authorization decision and
then have the CDNs enforce that decision (e.g., must validate URL then have the CDNs enforce that decision (e.g., must validate URL
signing, etc.). signing, etc.).
A.3. Branding A.3. Branding
Preserving the branding of the CSP throughout delivery is often Preserving the branding of the CSP throughout delivery is often
important to the CSP. CSPs may desire to offer content services important to the CSP. CSPs may desire to offer content services
under their own name, even when the associated CDN service involves under their own name, even when the associated CDN service involves
other CDN Providers. For instance, a CSP may desire to ensure that other CDN Providers. For instance, a CSP may desire to ensure that
content is delivered with URIs appearing to the End Users under the content is delivered with URIs appearing to the End Users under the
CSP's own domain name, even when the content delivery involves CSP's own domain name, even when the content delivery involves
separate CDN Providers. The CSP may wish to prevent the delivery of separate CDN Providers. The CSP may wish to prevent the delivery of
its content by specific dCDNs that lack support for such branding its content by specific dCDNs that lack support for such branding
preservation features. preservation features.
Analogous cases exist when the uCDN wants to offer CDN services under Analogous cases exist when the uCDN wants to offer CDN services under
its own branding even if dCDNs are involved. Similarly, a CDN its own branding even if dCDNs are involved, and so it restricts the
Provider might wish to restrict the delivery delegation to a chain delivery delegation to a chain that preserves its brand visibility.
that preserves its brand visibility.
Authors' Addresses Authors' Addresses
Gilles Bertrand (editor) Gilles Bertrand (editor)
France Telecom - Orange France Telecom - Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy les Moulineaux, 92130 Issy les Moulineaux, 92130
FR FR
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 FR
EMail: emile.stephan@orange.com
Email: emile.stephan@orange.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 J. Ma Kevin J. Ma
Azuki Systems, Inc. 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 Grant Watson
Alcatel-Lucent (Velocix) Alcatel-Lucent (Velocix)
3 Ely Road 3 Ely Road
Milton, Cambridge CB24 6AA Milton, Cambridge CB24 6AA
UK UK
EMail: gwatson@velocix.com
Email: gwatson@velocix.com
 End of changes. 91 change blocks. 
185 lines changed or deleted 170 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/