draft-ietf-cdni-use-cases-10.txt		rfc6770.txt
	Internet Engineering Task Force G. Bertrand, Ed.		Internet Engineering Task Force (IETF) G. Bertrand, Ed.
	Internet-Draft E. Stephan		Request for Comments: 6770 E. Stephan
	Obsoletes: 3570 (if approved) France Telecom - Orange		Obsoletes: 3570 France Telecom - Orange
	Intended status: Informational T. Burbridge		Category: Informational T. Burbridge
	Expires: February 10, 2013 P. Eardley		ISSN: 2070-1721 P. Eardley
	BT		BT
	K. Ma		K. Ma
	Azuki Systems, Inc.		Azuki Systems, Inc.
	G. Watson		G. Watson
	Alcatel-Lucent (Velocix)		Alcatel-Lucent (Velocix)
	August 9, 2012		November 2012
	Use Cases for Content Delivery Network Interconnection		Use Cases for Content Delivery Network Interconnection
	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 the
	interconnection of CDNs are specified and implemented. The document		interconnection of CDNs are specified and implemented. This document
	can be used to motivate 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
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is not an Internet Standards Track specification; it is
	Task Force (IETF). Note that other groups may also distribute		published for informational purposes.
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 5741.
	This Internet-Draft will expire on February 10, 2013.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc6770.
	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 24		skipping to change at page 2, line 28
	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 CDN Interconnection . . . . . . . . . . . . 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 . . . . . . . . . . . . . 7		2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 9		3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 8
	3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10		3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2.1. Failure of Content Delivery Resources . . . . . . . . 10		3.2.1. Failure of Content Delivery Resources . . . . . . . . 9
	3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10		3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10
	4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11		4. 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 . . . . . . . . . . 12		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 . . . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Appendix A. Content Service Providers' Delivery Policies . . . . 14		Appendix A. Content Service Providers' Delivery Policies . . . . 14
	A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 14		A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 14
	A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15		A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15
	A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15		A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 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 the
	interconnection of CDNs are specified and implemented. The document		interconnection of CDNs are specified and implemented. The document
	can be used to motivate 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 [CDNI-REQ]) to be supported by the set of CDN
	set of CDN Interconnection (CDNI) interfaces defined in		Interconnection (CDNI) interfaces defined in [RFC6707].
	[I-D.ietf-cdni-problem-statement].
	RFC 3570 described slightly different terminologies and models for		[RFC3570] describes slightly different terminologies and models for
	"Content Internetworking (CDI)". The present document obsoletes RFC		"Content Internetworking (CDI)". This document obsoletes RFC 3570 to
	3570 to avoid confusion.		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:
	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 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
	In this document, the first letter of each CDNI-specific term is		In this document, the first letter of each CDNI-specific term is
	capitalized. We adopt the terminology described in		capitalized. We adopt the terminology described in [RFC6707].
	[I-D.ietf-cdni-problem-statement].
	We extend this terminology with the following terms.		We extend this terminology with the following term:
	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 a CDN can use accurate information on the End
	User's network context to provide valued-added Content Delivery		User's network context to provide additional 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 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 4, line 43		skipping to change at page 4, line 38
	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		o reduce the Content Service Provider's (CSP) internal
	infrastructure costs, such as datacenter capacity, space, and		infrastructure costs, such as data center capacity, space, and
	electricity consumption, as popular content is delivered		electricity consumption, as popular content is delivered
	externally through the CDN rather than through the CSP's own		externally through the CDN rather than through the CSP's own
	servers.		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		stand-alone 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
	agreement with CDN Provider 'A' for the delivery of its content.		agreement with CDN Provider 'A' for the delivery of its content.
	Independently, CDN Provider 'A' and CDN Provider 'B' agree to		Independently, CDN Provider 'A' and CDN Provider 'B' agree to
	interconnect their CDNs.		interconnect their CDNs.
	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
	skipping to change at page 5, line 26		skipping to change at page 5, line 21
	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, see [RFC6390]), because the content is delivered		of Experience (QoE, see [RFC6390]), because the content is delivered
	from a nearby Surrogate (e.g., lower latency, bottlenecks avoided).		from a nearby Surrogate (e.g., lower latency, bottlenecks avoided).
	CDN Provider 'A' benefits because it does not need to deploy such an		CDN Provider 'A' benefits because it does not need to deploy such an
	extensive CDN, whilst CDN Provider 'B' may receive some compensation		extensive CDN, while CDN Provider 'B' may receive some compensation
	for the delivery. CSP-1 benefits because it only needs to make one		for the delivery. CSP-1 benefits because it only needs to make one
	business agreement and one technical arrangement with CDN Provider		business agreement and one technical arrangement with CDN Provider
	'A', but its End Users get a service quality as though CSP-1 had also		'A', but its End Users get a service quality as though CSP-1 had also
	gone to the trouble of making a business agreement and technical		gone to the trouble of making a business agreement and technical
	arrangement with CDN Provider 'B'.		arrangement with CDN Provider 'B'.
	+-------+ +-------+		+-------+ +-------+
	| CSP-1 | | CSP-2 |		| CSP-1 | | CSP-2 |
	+-------+ +-------+		+-------+ +-------+
	| |		| |
	skipping to change at page 6, line 22		skipping to change at page 6, line 15
	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:
	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
	would result from serving content from geographically or		would result from serving content from geographically or
	topologically remote Surrogates,		topologically remote Surrogates.
	o without incurring the cost of deploying and operating Surrogates		o without incurring the cost of deploying and operating Surrogates
	and the associated CDN infrastructure that may not be justified in		and the associated CDN infrastructure that may not be justified in
	the corresponding geographic region (e.g., because of relatively		the corresponding geographic region (e.g., because of relatively
	low delivery volume, or conversely because of the high investments		low delivery volume, or conversely because of the high investments
	that would be needed to satisfy the high volume).		that would be needed to satisfy the high volume).
	If there are several CDN Providers that have a geographically limited		If there are several CDN Providers that have a geographically limited
	footprint (e.g., restricted to one country), or do not serve all End		footprint (e.g., restricted to one country), or do not serve all End
	Users in a geographic area, then interconnecting their CDNs enables		Users in a geographic area, then interconnecting their CDNs enables
	these CDN Providers to provide their services beyond their own		these CDN Providers to provide their services beyond their own
	footprint.		footprint.
	As an example, suppose a French CSP wants to distribute its TV		As an example, suppose a French CSP wants to distribute its TV
	programs to End Users located in France and various countries in		programs to End Users located in France and various countries in
	North Africa. It asks a French CDN Provider to deliver the content.		North Africa. It asks a French CDN Provider to deliver the content.
	The French CDN Provider's network only covers France, so it makes an		The French CDN Provider's network only covers France, so it makes an
	agreement with another CDN Provider that covers North Africa.		agreement with another CDN Provider that covers North Africa.
	Overall, from the CSP's perspective the French CDN Provider provides		Overall, from the CSP's perspective, the French CDN Provider provides
	a CDN service for both France and North Africa.		a CDN service for both France and North Africa.
	In addition to video, this use case applies to other types of content		In addition to video, this use case applies to other types of content
	such as automatic software updates (browser updates, operating system		such as automatic software updates (browser updates, operating system
	patches, virus database update, etc).		patches, virus database update, etc.).
	2.2. Inter-Affiliates Interconnection		2.2. Inter-Affiliates Interconnection
	The previous section describes the case of geographic extension		The previous section describes the case of geographic extension
	between CDNs operated by different entities. A large CDN Provider		between CDNs operated by different entities. A large CDN Provider
	may have several subsidiaries that also each operate their own CDN		may have several subsidiaries that each operate their own CDN (which
	(which may rely on different CDN technologies, see Section 4.2). In		may rely on different CDN technologies, see Section 4.2). In certain
	certain circumstances, the CDN Provider needs to make these CDNs		circumstances, the CDN Provider needs to make these CDNs interoperate
	interoperate to provide a consistent service to its customers on the		to provide consistent service to its customers on the whole
	whole collective footprint.		collective footprint.
	2.3. ISP Handling of Third-Party Content		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 ISP's		comes from a third-party CSP and that is injected into the ISP's
	network by an Authoritative CDN Provider. There are mutual benefits		network by an Authoritative CDN Provider. There are mutual benefits
	to the ISP (acting as an Access CDN), the Authoritative CDN, and the		to the ISP (acting as an Access CDN), the Authoritative CDN, and the
	CSP that would make a case for establishing a CDNI agreement. For		CSP that would make a case for establishing a CDNI agreement. For
	example:		example:
	o Allow the CSP to offer improved QoE and QoE services to		o allowing the CSP to offer improved QoE and QoE services to
	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 allowing 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 allowing 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 ingress		o allowing 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 allowing the ISP to derive some incremental revenue for transport
	the traffic and to monetize QoE services.		of 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
	content with a consistent QoE, across a range of devices and/or		content with a consistent QoE across a range of devices and/or
	geographic regions.		geographic regions.
	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 ISP A, her "home ISP".		has a subscription to a broadband service from ISP A, her "home ISP".
	ISP 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
	ISP A (her "home ISP") 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 ISP A's network.		this example is within ISP A's network.
	However, while End User A is not connected to ISP 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 delivered by
	by an alternate CDN (CDN-B), in this case, hosted in the network of		an alternate CDN (CDN-B), in this case, hosted in the network of the
	the WiFi or mobile provider (ISP B), rather than from CDN-A in ISP		WiFi or mobile provider (ISP B), rather than from CDN-A in ISP A's
	A's network.		network.
	+-------+		+-------+
	|Content|		|Content|
	+-------+		+-------+
	|		|
	,--,--,--. ,--,--,--.		,--,--,--. ,--,--,--.
	,-' NSP A `-. ,-' NSP B `-.		,-' ISP A `-. ,-' ISP 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
	Though the content of CSP A is not accessible by typical End Users of		Though the content of CSP A is not accessible by typical End Users of
	CDN-B, End User A is able to gain access to their "home" content		CDN-B, End User A is able to gain access to her "home" content (i.e.,
	(i.e., the content of CSP A) through the alternate CDN (CDN-B).		the content of CSP A) through the alternate CDN (CDN-B).
	Depending on CSP's content delivery policies (see Appendix A.1), a		Depending on the CSP's content delivery policies (see Appendix A.1),
	user moving to a different geographic region may be subject to geo-		a 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
	A CDN is likely to be dimensioned to support an expected maximum		A CDN is likely to be dimensioned to support an expected maximum
	traffic load. However, unexpected spikes in content popularity		traffic load. However, unexpected spikes in content popularity
	(flash crowd) may drive load beyond the expected peak. The prime		(flash crowd) may drive load beyond the expected peak. The prime
	recurrent time peaks of content distribution may differ between two		recurrent time peaks of content distribution may differ between two
	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 each other's resources during their respective
	respective peaks of activity.		peaks of activity.
	Offload also applies to planned situations where a CDN Provider needs		Offload also applies to planned situations in which a CDN Provider
	CDN capacity in a particular region during a short period of time.		needs CDN capacity in a particular region during a short period of
	For example, a CDN can offload traffic to another CDN during a		time. For example, a CDN can offload traffic to another CDN for the
	specific maintenance operation or for covering the distribution of a		duration of a specific maintenance operation or for the distribution
	special event, as in the scenario depicted in Figure 3. For		of a special event, as in the scenario depicted in Figure 3. For
	instance, consider a TV-channel which is the distributor for a major		instance, consider a TV channel that is the distributor for a major
	event, such as a celebrities' wedding, or a major sport competition		event, such as a celebrity's wedding or a major sport competition,
	and this TV-channel has contracted particular CDNs for the delivery.		and this TV channel has contracted particular CDNs for the delivery.
	The CDNs (CDN-A and CDN-B) that the TV-channel uses for delivering		The CDNs (CDN-A and CDN-B) that the TV channel uses for delivering
	the content related to this event are likely to experience a flash		the content related to this event are likely to experience a flash
	crowd during the event and to need offloading traffic, while other		crowd during the event and will need to offload traffic, while other
	CDNs (CDN-C) will support a more usual traffic load and be able to		CDNs (CDN-C) will support a more typical traffic load and be able to
	handle the offloaded traffic.		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 each dCDN.
	+------------+		+------------+
	| TV Channel |		| TV Channel |
	+------------+		+------------+
	| \		| \
	,-,--,-. \ ,-,--,-. ,-,--,-.		,-,--,-. \ ,-,--,-. ,-,--,-.
	,' `. ,' `. ,' CDN-C `.		,' `. ,' `. ,' CDN-C `.
	( CDN-A ) ( CDN-B )==( offload )		( CDN-A ) ( CDN-B )==( offload )
	`. ,' `. ,' `. ,'		`. ,' `. ,' `. ,'
	`-'--'-' `-'--'-' `-'--'-'		`-'--'-' `-'--'-' `-'--'-'
	skipping to change at page 10, line 13		skipping to change at page 10, line 5
	Figure 3		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 onto
	surviving equipment,		surviving equipment,
	2. depending on traffic management policies, forward some requests		2. depending on traffic management policies, forward some requests
	to the CSP's origin servers, and		to the CSP's origin servers, and/or
	3. redirect some requests toward another CDN, which must be able to		3. redirect some requests toward another CDN, which must be able to
	serve the redirected requests.		serve the redirected requests.
	The last option is a use case for CDNI.		The last 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.
	The ability to support content acquisition resiliency, is an		The ability to support content acquisition resiliency is an important
	important use case for interconnected CDNs. When the content		use case for interconnected CDNs. When the content acquisition
	acquisition source fails, the CDN might switch to another content		source fails, the CDN might switch to another content acquisition
	acquisition source. Similarly, when several content acquisition		source. Similarly, when several content acquisition sources are
	sources are available, a CDN might balance the load between these		available, a CDN might balance the load between these multiple
	multiple sources.		sources.
	Though other server and/or DNS load balancing techniques may be		Though other server and/or DNS load-balancing techniques may be
	employed in the network, interconnected CDNs may have a better		employed in the network, interconnected CDNs may have a better
	understanding of origin server availability and be better equipped to		understanding of origin-server availability, and be better equipped
	both distribute load between origin servers and attempt content		to both distribute load between origin servers and attempt content
	acquisition from alternate content sources when acquisition failures		acquisition from alternate content sources 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 content source options, e.g.:		other content source options, for example:
	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,		within an upstream CDN,
	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 and		the selection of content acquisition sources should be considered and
	facilitated.		facilitated.
	4. CDN Capability Use Cases		4. Capability Use Cases
	4.1. Device and Network Technology Extension		4.1. Device and Network Technology Extension
	In this use case, the CDN Provider may have the right geographic		In this use case, the CDN Provider may have the right geographic
	footprint, but may wish to extend the supported range of devices and		footprint, but may wish to extend the supported range of devices and
	User Agents or the supported range of delivery technologies. In this		User Agents or the supported range of delivery technologies. In this
	case, a CDN Provider may interconnect with a CDN that offers		case, a CDN Provider may interconnect with a CDN that offers services
	services:		that:
	o that the CDN Provider is not willing to provide or,		o the CDN Provider is not willing to provide, or
	o that its own CDN is not able to support.		o its own CDN is not able to support.
	The following examples illustrate this use case:		The following examples illustrate this use case:
	1. CDN-A cannot support a specific delivery protocol. For instance,		1. CDN-A cannot support a specific delivery protocol. For instance,
	CDN-A may interconnect with CDN-B to serve a proportion of its		CDN-A may interconnect with CDN-B to serve a proportion of its
	traffic that requires HTTPS [RFC2818]. CDN-A may use CDN-B's		traffic that requires HTTPS [RFC2818]. CDN-A may use CDN-B's
	footprint (which may overlap with its own) to deliver HTTPS		footprint (which may overlap with its own) to deliver HTTPS
	without needing to deploy its own infrastructure. This case		without needing to deploy its own infrastructure. This case
	could also be true of other formats, delivery protocols (RTMP,		could also be true of other formats, delivery protocols (e.g.,
	RTSP, etc.) and features (specific forms of authorization such as		the Real Time Messaging Protocol (RTMP), the Real Time Streaming
	tokens, per session encryption, etc.).		Protocol (RTSP), etc.), and features (specific forms of
			authorization such as tokens, per session encryption, etc.).
	2. CDN-A has footprint covering traditional fixed line broadband and		2. CDN-A has a footprint covering traditional fixed-line broadband
	wants to extend coverage to mobile devices. In this case, CDN-A		and wants to extend coverage to mobile devices. In this case,
	may contract and interconnect with CDN-B who has both:		CDN-A may contract and interconnect with CDN-B, who has both:
	* physical footprint inside the mobile network,		* a physical footprint inside the mobile network,
	* the ability to deliver content over a protocol that is		* the ability to deliver content over a protocol that is
	required by specific mobile devices.		required by specific mobile devices.
	3. CDN-A only supports IPv4 within its infrastructure but wants to		3. CDN-A only supports IPv4 within its infrastructure but wants to
	deliver content over IPv6. CDN-B supports both IPv4 and IPv6		deliver content over IPv6. CDN-B supports both IPv4 and IPv6
	within its infrastructure. CDN-A interconnects with CDN-B to		within its infrastructure. CDN-A interconnects with CDN-B to
	serve out its content over native IPv6 connections.		serve out its content over native IPv6 connections.
	These cases can apply to many CDN features that a given CDN Provider		These cases can apply to many CDN features that a given CDN Provider
	may not be able to support or not be willing to invest in, and thus,		may not be able to support or not be willing to invest in, and thus,
	that the CDN Provider would delegate to another CDN.		that the CDN Provider would delegate to another CDN.
	4.2. Technology and Vendor Interoperability		4.2. Technology and Vendor Interoperability
	A CDN Provider may deploy a new CDN to run alongside its existing		A CDN Provider may deploy a new CDN to run alongside its existing CDN
	CDN, as a simple way of migrating its CDN service to a new		as a simple way of migrating its CDN service to a new technology. In
	technology. In addition, a CDN Provider may have a multi-vendor		addition, a CDN Provider may have a multi-vendor strategy for its CDN
	strategy for its CDN deployment. Finally, a CDN Provider may want to		deployment. Finally, a CDN Provider may want to deploy a separate
	deploy a separate CDN for a particular CSP or a specific network. In		CDN for a particular CSP or a specific network. In all these
	all these circumstances, CDNI benefits the CDN Provider, as it		circumstances, CDNI benefits the CDN Provider, as it simplifies or
	simplifies or automates some inter-CDN operations (e.g., migrating		automates some inter-CDN operations (e.g., migrating the request
	the request routing function progressively).		routing function progressively).
	4.3. QoE and QoS Improvement		4.3. QoE and QoS Improvement
	Some CSPs are willing to pay a premium for enhanced delivery of		Some CSPs are willing to pay a premium for enhanced delivery of
	content to their End Users. In some cases, even if the CDN Provider		content to their End Users. In some cases, even if the CDN Provider
	could deliver the content to the End Users, it cannot meet the CSP's		could deliver the content to the End Users, it would not meet the
	service level requirements. As a result, the CDN Provider may		CSP's service-level requirements. As a result, the CDN Provider may
	establish a CDN Interconnection agreement with another CDN Provider		establish a CDN Interconnection agreement with another CDN Provider
	that can provide the expected QoE to the End User, e.g., via an		that can provide the expected QoE to the End User, e.g., via an
	Access CDN able to deliver content from Surrogates located closer to		Access CDN that is able to deliver content from Surrogates located
	the End User and with the required service level.		closer to the End User and with the required service level.
	5. Enforcement of Content Delivery Policy		5. Enforcement of Content Delivery Policy
	An important aspect common to all the above use cases is that CSPs		An important aspect common to all the above use cases is that CSPs
	typically want to enforce content delivery policies. A CSP may want		typically want to enforce content delivery policies. A CSP may want
	to define content delivery policies that specify when, how, and/or to		to define content delivery policies that specify when, how, and/or to
	whom the CDN delivers content. These policies apply to all		whom the CDN delivers content. These policies apply to all
	interconnected CDNs (uCDNs and dCDNs) in the same or similar way that		interconnected CDNs (uCDNs and dCDNs) in the same or similar way that
	a CSP can define content delivery policies for content delivered by a		a CSP can define content delivery policies for content delivered by a
	single, non-interconnected CDN. Appendix A provides examples of CSP		single, non-interconnected CDN. Appendix A provides examples of CSP-
	defined policies.		defined policies.
	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		Finally, the authors acknowledge the work of the former CDI working
	group, which is now obsoleted to avoid confusion.		group. This document obsoletes [RFC3570] to avoid confusion.
	7. IANA Considerations
	This memo includes no request to IANA.
	8. Security Considerations		7. 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]. Appendix A.2		threats are discussed in [RFC6707]. Appendix A.2 of this document
	provides example security policies that CSPs might impose on CDNs to		provides example security policies that CSPs might impose on CDNs to
	mitigate the threats.		mitigate the threats.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[I-D.ietf-cdni-problem-statement]		[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar,
	Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content		"Content Distribution Network Interconnection (CDNI)
	Distribution Network Interconnection (CDNI) Problem		Problem Statement", RFC 6707, September 2012.
	Statement", draft-ietf-cdni-problem-statement-08 (work in
	progress), June 2012.
	9.2. Informative References		8.2. Informative References
	[I-D.ietf-cdni-requirements]		[CDNI-REQ] Leung, K. and Y. Lee, "Content Distribution Network
	Leung, K. and Y. Lee, "Content Distribution Network		Interconnection (CDNI) Requirements", Work in Progress,
	Interconnection (CDNI) Requirements",		June 2012.
	draft-ietf-cdni-requirements-03 (work in progress),
	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		[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
	Performance Metric Development", BCP 170, RFC 6390,		Internetworking (CDI) Scenarios", RFC 3570, July 2003.
	October 2011.
			[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 appendix 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
	asset may depend on many criteria. For instance, distribution		asset may depend on many criteria. For instance, distribution
	policies for audiovisual content often combine constraints of varying		policies for audiovisual content often combine constraints of varying
	levels of complexity and sophistication, e.g.:		levels of complexity and sophistication, for example:
	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 IP geo-blocking constraints (e.g., for a given coverage area).		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 with 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 be distilled into simple rules that can be
	be commonly enforced across all dCDNs. These rules may influence		commonly enforced across all dCDNs. These rules may influence dCDN
	dCDN delegation and Surrogate selection decisions, for instance, to		delegation and Surrogate selection decisions, for instance, to ensure
	ensure that the specific rules (e.g. time-window, geo-blocking, pre-		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 delivery		CDN. In turn, this can guarantee to the CSP that content delivery
	policies are properly applied.		policies are properly applied.
	+-----+		+-----+
	| CSP | Policies driven by business (e.g., available		| CSP | Policies driven by business (e.g., available only
	+-----+ only in UK and only from July 1st to September 1st)		+-----+ in the 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 geo-blocking)		+-----+ authorization token and enforce geo-blocking)
	\		\
	\ Distribute simple rules		\ Distribute simple rules
	V		V
	+-----+		+-----+
	| CDN | Apply simple rules		| CDN | Apply simple rules
	+-----+		+-----+
	Figure 4		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 that are acceptable
	for delivery of their content, especially in the case where a secured		for delivery of their content, especially in the case where a secured
	content transmission is required (e.g., must use HTTPS). CSPs may		content transmission is required (e.g., must use HTTPS). CSPs may
	also perform per-request authentication/authorization decision and		also perform a per-request authentication/authorization decision and
	then have the CDNs enforce that decision (e.g., must validate URL		then have the CDNs enforce that decision (e.g., must 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
	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.
	Analogous cases exist when the uCDN wants to offer CDN services under		Analogous cases exist when the uCDN wants to offer CDN services under
	its own branding even if dCDNs are involved. Similarly, a CDN		its own branding even if dCDNs are involved, and so it restricts the
	Provider might wish to restrict the delivery delegation to a chain		delivery delegation to a chain that preserves its brand visibility.
	that preserves its brand visibility.
	Authors' Addresses		Authors' Addresses
	Gilles Bertrand (editor)		Gilles Bertrand (editor)
	France Telecom - Orange		France Telecom - Orange
	38-40 rue du General Leclerc		38-40 rue du General Leclerc
	Issy les Moulineaux, 92130		Issy les Moulineaux, 92130
	FR		FR
	Phone: +33 1 45 29 89 46		Phone: +33 1 45 29 89 46
	Email: gilles.bertrand@orange.com		EMail: gilles.bertrand@orange.com
	Stephan Emile		Stephan Emile
	France Telecom - Orange		France Telecom - Orange
	2 avenue Pierre Marzin		2 avenue Pierre Marzin
	Lannion F-22307		Lannion F-22307
	France		FR
			EMail: emile.stephan@orange.com
	Email: emile.stephan@orange.com
	Trevor Burbridge		Trevor Burbridge
	BT		BT
	B54 Room 70, Adastral Park, Martlesham		B54 Room 70, Adastral Park, Martlesham
	Ipswich, IP5 3RE		Ipswich, IP5 3RE
	UK		UK
			EMail: trevor.burbridge@bt.com
	Email: trevor.burbridge@bt.com
	Philip Eardley		Philip Eardley
	BT		BT
	B54 Room 77, Adastral Park, Martlesham		B54 Room 77, Adastral Park, Martlesham
	Ipswich, IP5 3RE		Ipswich, IP5 3RE
	UK		UK
			EMail: philip.eardley@bt.com
	Email: philip.eardley@bt.com
	Kevin J. Ma		Kevin J. Ma
	Azuki Systems, Inc.		Azuki Systems, Inc.
	43 Nagog Park		43 Nagog Park
	Acton, MA 01720		Acton, MA 01720
	USA		USA
	Phone: +1 978-844-5100		Phone: +1 978-844-5100
	Email: kevin.ma@azukisystems.com		EMail: kevin.ma@azukisystems.com
	Grant Watson		Grant Watson
	Alcatel-Lucent (Velocix)		Alcatel-Lucent (Velocix)
	3 Ely Road		3 Ely Road
	Milton, Cambridge CB24 6AA		Milton, Cambridge CB24 6AA
	UK		UK
			EMail: gwatson@velocix.com
	Email: gwatson@velocix.com
End of changes. 91 change blocks.
	185 lines changed or deleted		170 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/