< draft-bertrand-cdni-use-cases-00.txt		draft-bertrand-cdni-use-cases-01.txt >
	Internet Engineering Task Force G. Bertrand		Internet Engineering Task Force G. Bertrand
	Internet-Draft E. Stephan		Internet-Draft E. Stephan
	Intended status: Informational France Telecom - Orange		Intended status: Informational France Telecom - Orange
	Expires: July 17, 2011 January 13, 2011		Expires: August 1, 2011 G. Watson
			T. Burbridge
			P. Eardley
			BT
			January 28, 2011
	Use Cases for Content Distribution Network Interconnection		Use Cases for Content Distribution Network Interconnection
	draft-bertrand-cdni-use-cases-00		draft-bertrand-cdni-use-cases-01
	Abstract		Abstract
	This document depicts use cases for content delivery network (CDN)		Content Delivery Networks (CDNs) are commonly used for improving the
	interconnection based on Orange experiments. The use cases are		footprint and the end-user experience of a content delivery service,
	divided in the two following categories. Category 1 use cases		at a reasonable cost. This document outlines real world use-cases
	present situations that require a footprint extension for existing		(not technical solutions) for interconnecting CDNs. The intention is
	CDNs. Category 2 use cases include additional situations where CDN		to motivate CDN Interconnection and to support the case for formation
	interconnection would be desirable in a longer term.		of a Working Group, which would work on the definition of
			standardized, inter-operable method(s) for interconnecting CDNs.
	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 July 17, 2011.		This Internet-Draft will expire on August 1, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 20 ¶		skipping to change at page 3, line 7 ¶
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
	2. High Level Use Cases for Multi-CDN Systems . . . . . . . . . . 5		2. High Level Use Cases for Multi-CDN Systems . . . . . . . . . . 7
	2.1. Footprint Extension Use Cases . . . . . . . . . . . . . . 5		2.1. Footprint Extension Use Cases . . . . . . . . . . . . . . 8
	2.1.1. CDN Interconnection inside one CDSP . . . . . . . . . 5		2.1.1. Geographic Extension . . . . . . . . . . . . . . . . . 8
	2.1.2. CDN Interconnection between CDSPs . . . . . . . . . . 5		2.1.2. Country to Country Interconnection . . . . . . . . . . 8
	2.2. Additional Potential Use Cases . . . . . . . . . . . . . . 6		2.1.3. Nomadic Users . . . . . . . . . . . . . . . . . . . . 8
	2.2.1. CDN Interconnection for CDN Overload Handling . . . . 6		2.1.4. Geo-blocking . . . . . . . . . . . . . . . . . . . . . 9
	2.2.2. CDN Interconnection for CDN Resiliency . . . . . . . . 6		2.1.5. Device and Network Technology Extension . . . . . . . 9
	2.2.3. Inter-Silos CDN Interconnection inside one CDSP . . . 7		2.2. Offload Use Cases . . . . . . . . . . . . . . . . . . . . 10
	3. Experiment with Existing CDN Solutions and Lessons Learned . . 8		2.2.1. Overload Handling and Dimensioning . . . . . . . . . . 10
	3.1. Description of the Experiments . . . . . . . . . . . . . . 8		2.2.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . 11
	3.2. Gaps in Existing Solutions and Need for Specifications . . 9		2.3. Technology and Vendor Interoperability . . . . . . . . . . 12
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		2.4. QoE and QoS improvement . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		2.4.1. NSP CDSP Use Case . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		3. Experiments with Existing CDN Solutions and Lessons Learned . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.1. France Telecom-Orange Experiments . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 10		3.2. Gaps in Existing Solutions and Need for Specifications . . 14
	7.2. Informative References . . . . . . . . . . . . . . . . . . 10		4. Discussion on Priorities for the Proposed Charter . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
			8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
			8.2. Informative References . . . . . . . . . . . . . . . . . . 15
			Appendix A. CDN Interconnection Patterns . . . . . . . . . . . . 16
			A.1. Single CDN . . . . . . . . . . . . . . . . . . . . . . . . 16
			A.2. Dual CDN with Direct Content Delivery . . . . . . . . . . 17
			A.3. Intermediary CDN . . . . . . . . . . . . . . . . . . . . . 19
			A.3.1. Option A - Recursive . . . . . . . . . . . . . . . . . 19
			A.3.2. Option B - Iterative . . . . . . . . . . . . . . . . . 20
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	This document depicts use cases for content delivery network (CDN)		This document now merges input from [I-D.watson-cdni-use-cases].
	interconnection based on Orange experiments. The use cases are
	divided in the two following categories. Category 1 use cases
	present situations that require a footprint extension for existing
	CDNs. Category 2 use cases include additional situations where CDN
	interconnection would be desirable in a longer term.
	The present document complements [I-D.watson-cdni-use-cases]. The		Content Delivery Networks (CDNs) are commonly used for improving the
	two drafts will be merged during the next weeks.		footprint and the end-user experience of a content delivery service,
			at a reasonable cost. This document outlines real world use-cases
			(not technical solutions) for interconnecting CDNs. The intention is
			to motivate CDN Interconnection and to support the case for formation
			of a Working Group, which would work on the definition of
			standardized, inter-operable method(s) for interconnecting CDNs.
			There are many possible combinations for the relationships between
			the different parties (Network Service Provider (NSP), Content
			Delivery Service Provider (CDSP), Content Service Provider (CSP),
			etc.) involved in end-to-end content delivery. However, in the
			context of interconnecting CDNs the key relationships are listed
			below.
			o How the CSP interacts with the CDN to publish and deliver content.
			o How the End User interacts with the interconnected CDNs to request
			and receive content.
			o How the different CDSPs, operating their CDNs, interact with one
			another to deliver the CSP's content to the End User.
			Section 2 describes a number of use cases that motivate CDN
			Interconnection. We also briefly describe some experiments with
			existing CDN solutions (Section 4).
	1.1. Terminology		1.1. Terminology
	Except for the terms defined below, we adopt the terminology		Except for the terms defined below, we adopt the terminology
	described in [RFC3466], [RFC3568], and [RFC3570].		described in [RFC3466], [RFC3568], and [RFC3570].
	Problem statement draft [I-D.jenkins-cdni-problem-statement] defines		Problem statement draft [I-D.jenkins-cdni-problem-statement]defines a
	a set of terms. Below we recall only the terms used in the memo.		set of terms. Below we recall only the terms used in the memo.
	Content Service Provider (CSP):		Content Service Provider (CSP):
	Provides Content Services to Users. A CSP may own the content made		Provides Content Services to Users. A CSP may own the content made
	available as part of the Content Service, or may license content		available as part of the Content Service, or may license content
	rights from another party.		rights from another party.
	Content Service:		Content Service:
	The service offered by a CSP. The Content Service encompasses the		The service offered by a CSP. The Content Service encompasses the
	skipping to change at page 3, line 47 ¶		skipping to change at page 5, line 17 ¶
	direct interaction with the CDN.		direct interaction with the CDN.
	Content Distribution Network (CDN) / Content Delivery Network (CDN):		Content Distribution Network (CDN) / Content Delivery Network (CDN):
	A type of network in which the components are arranged for more		A type of network in which the components are arranged for more
	effective delivery of content to User Agents.		effective delivery of content to User Agents.
	Content Delivery Service		Content Delivery Service
	Set of services offered to CSPs for delivering their contents through		Set of services offered to CSPs for delivering their contents through
	a single Content Delivery Network or a federation of Content Delivery		a single Content Delivery Network or interconnections of Content
	Networks.		Delivery Networks.
	CDN Service Provider (CDSP):		CDN Service Provider (CDSP):
	An administrative entity who operates a CDN over a NSP or over the		An administrative entity who operates a CDN over a NSP or over the
	Internet.		Internet.
	CDN federation
	Set of CDNs that maintain a CDNI relationship to one another. The
	federation of CDNs can interconnect CDNs operated by the same CDSP or
	operated by distinct CDSPs.
	Authoritative CDN (aCDN):		Authoritative CDN (aCDN):
	The CDSP contracted by the CSP for delivery of contents by this CDN		The CDSP contracted by the CSP for delivery of content by this CDN or
	or by its downstream dCDNs.		by its downstream CDNs.
	Downstream CDN (dCDN):		Downstream CDN (dCDN):
	A CDSP which is contacted by an aCDN to achieve the delivery of		A CDSP which is contracted by an aCDN to achieve the delivery of
	content to users.		content to users.
	Access CDN		Access CDN
	A CDN that is the connected to the end-user's access and has		A CDN that is connected to the end-user's access and has information
	information about the end-user's access capabilities and profile.		about the end-user's profile and access capabilities.
	Delivering CDN		Delivering CDN
	The CDN that delivers the requested content asset to the end-user.		The CDN that delivers the requested content asset to the end-user.
	In particular, the delivering CDN can be an access CDN.		In particular, the delivering CDN can be an access CDN.
	CDN Interconnection(CDNI):		CDN Interconnection (CDNI):
	Relationship between two CDNs that enables a CDN to provide content		Relationship between two CDNs that enables a CDN to provide content
	delivery services on behalf of another CDN. It relies on a set of		delivery services on behalf of another CDN. It relies on a set of
	interfaces over which two CDNs communicate in order to achieve the		interfaces over which two CDNs communicate in order to achieve the
	delivery of content to users by one CDN (the downstream CDN) on		delivery of content to end-users by one CDN (the downstream CDN) on
	behalf of another CDN (the upstream CDN).		behalf of another CDN (the upstream CDN).
	1.2. Acronyms		CDN peering: A business relation between two CDSPs based on one or
			more CDN interconnections.
	[Ed. Note: List of acronyms to be updated later ]		Recursive request routing:
			Recursive: Where a process is repeated, but embedded within the
			original process. In the case of Request Routing, this means that
			the initial request received by the Authoritative CDN is processed
			downstream from one CDN to another and that the responses are send
			back upstream to the Authoritative CDN which then replies to the
			initial request.
			Iterative request routing
			Iterative: Where a process is repeated multiple times to make
			progress towards a goal. In the case of Request Routing, this means
			that the initial request is received by the Authoritative CDN, which
			replies it with a redirection directive to a dowstream CDN. When the
			end-user sends its request to the downstream CDN, the same process is
			repeated, until the request arrives to the delivering CDN.
			1.2. Abbreviations
			[Ed. Note: List of abbreviations to be updated later and sorted
			alphabetically]
	o ISP		o ISP
	o NSP		o NSP
	o STB		o STB
	o PC		o PC
	o QoS QoE VoD WiFi 3G
			o QoS
			o QoE
			o SLA
			o VoD
			o WiFi
			o 3G
	2. High Level Use Cases for Multi-CDN Systems		2. High Level Use Cases for Multi-CDN Systems
	The prevalent use cases for CDNI are presented according to the CDSPs		The prevalent use cases for CDNI are presented according to a CDSP's
	main reason for interconnecting their CDNs. They are classified		main motivation for interconnecting its CDN. They are classified
	according to their level of priority for the CDSPs.		according to their level of priority for the CDSP:
	The CDNI model helps at building a federation of Content Delivery		o CDN Footprint Extension Use Cases
	Networks that collaborate, allowing Content Delivery Service
	Providers to offer Content Service Providers a set of consistent		o CDN Offload Use Cases
	delivery services throughout the CDN Federation. Let's take an
	example. CDSP A and B respectively operate CDNa and CDNb. They		o Technology and vendor interoperability
	establish a CDNI relationship for building a CDN federation CDNa-b
	that consists of CDNa and CDNb. CDSP A reaches an agreement with		o QoE and QoS improvement
	content service provider CSPa. CDSPa services rely on the CDN
	federation CDNa-b. Meanwhile, CDSP B reaches an agreement with		"CSPs have a desire to be able to get (some of their) content to very
	content service provider CSPb. These services also rely on the CDN		large number of users and/or over many/all geographies and/or with a
	federation CDNa-b.		high quality of experience, all without having to maintain direct
			business relationships with many different CDN providers"
			[draft-jenkins-cdni-problem-statement].
			In order to minimize the number of direct business relationships
			between a CSP and a set of interconnected CDNs, it is assumed that a
			CSP will only be required/ desire to have a direct relationship with
			a single CDN, although relationships with more than one CDN are not
			precluded. A CDN selected by the CSP is referred to as an
			"Authoritative CDN" in this document. When receiving requests from
			User Agents, the Authoritative CDN will select an appropriate
			Surrogate in its own CDN or will decide to delegate the delivery to
			another CDN, to which a CDN interconnection can be established.
			The CDNI model enables Content Delivery Networks to collaborate,
			allowing Content Delivery Service Providers to offer consistent
			delivery services throughout the CDN Interconnection
			The CDNI model helps enables Content Delivery Networks that
			collaborate to provide Content Service Providers with delivery
			services throughout CDN Interconnections.
			Let's take an example. CDSP-A and CDSP-B respectively operate CDN-A
			and CDN-B. They establish a CDN peering for building the CDN
			interconnections from CDN-A to CDN-B and from CDN-B to CDN-A. The
			content service provider CSP-A reaches an agreement with CDSP-A.
			CDSP-A services rely on the CDN-A and on the interconnection from
			CDN-A to CDN-B. Meanwhile, the content service provider CSP-B
			reaches an agreement with CDSP-B. These services rely on the CDN-A
			and on the interconnection from CDN-A to CDN-B.
			[Ed. Note: Figure to be added to help the reader understand the
			example]
	2.1. Footprint Extension Use Cases		2.1. Footprint Extension Use Cases
	2.1.1. CDN Interconnection inside one CDSP		Footprint extension is a major use case for CDN interconnection.
	A Large Content delivery service provider (CDSP) operates the CDNs of		2.1.1. Geographic Extension
	a set of subsidiaries from different countries, and these CDNs can
	rely on different CDN solutions. To provide a consistent service to
	his customers on its whole footprint, in certain circumstances, the
	CDSP needs to make its CDNs interoperate.
	Note that currently, the distribution of some content is restricted.		In this use case, the CDSP is concerned with extending the geographic
	For instance, distribution rights for audiovisual content are often		distribution that it can offer to the CSP without overly compromising
			the quality of delivery and without attracting transit and other
			network costs by serving from geographically or topologically remote
			surrogates. For example, several CDSPs have a geographically limited
			footprint (e.g., a country), or do not serve all end-users in a
			geographic area. Interconnecting CDNs enables CDSPs to provide their
			services beyond their own footprint by relying on other CDNs.
			As an example, a French CSP that distributes TV series wants to
			distribute them to end-users located in various countries in Europe
			and North Africa. It asks a French CDSP to deliver the series to
			several countries. The French CDSP makes an agreement with an
			external CDSP that covers North Africa , so that overall the French
			CDSP provides a CDN service for both France and North Africa.
			This use case applies to other types of contents such as automatic
			software updates (browser updates, operating system patches, or virus
			database update, etc).
			2.1.2. Country to Country Interconnection
			There is a specific scenario where a large content delivery service
			provider (CDSP) operates the CDNs of a set of subsidiaries from
			different countries. These CDNs can rely on different CDN solutions.
			Such a situation may occur due to independent regional operations, or
			through mergers and acquisitions. In certain circumstances, the CDSP
			needs to make its CDNs interoperate to provide a consistent service
			to its customers on its whole footprint.
			[Ed. Note: FIGURE TO BE INCLUDED
			Figure 1
			2.1.3. Nomadic Users
			Another scenario is nomadic situation. In this scenario a CSP wishes
			to allow users who move to other geographic regions to continue to
			access their content. The motivation in this case is to allow
			nomadic users to maintain access, rather than to allow all residents
			within a region access to the content.
			2.1.4. Geo-blocking
			Currently, the distribution of some content is restricted. For
			instance, distribution rights for audiovisual content are often
	negotiated per country.		negotiated per country.
	[Ed. Note: FIGURE TO BE INCLUDED]		The selection of the Authoritative CDN is influenced by policies
			which may include "geo-blocking" rules that specify
	Figure 1: [Ed. Note: Legend to be added ]		o the geographic regions where content can be delivered from (i.e.
			the location of the Surrogates),
	2.1.2. CDN Interconnection between CDSPs		o geographic locations where content can be delivered to (i.e. the
			location of the End Users),
	Several CDSPs have a geographically limited footprint (e.g., a		o or quality of service policies specifying how the content is to be
	country), or do not serve all end-users in a geographic area.		delivered.
	Interconnecting CDNs enables CDSPs to provide their services beyond
	their own footprint by relying on other CDNs.
	End-users in various countries access TV shows episodes. The CSP		Hence, the exchange through the CDN interconnection of information
	that distributes the TV show asks a French CDSP to deliver the serie		for controlling the footprint of the delivery is an important use
	to several countries. The French CDSP make an agreement with an		case.
	external CDSP that covers North Africa to provide a CDN service for
	France and North Africa.
	This use case applies to other types of contents like automatic		2.1.5. Device and Network Technology Extension
	software updates (browser updates, operating system patches, or virus
	database update...).
	2.2. Additional Potential Use Cases		In this use case the CDSP may have the geographic and end-user
			coverage that it requires, but wishes to support the delivery of
			content to alternative end devices. These devices may sit on remote
			networks (such as smartphones connected to a mobile network) and may
			also require unique delivery capabilities in the CDN. In this case
			the CDSP may federate with another CDSP that offers service to these
			devices.
	2.2.1. CDN Interconnection for CDN Overload Handling		As depicted in Figure 2, an end-user can use its tablet to download a
			VoD through WiFi (1) from CDN1 and then switch to 3G network (2),
			which is served by CDN2. The end user should be able to reach the
			selected VoD content through any access network technology.
			Consequently, every considered CDN must have access to this VoD
			content. One way to proceed consists in having an ingestion
			interface among the CDNs to access the content. Replication of the
			requested VoD content in the CDN serving the terminal (a) enables
			controlling the QoS (e.g. screen size, bitrate) of the VoD
			distribution to the terminal used by the end-user. In another
			situation, the serving of the VoD without replication (b) will save
			storage resources. The end-user's experience improves thanks to an
			increase of the number of situations where the end-user can access
			the service.
	The support of prime time traffic load requires overdimensioning the		-------------- --------------
	CDNs. However, prime time of content distribution may differ between		/ CDN1 \ / CDN2 \
	two CDNs. Therefore, two CDNs may benefit from dimensioning savings		| Fixed | | Mobile |
	by using resources of the other CDN during the prime time.		| ,---. | | ,---. |
			+---+ | . ) | (a) | . ) |
			|CSP|****| |`---'| |''''`---------.....>|`---'| |
			+---+ | | | -.. Acquisition | | | |
			| ( ) | `-.._ | ( ) |
			| `---' | `-.. | `---' |
			|,------------.| (b) ``-._ |,------------.|
			||Delivery || `->. Delivery ||
			\`------------'/ \`------------'/
			----------+--- -----*--+-----
			: * |
			: * |
			+........+ +--------+
			: Tablet : (1) | Tablet |(2)
			+........+ +--------+
	During a traffic peak, a CDSP redirects some traffic load toward		Figure 2: Fixed-Mobile CDN Inter-connection
	another CDSP (for instance, geographically close).
	2.2.2. CDN Interconnection for CDN Resiliency		.: This use case is similar to use case in Section 2.3.
			2.2. Offload Use Cases
			Offload is a major use case of CDN interconnection.
			2.2.1. Overload Handling and Dimensioning
			The support of prime-time traffic load requires over-dimensioning the
			CDN capacity. In addition unexpected spikes in content popularity
			may drive load beyond the expected peak. As prime time and peaks of
			content distribution may differ between two CDNs, a CDN may
			interconnect with another CDN to increase its effective peak
			capacity. Similarly, two CDNs may benefit from dimensioning savings
			by using the resources of each other during their peaks of activity.
			The profile of activity peaks (time, duration ...) differ not only
			from a country to another but also according to the kind of CDNs.
			Therefore, CDN interconnect will be required since the additional
			capacity is likely to be provided by alternative technology.
			Offload also applies to planned situation where a CDSP needs CDN
			capacities in a particular region during a short period of time. For
			example, during a specific maintenance operation or for covering the
			distribution of a special event, such as an international sport
			competition.
			2.2.2. Resiliency
	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 a set of surrogates). In		during partial failures (e.g., failure of a set of surrogates). In
	partial failure scenarios, a CDSP could redirect some requests toward		partial failure scenarios, a CDSP could redirect some requests toward
	another CDN. This downstream CDN must be able to serve the		another CDN. This downstream CDN must be able to serve the
	redirected requests or, depending on traffic management policies, to		redirected requests or, depending on traffic management policies, to
	forward these requests to the CSP origin server.		forward these requests to the CSP origin server.
			Resiliency may also be required against failure to ingest content
			from the CSP. In these cases the content may be available from
			another CDSP.
	-------------- --------------		-------------- --------------
	/ CDN1 \ / CDN2 \		/ CDN1 \ / CDN2 \
	| ,---. | | ,---. |		| ,---. | | ,---. |
	+---+ | . ) | | . ) |		+---+ | . ) | | . ) |
	|CSP|*******| |`---'| |__________________| |`---'| |		|CSP|*******| |`---'| |__________________| |`---'| |
	+---+ | | | | Acquisition | | | |		+---+ | | | | Acquisition | | | |
	| ( ) | | ( ) |		| ( ) | | ( ) |
	| `---' | | `---' |		| `---' | | `---' |
	|+-----------+ | |,------------.|		|+-----------+ | |,------------.|
	||Req-Routing| | .|Delivery ||		||Req-Routing| | .|Delivery ||
	skipping to change at page 7, line 31 ¶		skipping to change at page 12, line 5 ¶
	| .-'		| .-'
	| .-'		| .-'
	| .-'		| .-'
	| .-'		| .-'
	+-----+		+-----+
	| User|		| User|
	+-----+		+-----+
	Figure 3: Example of CDN Interconnection for failure resiliency		Figure 3: Example of CDN Interconnection for failure resiliency
	2.2.3. Inter-Silos CDN Interconnection inside one CDSP		2.3. Technology and Vendor Interoperability
	ISPs deployed platforms per service or per network technology. They		ISPs have deployed platforms per service or per network technology.
	are deploying CDNs or enhancing existing platforms to CDN. It is		They are deploying CDNs or enhancing existing platforms to CDN. It
	desirable in certain circumstances to share the content or the		is desirable in certain circumstances to share the content or the
	resources among these CDNs.		resources among these internal CDNs. A CDSP may wish to operate a
			multi-vendor strategy for its CDN. Currently, operating a single
			controller for such multi-vendor CDNs is problematic. This problem
			can be alleviated by a CDN interconnection that allows the automation
			of some operations among these CDNs.
	It is desirable to have the ability to provide content to different		2.4. QoE and QoS improvement
	terminals and through different access technologies, possibly served
	by different CDNs. As depicted in Figure 2, an end-user can use his
	tablet to download a VoD through WiFi (1) from CDN1 and then switch
	to 3G network (2), which is served by CDN2. The end user should be
	able to access the selected VoD content through any access network
	technology. Consequently, every considered CDN must have access to
	this VoD content. One way to proceed consists in having an ingestion
	interface among the CDNs to access the content.
	Replication of the requested VoD content in the CDN serving the		Some existing CDNs make the decision to work with ISPs to deploy
	terminal (a) enables controlling the QoS of the VoD distribution to		surrogates closer to the end users. Compared to alternatives such as
	the terminal used by the end-user. In another situation, the serving		adding capacity at major peering points, this method offers better
	of the CoD without replication (b) will save storage resources.		experience to the end users. Some CSPs are willing to pay a premium
			for such enhanced service rather than just using the CDSP to mitigate
			their server and network access costs. Improved experience may be
			provided by closer proximity to the end users. It could also involve
			network characteristics, such as provisioning or QoS, and specific
			delivery techniques such as encoding for constant Quality of
			Experience.
	The end-user's experience improves thanks to an increase of the		2.4.1. NSP CDSP Use Case
	number of situations where the end-user can access the service.
	-------------- --------------		In a interconnection use case, CDSP-A is likely to offer an SLA to
	/ CDN1 \ / CDN2 \		the CSP including performance or other quality metrics. If it cannot
	| Fixed | | Mobile |		meet the SLA it will push content via the interconnection to a CDSP-B
	| ,---. | | ,---. |		with CDN capabilities that are in a position to guaranty the SLA, and
	+---+ | . ) | (a) | . ) |		redirect users appropriately to CDSP-B. CDSP-A may not be able to,
	|CSP|****| |`---'| |''''`---------.....>|`---'| |		or may not wish to deploy its own CDN capabilities to meet the SLA
	+---+ | | | -.. Acquisition | | | |		requirements for only a subset of its CSP customers. The ability to
	| ( ) | `-.._ | ( ) |		offer stringent delivery quality SLAs is a differentiator against
	| `---' | `-.. | `---' |		other CDSPs and can be sold as a premium service.
	|,------------.| (b) ``-._ |,------------.|
	||Delivery || `->. Delivery ||
	\`------------'/ \`------------'/
	----------+--- -----*--+-----
	: * |
	: * |
	+........+ +--------+
	: Tablet : (1) | Tablet |(2)
	+........+ +--------+
	Figure 2: Example of Inter-Silos CDN Interconnection		Although this use case has similarities to extending geographic
			reach, in this case it is expected that the CDSP does have a CDN
			deployed which could effectively serve content to the end-users, but
			wishes to increase experience for specific CSPs.
	3. Experiment with Existing CDN Solutions and Lessons Learned		3. Experiments with Existing CDN Solutions and Lessons Learned
	3.1. Description of the Experiments		3.1. France Telecom-Orange Experiments
	To illustrate the realism of the short term scenario described in		As depicted in Figure 1, we have interconnected two CDNs (CDN A and
	previous sections, we present here the summary of some of our CDNI		CDN B) operated by different subsidiaries of a large CDSP. The CDNs
	experiments. These experiments will be further detailed in a		cover two different countries, henceforth referred to as Country A
	separate draft.		and Country B and they rely on CDN solutions from two different
			equipment vendors (Vendor A and Vendor B). The CDNI experiment
			supported the services of two CSPs (CSP A and CSP B).
	We have interconnected two CDNs (CDN A and CDN B)operated by		+-------+ : +-------+
	different subsidiaries of a large CDSP. The CDNs cover two different		| CSP A | : | CSP B |
	countries henceforth referred to as Country A and Country B. The CDNI		+------- : +-------
	experiment supported the services of two CSPs (CSP A and CSP B).		| : |
			,--,--,--. : ,--,--,--.
			,-' CDN A `-. : ,-' CDN B `-.
			( (Vendor A) )==:==( (Vendor B) )
			`-. ,-' : `-. ,-'
			`--'--'--' : `--'--'--'
			:
			COUNTRY A : COUNTRY B
			=== CDN Interconnect
			Experiment configuration
			Figure 1
			We have run several experiments in the configuration represented in
			Figure 2. In these experiments, CSP A has an agreement with CDSP A
			for content delivery to end-users located in Country A and Country B.
			However, CDSP A operates a CDN (CDN A), whose footprint does not
			include country B. Therefore, CDSP A has an agreement with CDSP B, so
			that CDN A can delegate to CDN B the delivery of some content. More
			specifically, CDN A is allowed to delegate to CDN B the handling of
			requests sent by end-users located in Country B for CSP A's content.
	In our first experiment, CSP A has an agreement with CDN A for
	content delivery to end-users located in Country A and Country B. CDN
	A has an agreement with CDN B, so that CDN A can delegate to CDN B
	the delivery of content from CSP A to end-users located in Country B.
	When CDN A receives a content request related to CSP A and from an		When CDN A receives a content request related to CSP A and from an
	end-user in Country B, it redirects the end-user to the appropriate		end-user in Country B, it redirects the end-user to the appropriate
	content on CDN B. If CDN B does not have a local copy of the		content on CDN B. If CDN B does not have a local copy of the
	requested content yet (cache miss), CDN B ingests the content from		requested content yet (cache miss), CDN B ingests the content from
	CDN A. If CDN A does neither have a local copy of the requested		CDN A (or from the CSP's origin servers, depending on the test
	content, it requests it from the CSP's origin servers before sending		scenario); if CDN A also does not have a local copy of the requested
	it to CDN B.		content, it requests this asset from the CSP's origin servers before
			sending the asset to CDN B.
	In our second experiment, CSP B has an agreement with CDN B for		+-------+ :
	content delivery to end-users located in Country A and Country B. CDN		| CSP A | :
	B has an agreement with CDN A, so that CDN B can delegate to CDN A		+-------+ :
	the delivery of content from CSP B to end-users located in Country A.		| :
	When CDN B receives a content request related to CSP B and from an		,--,--,--. : ,--,--,--.
	end-user in Country A, it redirects the end-user to the appropriate		,-' CDN A `-. : ,-' CDN B `-.
	content on CDN A. If CDN A does not have a local copy of the		( (Vendor A) )==:==( (Vendor B) )
	requested content yet (cache miss), it requests the content directly		`-. CDSP A ,-' : `-. CDSP B ,-'
	from the CSP's origin servers.		`--'--'--' : `--'--'--'
			: |
			: +------+
			: | EU B |
			: +------+
			:
			COUNTRY A : COUNTRY B
	The differences between the two experiments above are the ingestion		=== CDN Interconnect
	operations and the roles of CDN A and B, which rely on CDN solutions
	from different vendors.		Test scenario with heterogeneous solutions
			Figure 2
	3.2. Gaps in Existing Solutions and Need for Specifications		3.2. Gaps in Existing Solutions and Need for Specifications
	Our experiments have shown that the current CDN technologies suffer		Our experiments have shown that the current CDN technologies suffer
	from the following limitations.		from the following limitations.
	o The content management policies must be defined manually.		o The content management policies must be defined manually, so that
			the end-user's request triggers content delivery from the most
			appropriate CDN (e.g., a CDN in the country of the end-user, or a
			CDN that serves the type of files requested by the end-user).
	o The target URLs for the request redirection must also be defined		o The target URLs for the request redirection must also be defined
	manually.		manually, so that the authoritative CDN provides to the end-user a
			valid URI on the downstream CDN.
	o The content ingestion worked only in pull mode...		o The content ingestion from an upstream CDN worked only in pull
			mode.
	To address more sophisticated scenarios, we consider that common		To address more sophisticated scenarios, we consider that common
	interfaces are required for request routing among interconnected CDNs		interfaces are required for request routing among interconnected CDNs
	and for the exchange of content distribution metadata.		and for the exchange of content distribution metadata.
	4. Acknowledgments		4. Discussion on Priorities for the Proposed Charter
	The authors would like to thank the contributors of the EU FP7 OCEAN		This section will be worked out later according to the discussions on
	project for valuable input and discussions.		the mailing list.
	5. IANA Considerations		5. Acknowledgments
			The authors would like to thank Francois Le Faucheur and Ben Niven-
			Jenkins for lively discussions.
			They also thank the contributors of the EU FP7 OCEAN and ETICS
			projects for valuable inputs.
			6. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	6. Security Considerations		7. Security Considerations
	CDN interconnect, as described in this document, has a wide variety		CDN interconnect, as described in this document, has a wide variety
	of security issues that should be considered. For example, every		of security issues that should be considered. For example, every
	interconnected CDN should be able to assess if it must serve a		interconnected CDN should be able to assess if it must serve a
	delegated request or if this request is delegated by a non-allowed		delegated request or if this request is delegated by a non-allowed
	CDN. The CDNs should also be protected so as to avoid being		CDN. The CDNs should also be protected so as to avoid being
	overwhelmed by delegated requests. This document focuses on the		overwhelmed by delegated requests. This document focuses on the
	technical use cases for CDN interconnect, and therefore, does not		motivational use cases for CDN interconnect, and therefore, does not
	analyze the threats in details.		analyze the threats in detail.
	7. References		8. References
	7.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.2. Informative References		8.2. Informative References
	[I-D.jenkins-cdni-problem-statement]		[I-D.jenkins-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-jenkins-cdni-problem-statement-00 (work		Statement", draft-jenkins-cdni-problem-statement-01 (work
	in progress), December 2010.		in progress), January 2011.
			[I-D.lefaucheur-cdni-requirements]
			Faucheur, F., Viveganandhan, M., Watson, G., and Y. Lee,
			"Content Distribution Network Interconnection (CDNI)
			Requirements", draft-lefaucheur-cdni-requirements-00 (work
			in progress), January 2011.
	[I-D.watson-cdni-use-cases]		[I-D.watson-cdni-use-cases]
	Watson, G., "CDN Interconnect Use Cases",		Watson, G., "CDN Interconnect Use Cases",
	draft-watson-cdni-use-cases-00 (work in progress),		draft-watson-cdni-use-cases-00 (work in progress),
	January 2011.		January 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.
	[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known		[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
	Content Network (CN) Request-Routing Mechanisms",		Content Network (CN) Request-Routing Mechanisms",
	RFC 3568, July 2003.		RFC 3568, July 2003.
	[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content		[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
	Internetworking (CDI) Scenarios", RFC 3570, July 2003.		Internetworking (CDI) Scenarios", RFC 3570, July 2003.
			Appendix A. CDN Interconnection Patterns
			In this section we attempt to pull out the generic CDN
			interconnection patterns that may result from the use cases detailed
			previously. We find little difference between the use cases in the
			generic interconnection patterns that occur, and these are presented
			below. However, differences do occur due to the the business
			concerns of the different parties operating the components in each
			use case. This will result in different technical requirements at a
			more detailed level (for example in reporting and accounting
			mechanisms).
			A.1. Single CDN
			This section outlines an illustrative model for content delivery via
			a single CDN where there is no interconnection with other CDNs. It
			does not describe all the details and variations but rather the high
			level interactions between the different Actors (CSP, CDN, End User)
			which can be used as a point of comparison with the CDN
			Interconnection patterns described in subsequent sections.
			+-------+
			| CSP-1 |
			+-------+
			|
			,---------.
			,-' `-.
			( CDN-A )
			`-. ,-'
			`---------'
			|
			,---------.
			,-' 0 or `-.
			( more other )
			`-. networks ,-'
			/ `---------' \
			/ \
			,---------. ,---------.
			,-' `-. ,-' `-.
			( NSP-X ) ( NSP-Y )
			`-. ,-' `-. ,-'
			`---------' `---------'
			| |
			+-------+ +-------+
			| UA-X | | UA-Y |
			+-------+ +-------+
			A.2. Dual CDN with Direct Content Delivery
			Taking the above use cases into account the base pattern for CDN
			Interconnection is shown in the diagram below. To simplify the
			diagram the cloud showing "zero or more other networks" has been
			excluded and NSPs are shown as though they are directly attached to
			CDNs. This is not intended to imply any direct relationships or to
			exclude the case where one or more networks may exist between the NSP
			illustrated and the CDN.
			+-------+
			| CSP-1 |
			+-------+
			|
			,---------. ,---------.
			,-' `-. ,-' `-.
			( CDN-A )==I==( CDN-B )
			`-. ,-' /`-. ,-'
			`---------' / `---------'
			| ___/ |
			| / |
			,---------. / ,---------.
			,-' `-. ,-' `-.
			( NSP-X ) ( NSP-Y )
			`-. ,-' `-. ,-'
			`---------' `---------'
			| |
			+-------+ +-------+
			| UA-X | | UA-Y |
			+-------+ +-------+
			==I== CDN Intercon
			As shown in the diagram CSP-1 maintains a direct relationship with
			CDN-A and so CDN-A is the Authoritative CDN for CSP-1. CDN-A
			maintains a CDN Interconnect with CDN-B. CDN-A may decide to
			delegate to CDN-B the delivery of contentto a UA/NSP. How CDN-A
			makes such a decision is out of scope for this document, although the
			motivations for doing so are captured in the above use cases. Let us
			assume that an End User, at User Agent Y, wishes to use CSP-1's
			service and that CDN-A decides to delegate the delivery of the
			content to CDN-B and that CDN-B is willing to perform the delegated
			delivery. In order for EU-Y to receive content the following
			illustrative interactions occur:
			1. UA-Y selects a piece of content (as directed by EU-Y) from
			CSP-1's service.
			2. CSP-1 returns a URL, URL-A, for the selected content which
			resolve to the Request Router in CDN-A, the Authoritative CDN for
			CSP-1.
			3. CDN-A's Request Router makes a decision to delegate the delivery
			to CDN-B.
			4. CDN-A makes a request to CDN-B to deliver the content on behalf
			of CDN-A and CDN-B responds with details of how CDN-A's Request
			Router should respond to the request.
			5. CDN-A's Request Router returns the appropriate response to UA-Y
			or another device acting on its behalf (such as a DNS resolver).
			6. UA-Y will connect to CDN-B and request the content. At this
			point there are several possible variations:
			a. The content request is directed to the Request Router of CDN-B.
			In this manner the UA can be iteratively passed between CDNs. The
			Request Router of CDN-B may identify a surrogate in CDN-B, or may
			identify another CDN (as elaborated in the Intermediary Pattern
			below).
			b. The content request is directed to a surrogate in CDN-B.
			7. UA-Y receives the content from the surrogate in CDN-B. Again
			there are a couple of options:
			a. The content already exists in the chosen surrogate and is
			delivered to the UA.
			b. The content is not stored within the chosen surrogate and is
			dynamically transferred to the surrogate and sequentially delivered
			to the UA.
			8. CDN-B may link the content to URL-B. In this manner another
			service may use URL-B to preferentially serve the content from CDN-B
			directly rather than being directed through CDN-A.
			A.3. Intermediary CDN
			This use case extends the dual CDN pattern by allowing CDN-B to
			accept a delegated content delivery from CDN-A and then delegate the
			delivery to CDN-C. There are a couple of options for this pattern.
			A.3.1. Option A - Recursive
			Steps 1 to 3 proceed as for the dual CDN pattern.
			4. CDN-A makes a request to CDN-B to deliver the content on behalf
			of CDN-A. CDN-B instead decides to delegate this request to CDN-C,
			as permiited by its CDN peering agreement with CDN-A. Thus, the
			Request Router of CDN-B refers the request to the Request Router of
			CDN-C. CDN-C responds to CDN-B and in turn CDN-A's Request Router
			with details of how to respond to UA-Y
			Steps 5 to 8 proceed as for the dual CDN pattern with the exception
			that CDN-B is replaced by CDN-C.
			A.3.2. Option B - Iterative
			Steps 1 to 5 proceed as for the dual CDN pattern.
			6. UA-Y will connect to CDN-B and request the content. The content
			request is directed to the Request Router of CDN-B. The Request
			Router of CDN-B identifies that the request should be serviced by
			CDN-C.
			The pattern then proceeds from step 4 of the dual CDN pattern with
			CDN-A replaced by CDN-B and CDN-B replaced by CDN-C.
			+-------+
			| CSP-1 |
			+-------+
			|
			,---------. ,---------. ,---------.
			,-' `-. ,-' `-. ,-' `-.
			( CDN-A )====( CDN-B )====( CDN-C )
			`-. ,-' `-. ,-' `-. ,-'
			`---------' `---------' `---------'
			|
			|
			,---------.
			,-' `-.
			( NSP-Z )
			`-. ,-'
			`---------'
			|
			+-------+
			| UA-Z |
			+-------+
			==== CDN Interconnect
	Authors' Addresses		Authors' Addresses
	Gilles Bertrand		Gilles Bertrand
	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-ftgroup.com		Email: gilles.bertrand@orange-ftgroup.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		France
	Email: emile.stephan@orange-ftgroup.com		Email: emile.stephan@orange-ftgroup.com
			Grant Watson
			BT
			pp GDC 1 PP14, Orion Building, Adastral Park, Martlesham
			Ipswich, IP5 3RE
			UK
			Email: grant.watson@bt.com
			Trevor Burbridge
			BT
			B54 Room 70, Adastral Park, Martlesham
			Ipswich, IP5 3RE
			UK
			Email: trevor.burbridge@bt.com
			Philip Eardley
			BT
			B54 Room 77, Adastral Park, Martlesham
			Ipswich, IP5 3RE
			UK
			Email: philip.eardley@bt.com
End of changes. 64 change blocks.
	187 lines changed or deleted		613 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/