--- 1/draft-ietf-cdni-framework-02.txt 2013-02-18 21:15:38.747707818 +0100 +++ 2/draft-ietf-cdni-framework-03.txt 2013-02-18 21:15:38.847708162 +0100 @@ -1,19 +1,19 @@ Network Working Group L. Peterson, Ed. Internet-Draft Akamai Technologies, Inc. Obsoletes: 3466 (if approved) B. Davie Intended status: Informational VMware, Inc. -Expires: June 20, 2013 December 17, 2012 +Expires: August 22, 2013 February 18, 2013 Framework for CDN Interconnection - draft-ietf-cdni-framework-02 + draft-ietf-cdni-framework-03 Abstract This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange @@ -30,25 +30,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -655,20 +655,23 @@ | |HTTP op-b-acq.op-a.net | | |------------------------>| | | |(8) | |302 node2.op-b.acq.op-A.net | |<------------------------| | |DNS node2.op-b-acq.op-a.net | |------------------------>| | | |(9) | |IPaddr of A's Delivery Node | |<------------------------| + | | | + | |HTTP node2.op-b-acq.op-a.net + | |------------------------>| | | |(10) | |Data | | |<------------------------| |Data | | |<------------------------| | Figure 3: Message Flow for Iterative HTTP Redirection The steps illustrated in the figure are as follows: @@ -729,21 +732,21 @@ infinite loop). The request router for Operator A selects a suitable delivery node in uCDN to serve the inter-CDN acquisition request and returns a 302 redirect message for a new URL constructed by replacing the hostname by a subdomain of the Operator A's distinguished inter-CDN acquisition domain that points to the selected delivery node. 9. Operator A DNS resolver processes the DNS request and returns 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 extracts information identifying the origin server, validates that this server has been registered, and determines the content provider that owns the origin server. It may also perform its own content acquisition steps if needed before returning the content to dCDN. 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 upstream CDN "pushing" the downstream CDN-Domain onto the URL as part @@ -860,21 +863,21 @@ |-------------------------------------------------->| | | |(2) | |RR/RI REQ cdn.csp.com | | |<------------------------| | | | | |RR/RI RESP node1.op-b.net| | |------------------------>| | | |(3) |302 node1.op-b.net/cdn.csp.com | |<--------------------------------------------------| - |DNS mode1.op-b.net | | + |DNS node1.op-b.net | | |------------------------>| | | |(4) | |IPaddr of B's Delivery Node | |<------------------------| | |HTTP node1.op-b.net/cdn.csp.com | |------------------------>| | | |(5) | | |DNS op-b-acq.op-a.net | | |------------------------>| | | |(6) @@ -883,20 +886,23 @@ | |HTTP op-b-acq.op-a.net | | |------------------------>| | | |(7) | |302 node2.op-b.acq.op-A.net | |<------------------------| | |DNS node2.op-b-acq.op-a.net | |------------------------>| | | |(8) | |IPaddr of A's Delivery Node | |<------------------------| + | | | + | |HTTP node2.op-b-acq.op-a.net + | |------------------------>| | | |(9) | |Data | | |<------------------------| |Data | | |<------------------------| | Figure 4: Message Flow for Recursive HTTP Redirection The steps illustrated in the figure are as follows: @@ -951,21 +957,22 @@ Operator A's distinguished inter-CDN acquisition domain that points to the selected delivery node. 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 returns the address of a delivery node. (Note that without this specially defined internal domain, Operator A would be at risk of redirecting the request back to Operator B, resulting in an 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 the rest of the URL: it extracts information identifying the origin server, validates that this server has been registered, and determines the content provider that owns the origin server. It may also perform its own content acquisition steps if needed before returning the content to dCDN. Recursive redirection has the advantage over iterative of being more transparent from the end-user's perspective, but the disadvantage of each CDN exposing more of its internal structure (in particular, the @@ -2305,22 +2312,22 @@ [I-D.bertrand-cdni-logging] Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F., and P. Grochocki, "CDNI Logging Interface", draft-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-03 (work in progress), - July 2012. + draft-brandenburg-cdni-has-04 (work in progress), + January 2013. [I-D.ietf-cdni-metadata] Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-ietf-cdni-metadata-00 (work in progress), October 2012. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements",