draft-ietf-cdni-use-cases-01.txt   draft-ietf-cdni-use-cases-02.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: June 23, 2012 G. Watson Expires: July 21, 2012 G. Watson
T. Burbridge T. Burbridge
P. Eardley P. Eardley
BT BT
K. Ma K. Ma
Azuki Systems Azuki Systems
December 21, 2011 January 18, 2012
Use Cases for Content Delivery Network Interconnection Use Cases for Content Delivery Network Interconnection
draft-ietf-cdni-use-cases-01 draft-ietf-cdni-use-cases-02
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 outlines real world use cases (not technical cost. This document outlines real world use cases (not technical
solutions) for interconnecting CDNs. It can be used to provide solutions) for interconnecting CDNs. It focuses on use cases that
guidance to the CDNI WG about the interconnection arrangements to be correspond to identified industry needs and that are expected to be
supported and to validate the requirements of the various CDNI realized once a CDN Interconnection (CDNI) solution is available.
interfaces. This document can be used to provide guidance to the CDNI WG about
the interconnection arrangements to be supported and to validate the
requirements of the various CDNI interfaces.
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 June 23, 2012. This Internet-Draft will expire on July 21, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5 1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5
1.4. The Need for CDN Interconnection Standards . . . . . . . . 6 1.4. The Need for CDN Interconnection Standards . . . . . . . . 7
2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7
2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7
2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 8 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 8
2.3. Mastering Incoming Traffic . . . . . . . . . . . . . . . . 8 2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 8
2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8
3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 10 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 10
3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Failure of Content Delivery Resources . . . . . . . . 10 3.2.1. Failure of Content Delivery Resources . . . . . . . . 10
3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 11
4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11
4.1. Device and Network Technology Extension . . . . . . . . . 11 4.1. Device and Network Technology Extension . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . 13
5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 13 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 13
5.1. Content Availability . . . . . . . . . . . . . . . . . . . 13 5.1. Content Delivery Restrictions . . . . . . . . . . . . . . 13
5.2. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Secure Access . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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 outlines real world use cases (not technical cost. This document outlines real world use cases (not technical
solutions) for interconnecting CDNs. It can be used to provide solutions) for interconnecting CDNs. It focuses on use cases that
guidance to the CDNI WG about the interconnection arrangements to be correspond to identified industry needs and that are expected to be
supported and to validate the requirements of the various CDNI realized once a CDNI solution is available. This document can be
interfaces. used to provide guidance to the CDNI WG about the interconnection
arrangements to be supported and to validate the requirements of the
various CDNI interfaces.
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 to
exchange and enforce content delivery policies (Section 5). 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.
Access CDN: Access CDN:
A CDN that is directly connected to the End User's access. An Access A CDN that is directly connected to the End User's access. An Access
CDN may have specific information about the End User and the network, CDN may have specific information about the End User and the network,
for instance, End User's profile and access capabilities. for instance, End User's profile and access capabilities.
Delivering CDN: Delivering CDN:
The CDN that delivers the requested piece of content to the End User. The CDN that delivers the requested piece of content to the End User.
In particular, the delivering CDN can be an Access CDN. 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
o NSP: Network Service Provider o NSP: Network Service Provider
skipping to change at page 7, line 22 skipping to change at page 7, line 28
experiments are hardly usable in an operational context, because they experiments are hardly usable in an operational context, because they
suffer from several limitations in terms of functionalities, suffer from several limitations in terms of functionalities,
scalability, and security level. scalability, and security level.
The aim of IETF CDNI WG's solution is, therefore, to overcome such The aim of IETF CDNI WG's solution is, therefore, to overcome such
shortcomings; a full list of requirements is being developed in shortcomings; a full list of requirements is being developed in
[I-D.ietf-cdni-requirements]. [I-D.ietf-cdni-requirements].
2. Footprint Extension Use Cases 2. Footprint Extension Use Cases
Footprint extension is expected to be the 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
skipping to change at page 8, line 17 skipping to change at page 8, line 23
In the previous section, we have described the case of geographic In the previous section, we have described the case of geographic
extension between CDNs operated by different entities. A large CDN extension between CDNs operated by different entities. A large CDN
Provider may also operate CDNs from several subsidiaries (which may Provider may also operate CDNs from several subsidiaries (which may
rely on different CDN solutions, see Section 4.2). In certain rely on different CDN solutions, see Section 4.2). In certain
circumstances, the CDN Provider needs to make its CDNs interoperate circumstances, the CDN Provider needs to make its CDNs interoperate
to provide a consistent service to its customers on its whole to provide a consistent service to its customers on its whole
footprint. For example, the CDN Provider might want to expose a footprint. For example, the CDN Provider might want to expose a
single set of interfaces to the CSPs. single set of interfaces to the CSPs.
2.3. Mastering Incoming Traffic 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 access
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 Access CDN, the Authoritative CDN, and the CSP that would make
a case for establishing a CDNI agreement. For example: 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, QoS and reduced round trip time.
skipping to change at page 10, line 46 skipping to change at page 11, line 5
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 two options:
(1) depending on traffic management policies, forward some requests (1) depending on traffic management policies, forward some requests
to the CSP's origin servers, and (2) redirect some requests toward to the CSP's origin servers, and (2) redirect some requests toward
another CDN, which must be able to serve the redirected requests. another CDN, which must be able to serve the redirected requests.
The second 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 13, line 14 skipping to change at page 13, line 25
5. Enforcement of Content Delivery Policy 5. Enforcement of Content Delivery Policy
CSPs commonly require the ability to place delivery restriction on CSPs commonly require the ability to place delivery restriction on
sets of content, which are provided by existing CDNs. The ability to sets of content, which are provided by existing CDNs. The ability to
support such delivery restrictions across interconnected CDNs is support such delivery restrictions across interconnected CDNs is
desirable, but depends on the capabilities of the involved CDNs. desirable, but depends on the capabilities of the involved CDNs.
Thus, it is important to be able to detect and define when these Thus, it is important to be able to detect and define when these
features cannot be enforced. features cannot be enforced.
5.1. Content Availability 5.1. Content Delivery Restrictions
The content distribution policies that a CSP attaches to a piece of The content distribution policies that a CSP attaches to a piece of
content depend on many criteria. For instance, distribution policies content depend on many criteria. For instance, distribution policies
for audiovisual content often combine: for audiovisual content often combine:
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 resolution-based constraints (e.g., high definition vs. standard
definition), and definition), and
o geolocation-based constraints (e.g., per country). o geolocation-based constraints (e.g., per country).
CSPs may require from their CDN Providers that they translate some of CSPs may require from their CDN Providers that they translate some of
the above requirements into content delivery policies for their CDNs. the above requirements into content delivery policies for their CDNs.
For instance, CDNs might implement "geo-blocking" rules specifying: For instance, CDNs might implement "geo-blocking" rules specifying:
o the geographic regions from where content can be delivered (i.e.,
the location of the Surrogates), or
o geographic locations to which content can be delivered (i.e., the o geographic locations to which content can be delivered (i.e., the
location of the End Users). location of the End Users), or
o the geographic regions from where content can be delivered (i.e.,
the location of the Surrogates).
Similarly, an uCDN might implement some temporal constraints on Similarly, an uCDN might implement some temporal constraints on
content availability. For example, it could restrict access to pre- content availability. For example, it could restrict access to pre-
positioned content prior to the opening of the availability window or positioned content prior to the opening of the availability window or
disable the delivery of content from the dCDNs (e.g., through disable the delivery of content from the dCDNs (e.g., through
purging) after the availability window has closed. purging) after the availability window has closed.
5.2. Branding 5.2. Secure Access
Many protocols exist for delivering content to End Users. CSPs may
often wish to dictate a specific protocol or set of protocols which
are acceptable for delivery of their content, especially in the case
where content protection or user authentication is required (e.g.,
must use HTTPS). CSPs may also wish to perform per-request
authentication/authorization decision and then have the CDNs enforce
that decision (e.g., must validate URL signing, etc.).
An uCDN needs to be able to exclude dCDNs which lack support for the
secure access features requested by the CSP.
5.3. Branding
Preserving the branding of the CSP throughout delivery is often 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. The CSP may request that the name of the CDN other CDN Providers. For instance, a CSP may desire to ensure that
Providers does not appear in the URLs and may wish to specify a content is delivered with URIs appearing to the endusers under the
specific brand related tag to appear in the URLs. The CSP may wish CSP's own domain name, even when the content delivery involves
to forbid the delivery of its content by specific dCDNs that lack separate CDN Providers. The CSP may wish to forbid the delivery of
support for such branding preservation features. its content by specific dCDNs that lack support for such branding
preservation features.
Similar restrictions may exist when the uCDN wants to offer CDN Similar restrictions may exist when the uCDN wants to offer CDN
services under its own branding even if dCDNs are involved. services under its own branding even if dCDNs are involved.
Conversely, a CDN Provider might not want the brand of a CDN Exchange Conversely, a CDN Provider might not want the brand of a CDN Exchange
to be visible, even if the CDN Exchange is involved in the content to be visible, even if the CDN Exchange is involved in the content
delivery call flow. delivery call flow.
5.3. Secure Access
Many protocols exist for delivering content to End Users. CSPs may
often wish to dictate a specific protocol or set of protocols which
are acceptable for delivery of their content, especially in the case
where content protection or user authentication is required (e.g.,
must use HTTPS, or must use URL hashing, etc.).
The CSP may wish to blacklist specific dCDNs which lack support for
these secure access features.
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
skipping to change at page 16, line 28 skipping to change at page 16, line 40
August 2011. August 2011.
[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-01 (work in Statement", draft-ietf-cdni-problem-statement-02 (work in
progress), October 2011. progress), January 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.
[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.
 End of changes. 28 change blocks. 
50 lines changed or deleted 61 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/