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