draft-ietf-cdni-use-cases-02.txt   draft-ietf-cdni-use-cases-03.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: July 21, 2012 G. Watson Expires: August 2, 2012 G. Watson
T. Burbridge T. Burbridge
P. Eardley P. Eardley
BT BT
K. Ma K. Ma
Azuki Systems Azuki Systems
January 18, 2012 January 30, 2012
Use Cases for Content Delivery Network Interconnection Use Cases for Content Delivery Network Interconnection
draft-ietf-cdni-use-cases-02 draft-ietf-cdni-use-cases-03
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 focuses on use cases that solutions) for interconnecting CDNs. It 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 a CDN Interconnection (CDNI) solution is available. realized once a CDN Interconnection (CDNI) solution is available.
This document can be used to provide guidance to the CDNI WG about This document can be used to provide guidance to the CDNI WG about
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 July 21, 2012. This Internet-Draft will expire on August 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 11, line 36 skipping to change at page 11, line 36
understanding of origin server availability and be better equipped to understanding of origin server availability and be better equipped to
both distribute load between origin servers and attempt content both distribute load between origin servers and attempt content
acquisition from alternate origin servers when acquisition failures acquisition from alternate origin servers when acquisition failures
occur. When normal content acquisition fails, a CDN may need to try occur. When normal content acquisition fails, a CDN may need to try
other origin server options, e.g.: other origin server options, e.g.:
o an upstream CDN may acquire content from an alternate CSP origin o an upstream CDN may acquire content from an alternate CSP origin
server, server,
o a downstream CDN may acquire content from an alternate Surrogate o a downstream CDN may acquire content from an alternate Surrogate
within an upstream CDN, as directed by the upstream CDN's request within an upstream CDN,
routing interface,
o a downstream CDN may acquire content from an alternate upstream o a downstream CDN may acquire content from an alternate upstream
CDN, or CDN, or
o a downstream CDN may acquire content directly from the CSP's o a downstream CDN may acquire content directly from the CSP's
origin server. origin server.
Though content acquisition protocols are beyond the scope of CDNI, Though content acquisition protocols are beyond the scope of CDNI,
the selection of content acquisition sources should be considered. the selection of content acquisition sources should be considered.
skipping to change at page 14, line 26 skipping to change at page 14, line 26
An uCDN needs to be able to exclude dCDNs which lack support for the An uCDN needs to be able to exclude dCDNs which lack support for the
secure access features requested by the CSP. secure access features requested by the CSP.
5.3. Branding 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. 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 endusers 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 forbid the delivery of separate CDN Providers. The CSP may wish to forbid 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.
Similar restrictions may exist when the uCDN wants to offer CDN Analogous 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 Similarly, a CDN Provider might not want the brand of an intermediary
to be visible, even if the CDN Exchange is involved in the content in the CDN delegation chain to be visible, even if the intermediary
delivery call flow. is involved in the content delivery call flow.
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.
skipping to change at page 15, line 28 skipping to change at page 15, line 28
b. The relationship between the uCDN and dCDN: the transitive trust b. The relationship between the uCDN and dCDN: the transitive trust
relationship that extends the contract defined in (a) above and relationship that extends the contract defined in (a) above and
that authorizes the dCDN to acquire content on uCDN's or CSP's that authorizes the dCDN to acquire content on uCDN's or CSP's
origin servers and to deliver it, potentially with content origin servers and to deliver it, potentially with content
delivery restrictions. delivery restrictions.
c. The relationship between the End User and dCDN: the recognition c. The relationship between the End User and dCDN: the recognition
of right to download predicated on (b) above. of right to download predicated on (b) above.
d. The relationship between the End User and the CSP: the contract d. The relationship between the End User and the CSP: the contract
that authorizes the End User to access to the content. that authorizes the End User to access the content.
CDNI should enable the four parties (CSP, uCDN, dCDN, End User) to CDNI should enable the four parties (CSP, uCDN, dCDN, End User) to
negotiate a security method or a method for confirming authorization negotiate a security method or a method for confirming authorization
along the chain of trust (CSP -> uCDN -> dCDN -> End User). along the chain of trust (CSP -> uCDN -> dCDN -> End User).
The security issues fall into three general categories: The security issues fall into three general categories:
o CSP Trust: where the CSP may have negotiated service level o CSP Trust: where the CSP may have negotiated service level
agreements for delivery quality of service with the uCDN, and/or agreements for delivery quality of service with the uCDN, and/or
configured distribution policies (e.g., geo-restrictions, configured distribution policies (e.g., geo-restrictions,
skipping to change at page 16, line 40 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-02 (work in Statement", draft-ietf-cdni-problem-statement-03 (work in
progress), January 2012. 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,
 End of changes. 10 change blocks. 
13 lines changed or deleted 12 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/