< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/