--- 1/draft-ietf-cdni-framework-11.txt 2014-05-26 09:14:25.359056940 -0700 +++ 2/draft-ietf-cdni-framework-12.txt 2014-05-26 09:14:25.483059992 -0700 @@ -1,21 +1,21 @@ Network Working Group L. Peterson Internet-Draft Akamai Technologies, Inc. Obsoletes: 3466 (if approved) B. Davie Intended status: Informational VMware, Inc. -Expires: November 6, 2014 R. van Brandenburg, Ed. +Expires: November 27, 2014 R. van Brandenburg, Ed. TNO - May 5, 2014 + May 26, 2014 Framework for CDN Interconnection - draft-ietf-cdni-framework-11 + draft-ietf-cdni-framework-12 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 interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange @@ -33,21 +33,21 @@ 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 November 6, 2014. + This Internet-Draft will expire on November 27, 2014. Copyright Notice Copyright (c) 2014 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 @@ -139,59 +139,60 @@ 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 in client requests. Such CDN-Domains may be used for inter-CDN acquisition, or as redirection targets, and enable a CDN to distinguish a request from a peer CDN from an end-user request. Delivering CDN: the CDN that ultimately delivers a piece of content to the end-user. The last in a potential sequence of downstream CDNs. - Recursive CDNI Request Redirection: When an upstream CDN elects to - redirect a request towards a downstream CDN, the upstream CDN can - query the downstream CDN Request Routing system via the CDNI Request - Routing Redirection Interface (or use information cached from earlier - similar queries) to find out how the downstream CDN wants the request - to be redirected, which allows the upstream CDN to factor in the - downstream CDN response when redirecting the user agent. This - approach is referred to as "Recursive" CDNI Request Redirection. - Note that the downstream CDN may elect to have the request redirected - directly to a Surrogate inside the downstream CDN, to the Request - Routing System of the downstream CDN, to another CDN, or to whatever - system is necessary to handle the redirected request appropriately. - Iterative CDNI Request Redirection: When an upstream CDN elects to redirect a request towards a downstream CDN, the upstream CDN can base its redirection purely on a local decision (and without attempting to take into account how the downstream CDN may in turn redirect the user agent). In that case, the upstream CDN redirects the request to the request routing system in the downstream CDN, which in turn will decide how to redirect that request: this approach is referred to as "Iterative" CDNI Request Redirection. + Recursive CDNI Request Redirection: When an upstream CDN elects to + redirect a request towards a downstream CDN, the upstream CDN can + query the downstream CDN Request Routing system via the CDNI Request + Routing Redirection Interface (or use information cached from earlier + similar queries) to find out how the downstream CDN wants the request + to be redirected. This allows the upstream CDN to factor in the + downstream CDN response when redirecting the user agent. This + approach is referred to as "Recursive" CDNI Request Redirection. + Note that the downstream CDN may elect to have the request redirected + directly to a Surrogate inside the downstream CDN, or to any other + element in the downstream CDN (or in another CDN) to handle the + redirected request appropriately. + Synchronous CDNI operations: operations between CDNs that happen 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 at which that request is served. Asynchronous CDNI operations: operations between CDNs that happen independently of any given user request, such as advertisement of footprint information or pre-positioning of content for later delivery. Trigger Interface: a subset of the CDNI Control interface that includes operations to pre-position, revalidate, and purge both 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 Content Service Provider + (CSP) on the upstream CDN. We also sometimes use uCDN and dCDN as shorthand for upstream CDN and - downstream CDN, respectively. + downstream CDN (see [RFC6707]), respectively. At various points in this document, the concept of a CDN footprint is used. For a discussion on what constitutes a CDN footprint, the reader is referred to [I-D.ietf-cdni-footprint-capabilities-semantics]. 1.2. Reference Model This document uses the reference model in Figure 1, which expands the reference model originally defined in [RFC6707]. (The difference is @@ -629,23 +630,22 @@ We assume DNS is configured in the following way: o The content provider is configured to make operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which operator A is the authoritative DNS server). o Operator A is configured so that a DNS request for op-b-acq.op-a.example returns a request router in Operator A. - o Operator B is configured so that a DNS request for - peer-a.op-b.example/cdn.csp.example returns a request router in - Operator B. + o Operator B is configured so that a DNS request for peer-a.op-b + .example/cdn.csp.example returns a request router in Operator B. Figure 3 illustrates how a client request for http://cdn.csp.example/...rest of url... is handled. End-User Operator B Operator A |DNS cdn.csp.example | | |-------------------------------------------------->| @@ -1043,21 +1043,21 @@ redirection for request redirection from uCDN to dCDN (as well as for request routing inside dCDN and uCDN). As noted in Section 2.1, DNS- based redirection has certain advantages over HTTP-based redirection (notably, it is transparent to the end-user) as well as some drawbacks (notably the client IP address is not visible to the request router). As before, Operator A has to learn the set of requests that dCDN is willing or able to serve (e.g. which client IP address prefixes or geographic regions are part of the dCDN footprint). We assume - Operator has and makes known to operator A some unique identifier + Operator B has and makes known to Operator A some unique identifier that can be used for the construction of a distinguished CDN-Domain, as shown in more detail below. (This identifier strictly needs only to be unique within the scope of Operator A, but a globally unique identifier, such as an AS number assigned to B, is one easy way to achieve that.) Also, Operator A obtains the NS records for Operator B's externally visible redirection servers. Also, as before, a distinguished CDN-Domain, such as op-b-acq.op-a.example, must be assigned for inter-CDN acquisition. We assume DNS is configured in the following way: @@ -1270,21 +1270,21 @@ | |------------------------>| | | |(5) | |Data | | |<------------------------| |Data | | |<------------------------| | Figure 6: Message Flow for Dynamic Footprint Discovery This example differs from the one in Figure 5 only in the addition of - a FCI request (step 2) and corresponding response (step 3). The RI + a RI request (step 2) and corresponding response (step 3). The RI REQ could be a message such as "Can you serve clients from this IP Prefix?" or it could be "Provide the list of client IP prefixes you can currently serve". In either case the response might be cached by operator A to avoid repeatedly asking the same question. Alternatively, or in addition, Operator B may spontaneously advertise to Operator A information (or changes) on the set of requests it is willing and able to serve on behalf of operator A; in that case, Operator B may spontaneously issue RR/RI REPLY messages that are not in direct response to a corresponding RR/RI REQ message. (Note that the issues of determining the client's subnet from DNS requests, as @@ -1300,21 +1300,25 @@ 3.6. Content Removal Example The following example illustrates how the CDNI Control interface may be used to achieve pre-positioning of an item of content in the dCDN. In this example, user requests for a particular content, and corresponding redirection of such requests from Operator A to 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 corresponding Trigger from the Content Provider) uses the CI to 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. It should be + noted that a uCDN will typically not know whether a dCDN has cached a + given content item, however, it may send the content removal request + to make sure no cached versions remain to satisfy any contractual + obligations it may have. End-User Operator B Operator A | |CI purge cdn.csp.example/... | |<------------------------| | | | | |CI OK | | |------------------------>| | | | Figure 7: Message Flow for Content Removal