draft-ietf-cdni-use-cases-09.txt   draft-ietf-cdni-use-cases-10.txt 
Internet Engineering Task Force G. Bertrand, Ed. Internet Engineering Task Force G. Bertrand, Ed.
Internet-Draft E. Stephan Internet-Draft E. Stephan
Obsoletes: 3570 (if approved) France Telecom - Orange Obsoletes: 3570 (if approved) France Telecom - Orange
Intended status: Informational T. Burbridge Intended status: Informational T. Burbridge
Expires: January 11, 2013 P. Eardley Expires: February 10, 2013 P. Eardley
BT BT
K. Ma K. Ma
Azuki Systems, Inc. Azuki Systems, Inc.
G. Watson G. Watson
Alcatel-Lucent (Velocix) Alcatel-Lucent (Velocix)
July 10, 2012 August 9, 2012
Use Cases for Content Delivery Network Interconnection Use Cases for Content Delivery Network Interconnection
draft-ietf-cdni-use-cases-09 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
interconnection of CDNs are specified and implemented. The document interconnection of CDNs are specified and implemented. The document
can be used to guide 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 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 January 11, 2013. This Internet-Draft will expire on February 10, 2013.
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 21 skipping to change at page 2, line 21
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.
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 Multi-CDN Systems . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 6 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 9 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 9
3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Failure of Content Delivery Resources . . . . . . . . 9 3.2.1. Failure of Content Delivery Resources . . . . . . . . 10
3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10
4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 10 4. CDN 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 . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Informative References . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Content Service Providers' Delivery Policies . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Content Service Providers' Delivery Policies . . . . 14
A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 14
A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15
A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
interconnection of CDNs are specified and implemented. The document interconnection of CDNs are specified and implemented. The document
can be used to guide 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 [I-D.ietf-cdni-requirements]) to be supported by the
set of CDN Interconnection (CDNI) interfaces defined in set of CDN Interconnection (CDNI) interfaces defined in
[I-D.ietf-cdni-problem-statement]. [I-D.ietf-cdni-problem-statement].
RFC 3570 described slightly different terminologies and models for RFC 3570 described slightly different terminologies and models for
"Content Internetworking (CDI)". The present document obsoletes RFC "Content Internetworking (CDI)". The present document obsoletes RFC
3570 to avoid confusion. 3570 to 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:
skipping to change at page 3, line 36 skipping to change at page 3, line 36
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
We adopt the terminology described in In this document, the first letter of each CDNI-specific term is
[I-D.ietf-cdni-problem-statement], and [I-D.ietf-cdni-framework]. capitalized. We adopt the terminology described in
[I-D.ietf-cdni-problem-statement].
We extend this terminology with the following terms. We extend this terminology with the following terms.
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 CDN can use accurate information on the End
User's network context to provide valued-added Content Delivery User's network context to provide valued-added Content Delivery
Services to Content Service Providers. Services to Content Service Providers.
skipping to change at page 3, line 49 skipping to change at page 4, line 4
We extend this terminology with the following terms. We extend this terminology with the following terms.
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 CDN can use accurate information on the End
User's network context to provide valued-added Content Delivery User's network context to provide valued-added 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 DRM: Digital Rights Management
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
o QoE: Quality of Experience o QoE: Quality of Experience
o QoS: Quality of Service o QoS: Quality of Service
o uCDN: upstream CDN o uCDN: upstream CDN
o URL: Uniform Resource Locator o URL: Uniform Resource Locator
o WiFi: Wireless Fidelity o WiFi: Wireless local area network (WLAN) based on IEEE 802.11
1.3. Rationale for Multi-CDN Systems 1.3. Rationale for CDN Interconnection
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 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 costs, such o reduce the Content Service Provider's (CSP) internal
as datacenter capacity, space, and electricity consumption, as infrastructure costs, such as datacenter capacity, space, and
popular content is delivered externally through the CDN rather electricity consumption, as popular content is delivered
than through the CSP's own servers. externally through the CDN rather 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, 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
skipping to change at page 5, line 21 skipping to change at page 5, line 23
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
CDN-B is an Access CDN and the user is directly attached to it. CDN-B is an Access CDN and the user is directly attached to it.
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), because the content is delivered from a nearby of Experience (QoE, see [RFC6390]), because the content is delivered
Surrogate. CDN Provider 'A' benefits because it does not need to from a nearby Surrogate (e.g., lower latency, bottlenecks avoided).
deploy such an extensive CDN, whilst CDN Provider 'B' may receive CDN Provider 'A' benefits because it does not need to deploy such an
some compensation for the delivery. CSP-1 benefits because it only extensive CDN, whilst CDN Provider 'B' may receive some compensation
needs to make one business agreement and one technical arrangement for the delivery. CSP-1 benefits because it only needs to make one
with CDN Provider 'A', but its End Users get a service quality as business agreement and one technical arrangement with CDN Provider
though CSP-1 had also gone to the trouble of making a business 'A', but its End Users get a service quality as though CSP-1 had also
agreement and technical arrangement with CDN Provider 'B'. gone to the trouble of making a business 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 | | End User |
+------------+ +----------+
=== 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'. However, CSP-2 may also reach an agreement with CDN Provider 'A'. However, CSP-2 may
not want its content to be distributed by CDN Provider B; for not want its content to be distributed by CDN Provider B; for
example, CSP-2 may not have distribution rights in the country where example, CSP-2 may not want to distribute its content in the area
CDN Provider 'B' operates. This example illustrates that policy where CDN Provider 'B' operates. This example illustrates that
considerations are an important part of CDNI. policy 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:
skipping to change at page 7, line 30 skipping to change at page 7, line 35
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 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 ingress
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
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
skipping to change at page 8, line 6 skipping to change at page 8, line 10
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 NSP A, her "home NSP". has subscription to a broadband service from ISP A, her "home ISP".
NSP 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
NSP A (her "home NSP") 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 NSP A's network. this example is within ISP 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 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 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 (NSP B), rather than from CDN-A in NSP the WiFi or mobile provider (ISP B), rather than from CDN-A in ISP
A's network. A's network.
+-------+ +-------+
|Content| |Content|
+-------+ +-------+
| |
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' NSP A `-. ,-' NSP B `-. ,-' NSP A `-. ,-' NSP 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
The alternate CDN (CDN-B) is allowed to distribute the content of CSP Though the content of CSP A is not accessible by typical End Users of
A to End User A; however, no other End Users (e.g., End User B) in CDN-B, End User A is able to gain access to their "home" content
the region of CDN-B are allowed to retrieve the content unless they (i.e., the content of CSP A) through the alternate CDN (CDN-B).
too have such an agreement for nomadic access to content. Note that
the mechanism on how to enforce that End User A is allowed to
retrieve the content but End User B is not, is not part of the
discussion in this memo.
Depending on CSP's content delivery policies (see Appendix A.1), a Depending on CSP's content delivery policies (see Appendix A.1), a
user moving to a different geographic region may be subject to geo- 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
skipping to change at page 9, line 23 skipping to change at page 9, line 23
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 capacity 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, as in the scenario depicted in Figure 3. For
exclusive distribution rights on a major event, such as a instance, consider a TV-channel which is the distributor for a major
celebrities' wedding, or a major sport competition. The CDNs that event, such as a celebrities' wedding, or a major sport competition
the TV-channel uses for delivering the content related to this event and this TV-channel has contracted particular CDNs for the delivery.
are likely to experience a flash crowd during the event and to need The CDNs (CDN-A and CDN-B) that the TV-channel uses for delivering
offloading traffic, while other CDNs will support a more usual the content related to this event are likely to experience a flash
traffic load and be able to handle the offloaded traffic. crowd during the event and to need offloading traffic, while other
CDNs (CDN-C) will support a more usual traffic load and be able to
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 every dCDN.
+------------+
| TV Channel |
+------------+
| \
,-,--,-. \ ,-,--,-. ,-,--,-.
,' `. ,' `. ,' CDN-C `.
( CDN-A ) ( CDN-B )==( offload )
`. ,' `. ,' `. ,'
`-'--'-' `-'--'-' `-'--'-'
=== CDN Interconnection
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 on
surviving equipment, surviving equipment,
skipping to change at page 12, line 39 skipping to change at page 13, line 9
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
group, which is now obsoleted to avoid confusion.
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
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]. are discussed in [I-D.ietf-cdni-problem-statement]. Appendix A.2
provides example security policies that CSPs might impose on CDNs to
mitigate the threats.
9. Informative References 9. References
[I-D.ietf-cdni-framework] 9.1. Normative References
Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-00 (work in
progress), April 2012.
[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-08 (work in Statement", draft-ietf-cdni-problem-statement-08 (work in
progress), June 2012. progress), June 2012.
9.2. Informative References
[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-03 (work in progress), draft-ietf-cdni-requirements-03 (work in progress),
June 2012. 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
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 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
skipping to change at page 14, line 4 skipping to change at page 14, line 29
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 geolocation-based constraints (e.g., per country). 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 to 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 indeed be distilled into simple rules which can
be commonly enforced across all dCDNs. These rules may influence be commonly enforced across all dCDNs. These rules may influence
dCDN delegation and Surrogate selection decisions, for instance, to dCDN delegation and Surrogate selection decisions, for instance, to
ensure that the specific rules (e.g. time-window, geo-blocking, pre- ensure 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 license CDN. In turn, this can guarantee to the CSP that content delivery
violations can be prevented, including prevention of premature access policies are properly applied.
to pre-positioned content or enforcement of geo-blocking policies.
+-----+ +-----+
| CSP | Policies driven by business (e.g., available | CSP | Policies driven by business (e.g., available
+-----+ only in UK and only from July 1st to September 1st) +-----+ only in 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 geoblocking) +-----+ authorization token and enforce geo-blocking)
\ \
\ Distribute simple rules \ Distribute simple rules
V V
+-----+ +-----+
| CDN | Apply simple rules | CDN | Apply simple rules
+-----+ +-----+
Figure 3 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 which are acceptable
for delivery of their content, especially in the case where content for delivery of their content, especially in the case where a secured
protection or user authentication is required (e.g., must use HTTPS). content transmission is required (e.g., must use HTTPS). CSPs may
CSPs may also perform per-request authentication/authorization also perform per-request authentication/authorization decision and
decision and then have the CDNs enforce that decision (e.g., must then have the CDNs enforce that decision (e.g., must validate URL
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
 End of changes. 41 change blocks. 
82 lines changed or deleted 104 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/