draft-ietf-cdni-framework-13.txt		draft-ietf-cdni-framework-14.txt
	Network Working Group L. Peterson		Network Working Group L. Peterson
	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: December 1, 2014 R. van Brandenburg, Ed.		Expires: December 8, 2014 R. van Brandenburg, Ed.
	TNO		TNO
	May 30, 2014		June 6, 2014
	Framework for CDN Interconnection		Framework for CDN Interconnection
	draft-ietf-cdni-framework-13		draft-ietf-cdni-framework-14
	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 interfaces		CDNs. CDN Interconnection requires the specification of 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
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 1, 2014.		This Internet-Draft will expire on December 8, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 12, line 17		skipping to change at page 12, line 17
	| | |		| | |
	| | [Async FCI Push] | (1)		| | [Async FCI Push] | (1)
	| | |		| | |
	| | [MI pre-positioning] | (2)		| | [MI pre-positioning] | (2)
	| | |		| | |
	| CONTENT REQUEST | |		| CONTENT REQUEST | |
	|-------------------------------------------------->| (3)		|-------------------------------------------------->| (3)
	| | |		| | |
	| | [Sync RI Pull] | (4)		| | [Sync RI Pull] | (4)
	| | |		| | |
	| RI REPLY | |		| CONTENT REQUEST REDIRECTION |
	|<--------------------------------------------------| (5)		|<--------------------------------------------------| (5)
	| | |		| | |
	| | |		| | |
	| CONTENT REQUEST | |		| CONTENT REQUEST | |
	|------------------------>| | (6)		|------------------------>| | (6)
	| | |		| | |
	| | [Sync MI Pull] | (7)		| | [Sync MI Pull] | (7)
	| | |		| | |
	| | ACQUISITION REQUEST |		| | ACQUISITION REQUEST |
	| X------------------------>| (8)		| X------------------------>| (8)
	skipping to change at page 15, line 14		skipping to change at page 15, line 14
	region or a set of IP address prefixes. This information may again		region or a set of IP address prefixes. This information may again
	be provided out of band or via a defined CDNI interface.		be provided out of band or via a defined CDNI interface.
	We assume DNS is configured in the following way:		We assume DNS is configured in the following way:
	o The content provider is configured to make operator A the		o The content provider is configured to make operator A the
	authoritative DNS server for cdn.csp.example (or to return a CNAME		authoritative DNS server for cdn.csp.example (or to return a CNAME
	for cdn.csp.example for which operator A is the authoritative DNS		for cdn.csp.example for which operator A is the authoritative DNS
	server).		server).
	o Operator A is configured so that a DNS request for		o Operator A is configured so that a DNS request for op-b-acq.op-
	op-b-acq.op-a.example returns a request router in Operator A.		a.example returns a request router in Operator A.
	o Operator B is configured so that a DNS request for peer-a.op-b		o Operator B is configured so that a DNS request for peer-a.op-
	.example/cdn.csp.example returns a request router in Operator B.		b.example/cdn.csp.example returns a request router in Operator B.
	Figure 3 illustrates how a client request for		Figure 3 illustrates how a client request for
	http://cdn.csp.example/...rest of url...		http://cdn.csp.example/...rest of url...
	is handled.		is handled.
	End-User Operator B Operator A		End-User Operator B Operator A
	|DNS cdn.csp.example | |		|DNS cdn.csp.example | |
	|-------------------------------------------------->|		|-------------------------------------------------->|
	skipping to change at page 20, line 11		skipping to change at page 20, line 11
	Routing Redirection interface) to enable "recursive" CDNI request		Routing Redirection interface) to enable "recursive" CDNI request
	routing. We build on the HTTP-based redirection approach because it		routing. We build on the HTTP-based redirection approach because it
	illustrates the principles and benefits clearly, but it is equally		illustrates the principles and benefits clearly, but it is equally
	possible to perform recursive redirection when DNS-based redirection		possible to perform recursive redirection when DNS-based redirection
	is employed.		is employed.
	In contrast to the prior example, the operators need not agree in		In contrast to the prior example, the operators need not agree in
	advance on a CDN-Domain to serve as the target of redirections from		advance on a CDN-Domain to serve as the target of redirections from
	uCDN to dCDN. We assume that the operators agree on some		uCDN to dCDN. We assume that the operators agree on some
	distinguished CDN-Domain that will be used for inter-CDN acquisition		distinguished CDN-Domain that will be used for inter-CDN acquisition
	of CSP's content by dCDN. In this example, we'll use		of CSP's content by dCDN. In this example, we'll use op-b-acq.op-
	op-b-acq.op-a.example.		a.example.
	We assume the operators also exchange information regarding which		We assume the operators also exchange information regarding which
	requests dCDN is prepared to serve. For example, dCDN may be		requests dCDN is prepared to serve. For example, dCDN may be
	prepared to serve requests from clients in a given geographical		prepared to serve requests from clients in a given geographical
	region or a set of IP address prefixes. This information may again		region or a set of IP address prefixes. This information may again
	be provided out of band or via a defined protocol.		be provided out of band or via a defined protocol.
	We assume DNS is configured in the following way:		We assume DNS is configured in the following way:
	o The content provider is configured to make operator A the		o The content provider is configured to make operator A the
	authoritative DNS server for cdn.csp.example (or to return a CNAME		authoritative DNS server for cdn.csp.example (or to return a CNAME
	for cdn.csp.example for which operator A is the authoritative DNS		for cdn.csp.example for which operator A is the authoritative DNS
	server).		server).
	o Operator A is configured so that a DNS request for		o Operator A is configured so that a DNS request for op-b-acq.op-
	op-b-acq.op-a.example returns a request router in Operator A.		a.example returns a request router in Operator A.
	o Operator B is configured so that a request for node1.op-b.example/		o Operator B is configured so that a request for node1.op-b.example/
	cdn.csp.example returns the IP address of a delivery node. Note		cdn.csp.example returns the IP address of a delivery node. Note
	that there might be a number of such delivery nodes.		that there might be a number of such delivery nodes.
	Figure 3 illustrates how a client request for		Figure 3 illustrates how a client request for
	http://cdn.csp.example/...rest of url...		http://cdn.csp.example/...rest of url...
	is handled.		is handled.
	skipping to change at page 22, line 36		skipping to change at page 22, line 36
	avoid being tricked into serving as an open proxy). It then does		avoid being tricked into serving as an open proxy). It then does
	a DNS request for the inter-CDN Acquisition "distinguished" CDN-		a DNS request for the inter-CDN Acquisition "distinguished" CDN-
	Domain as agreed above (in this case, op-b-acq.op-a.example).		Domain as agreed above (in this case, op-b-acq.op-a.example).
	6. Operator A DNS resolver processes the DNS request and returns the		6. Operator A DNS resolver processes the DNS request and returns the
	IP address of a request router in operator A.		IP address of a request router in operator A.
	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-
	(op-b-acq.op-a.example). (Note that without this specially		acq.op-a.example). (Note that without this specially defined
	defined inter-CDN acquisition domain, operator A would be at risk		inter-CDN acquisition domain, operator A would be at risk of
	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 with 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
End of changes. 10 change blocks.
	17 lines changed or deleted		17 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/