draft-ietf-cdni-framework-02.txt		draft-ietf-cdni-framework-03.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: June 20, 2013 December 17, 2012		Expires: August 22, 2013 February 18, 2013
	Framework for CDN Interconnection		Framework for CDN Interconnection
	draft-ietf-cdni-framework-02		draft-ietf-cdni-framework-03
	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 several
	interfaces and mechanisms to address issues such as request routing,		interfaces 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 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 June 20, 2013.		This Internet-Draft will expire on August 22, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 16, line 20		skipping to change at page 16, line 20
	| |HTTP op-b-acq.op-a.net |		| |HTTP op-b-acq.op-a.net |
	| |------------------------>|		| |------------------------>|
	| | |(8)		| | |(8)
	| |302 node2.op-b.acq.op-A.net		| |302 node2.op-b.acq.op-A.net
	| |<------------------------|		| |<------------------------|
	| |DNS node2.op-b-acq.op-a.net		| |DNS node2.op-b-acq.op-a.net
	| |------------------------>|		| |------------------------>|
	| | |(9)		| | |(9)
	| |IPaddr of A's Delivery Node		| |IPaddr of A's Delivery Node
	| |<------------------------|		| |<------------------------|
			| | |
			| |HTTP node2.op-b-acq.op-a.net
			| |------------------------>|
	| | |(10)		| | |(10)
	| |Data |		| |Data |
	| |<------------------------|		| |<------------------------|
	|Data | |		|Data | |
	|<------------------------| |		|<------------------------| |
	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:
	skipping to change at page 17, line 46		skipping to change at page 17, line 49
	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 by 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.
	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 A serves content for the requested CDN-Domain to dCDN.		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
	own content acquisition steps if needed before returning the		own content acquisition steps if needed before returning the
	content to dCDN.		content to dCDN.
	The main advantage of this design is that it is simple: each CDN need		The main advantage of this design is that it is simple: each CDN need
	only know the distinguished CDN-Domain for each peer, with the		only know the distinguished CDN-Domain for each peer, with the
	upstream CDN "pushing" the downstream CDN-Domain onto the URL as part		upstream CDN "pushing" the downstream CDN-Domain onto the URL as part
	skipping to change at page 21, line 22		skipping to change at page 21, line 22
	|-------------------------------------------------->|		|-------------------------------------------------->|
	| | |(2)		| | |(2)
	| |RR/RI REQ cdn.csp.com |		| |RR/RI REQ cdn.csp.com |
	| |<------------------------|		| |<------------------------|
	| | |		| | |
	| |RR/RI RESP node1.op-b.net|		| |RR/RI RESP node1.op-b.net|
	| |------------------------>|		| |------------------------>|
	| | |(3)		| | |(3)
	|302 node1.op-b.net/cdn.csp.com |		|302 node1.op-b.net/cdn.csp.com |
	|<--------------------------------------------------|		|<--------------------------------------------------|
	|DNS mode1.op-b.net | |		|DNS node1.op-b.net | |
	|------------------------>| |		|------------------------>| |
	| |(4) |		| |(4) |
	|IPaddr of B's Delivery Node |		|IPaddr of B's Delivery Node |
	|<------------------------| |		|<------------------------| |
	|HTTP node1.op-b.net/cdn.csp.com |		|HTTP node1.op-b.net/cdn.csp.com |
	|------------------------>| |		|------------------------>| |
	| |(5) |		| |(5) |
	| |DNS op-b-acq.op-a.net |		| |DNS op-b-acq.op-a.net |
	| |------------------------>|		| |------------------------>|
	| | |(6)		| | |(6)
	skipping to change at page 21, line 45		skipping to change at page 21, line 45
	| |HTTP op-b-acq.op-a.net |		| |HTTP op-b-acq.op-a.net |
	| |------------------------>|		| |------------------------>|
	| | |(7)		| | |(7)
	| |302 node2.op-b.acq.op-A.net		| |302 node2.op-b.acq.op-A.net
	| |<------------------------|		| |<------------------------|
	| |DNS node2.op-b-acq.op-a.net		| |DNS node2.op-b-acq.op-a.net
	| |------------------------>|		| |------------------------>|
	| | |(8)		| | |(8)
	| |IPaddr of A's Delivery Node		| |IPaddr of A's Delivery Node
	| |<------------------------|		| |<------------------------|
			| | |
			| |HTTP node2.op-b-acq.op-a.net
			| |------------------------>|
	| | |(9)		| | |(9)
	| |Data |		| |Data |
	| |<------------------------|		| |<------------------------|
	|Data | |		|Data | |
	|<------------------------| |		|<------------------------| |
	Figure 4: Message Flow for Recursive HTTP Redirection		Figure 4: Message Flow for Recursive HTTP Redirection
	The steps illustrated in the figure are as follows:		The steps illustrated in the figure are as follows:
	skipping to change at page 23, line 16		skipping to change at page 23, line 18
	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.)
	9. Operator A serves content for the requested CDN-Domain to dCDN.		9. Operator B requests (acquires) the content from Operator A.
			Operator A serves content for the requested CDN-Domain to dCDN.
	Although not shown, it is at this point that Operator A processes		Although not shown, it is at this point that Operator A processes
	the rest of the URL: it extracts information identifying the		the rest of the URL: it extracts information identifying the
	origin server, validates that this server has been registered,		origin server, validates that this server has been registered,
	and determines the content provider that owns the origin server.		and determines the content provider that owns the origin server.
	It may also perform its own content acquisition steps if needed		It may also perform its own content acquisition steps if needed
	before returning the content to dCDN.		before returning the content to dCDN.
	Recursive redirection has the advantage over iterative of being more		Recursive redirection has the advantage over iterative of being more
	transparent from the end-user's perspective, but the disadvantage of		transparent from the end-user's perspective, but the disadvantage of
	each CDN exposing more of its internal structure (in particular, the		each CDN exposing more of its internal structure (in particular, the
	skipping to change at page 54, line 9		skipping to change at page 54, line 9
	[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",		and P. Grochocki, "CDNI Logging Interface",
	draft-bertrand-cdni-logging-02 (work in progress),		draft-bertrand-cdni-logging-02 (work in progress),
	October 2012.		October 2012.
	[I-D.brandenburg-cdni-has]		[I-D.brandenburg-cdni-has]
	Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung,		Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung,
	"Models for adaptive-streaming-aware CDN Interconnection",		"Models for adaptive-streaming-aware CDN Interconnection",
	draft-brandenburg-cdni-has-03 (work in progress),		draft-brandenburg-cdni-has-04 (work in progress),
	July 2012.		January 2013.
	[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",		Leung, K., and K. Ma, "CDN Interconnect Metadata",
	draft-ietf-cdni-metadata-00 (work in progress),		draft-ietf-cdni-metadata-00 (work in progress),
	October 2012.		October 2012.
	[I-D.ietf-cdni-requirements]		[I-D.ietf-cdni-requirements]
	Leung, K. and Y. Lee, "Content Distribution Network		Leung, K. and Y. Lee, "Content Distribution Network
	Interconnection (CDNI) Requirements",		Interconnection (CDNI) Requirements",
End of changes. 10 change blocks.
	9 lines changed or deleted		16 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/