draft-ietf-cdni-framework-05.txt		draft-ietf-cdni-framework-06.txt
	Network Working Group L. Peterson, Ed.		Network Working Group L. Peterson, Ed.
	Internet-Draft Akamai Technologies, Inc.		Internet-Draft Akamai Technologies, Inc.
	Obsoletes: 3466 (if approved) B. Davie		Obsoletes: 3466 (if approved) B. Davie
	Intended status: Informational VMware, Inc.		Intended status: Informational VMware, Inc.
	Expires: March 13, 2014 September 09, 2013		Expires: April 24, 2014 October 21, 2013
	Framework for CDN Interconnection		Framework for CDN Interconnection
	draft-ietf-cdni-framework-05		draft-ietf-cdni-framework-06
	Abstract		Abstract
	This document presents a framework for Content Distribution Network		This document presents a framework for Content Distribution Network
	Interconnection (CDNI). The purpose of the framework is to provide		Interconnection (CDNI). The purpose of the framework is to provide
	an overall picture of the problem space of CDNI and to describe the		an overall picture of the problem space of CDNI and to describe the
	relationships among the various components necessary to interconnect		relationships among the various components necessary to interconnect
	CDNs. CDN Interconnection requires the specification of several		CDNs. CDN Interconnection requires the specification of interfaces
	interfaces and mechanisms to address issues such as request routing,		and mechanisms to address issues such as request routing,
	distribution metadata exchange, and logging information exchange		distribution metadata exchange, and logging information exchange
	across CDNs. The intent of this document is to outline what each		across CDNs. The intent of this document is to outline what each
	interface needs to accomplish, and to describe how these interfaces		interface needs to accomplish, and to describe how these interfaces
	and mechanisms fit together, while leaving their detailed		and mechanisms fit together, while leaving their detailed
	specification to other documents. It obsoletes RFC 3466.		specification to other documents. It obsoletes RFC 3466.
	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.
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	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 March 13, 2014.		This Internet-Draft will expire on April 24, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 17		skipping to change at page 2, line 17
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	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. Reference Model . . . . . . . . . . . . . . . . . . . . . 4		1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Structure Of This Document . . . . . . . . . . . . . . . 8		1.3. Structure Of This Document . . . . . . . . . . . . . . . 7
	2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8		2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8
	2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8		2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8
	2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8		2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8
	2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9		2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9
	3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10		3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10
	3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12		3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12
	3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13		3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13
	3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18		3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18
	3.4. Iterative DNS-based Redirection Example . . . . . . 22		3.4. Iterative DNS-based Redirection Example . . . . . . 22
	3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25		3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25
	skipping to change at page 2, line 42		skipping to change at page 2, line 42
	3.10. Content and Metadata Acquisition with Multiple Upstream		3.10. Content and Metadata Acquisition with Multiple Upstream
	CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32		CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33		4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33
	4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34		4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34
	4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 34		4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 34
	4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 35		4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 35
	4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 36		4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 36
	4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 38		4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 38
	4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 38		4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 38
	4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39		4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39
	4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 41		4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 40
	5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 41		5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 41
	5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42		5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42
	5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43		5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43
	5.3. CSP using CDNI Request Routing Interface . . . . . . . . 44		5.3. CSP using CDNI Request Routing Interface . . . . . . . . 43
	5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 45		5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 44
	6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 46		6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 46
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 48		8. Security Considerations . . . . . . . . . . . . . . . . . . . 48
	8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 49		8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 49
	8.2. Digital Rights Management . . . . . . . . . . . . . . . . 50		8.2. Digital Rights Management . . . . . . . . . . . . . . . . 49
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
	11. Informative References . . . . . . . . . . . . . . . . . . . 51		11. Informative References . . . . . . . . . . . . . . . . . . . 50
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
	1. Introduction		1. Introduction
	The interconnection of Content Distribution Networks (CDNs) is		This document provides an overview of the various components
	motivated by several use cases, such as those described in		necessary to interconnect CDNs, expanding on the problem statement
	[I-D.ietf-cdni-use-cases]. The overall problem space for CDN		and use cases introduced in RFCs 6770 and 6707. It describes the
	Interconnection is described in RFC 6707. The purpose of this		necessary interfaces and mechanisms in general terms and outlines how
	document is to provide an overview of the various components		they fit together to form a complete system for CDN Interconnection.
	necessary to interconnect CDNs. CDN Interconnection requires the		Detailed specifications are left to other documents. This document
	specification of several interfaces and mechanisms to address issues		makes extensive use of message flow examples to illustrate the
	such as request routing, metadata exchange, and the acquisition of		operation of interconnected CDNs, but these examples should be
	content by one CDN from another. The intent of this document is to		considered illustrative rather than prescriptive.
	describe how these interfaces and mechanisms fit together, leaving
	their detailed specification to other documents. We make extensive
	use of message flow examples to illustrate the operation of
	interconnected CDNs, but these examples should be considered
	illustrative rather than prescriptive.
	RFC 3466 uses different terminology and models for "Content		RFC 3466 uses different terminology and models for "Content
	Internetworking (CDI)". It is also less prescriptive in terms of		Internetworking (CDI)". It is also less prescriptive in terms of
	interfaces. To avoid confusion, this document obsoletes RFC 3466.		interfaces. To avoid confusion, this document obsoletes RFC 3466.
	1.1. Terminology		1.1. Terminology
	This document draws freely on the core terminology defined in RFC		This document uses the core terminology defined in RFC 6707. It also
	6707. It also introduce the following terms:		introduces the following terms:
	CDN-Domain: a host name (FQDN) at the beginning of a URL,		CDN-Domain: a host name (FQDN) at the beginning of a URL,
	representing a set of content that is served by a given CDN. For		representing a set of content that is served by a given CDN. For
	example, in the URL http://cdn.csp.com/...rest of url..., the CDN		example, in the URL http://cdn.csp.com/...rest of url..., the CDN
	domain is cdn.csp.com. A major role of CDN-Domain is to identify a		domain is cdn.csp.com. A major role of CDN-Domain is to identify a
	region (subset) of the URI space relative to which various CDN		region (subset) of the URI space relative to which various CDN
	Interconnection rules and policies are to apply. For example, a		Interconnection rules and policies are to apply. For example, a
	record of CDN Metadata might be defined for the set of resources		record of CDN Metadata might be defined for the set of resources
	corresponding to some CDN-Domain.		corresponding to some CDN-Domain.
	Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for		Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for
	the purposes of communication with a peer CDN, but which is not found		the purposes of communication with a peer CDN, but which is not found
	in client requests. Such CDN-Domains may be used for inter-CDN		in client requests. Such CDN-Domains may be used for inter-CDN
	acquisition, or as redirection targets, and enable a CDN to		acquisition, or as redirection targets, and enable a CDN to
	distinguish a request from a peer CDN from an end-user request.		distinguish a request from a peer CDN from an end-user request.
	Delivering CDN: the CDN that ultimately delivers a piece of content		Delivering CDN: the CDN that ultimately delivers a piece of content
	to the end-user. The last in a potential sequence of downstream		to the end-user. The last in a potential sequence of downstream
	CDNs.		CDNs.
	Recursive CDNI Request Redirection: When an Upstream CDN elects to		Recursive CDNI Request Redirection: When an upstream CDN elects to
	redirect a request towards a Downstream CDN, the Upstream CDN can		redirect a request towards a downstream CDN, the upstream CDN can
	query the Downstream CDN Request Routing system via the CDNI Request		query the downstream CDN Request Routing system via the CDNI Request
	Routing Redirection Interface (or use information cached from earlier		Routing Redirection Interface (or use information cached from earlier
	similar queries) to find out how the Downstream CDN wants the request		similar queries) to find out how the downstream CDN wants the request
	to be redirected, which allows the Upstream CDN to factor in the		to be redirected, which allows the upstream CDN to factor in the
	Downstream CDN response when redirecting the user agent. This		downstream CDN response when redirecting the user agent. This
	approach is referred to as "Recursive" CDNI Request Redirection.		approach is referred to as "Recursive" CDNI Request Redirection.
	Note that the Downstream CDN may elect to have the request redirected		Note that the downstream CDN may elect to have the request redirected
	directly to a Surrogate inside the Downstream CDN, to the Request		directly to a Surrogate inside the downstream CDN, to the Request
	Routing System of the Downstream CDN, to another CDN, or to any other		Routing System of the downstream CDN, to another CDN, or to whatever
	system that the Downstream CDN sees as fit for handling the		system is necessary to handle the redirected request appropriately.
	redirected request.
	Iterative CDNI Request Redirection: When an Upstream CDN elects to		Iterative CDNI Request Redirection: When an upstream CDN elects to
	redirect a request towards a Downstream CDN, the Upstream CDN can		redirect a request towards a downstream CDN, the upstream CDN can
	base its redirection purely on a local decision (and without		base its redirection purely on a local decision (and without
	attempting to take into account how the Downstream CDN may in turn		attempting to take into account how the downstream CDN may in turn
	redirect the user agent). In that case, the Upstream CDN redirects		redirect the user agent). In that case, the upstream CDN redirects
	the request to the request routing system in the Downstream CDN,		the request to the request routing system in the downstream CDN,
	which in turn will decide how to redirect that request: this approach		which in turn will decide how to redirect that request: this approach
	is referred to as "Iterative" CDNI Request Redirection.		is referred to as "Iterative" CDNI Request Redirection.
	Synchronous CDNI operations: operations between CDNs that happen		Synchronous CDNI operations: operations between CDNs that happen
	during the process of servicing a user request, i.e. between the time		during the process of servicing a user request, i.e. between the time
	that the user agent begins its attempt to obtain content and the time		that the user agent begins its attempt to obtain content and the time
	at which that request is served.		at which that request is served.
	Asynchronous CDNI operations: operations between CDNs that happen		Asynchronous CDNI operations: operations between CDNs that happen
	independently of any given user request, such as advertisement of		independently of any given user request, such as advertisement of
	footprint information or pre-positioning of content for later		footprint information or pre-positioning of content for later
	delivery.		delivery.
	Trigger Interface: a subset of the CDNI Control interface that		Trigger Interface: a subset of the CDNI Control interface that
	includes operations to pre-position, revalidate, and purge both		includes operations to pre-position, revalidate, and purge both
	metadata and content. These operations are typically called in		metadata and content. These operations are typically called in
	response to some action (trigger) by the CSP on the upstream CDN.		response to some action (Trigger) by the CSP on the upstream CDN.
			We also sometimes use uCDN and dCDN as shorthand for upstream CDN and
			downstream CDN, respectively.
	1.2. Reference Model		1.2. Reference Model
	This document uses the reference model in Figure 1, which expands the		This document uses the reference model in Figure 1, which expands the
	reference model originally defined in RFC 6707. (The difference is		reference model originally defined in RFC 6707. (The difference is
	that the expanded model splits the Request Routing Interface into its		that the expanded model splits the Request Routing Interface into its
	two distinct parts: the Request Routing Redirection interface and the		two distinct parts: the Request Routing Redirection interface and the
	Footprint and Capabilities Advertisement interface, as described		Footprint and Capabilities Advertisement interface, as described
	below.)		below.)
	skipping to change at page 6, line 14		skipping to change at page 6, line 10
	**** interfaces outside the scope of CDNI		**** interfaces outside the scope of CDNI
	.... interfaces outside the scope of CDNI		.... interfaces outside the scope of CDNI
	Figure 1: CDNI Expanded Model and CDNI Interfaces		Figure 1: CDNI Expanded Model and CDNI Interfaces
	We note that while some interfaces in the reference model are "out of		We note that while some interfaces in the reference model are "out of
	scope" for the CDNI WG (in the sense that there is no need to define		scope" for the CDNI WG (in the sense that there is no need to define
	new protocols for those interfaces) we still need to refer to them in		new protocols for those interfaces) we still need to refer to them in
	this document to explain the overall operation of CDNI.		this document to explain the overall operation of CDNI.
	We also note that, while we generally show only one uCDN serving a		We also note that, while we generally show only one upstream CDN
	given CSP, it is entirely possible that multiple uCDNs can serve a		serving a given CSP, it is entirely possible that multiple uCDNs can
	single CSP. In fact, this situation effectively exists today in the		serve a single CSP. In fact, this situation effectively exists today
	sense that a single CSP can currently delegate its content delivery		in the sense that a single CSP can currently delegate its content
	to more than one CDN.		delivery to more than one CDN.
	The following briefly describes the five CDNI interfaces,		The following briefly describes the five CDNI interfaces,
	paraphrasing the definitions given in RFC 6707. We discuss these		paraphrasing the definitions given in RFC 6707. We discuss these
	interfaces in more detail in Section 4.		interfaces in more detail in Section 4.
	o CDNI Control interface (CI): Operations to bootstrap and		o CDNI Control interface (CI): Operations to bootstrap and
	parameterize the other CDNI interfaces, as well as operations to		parameterize the other CDNI interfaces, as well as operations to
	pre-position, revalidate, and purge both metadata and content.		pre-position, revalidate, and purge both metadata and content.
	The latter subset of operations is sometimes collectively called		The latter subset of operations is sometimes collectively called
	the "trigger interface."		the "Trigger interface."
	o CDNI Request Routing interface: Operations to determine what CDN		o CDNI Request Routing interface: Operations to determine what CDN
	(and optionally what surrogate within a CDN) is to serve end-		(and optionally what surrogate within a CDN) is to serve end-
	user's requests. Is actually a logical bundling of two separate		user's requests. Is actually a logical bundling of two separate
	but related interfaces:		but related interfaces:
	* CDNI Footprint & Capabilities Advertisement interface (FCI):		* CDNI Footprint & Capabilities Advertisement interface (FCI):
	Asynchronous operations to exchange routing information (e.g.,		Asynchronous operations to exchange routing information (e.g.,
	the network footprint and capabilities served by a given CDN)		the network footprint and capabilities served by a given CDN)
	that enables CDN selection for subsequent user requests; and		that enables CDN selection for subsequent user requests; and
	* CDNI Request Routing Redirection interface (RI): Synchronous		* CDNI Request Routing Redirection interface (RI): Synchronous
	operations to select a delivery CDN (surrogate) for a given		operations to select a delivery CDN (surrogate) for a given
	user request.		user request.
	o CDNI Metadata interface (MI): Operations to communicate metadata		o CDNI Metadata interface (MI): Operations to communicate metadata
	that governs how the content is delivered by interconnected CDNs.		that governs how the content is delivered by interconnected CDNs.
	Examples of CDNI metadata include geo-blocking directives,		Examples of CDNI metadata include geo-blocking directives,
	availability windows, access control mechanisms, and purge		availability windows, access control mechanisms, and purge
	directives. May include a combination of:		directives. It may include a combination of:
	* Asynchronous operations to exchange metadata that govern		* Asynchronous operations to exchange metadata that govern
	subsequent user requests for content; and		subsequent user requests for content; and
	* Synchronous operations that govern behavior for a given user		* Synchronous operations that govern behavior for a given user
	request for content.		request for content.
	o CDNI Logging interface (LI): Operations that allow interconnected		o CDNI Logging interface (LI): Operations that allow interconnected
	CDNs to exchange relevant activity logs. May include a		CDNs to exchange relevant activity logs. May include a
	combination of:		combination of:
	* Real-time exchanges, suitable for runtime traffic monitoring;		* Real-time exchanges, suitable for runtime traffic monitoring;
	and		and
	* Offline exchanges, suitable for analytics and billing.		* Offline exchanges, suitable for analytics and billing.
	There is some potential overlap between the set of trigger-based		There is some potential overlap between the set of Trigger-based
	operations in the CDNI Control interface and the CDNI Metadata		operations in the CDNI Control interface and the CDNI Metadata
	interface. For both cases, the information passed from the upstream		interface. For both cases, the information passed from the upstream
	CDN to the downstream CDN can broadly be viewed as metadata that		CDN to the downstream CDN can broadly be viewed as metadata that
	describes how content is to be managed by the downstream CDN. For		describes how content is to be managed by the downstream CDN. For
	example, the information conveyed by CI to pre-position, revalidate		example, the information conveyed by CI to pre-position, revalidate
	or purge metadata is similar to the information conveyed by posting		or purge metadata is similar to the information conveyed by posting
	updated metadata via the MI. Even the CI operation to purge content		updated metadata via the MI. Even the CI operation to purge content
	could be viewed as an metadata update for that content: purge simply		could be viewed as an metadata update for that content: purge simply
	says that the availability window for the named content ends now.		says that the availability window for the named content ends now.
	The two interfaces share much in common, so minimally, there will		The two interfaces share much in common, so minimally, there will
	need to be a consistent data model that spans both.		need to be a consistent data model that spans both.
	The distinction we draw has to do with what the caller knows about		The distinction we draw has to do with what the uCDN knows about the
	the successful application of the metadata by the callee. In the		successful application of the metadata by the dCDN. In the case of
	case of the CI, the downstream CDN returning a successful status		the CI, the downstream CDN returning a successful status message
	message guarantees that the operation has been successfully		guarantees that the operation has been successfully completed; e.g.,
	completed; e.g., the content has been purged or pre-positioned. This		the content has been purged or pre-positioned. This implies that the
	implies that the downstream CDN accepts responsibility for having		downstream CDN accepts responsibility for having successfully
	successfully completed the requested operation. In contrast,		completed the requested operation. In contrast, metadata passed
	metadata passed between CDNs via the MI carries no such completion		between CDNs via the MI carries no such completion guarantee.
	guarantee. Returning success implies successful receipt of the		Returning success implies successful receipt of the metadata, but
	metadata, but nothing can be inferred about precisely when the		nothing can be inferred about precisely when the metadata will take
	metadata will take effect in the downstream CDN, only that it will		effect in the downstream CDN, only that it will take effect
	take effect eventually. This is because of the challenge in globally		eventually. This is because of the challenge in globally
	synchronizing updates to metadata with end-user requests that are		synchronizing updates to metadata with end-user requests that are
	currently in progress (or indistinguishable from currently being in		currently in progress (or indistinguishable from currently being in
	progress). Clearly, a CDN will not be viewed as a trusted peer if		progress). Clearly, a CDN will not be viewed as a trusted peer if
	"eventually" often becomes an indefinite period of time, but the		"eventually" often becomes an indefinite period of time, but the
	acceptance of responsibility cannot be as crisply defined for the MI.		acceptance of responsibility cannot be as crisply defined for the MI.
	Finally, there is a practical issue that impacts all of the CNDI		Finally, there is a practical issue that impacts all of the CNDI
	interfaces, and that is whether or not to optimize CDNI for HTTP		interfaces, and that is whether or not to optimize CDNI for HTTP
	Adaptive Streaming (HAS). We highlight specific issues related to		Adaptive Streaming (HAS). We highlight specific issues related to
	delivering HAS content throughout this document, but for a more		delivering HAS content throughout this document, but for a more
	thorough treatment of the topic, see [I-D.brandenburg-cdni-has].		thorough treatment of the topic, see RFC 6983.
	1.3. Structure Of This Document		1.3. Structure Of This Document
	The remainder of this document is organized as follows:		The remainder of this document is organized as follows:
	o Section 2 describes some essential building blocks for CDNI,		o Section 2 describes some essential building blocks for CDNI,
	notably the various options for redirecting user requests to a		notably the various options for redirecting user requests to a
	given CDN.		given CDN.
	o Section 3 provides a number of illustrative examples of various		o Section 3 provides a number of illustrative examples of various
	CDNI operations.		CDNI operations.
	o Section 4 describes the functionality of the main CDNI interfaces.		o Section 4 describes the functionality of the main CDNI interfaces.
	skipping to change at page 8, line 48		skipping to change at page 8, line 45
	2.1.1. DNS Redirection		2.1.1. DNS Redirection
	DNS redirection is based on returning different IP addresses for the		DNS redirection is based on returning different IP addresses for the
	same DNS name, for example, to balance server load or to account for		same DNS name, for example, to balance server load or to account for
	the client's location in the network. A DNS server, sometimes called		the client's location in the network. A DNS server, sometimes called
	the Local DNS (LDNS), resolves DNS names on behalf of an end-user.		the Local DNS (LDNS), resolves DNS names on behalf of an end-user.
	The LDNS server in turn queries other DNS servers until it reaches		The LDNS server in turn queries other DNS servers until it reaches
	the authoritative DNS server for the CDN-Domain. The network		the authoritative DNS server for the CDN-Domain. The network
	operator typically provides the LDNS server, although the user is		operator typically provides the LDNS server, although the user is
	free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).		free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).
			This latter possibility is important because the authoritative DNS
			server sees only the IP address of the DNS server that queries it,
			not the IP address of the original end-user.
	The advantage of DNS redirection is that it is completely transparent		The advantage of DNS redirection is that it is completely transparent
	to the end user-\u002Dthe user sends a DNS name to the LDNS server		to the end user; the user sends a DNS name to the LDNS server and
	and gets back an IP address. On the other hand, DNS redirection is		gets back an IP address. On the other hand, DNS redirection is
	problematic because the DNS request comes from the LDNS server, not		problematic because the DNS request comes from the LDNS server, not
	the end-user. This may affect the accuracy of server selection that		the end-user. This may affect the accuracy of server selection that
	is based on the user's location. The transparency of DNS redirection		is based on the user's location. The transparency of DNS redirection
	is also a problem in that there is no opportunity to take the		is also a problem in that there is no opportunity to take the
	attributes of the user agent or the URI path component into account.		attributes of the user agent or the URI path component into account.
	We consider two main forms of DNS redirection: simple and CNAME-		We consider two main forms of DNS redirection: simple and CNAME-
	based.		based.
	In simple DNS redirection, the authoritative DNS server for the name		In simple DNS redirection, the authoritative DNS server for the name
	simply returns an IP address from a set of possible IP addresses.		simply returns an IP address from a set of possible IP addresses.
	The answer is chosen from the set based on characteristics of the set		The answer is chosen from the set based on characteristics of the set
	(e.g., the relative loads on the servers) or characteristics of the		(e.g., the relative loads on the servers) or characteristics of the
	client (e.g., the location of the client relative to the servers).		client (e.g., the location of the client relative to the servers).
	Simple redirection is straightforward. The only caveats are (1)		Simple redirection is straightforward. The only caveats are (1)
	there is a limit to the number alternate IP addresses a single DNS		there is a limit to the number of alternate IP addresses a single DNS
	server can manage; and (2) DNS responses are cached by downstream		server can manage; and (2) DNS responses are cached by downstream
	servers so the TTL on the response must be set to an appropriate		servers so the TTL on the response must be set to an appropriate
	value so as to preserve the fresheness of the redirection.		value so as to preserve the fresheness of the redirection.
	In CNAME-based DNS redirection, the authoritative server returns a		In CNAME-based DNS redirection, the authoritative server returns a
	CNAME response to the DNS request, telling the LDNS server to restart		CNAME response to the DNS request, telling the LDNS server to restart
	the name lookup using a new name. A CNAME is essentially a symbolic		the name lookup using a new name. A CNAME is essentially a symbolic
	link in the DNS namespace, and like a symbolic link, redirection is		link in the DNS namespace, and like a symbolic link, redirection is
	transparent to the client-\u002Dthe LDNS server gets the CNAME		transparent to the client; the LDNS server gets the CNAME response
	response and re-executes the lookup. Only when the name has been		and re-executes the lookup. Only when the name has been resolved to
	resolved to an IP address does it return the result to the user.		an IP address does it return the result to the user. Note that DNAME
	Note that DNAME would be preferable to CNAME if it becomes widely		would be preferable to CNAME if it becomes widely supported.
	supported.
	2.1.2. HTTP Redirection		2.1.2. HTTP Redirection
	HTTP redirection makes use of the redirection response of the HTTP		HTTP redirection makes use of the redirection response of the HTTP
	protocol (e.g.,"302" or "307"). This response contains a new URL		protocol (e.g.,"302" or "307"). This response contains a new URL
	that the application should fetch instead of the original URL. By		that the application should fetch instead of the original URL. By
	changing the URL appropriately, the server can cause the user to		changing the URL appropriately, the server can cause the user to
	redirect to a different server. The advantages of HTTP redirection		redirect to a different server. The advantages of HTTP redirection
	are that (1) the server can change the URL fetched by the client to		are that (1) the server can change the URL fetched by the client to
	include, for example, both the DNS name of the particular server to		include, for example, both the DNS name of the particular server to
	skipping to change at page 15, line 29		skipping to change at page 15, line 29
	Figure 3: Message Flow for Iterative HTTP Redirection		Figure 3: Message Flow for Iterative HTTP Redirection
	The steps illustrated in the figure are as follows:		The steps illustrated in the figure are as follows:
	1. A DNS resolver for Operator A processes the DNS request for its		1. A DNS resolver for Operator A processes the DNS request for its
	customer based on CDN-Domain cdn.csp.com. It returns the IP		customer based on CDN-Domain cdn.csp.com. It returns the IP
	address of a request router in Operator A.		address of a request router in Operator A.
	2. A Request Router for Operator A processes the HTTP request and		2. A Request Router for Operator A processes the HTTP request and
	recognizes that the end-user is best served by another		recognizes that the end-user is best served by another CDN,
	CDN-\u002Dspecifically one provided by Operator B-\u002Dand so		specifically one provided by Operator B, and so it returns a 302
	it returns a 302 redirect message for a new URL constructed by		redirect message for a new URL constructed by "stacking"
	"stacking" Operator B's distinguished CDN-Domain		Operator B's distinguished CDN-Domain (peer-a.op-b.net) on the
	(peer-a.op-b.net) on the front of the original URL. (Note that		front of the original URL. (Note that more complex URL
	more complex URL manipulations are possible, such as replacing		manipulations are possible, such as replacing the initial CDN-
	the initial CDN-Domain by some opaque handle.)		Domain by some opaque handle.)
	3. The end-user does a DNS lookup using Operator B's distinguished		3. The end-user does a DNS lookup using Operator B's distinguished
	CDN-Domain (peer-a.op-b.net). B's DNS resolver returns the IP		CDN-Domain (peer-a.op-b.net). B's DNS resolver returns the IP
	address of a request router for Operator B. Note that if request		address of a request router for Operator B. Note that if request
	routing within dCDN was performed using DNS instead of HTTP		routing within dCDN was performed using DNS instead of HTTP
	redirection, B's DNS resolver would also behave as the request		redirection, B's DNS resolver would also behave as the request
	router and directly return the IP address of a delivery node.		router and directly return the IP address of a delivery node.
	4. The request router for Operator B processes the HTTP request and		4. The request router for Operator B processes the HTTP request and
	selects a suitable delivery node to serve the end-user request,		selects a suitable delivery node to serve the end-user request,
	and returns a 302 redirect message for a new URL constructed by		and returns a 302 redirect message for a new URL constructed by
	replacing the hostname by a subdomain of the Operator B's		replacing the hostname with a subdomain of the Operator B's
	distinguished CDN-Domain that points to the selected delivery		distinguished CDN-Domain that points to the selected delivery
	node.		node.
	5. The end-user does a DNS lookup using Operator B's delivery node		5. The end-user does a DNS lookup using Operator B's delivery node
	subdomain (node1.peer-a.op-b.net). B's DNS resolver returns the		subdomain (node1.peer-a.op-b.net). B's DNS resolver returns the
	IP address of the delivery node.		IP address of the delivery node.
	6. The end-user requests the content from B's delivery node. In		6. The end-user requests the content from B's delivery node. In
	the case of a cache hit, steps 6, 7, 8, 9 and 10 below do not		the case of a cache hit, steps 6, 7, 8, 9 and 10 below do not
	happen, and the content data is directly returned by the		happen, and the content data is directly returned by the
	skipping to change at page 16, line 35		skipping to change at page 16, line 35
	8. The request router for Operator A processes the HTTP request		8. The request router for Operator A processes the HTTP request
	from Operator B delivery node. Operator A request router		from Operator B delivery node. Operator A request router
	recognizes that the request is from a peer CDN rather than an		recognizes that the request is from a peer CDN rather than an
	end-user because of the dedicated inter-CDN acquisition domain		end-user because of the dedicated inter-CDN acquisition domain
	(op-b-acq.op-a.net). (Note that without this specially defined		(op-b-acq.op-a.net). (Note that without this specially defined
	inter-CDN acquisition domain, operator A would be at risk of		inter-CDN acquisition domain, operator A would be at risk of
	redirecting the request back to operator B, resulting in an		redirecting the request back to operator B, resulting in an
	infinite loop). The request router for Operator A selects a		infinite loop). The request router for Operator A selects a
	suitable delivery node in uCDN to serve the inter-CDN		suitable delivery node in uCDN to serve the inter-CDN
	acquisition request and returns a 302 redirect message for a new		acquisition request and returns a 302 redirect message for a new
	URL constructed by replacing the hostname by a subdomain of the		URL constructed by replacing the hostname with a subdomain of
	Operator A's distinguished inter-CDN acquisition domain that		the Operator A's distinguished inter-CDN acquisition domain that
	points to the selected delivery node.		points to the selected delivery node.
	9. Operator A DNS resolver processes the DNS request and returns		9. Operator A DNS resolver processes the DNS request and returns
	the IP address of the delivery node in operator A.		the IP address of the delivery node in operator A.
	10. Operator B requests (acquires) the content from Operator A.		10. Operator B requests (acquires) the content from Operator A.
	Although not shown, Operator A processes the rest of the URL: it		Although not shown, Operator A processes the rest of the URL: it
	extracts information identifying the origin server, validates		extracts information identifying the origin server, validates
	that this server has been registered, and determines the content		that this server has been registered, and determines the content
	provider that owns the origin server. It may also perform its		provider that owns the origin server. It may also perform its
	skipping to change at page 21, line 15		skipping to change at page 21, line 15
	7. The request router for Operator A processes the HTTP request from		7. The request router for Operator A processes the HTTP request from
	Operator B delivery node. Operator A request router recognizes		Operator B delivery node. Operator A request router recognizes
	that the request is from a peer CDN rather than an end-user		that the request is from a peer CDN rather than an end-user
	because of the dedicated inter-CDN acquisition domain		because of the dedicated inter-CDN acquisition domain
	(op-b-acq.op-a.net). (Note that without this specially defined		(op-b-acq.op-a.net). (Note that without this specially defined
	inter-CDN acquisition domain, operator A would be at risk of		inter-CDN acquisition domain, operator A would be at risk of
	redirecting the request back to operator B, resulting in an		redirecting the request back to operator B, resulting in an
	infinite loop). The request router for Operator A selects a		infinite loop). The request router for Operator A selects a
	suitable delivery node in uCDN to serve the inter-CDN acquisition		suitable delivery node in uCDN to serve the inter-CDN acquisition
	request and returns a 302 redirect message for a new URL		request and returns a 302 redirect message for a new URL
	constructed by replacing the hostname by a subdomain of the		constructed by replacing the hostname with a subdomain of the
	Operator A's distinguished inter-CDN acquisition domain that		Operator A's distinguished inter-CDN acquisition domain that
	points to the selected delivery node.		points to the selected delivery node.
	8. Operator A recognizes that the DNS request is from a peer CDN		8. Operator A recognizes that the DNS request is from a peer CDN
	rather than an end-user (due to the internal CDN-Domain) and so		rather than an end-user (due to the internal CDN-Domain) and so
	returns the address of a delivery node. (Note that without this		returns the address of a delivery node. (Note that without this
	specially defined internal domain, Operator A would be at risk of		specially defined internal domain, Operator A would be at risk of
	redirecting the request back to Operator B, resulting in an		redirecting the request back to Operator B, resulting in an
	infinite loop.)		infinite loop.)
	skipping to change at page 26, line 34		skipping to change at page 26, line 34
	footprint discovery).		footprint discovery).
	3.6. Content Removal Example		3.6. Content Removal Example
	The following example illustrates how the CDNI Control interface may		The following example illustrates how the CDNI Control interface may
	be used to achieve pre-positioning of an item of content in the dCDN.		be used to achieve pre-positioning of an item of content in the dCDN.
	In this example, user requests for a particular content, and		In this example, user requests for a particular content, and
	corresponding redirection of such requests from Operator A to		corresponding redirection of such requests from Operator A to
	Operator B CDN, may (or may not) have taken place earlier. Then, at		Operator B CDN, may (or may not) have taken place earlier. Then, at
	some point in time, the uCDN (for example, in response to a		some point in time, the uCDN (for example, in response to a
	corresponding trigger from the Content Provider) uses the CI to		corresponding Trigger from the Content Provider) uses the CI to
	request that content identified by a particular URL be removed from		request that content identified by a particular URL be removed from
	dCDN. The following diagram illustrates the operation.		dCDN. The following diagram illustrates the operation.
	End-User Operator B Operator A		End-User Operator B Operator A
	| |CI purge cdn.csp.com/... |		| |CI purge cdn.csp.com/... |
	| |<------------------------|		| |<------------------------|
	| | |		| | |
	| |CI OK |		| |CI OK |
	| |------------------------>|		| |------------------------>|
	| | |		| | |
	skipping to change at page 28, line 40		skipping to change at page 28, line 40
	positioning; however, such intra-CDN dynamic acquisition would not		positioning; however, such intra-CDN dynamic acquisition would not
	involve the uCDN.		involve the uCDN.
	3.8. Asynchronous CDNI Metadata Example		3.8. Asynchronous CDNI Metadata Example
	In this section we walk through a simple example illustrating a		In this section we walk through a simple example illustrating a
	scenario of asynchronously exchanging CDNI metadata, where the		scenario of asynchronously exchanging CDNI metadata, where the
	downstream CDN obtains CDNI metadata for content ahead of a		downstream CDN obtains CDNI metadata for content ahead of a
	corresponding content request. The example that follows assumes that		corresponding content request. The example that follows assumes that
	HTTP-based inter-CDN redirection and recursive CDNI request-routing		HTTP-based inter-CDN redirection and recursive CDNI request-routing
	are used, as in Section 3.3. However, asynchronous exchange of CDNI		are used, as in Section 3.3. However, Asynchronous exchange of CDNI
	Metadata is similarly applicable to DNS-based inter-CDN redirection		Metadata is similarly applicable to DNS-based inter-CDN redirection
	and iterative request routing (in which cases the CDNI metadata may		and iterative request routing (in which cases the CDNI metadata may
	be used at slightly different processing stages of the message		be used at slightly different processing stages of the message
	flows).		flows).
	End-User Operator B Operator A		End-User Operator B Operator A
	| | |		| | |
	| |CI pre-position (trigger)|		| |CI pre-position (Trigger)|
	| |<------------------------|(1)		| |<------------------------|(1)
	| | |		| | |
	| |CI OK |		| |CI OK |
	| |------------------------>|(2)		| |------------------------>|(2)
	| | |		| | |
	| |MI pull REQ |		| |MI pull REQ |
	| |------------------------>|(3)		| |------------------------>|(3)
	| | |		| | |
	| |MI metadata REP |(4)		| |MI metadata REP |(4)
	| | |		| | |
	skipping to change at page 29, line 35		skipping to change at page 29, line 35
	|------------------------>|(9) |		|------------------------>|(9) |
	| | |		| | |
	: : :		: : :
	| CONTENT DATA | |		| CONTENT DATA | |
	|<------------------------| |(10)		|<------------------------| |(10)
	Figure 9: Message Flow for Asynchronous CDNI Metadata		Figure 9: Message Flow for Asynchronous CDNI Metadata
	The steps illustrated in the figure are as follows:		The steps illustrated in the figure are as follows:
	1. Operator A uses the CI to trigger to signal the availability of		1. Operator A uses the CI to Trigger to signal the availability of
	CDNI metadata to Operator B.		CDNI metadata to Operator B.
	2. Operator B acknowledges the receipt of this trigger.		2. Operator B acknowledges the receipt of this Trigger.
	3. Operator B requests the latest metadata from Operator A using		3. Operator B requests the latest metadata from Operator A using
	the MI.		the MI.
	4. Operator A replies with the requested metadata. This document		4. Operator A replies with the requested metadata. This document
	does not constrain how the CDNI metadata information is actually		does not constrain how the CDNI metadata information is actually
	represented. For the purposes of this example, we assume that		represented. For the purposes of this example, we assume that
	Operator A provides CDNI metadata to Operator B indicating that:		Operator A provides CDNI metadata to Operator B indicating that:
	* this CDNI Metadata is applicable to any content referenced by		* this CDNI Metadata is applicable to any content referenced by
	skipping to change at page 30, line 39		skipping to change at page 30, line 39
	before serving the content. (Details of this authorization are		before serving the content. (Details of this authorization are
	not shown.)		not shown.)
	10. Assuming successful per-request authorization, serving of		10. Assuming successful per-request authorization, serving of
	Content Data (possibly preceded by inter-CDN acquisition)		Content Data (possibly preceded by inter-CDN acquisition)
	proceeds as in Section 3.3.		proceeds as in Section 3.3.
	3.9. Synchronous CDNI Metadata Acquisition Example		3.9. Synchronous CDNI Metadata Acquisition Example
	In this section we walk through a simple example illustrating a		In this section we walk through a simple example illustrating a
	scenario of synchronous CDNI metadata acquisition, in which the		scenario of Synchronous CDNI metadata acquisition, in which the
	downstream CDN obtains CDNI metadata for content at the time of		downstream CDN obtains CDNI metadata for content at the time of
	handling a first request for the corresponding content. As in the		handling a first request for the corresponding content. As in the
	preceding section, this example assumes that HTTP-based inter-CDN		preceding section, this example assumes that HTTP-based inter-CDN
	redirection and recursive CDNI request-routing are used (as in		redirection and recursive CDNI request-routing are used (as in
	Section 3.3), but dynamic CDNI metadata acquisition is applicable to		Section 3.3), but dynamic CDNI metadata acquisition is applicable to
	other variations of request routing.		other variations of request routing.
	End-User Operator B Operator A		End-User Operator B Operator A
	| | |		| | |
	| CONTENT REQUEST | |		| CONTENT REQUEST | |
	skipping to change at page 31, line 39		skipping to change at page 31, line 39
	Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition		Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition
	The steps illustrated in the figure are as follows:		The steps illustrated in the figure are as follows:
	1. A Content Request arrives as normal.		1. A Content Request arrives as normal.
	2. An RI request occurs as in the prior example.		2. An RI request occurs as in the prior example.
	3. On receipt of the CDNI Request Routing Request, Operator B's CDN		3. On receipt of the CDNI Request Routing Request, Operator B's CDN
	initiates synchronous acquisition of CDNI Metadata that are		initiates Synchronous acquisition of CDNI Metadata that are
	needed for routing of the end-user request. We assume the URI		needed for routing of the end-user request. We assume the URI
	for the a Metadata server is known ahead of time through some		for the a Metadata server is known ahead of time through some
	out-of-band means.		out-of-band means.
	4. On receipt of a CDNI Metadata Request, Operator A's CDN		4. On receipt of a CDNI Metadata Request, Operator A's CDN
	responds, making the corresponding CDNI metadata information		responds, making the corresponding CDNI metadata information
	available to Operator B's CDN. This metadata is considered by		available to Operator B's CDN. This metadata is considered by
	operator B's CDN before responding to the Request Routing		operator B's CDN before responding to the Request Routing
	request. (In a simple case, the metadata could simply be an		request. (In a simple case, the metadata could simply be an
	allow or deny response for this particular request.)		allow or deny response for this particular request.)
	5. Response to the RI request as normal.		5. Response to the RI request as normal.
	6. Redirection message is sent to the end user.		6. Redirection message is sent to the end user.
	7. A delivery node of Operator B receives the end user request.		7. A delivery node of Operator B receives the end user request.
	8. The delivery node triggers dynamic acquisition of additional		8. The delivery node Triggers dynamic acquisition of additional
	CDNI metadata that are needed to process the end-user content		CDNI metadata that are needed to process the end-user content
	request. Note that there may exist cases where this step need		request. Note that there may exist cases where this step need
	not happen, for example because the metadata were already		not happen, for example because the metadata were already
	acquired previously.		acquired previously.
	9. Operator A's CDN responds to the CDNI Metadata Request and makes		9. Operator A's CDN responds to the CDNI Metadata Request and makes
	the corresponding CDNI metadata available to Operator B. This		the corresponding CDNI metadata available to Operator B. This
	metadata influence how Operator B's CDN processes the end-user		metadata influence how Operator B's CDN processes the end-user
	request.		request.
	skipping to change at page 35, line 12		skipping to change at page 35, line 12
	URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at		URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at
	the beginning of a URI) or by a URI-Filter (i.e., a regular		the beginning of a URI) or by a URI-Filter (i.e., a regular
	expression that matches a subset of URIs contained in some CDN-		expression that matches a subset of URIs contained in some CDN-
	Doman). In other words, CDN-Domains and URI-Filters provide a		Doman). In other words, CDN-Domains and URI-Filters provide a
	uniform means to aggregate sets (and subsets) of URIs for the purpose		uniform means to aggregate sets (and subsets) of URIs for the purpose
	of defining the scope for some operation in one of the CDNI		of defining the scope for some operation in one of the CDNI
	interfaces.		interfaces.
	4.3. Request Routing Interfaces		4.3. Request Routing Interfaces
	The Request Routing interface comprises two parts: the asynchronous		The Request Routing interface comprises two parts: the Asynchronous
	interface used by a dCDN to advertize footprint and capabilities		interface used by a dCDN to advertize footprint and capabilities
	(denoted FCI) to a uCDN, allowing the uCDN to decide whether to		(denoted FCI) to a uCDN, allowing the uCDN to decide whether to
	redirect particular user requests to that dCDN; and the synchronous		redirect particular user requests to that dCDN; and the Synchronous
	interface used by the uCDN to redirect a user request to the dCDN		interface used by the uCDN to redirect a user request to the dCDN
	(denoted RI). (These are somewhat analogous to the operations of		(denoted RI). (These are somewhat analogous to the operations of
	routing and forwarding in IP.)		routing and forwarding in IP.)
	As illustrated in Section 3, the RI part of request routing may be		As illustrated in Section 3, the RI part of request routing may be
	implemented in part by DNS and HTTP. Naming conventions may be		implemented in part by DNS and HTTP. Naming conventions may be
	established by which CDN peers communicate whether a request should		established by which CDN peers communicate whether a request should
	be routed or content served.		be routed or content served.
	We also note that RI plays a key role in enabling recursive		We also note that RI plays a key role in enabling recursive
	skipping to change at page 38, line 19		skipping to change at page 38, line 19
	4.5. CDNI Control Interface		4.5. CDNI Control Interface
	The CDNI Control interface is initially used to bootstrap the other		The CDNI Control interface is initially used to bootstrap the other
	interfaces. As a simple example, it could be used to provide the		interfaces. As a simple example, it could be used to provide the
	address of the logging server in dCDN to uCDN in order to bootstrap		address of the logging server in dCDN to uCDN in order to bootstrap
	the CDNI Logging interface. It may also be used, for example, to		the CDNI Logging interface. It may also be used, for example, to
	establish security associations for the other interfaces.		establish security associations for the other interfaces.
	The other role the CI plays is to allow the uCDN to pre-position,		The other role the CI plays is to allow the uCDN to pre-position,
	revalidate, or purge metadata and content on a dCDN. These		revalidate, or purge metadata and content on a dCDN. These
	operations, sometimes collectively called the trigger interface, are		operations, sometimes collectively called the Trigger interface, are
	discussed further in [I-D.murray-cdni-triggers].		discussed further in [I-D.murray-cdni-triggers].
	4.6. CDNI Metadata Interface		4.6. CDNI Metadata Interface
	The role of the CDNI Metadata interface is to enable CDNI		The role of the CDNI Metadata interface is to enable CDNI
	distribution metadata to be conveyed to the downstream CDN by the		distribution metadata to be conveyed to the downstream CDN by the
	upstream CDN. For example, see [I-D.ietf-cdni-metadata]. Such		upstream CDN. For example, see [I-D.ietf-cdni-metadata]. Such
	metadata includes geo-blocking restrictions, availability windows,		metadata includes geo-blocking restrictions, availability windows,
	access control policies, and so on. It may also include information		access control policies, and so on. It may also include information
	to facilitate acquisition of content by dCDN (e.g., alternate sources		to facilitate acquisition of content by dCDN (e.g., alternate sources
	skipping to change at page 39, line 36		skipping to change at page 39, line 36
	over the various inter-CDN acquisition protocols (e.g., HTTP)		over the various inter-CDN acquisition protocols (e.g., HTTP)
	requires further investigation and may require small extensions or		requires further investigation and may require small extensions or
	semantic changes to the acquisition protocol.		semantic changes to the acquisition protocol.
	4.7. HTTP Adaptive Streaming Concerns		4.7. HTTP Adaptive Streaming Concerns
	We consider HTTP Adaptive Streaming (HAS) and the impact it has on		We consider HTTP Adaptive Streaming (HAS) and the impact it has on
	the CDNI interfaces because large objects (e.g., videos) are broken		the CDNI interfaces because large objects (e.g., videos) are broken
	into a sequence of small, independent chunks. For each of the		into a sequence of small, independent chunks. For each of the
	following, a more thorough discussion, including an overview of the		following, a more thorough discussion, including an overview of the
	tradeoffs involved in alternative designs, can be found in		tradeoffs involved in alternative designs, can be found in RFC 6983.
	[I-D.brandenburg-cdni-has].
	First, with respect to Content Acquisition and File Management, which		First, with respect to Content Acquisition and File Management, which
	are out-of-scope for the CDNI interfaces but nontheless relevant to		are out-of-scope for the CDNI interfaces but nontheless relevant to
	the overall operation, we assume no additional measures are required		the overall operation, we assume no additional measures are required
	to deal with large numbers of chunks. This means that the dCDN is		to deal with large numbers of chunks. This means that the dCDN is
	not explicitly made aware of any relationship between different		not explicitly made aware of any relationship between different
	chunks and the dCDN handles each chunk as if it were an individual		chunks and the dCDN handles each chunk as if it were an individual
	and independent content item. The result is that content acquisition		and independent content item. The result is that content acquisition
	between uCDN and dCDN also happens on a per-chunk basis. This		between uCDN and dCDN also happens on a per-chunk basis. This
	approach is in line with the recommendations made in		approach is in line with the recommendations made in RFC 6983, which
	[I-D.brandenburg-cdni-has], which also identifies potential		also identifies potential improvements in this area that might be
	improvements in this area that might be considered in the future.		considered in the future.
	Second, with respect to Request Routing, we note that HAS manifest		Second, with respect to Request Routing, we note that HAS manifest
	files have the potential to interfere with request routing since		files have the potential to interfere with request routing since
	manifest files contain URLs pointing to the location of content		manifest files contain URLs pointing to the location of content
	chunks. To make sure that a manifest file does not hinder CDNI		chunks. To make sure that a manifest file does not hinder CDNI
	request routing and does not place excessive load on CDNI resources,		request routing and does not place excessive load on CDNI resources,
	the use of manifest files could either be limited to those containing		the use of manifest files could either be limited to those containing
	relative URLs or the uCDN could modify the URLs in the manifest. Our		relative URLs or the uCDN could modify the URLs in the manifest. Our
	approach for dealing with these issues is twofold. As a mandatory		approach for dealing with these issues is twofold. As a mandatory
	requirement, CDNs should be able to handle unmodified manifest files		requirement, CDNs should be able to handle unmodified manifest files
	skipping to change at page 40, line 33		skipping to change at page 40, line 32
	information, and the desire to correlate logging information for		information, and the desire to correlate logging information for
	chunk requests that correspond to the same HAS session. For the		chunk requests that correspond to the same HAS session. For the
	initial CDNI specification, our approach is to expect participating		initial CDNI specification, our approach is to expect participating
	CDNs to support per-chunk logging (e.g. logging each chunk request as		CDNs to support per-chunk logging (e.g. logging each chunk request as
	if it were an independent content request) over the CDNI Logging		if it were an independent content request) over the CDNI Logging
	interface. Optionally, the LI may include a Content Collection		interface. Optionally, the LI may include a Content Collection
	IDentifier (CCID) and/or a Session IDentifier (SID) as part of the		IDentifier (CCID) and/or a Session IDentifier (SID) as part of the
	logging fields, thereby facilitating correlation of per-chunk logs		logging fields, thereby facilitating correlation of per-chunk logs
	into per-session logs for applications benefiting from such session		into per-session logs for applications benefiting from such session
	level information (e.g. session-based analytics). This approach is		level information (e.g. session-based analytics). This approach is
	in line with the recommendations made in [I-D.brandenburg-cdni-has],		in line with the recommendations made in RFC 6983, which also
	which also identifies potential improvements in this area that might		identifies potential improvements in this area that might be
	be considered in the future.		considered in the future.
	Fourth, with respect to the CDNI Control interface, and in particular		Fourth, with respect to the CDNI Control interface, and in particular
	purging HAS chunks from a given CDN, our approach is to expect each		purging HAS chunks from a given CDN, our approach is to expect each
	CDN supports per-chunk content purge (e.g. purging of chunks as if		CDN supports per-chunk content purge (e.g. purging of chunks as if
	they were individual content items). Optionally, a CDN may support		they were individual content items). Optionally, a CDN may support
	content purge on the basis of a "Purge IDentifier (Purge-ID)"		content purge on the basis of a "Purge IDentifier (Purge-ID)"
	allowing the removal of all chunks related to a given Content		allowing the removal of all chunks related to a given Content
	Collection with a single reference. It is possible that this Purge-		Collection with a single reference. It is possible that this Purge-
	ID could be merged with the CCID discussed above for HAS Logging, or		ID could be merged with the CCID discussed above for HAS Logging, or
	alternatively, they may remain distinct.		alternatively, they may remain distinct.
	skipping to change at page 50, line 27		skipping to change at page 50, line 12
	distribute encrypted content, with decryption keys distributed to		distribute encrypted content, with decryption keys distributed to
	users by some other means (e.g. directly from the CSP to the end		users by some other means (e.g. directly from the CSP to the end
	user.) For this reason, DRM is considered out of scope for the CDNI		user.) For this reason, DRM is considered out of scope for the CDNI
	WG RFC 6707 and does not introduce additional security issues for		WG RFC 6707 and does not introduce additional security issues for
	CDNI.		CDNI.
	9. Contributors		9. Contributors
	The following individuals contributed to this document:		The following individuals contributed to this document:
	o Ray Brandenburg		o Ray van Brandenburg
	o Matt Caulfield		o Matt Caulfield
	o Francois le Faucheur		o Francois le Faucheur
	o Aaron Falk		o Aaron Falk
	o David Ferguson		o David Ferguson
	o John Hartman		o John Hartman
	skipping to change at page 51, line 12		skipping to change at page 50, line 39
	We thank Huw Jones for helpful input to the draft.		We thank Huw Jones for helpful input to the draft.
	11. Informative References		11. Informative References
	[I-D.bertrand-cdni-logging]		[I-D.bertrand-cdni-logging]
	Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F.,		Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F.,
	and P. Grochocki, "CDNI Logging Interface", draft-		and P. Grochocki, "CDNI Logging Interface", draft-
	bertrand-cdni-logging-02 (work in progress), October 2012.		bertrand-cdni-logging-02 (work in progress), October 2012.
	[I-D.brandenburg-cdni-has]
	Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung,
	"Models for adaptive-streaming-aware CDN Interconnection",
	draft-brandenburg-cdni-has-05 (work in progress), April
	2013.
	[I-D.ietf-appsawg-http-forwarded]		[I-D.ietf-appsawg-http-forwarded]
	Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",		Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
	draft-ietf-appsawg-http-forwarded-10 (work in progress),		draft-ietf-appsawg-http-forwarded-10 (work in progress),
	October 2012.		October 2012.
	[I-D.ietf-cdni-metadata]		[I-D.ietf-cdni-metadata]
	Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,		Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
	Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-		Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
	ietf-cdni-metadata-02 (work in progress), July 2013.		ietf-cdni-metadata-02 (work in progress), July 2013.
	[I-D.ietf-cdni-requirements]		[I-D.ietf-cdni-requirements]
	Leung, K. and Y. Lee, "Content Distribution Network		Leung, K. and Y. Lee, "Content Distribution Network
	Interconnection (CDNI) Requirements", draft-ietf-cdni-		Interconnection (CDNI) Requirements", draft-ietf-cdni-
	requirements-09 (work in progress), July 2013.		requirements-10 (work in progress), September 2013.
	[I-D.ietf-cdni-use-cases]
	Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
	K., and G. Watson, "Use Cases for Content Delivery Network
	Interconnection", draft-ietf-cdni-use-cases-10 (work in
	progress), August 2012.
	[I-D.lefaucheur-cdni-logging-delivery]		[I-D.lefaucheur-cdni-logging-delivery]
	Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI		Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI
	Logging Formats for HTTP and HTTP Adaptive Streaming		Logging Formats for HTTP and HTTP Adaptive Streaming
	Deliveries", draft-lefaucheur-cdni-logging-delivery-01		Deliveries", draft-lefaucheur-cdni-logging-delivery-01
	(work in progress), July 2012.		(work in progress), July 2012.
	[I-D.murray-cdni-triggers]		[I-D.murray-cdni-triggers]
	Murray, R. and B. Niven-Jenkins, "CDNI Control Interface /		Murray, R. and B. Niven-Jenkins, "CDNI Control Interface /
	Triggers", draft-murray-cdni-triggers-03 (work in		Triggers", draft-murray-cdni-triggers-03 (work in
	skipping to change at page 52, line 28		skipping to change at page 51, line 46
	2003.		2003.
	[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic		[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
	Optimization (ALTO) Problem Statement", RFC 5693, October		Optimization (ALTO) Problem Statement", RFC 5693, October
	2009.		2009.
	[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content		[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
	Distribution Network Interconnection (CDNI) Problem		Distribution Network Interconnection (CDNI) Problem
	Statement", RFC 6707, September 2012.		Statement", RFC 6707, September 2012.
			[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
			K., and G. Watson, "Use Cases for Content Delivery Network
			Interconnection", RFC 6770, November 2012.
			[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
			and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
			Content Distribution Network Interconnection (CDNI)", RFC
			6983, July 2013.
	Authors' Addresses		Authors' Addresses
	Larry Peterson (editor)		Larry Peterson (editor)
	Akamai Technologies, Inc.		Akamai Technologies, Inc.
	8 Cambridge Center		8 Cambridge Center
	Cambridge, MA 02142		Cambridge, MA 02142
	USA		USA
	Email: lapeters@akamai.com		Email: lapeters@akamai.com
End of changes. 50 change blocks.
	118 lines changed or deleted		112 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/