--- 1/draft-ietf-cdni-framework-07.txt 2014-01-19 12:14:37.639242787 -0800 +++ 2/draft-ietf-cdni-framework-08.txt 2014-01-19 12:14:37.759245945 -0800 @@ -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: May 29, 2014 November 25, 2013 +Expires: July 23, 2014 January 19, 2014 Framework for CDN Interconnection - draft-ietf-cdni-framework-07 + draft-ietf-cdni-framework-08 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 @@ -30,109 +30,110 @@ 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 May 29, 2014. + This Internet-Draft will expire on July 23, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + 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 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4 - 1.3. Structure Of This Document . . . . . . . . . . . . . . . 7 + 1.3. Structure Of This Document . . . . . . . . . . . . . . . 8 2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8 2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8 2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9 3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13 3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18 3.4. Iterative DNS-based Redirection Example . . . . . . 22 3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25 - 3.6. Content Removal Example . . . . . . . . . . . . . . . . . 26 - 3.7. Pre-Positioned Content Acquisition Example . . . . . . . 27 - 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 28 - 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 30 + 3.6. Content Removal Example . . . . . . . . . . . . . . . . . 27 + 3.7. Pre-Positioned Content Acquisition Example . . . . . . . 28 + 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 29 + 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 31 3.10. Content and Metadata Acquisition with Multiple Upstream - CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33 - 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34 - 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 34 - 4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 35 - 4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 36 - 4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 38 - 4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 38 - 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39 - 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 40 - 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 41 - 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42 - 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43 - 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 43 - 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 44 - 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 46 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 - 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 49 - 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 49 - 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 - 11. Informative References . . . . . . . . . . . . . . . . . . . 50 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 + CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 34 + 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 35 + 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 35 + 4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 36 + 4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 37 + 4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 39 + 4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 39 + 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 40 + 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 42 + 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 43 + 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 43 + 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 44 + 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 45 + 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 46 + 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 49 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 + 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 51 + 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 52 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 + 11. Informative References . . . . . . . . . . . . . . . . . . . 52 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 1. Introduction This document provides an overview of the various components necessary to interconnect CDNs, expanding on the problem statement - and use cases introduced in RFCs 6770 and 6707. It describes the - necessary interfaces and mechanisms in general terms and outlines how - they fit together to form a complete system for CDN Interconnection. - Detailed specifications are left to other documents. This document - makes extensive use of message flow examples to illustrate the - operation of interconnected CDNs, but these examples should be - considered illustrative rather than prescriptive. + and use cases introduced in [RFC6770] and [RFC6707]. It describes + the necessary interfaces and mechanisms in general terms and outlines + how they fit together to form a complete system for CDN + Interconnection. Detailed specifications are left to other + documents. This document makes 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 + [RFC3466] uses different terminology and models for "Content 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 [RFC3466]. 1.1. Terminology - This document uses the core terminology defined in RFC 6707. It also - introduces the following terms: + This document uses the core terminology defined in [RFC6707]. It + also introduces the following terms: 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 - 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 - region (subset) of the URI space relative to which various CDN + example, in the URL http://cdn.csp.example/...rest of url..., the CDN + domain is cdn.csp.example. A major role of CDN-Domain is to identify + a region (subset) of the URI space relative to which various CDN Interconnection rules and policies are to apply. For example, a record of CDN Metadata might be defined for the set of resources corresponding to some CDN-Domain. 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. @@ -176,21 +177,21 @@ 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. We also sometimes use uCDN and dCDN as shorthand for upstream CDN and downstream CDN, respectively. 1.2. Reference Model 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 [RFC6707]. (The difference is that the expanded model splits the Request Routing Interface into its two distinct parts: the Request Routing Redirection interface and the Footprint and Capabilities Advertisement interface, as described below.) -------- / \ | CSP | \ / -------- * @@ -242,21 +243,21 @@ new protocols for those interfaces) we still need to refer to them in this document to explain the overall operation of CDNI. We also note that, while we generally show only one upstream CDN serving a given CSP, it is entirely possible that multiple uCDNs can serve a single CSP. In fact, this situation effectively exists today in the sense that a single CSP can currently delegate its content delivery to more than one CDN. The following briefly describes the five CDNI interfaces, - paraphrasing the definitions given in RFC 6707. We discuss these + paraphrasing the definitions given in [RFC6707]. We discuss these interfaces in more detail in Section 4. o CDNI Control interface (CI): Operations to bootstrap and parameterize the other CDNI interfaces, as well as operations to pre-position, revalidate, and purge both metadata and content. The latter subset of operations is sometimes collectively called the "Trigger interface." o CDNI Request Routing interface: Operations to determine what CDN (and optionally what surrogate within a CDN) is to serve end- @@ -321,23 +322,24 @@ synchronizing updates to metadata with end-user requests that are currently in progress (or indistinguishable from currently being in progress). Clearly, a CDN will not be viewed as a trusted peer if "eventually" often becomes an indefinite period of time, but the acceptance of responsibility cannot be as crisply defined for the MI. Finally, there is a practical issue that impacts all of the CNDI interfaces, and that is whether or not to optimize CDNI for HTTP Adaptive Streaming (HAS). We highlight specific issues related to delivering HAS content throughout this document, but for a more - thorough treatment of the topic, see RFC 6983. + thorough treatment of the topic, see [RFC6983]. 1.3. Structure Of This Document + The remainder of this document is organized as follows: o Section 2 describes some essential building blocks for CDNI, notably the various options for redirecting user requests to a given CDN. o Section 3 provides a number of illustrative examples of various CDNI operations. o Section 4 describes the functionality of the main CDNI interfaces. @@ -544,28 +546,28 @@ Initially, we assume that there is at least one CSP that has contracted with an upstream CDN (uCDN) to deliver content on its behalf. We are not particularly concerned with the interface between the CSP and uCDN, other than to note that it is expected to be the same as in the "traditional" (non-interconnected) CDN case. Existing mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be used to direct a user request for a piece of content from the CSP towards the CSP's chosen upstream CDN. We assume Operator A provides an upstream CDN that serves content on - behalf of a CSP with CDN-Domain cdn.csp.com. We assume that Operator - B provides a downstream CDN. An end user at some point makes a - request for URL + behalf of a CSP with CDN-Domain cdn.csp.example. We assume that + Operator B provides a downstream CDN. An end user at some point + makes a request for URL - http://cdn.csp.com/...rest of url... + http://cdn.csp.example/...rest of url... - It may well be the case that cdn.csp.com is just a CNAME for some - other CDN-Domain (such as csp.op-a.net). Nevertheless, the HTTP + It may well be the case that cdn.csp.example is just a CNAME for some + other CDN-Domain (such as csp.op-a.example). Nevertheless, the HTTP request in the examples that follow is assumed to be for the example URL above. Our goal is to enable content identified by the above URL to be served by the CDN of operator B. In the following sections we will walk through some scenarios in which content is served, as well as other CDNI operations such as the removal of content from a downstream CDN. 3.2. Iterative HTTP Redirect Example @@ -575,170 +577,173 @@ of HTTP redirection inside uCDN and dCDN; however, this is independent of the choice of redirection approach across CDNs, so an alternative example could be constructed still showing HTTP redirection from uCDN to dCDN but using DNS for handling of request inside each CDN. We assume for this example that Operators A and B have established an agreement to interconnect their CDNs, with A being upstream and B being downstream. - The operators agree that a CDN-Domain peer-a.op-b.net will be used as - the target of redirections from uCDN to dCDN. We assume the name of - this domain is communicated by some means to each CDN. (This could - be established out-of-band or via a CDNI interface.) We refer to - this domain as a "distinguished" CDN-Domain to convey the fact that - its use is limited to the interconnection mechanism; such a domain is - never used directly by a CSP. + The operators agree that a CDN-Domain peer-a.op-b.example will be + used as the target of redirections from uCDN to dCDN. We assume the + name of this domain is communicated by some means to each CDN. (This + could be established out-of-band or via a CDNI interface.) We refer + to this domain as a "distinguished" CDN-Domain to convey the fact + that its use is limited to the interconnection mechanism; such a + domain is never used directly by a CSP. We assume the operators also agree on some distinguished CDN-Domain that will be used for inter-CDN acquisition of CSP's content from - uCDN by dCDN. In this example, we'll use op-b-acq.op-a.net. + uCDN by dCDN. In this example, we'll use op-b-acq.op-a.example. We assume the operators also exchange information regarding which requests dCDN is prepared to serve. For example, dCDN may be prepared to serve requests from clients in a given geographical region or a set of IP address prefixes. This information may again be provided out of band or via a defined CDNI interface. 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.com (or to return a CNAME for - cdn.csp.com for which operator A is the authoritative DNS server). + 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.net returns a request router in Operator A. + 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.net - /cdn.csp.com 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.com/...rest of url... + http://cdn.csp.example/...rest of url... is handled. End-User Operator B Operator A - |DNS cdn.csp.com | | + |DNS cdn.csp.example | | |-------------------------------------------------->| | | |(1) |IPaddr of A's Request Router | |<--------------------------------------------------| - |HTTP cdn.csp.com | | + |HTTP cdn.csp.example | | |-------------------------------------------------->| | | |(2) - |302 peer-a.op-b.net/cdn.csp.com | + |302 peer-a.op-b.example/cdn.csp.example | |<--------------------------------------------------| - |DNS peer-a.op-b.net | | + |DNS peer-a.op-b.example | | |------------------------>| | | |(3) | |IPaddr of B's Request Router | |<------------------------| | | | | - |HTTP peer-a.op-b.net/cdn.csp.com | + |HTTP peer-a.op-b.example/cdn.csp.example | |------------------------>| | | |(4) | - |302 node1.peer-a.op-b.net/cdn.csp.com | + |302 node1.peer-a.op-b.example/cdn.csp.example | |<------------------------| | - |DNS node1.peer-a.op-b.net| | + |DNS node1.peer-a.op-b.example | |------------------------>| | | |(5) | |IPaddr of B's Delivery Node | |<------------------------| | | | | - |HTTP node1.peer-a.op-b.net/cdn.csp.com | + |HTTP node1.peer-a.op-b.example/cdn.csp.example | |------------------------>| | | |(6) | - | |DNS op-b-acq.op-a.net | + | |DNS op-b-acq.op-a.example| | |------------------------>| | | |(7) | |IPaddr of A's Request Router | |<------------------------| - | |HTTP op-b-acq.op-a.net | + | |HTTP op-b-acq.op-a.example | |------------------------>| | | |(8) - | |302 node2.op-b.acq.op-A.net + | |302 node2.op-b.acq.op-A.example | |<------------------------| - | |DNS node2.op-b-acq.op-a.net + | |DNS node2.op-b-acq.op-a.example | |------------------------>| | | |(9) | |IPaddr of A's Delivery Node | |<------------------------| | | | - | |HTTP node2.op-b-acq.op-a.net + | |HTTP node2.op-b-acq.op-a.example | |------------------------>| | | |(10) | |Data | | |<------------------------| |Data | | |<------------------------| | Figure 3: Message Flow for Iterative HTTP Redirection The steps illustrated in the figure are as follows: 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.example. It returns the IP address of a request router in Operator A. 2. A Request Router for Operator A processes the HTTP request and recognizes that the end-user is best served by another CDN, specifically one provided by Operator B, and so it returns a 302 redirect message for a new URL constructed by "stacking" - Operator B's distinguished CDN-Domain (peer-a.op-b.net) on the - front of the original URL. (Note that more complex URL + Operator B's distinguished CDN-Domain (peer-a.op-b.example) on + the front of the original URL. (Note that more complex URL manipulations are possible, such as replacing the initial CDN- Domain by some opaque handle.) 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 - address of a request router for Operator B. Note that if request - routing within dCDN was performed using DNS instead of HTTP - redirection, B's DNS resolver would also behave as the request - router and directly return the IP address of a delivery node. + CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the + IP address of a request router for Operator B. Note that if + request routing within dCDN was performed using DNS instead of + HTTP redirection, B's DNS resolver would also behave as the + request router and directly return the IP address of a delivery + node. 4. The request router for Operator B processes the HTTP request and selects a suitable delivery node to serve the end-user request, and returns a 302 redirect message for a new URL constructed by replacing the hostname with a subdomain of the Operator B's distinguished CDN-Domain that points to the selected 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 - IP address of the delivery node. + subdomain (node1.peer-a.op-b.example). B's DNS resolver returns + the IP address of the delivery node. 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 happen, and the content data is directly returned by the delivery node to the end-user. In the case of a cache miss, the content needs to be acquired by dCDN from uCDN (not the CSP). - The distinguished CDN-Domain peer-a.op-b.net indicates to dCDN - that this content is to be acquired from uCDN; stripping the - CDN-Domain reveals the original CDN-Domain cdn.csp.com and dCDN - may verify that this CDN-Domain belongs to a known peer (so as - to avoid being tricked into serving as an open proxy). It then - does a DNS request for an inter-CDN acquisition CDN-Domain as - agreed above (in this case, op-b-acq.op-a.net). + The distinguished CDN-Domain peer-a.op-b.example indicates to + dCDN that this content is to be acquired from uCDN; stripping + the CDN-Domain reveals the original CDN-Domain cdn.csp.example + and dCDN may verify that this CDN-Domain belongs to a known peer + (so as to avoid being tricked into serving as an open proxy). + It then does a DNS request for an inter-CDN acquisition CDN- + Domain as agreed above (in this case, op-b-acq.op-a.example). 7. Operator A's DNS resolver processes the DNS request and returns the IP address of a request router in operator A. 8. The request router for Operator A processes the HTTP request from Operator B delivery node. Operator A request router recognizes that the request is from a peer CDN rather than an end-user because of the dedicated inter-CDN acquisition domain - (op-b-acq.op-a.net). (Note that without this specially defined - inter-CDN acquisition domain, operator A would be at risk of - redirecting the request back to operator B, resulting in an - infinite loop). The request router for Operator A selects a + (op-b-acq.op-a.example). (Note that without this specially + defined inter-CDN acquisition domain, operator A would be at + risk of redirecting the request back to operator B, resulting in + an 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 with 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 B requests (acquires) the content from Operator A. @@ -757,23 +762,23 @@ correctly process. Neither CDN needs to be aware of the internal structure of the other's URLs. Moreover, the inter-CDN redirection is entirely supported by a single HTTP redirect; neither CDN needs to be aware of the other's internal redirection mechanism (i.e., whether it is DNS or HTTP based). One disadvantage is that the end-user's browser is redirected to a new URL that is not in the same domain of the original URL. This has implications on a number of security or validation mechanisms sometimes used on endpoints. For example, it is important that any - redirected URL be in the same domain (e.g., csp.com) if the browser - is expected to send any cookies associated with that domain. As - another example, some video players enforce validation of a cross + redirected URL be in the same domain (e.g., csp.example) if the + browser is expected to send any cookies associated with that domain. + As another example, some video players enforce validation of a cross domain policy that needs to allow for the domains involved in the CDN redirection. These problems are generally soluble, but the solutions complicate the example, so we do not discuss them further in this version of the draft. We note that this example begins to illustrate some of the interfaces that may be required for CDNI, but does not require all of them. For example, obtaining information from dCDN regarding the set of client IP addresses or geographic regions it might be able to serve is an aspect of request routing (specifically of the CDNI Footprint & @@ -821,143 +826,144 @@ routing. We build on the HTTP-based redirection approach because it illustrates the principles and benefits clearly, but it is equally possible to perform recursive redirection when DNS-based redirection is employed. 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 uCDN to dCDN. We assume that the operators agree on some distinguished CDN-Domain that will be used for inter-CDN acquisition of CSP's content by dCDN. In this example, we'll use - op-b-acq.op-a.net. + op-b-acq.op-a.example. We assume the operators also exchange information regarding which requests dCDN is prepared to serve. For example, dCDN may be prepared to serve requests from clients in a given geographical region or a set of IP address prefixes. This information may again be provided out of band or via a defined protocol. 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.com (or to return a CNAME for - cdn.csp.com for which operator A is the authoritative DNS server). + 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.net returns a request router in Operator A. + op-b-acq.op-a.example returns a request router in Operator A. - o Operator B is configured so that a request for node1.op-b.net/ - cdn.csp.com returns the IP address of a delivery node. Note that - there might be a number of such delivery nodes. + 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 + that there might be a number of such delivery nodes. Figure 3 illustrates how a client request for - http://cdn.csp.com/...rest of url... + http://cdn.csp.example/...rest of url... is handled. End-User Operator B Operator A - |DNS cdn.csp.com | | + |DNS cdn.csp.example | | |-------------------------------------------------->| | | |(1) |IPaddr of A's Request Router | |<--------------------------------------------------| - |HTTP cdn.csp.com | | + |HTTP cdn.csp.example | | |-------------------------------------------------->| | | |(2) - | |RR/RI REQ cdn.csp.com | + | |RR/RI REQ cdn.csp.example| | |<------------------------| | | | - | |RR/RI RESP node1.op-b.net| + | |RR/RI RESP node1.op-b.example | |------------------------>| | | |(3) - |302 node1.op-b.net/cdn.csp.com | + |302 node1.op-b.example/cdn.csp.example | |<--------------------------------------------------| - |DNS node1.op-b.net | | + |DNS node1.op-b.example | | |------------------------>| | | |(4) | |IPaddr of B's Delivery Node | |<------------------------| | - |HTTP node1.op-b.net/cdn.csp.com | + |HTTP node1.op-b.example/cdn.csp.example | |------------------------>| | | |(5) | - | |DNS op-b-acq.op-a.net | + | |DNS op-b-acq.op-a.example| | |------------------------>| | | |(6) | |IPaddr of A's Request Router | |<------------------------| - | |HTTP op-b-acq.op-a.net | + | |HTTP op-b-acq.op-a.example | |------------------------>| | | |(7) - | |302 node2.op-b.acq.op-A.net + | |302 node2.op-b.acq.op-A.example | |<------------------------| - | |DNS node2.op-b-acq.op-a.net + | |DNS node2.op-b-acq.op-a.example | |------------------------>| | | |(8) | |IPaddr of A's Delivery Node | |<------------------------| | | | - | |HTTP node2.op-b-acq.op-a.net + | |HTTP node2.op-b-acq.op-a.example | |------------------------>| | | |(9) | |Data | | |<------------------------| |Data | | |<------------------------| | Figure 4: Message Flow for Recursive HTTP Redirection The steps illustrated in the figure are as follows: 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.example. It returns the IP address of a Request Router in Operator A. 2. A Request Router for Operator A processes the HTTP request and - recognizes that the end-user is best served by another - CDN-\u002Dspecifically one provided by Operator B-\u002Dand so it - queries the CDNI Request Routing Redirection interface of - Operator B, providing a set of information about the request - including the URL requested. Operator B replies with the DNS - name of a delivery node. + recognizes that the end-user is best served by another CDN-- + specifically one provided by Operator B--and so it queries the + CDNI Request Routing Redirection interface of Operator B, + providing a set of information about the request including the + URL requested. Operator B replies with the DNS name of a + delivery node. 3. Operator A returns a 302 redirect message for a new URL obtained from the RI. 4. The end-user does a DNS lookup using the host name of the URL - just provided (node1.op-b.net). B's DNS resolver returns the IP - address of the corresponding delivery node. Note that, since the - name of the delivery node was already obtained from B using the - RI, there should not be any further redirection here (in contrast - to the iterative method described above.) + just provided (node1.op-b.example). B's DNS resolver returns the + IP address of the corresponding delivery node. Note that, since + the name of the delivery node was already obtained from B using + the RI, there should not be any further redirection here (in + contrast to the iterative method described above.) 5. The end-user requests the content from B's delivery node, potentially resulting in a cache miss. In the case of a cache miss, the content needs to be acquired from uCDN (not the CSP.) - The distinguished CDN-Domain op-b.net indicates to dCDN that this - content is to be acquired from another CDN; stripping the CDN- - Domain reveals the original CDN-Domain cdn.csp.com, dCDN may - verify that this CDN-Domain belongs to a known peer (so as to + The distinguished CDN-Domain op-b.example indicates to dCDN that + this content is to be acquired from another CDN; stripping the + CDN-Domain reveals the original CDN-Domain cdn.csp.example, dCDN + may verify that this CDN-Domain belongs to a known peer (so as to avoid being tricked into serving as an open proxy). It then does a DNS request for the inter-CDN Acquisition "distinguished" CDN- - Domain as agreed above (in this case, op-b-acq.op-a.net). + 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 IP address of a request router in operator A. 7. The request router for Operator A processes the HTTP request from Operator B delivery node. Operator A request router recognizes that the request is from a peer CDN rather than an end-user because of the dedicated inter-CDN acquisition domain - (op-b-acq.op-a.net). (Note that without this specially defined - inter-CDN acquisition domain, operator A would be at risk of - redirecting the request back to operator B, resulting in an + (op-b-acq.op-a.example). (Note that without this specially + defined inter-CDN acquisition domain, operator A would be at risk + of redirecting the request back to operator B, resulting in an 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 with a subdomain of the 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 @@ -1006,119 +1012,120 @@ 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 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.net, must be assigned - for inter-CDN acquisition. + 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: o The CSP is configured to make Operator A the authoritative DNS - server for cdn.csp.com (or to return a CNAME for cdn.csp.com for - which operator A is the authoritative DNS server). + server for cdn.csp.example (or to return a CNAME for + cdn.csp.example for which operator A is the authoritative DNS + server). o When uCDN sees a request best served by dCDN, it returns CNAME and - NS records for "b.cdn.csp.com", where "b" is the unique identifier - assigned to Operator B. (It may, for example, be an AS number - assigned to Operator B.) + NS records for "b.cdn.csp.example", where "b" is the unique + identifier assigned to Operator B. (It may, for example, be an AS + number assigned to Operator B.) - o dCDN is configured so that a request for "b.cdn.csp.com" returns a - delivery node in dCDN. + o dCDN is configured so that a request for "b.cdn.csp.example" + returns a delivery node in dCDN. - o uCDN is configured so that a request for "op-b-acq.op-a.net" + o uCDN is configured so that a request for "op-b-acq.op-a.example" returns a delivery node in uCDN. Figure 5 depicts the exchange of DNS and HTTP requests. The main differences from Figure 3 are the lack of HTTP redirection and transparency to the end-user. End-User Operator B Operator A - |DNS cdn.csp.com | | + |DNS cdn.csp.example | | |-------------------------------------------------->| | | |(1) - |CNAME b.cdn.csp.com | | - |NS records for b.cdn.csp.com | + |CNAME b.cdn.csp.example | | + |NS records for b.cdn.csp.example | |<--------------------------------------------------| - |DNS b.cdn.csp.com | | + |DNS b.cdn.csp.example | | |------------------------>| | | |(2) | |IPaddr of B's Delivery Node | |<------------------------| | - |HTTP cdn.csp.com | | + |HTTP cdn.csp.example | | |------------------------>| | | |(3) | - | |DNS op-b-acq.op-a.net | + | |DNS op-b-acq.op-a.example| | |------------------------>| | | |(4) | |IPaddr of A's Delivery Node | |<------------------------| - | |HTTP op-b-acq.op-a.net | + | |HTTP op-b-acq.op-a.example | |------------------------>| | | |(5) | |Data | | |<------------------------| |Data | | |<------------------------| | Figure 5: Message Flow for DNS-based Redirection The steps illustrated in the figure are as follows: 1. Request Router for Operator A processes the DNS request for CDN- - Domain cdn.csp.com and recognizes that the end-user is best + Domain cdn.csp.example and recognizes that the end-user is best served by another CDN. (This may depend on the IP address of the user's local DNS resolver, or other information discussed below.) The Request Router returns a DNS CNAME response by "stacking" the distinguished identifier for Operator B onto the original CDN- - Domain (e.g., b.cdn.csp.com), plus an NS record that maps - b.cdn.csp.com to B's Request Router. + Domain (e.g., b.cdn.csp.example), plus an NS record that maps + b.cdn.csp.example to B's Request Router. 2. The end-user does a DNS lookup using the modified CDN-Domain - (i.e., b.cdn.csp.com). This causes B's Request Router to respond - with a suitable delivery node. + (i.e., b.cdn.csp.example). This causes B's Request Router to + respond with a suitable delivery node. 3. The end-user requests the content from B's delivery node. The - requested URL contains the name cdn.csp.com. (Note that the + requested URL contains the name cdn.csp.example. (Note that the returned CNAME does not affect the URL.) At this point the delivery node has the correct IP address of the end-user and can do an HTTP 302 redirect if the redirections in steps 2 and 3 were incorrect. Otherwise B verifies that this CDN-Domain belongs to a known peer (so as to avoid being tricked into serving as an open proxy). It then does a DNS request for an "internal" CDN- - Domain as agreed above (op-b-acq.op-a.net). + Domain as agreed above (op-b-acq.op-a.example). 4. 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 in uCDN. 5. Operator A serves content 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. The advantages of this approach are that it is more transparent to the end-user and requires fewer round trips than HTTP-based redirection (in its worst case, i.e., when none of the needed DNS information is cached). A potential problem is that the upstream CDN depends on being able to learn the correct downstream CDN that serves the end-user from the client address in the DNS request. In standard DNS operation, uCDN will only obtain the address of the client's local DNS resolver (LDNS), which is not guaranteed to be in the same - network (or geographic region) as the client. If not-\u002De.g., the - end-user uses a global DNS service-\u002Dthen the upstream CDN cannot + network (or geographic region) as the client. If not--e.g., the end- + user uses a global DNS service--then the upstream CDN cannot determine the appropriate downstream CDN to serve the end-user. In this case, and assuming the uCDN is capable of detecting that situation, one option is for the upstream CDN to treat the end-user as it would any user not connected to a peer CDN. Another option is for the upstream CDN to "fall back" to a pure HTTP-based redirection strategy in this case (i.e., use the first method). Note that this problem affects existing CDNs that rely on DNS to determine where to redirect client requests, but the consequences are arguably less serious for CDNI since the LDNS is likely in the same network as the dCDN serves. One approach to ensuring that the client's IP address @@ -1143,46 +1150,46 @@ There could be situations where being able to dynamically discover the set of requests that a given dCDN is willing and able to serve is beneficial. For example, a CDN might at one time be able to serve a certain set of client IP prefixes, but that set might change over time due to changes in the topology and routing policies of the IP network. The following example illustrates this capability. We have chosen the example of DNS-based redirection, but HTTP-based redirection could equally well use this approach. End-User Operator B Operator A - |DNS cdn.csp.com | | + |DNS cdn.csp.example | | |-------------------------------------------------->| | | |(1) - | | RI REQ op-b.net | + | | RI REQ op-b.example | | |<------------------------| | | |(2) | | RI REPLY | | |------------------------>| | | |(3) - |CNAME b.cdn.csp.com | | - |NS records for b.cdn.csp.com | + |CNAME b.cdn.csp.example | | + |NS records for b.cdn.csp.example | |<--------------------------------------------------| - |DNS b.cdn.csp.com | | + |DNS b.cdn.csp.example | | |------------------------>| | | |(2) | |IPaddr of B's Delivery Node | |<------------------------| | - |HTTP cdn.csp.com | | + |HTTP cdn.csp.example | | |------------------------>| | | |(3) | - | |DNS op-b-acq.op-a.net | + | |DNS op-b-acq.op-a.example| | |------------------------>| | | |(4) | |IPaddr of A's Delivery Node | |<------------------------| - | |HTTP op-b-acq.op-a.net | + | |HTTP op-b-acq.op-a.example | |------------------------>| | | |(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 @@ -1212,109 +1219,109 @@ 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. End-User Operator B Operator A - | |CI purge cdn.csp.com/... | + | |CI purge cdn.csp.example/... | |<------------------------| | | | | |CI OK | | |------------------------>| | | | Figure 7: Message Flow for Content Removal The CI is used to convey the request from uCDN to dCDN that some previously acquired content should be deleted. The URL in the request specifies which content to remove. This example corresponds to a DNS-based redirection scenario such as Section 3.4. If HTTP- based redirection had been used, the URL for removal would be of the - form peer-a.op-b.net/cdn.csp.com/... + form peer-a.op-b.example/cdn.csp.example/... The dCDN is expected to confirm to the uCDN, as illustrated by the CI OK message, the completion of the removal of the targeted content from all the caches in dCDN. 3.7. Pre-Positioned Content Acquisition Example The following example illustrates how the CI may be used to pre- position an item of content in the dCDN. In this example, Operator A uses the CDNI Metadata interface to request that content identified by a particular URL be pre-positioned into Operator B CDN. End-User Operator B Operator A - | |CI pre-position cdn.csp.com/... + | |CI pre-position cdn.csp.example/... | |<------------------------| | | |(1) | |CI OK | | |------------------------>| | | | - | |DNS op-b-acq.op-a.net | + | |DNS op-b-acq.op-a.example| | |------------------------>| | | |(2) | |IPaddr of A's Delivery Node | |<------------------------| - | |HTTP op-b-acq.op-a.net | + | |HTTP op-b-acq.op-a.example | |------------------------>| | | |(3) | |Data | | |<------------------------| - |DNS cdn.csp.com | | - |-------------------------------------------------->| + |DNS cdn.csp.example | | + |--------------------------------------------->| | | |(4) |IPaddr of A's Request Router | - |<--------------------------------------------------| - |HTTP cdn.csp.com | | - |-------------------------------------------------->| + |<---------------------------------------------| + |HTTP cdn.csp.example| | + |--------------------------------------------->| | | |(5) - |302 peer-a.op-b.net/cdn.csp.com | - |<--------------------------------------------------| - |DNS peer-a.op-b.net | | - |------------------------>| | + |302 peer-a.op-b.example/cdn.csp.example | + |<---------------------------------------------| + |DNS peer-a.op-b.example | + |------------------->| | | |(6) | |IPaddr of B's Delivery Node | - |<------------------------| | - |HTTP peer-a.op-b.net/cdn.csp.com | - |------------------------>| | + |<-------------------| | + |HTTP peer-a.op-b.example/cdn.csp.example | + |------------------->| | | |(7) | |Data | | - |<------------------------| | + |<-------------------| | Figure 8: Message Flow for Content Pre-Positioning The steps illustrated in the figure are as follows: 1. Operator A uses the CI to request that Operator B pre-positions a particular content item identified by its URL. Operator B responds by confirming that it is willing to perform this operation. Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only this time those steps happen as the result of the Pre-positioning request instead of as the result of a cache miss. - Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of Figure - 3, only this time Operator B CDN can serve the end-user request - without triggering dynamic content acquisition, since the content has - been pre-positioned in dCDN. Note that, depending on dCDN operations - and policies, the content pre-positioned in the dCDN may be pre- - positioned to all, or a subset of, dCDN caches. In the latter case, - intra-CDN dynamic content acquisition may take place inside the dCDN - serving requests from caches on which the content has not been pre- - positioning; however, such intra-CDN dynamic acquisition would not - involve the uCDN. + Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of + Figure 3, only this time Operator B CDN can serve the end-user + request without triggering dynamic content acquisition, since the + content has been pre-positioned in dCDN. Note that, depending on + dCDN operations and policies, the content pre-positioned in the dCDN + may be pre-positioned to all, or a subset of, dCDN caches. In the + latter case, intra-CDN dynamic content acquisition may take place + inside the dCDN serving requests from caches on which the content has + not been pre-positioning; however, such intra-CDN dynamic acquisition + would not involve the uCDN. 3.8. Asynchronous CDNI Metadata Example In this section we walk through a simple example illustrating a scenario of asynchronously exchanging CDNI metadata, where the downstream CDN obtains CDNI metadata for content ahead of a corresponding content request. The example that follows assumes that HTTP-based inter-CDN redirection and recursive CDNI request-routing are used, as in Section 3.3. However, Asynchronous exchange of CDNI Metadata is similarly applicable to DNS-based inter-CDN redirection @@ -1542,21 +1549,21 @@ lookup. If the content metadata includes information for acquiring the content, then the MI is also tightly coupled with the acquisition interface in that the result of the metadata lookup (an acquisition URL likely hosted by the uCDN) should serve as input to the content acquisition. 4. Main Interfaces Figure 1 illustrates the main interfaces that are in scope for the CDNI WG, along with several others. The detailed specifications of - these interfaces are left to other documents, but see RFC 6707 and + these interfaces are left to other documents, but see [RFC6707] and [I-D.ietf-cdni-requirements] for some discussion of the interfaces. One interface that is not shown in Figure 1 is the interface between the user and the CSP. While for the purposes of CDNI that interface is out of scope, it is worth noting that it does exist and can provide useful functions, such as end-to-end performance monitoring and some forms of authentication and authorization. There is also an important interface between the user and the Request Routing function of both uCDN and dCDN (shown as the "Request" @@ -1632,21 +1639,22 @@ As illustrated in Section 3, the RI part of request routing may be implemented in part by DNS and HTTP. Naming conventions may be established by which CDN peers communicate whether a request should be routed or content served. We also note that RI plays a key role in enabling recursive redirection, as illustrated in Section 3.3. It enables the user to be redirected to the correct delivery node in dCDN with only a single redirection step (as seen by the user). This may be particularly valuable as the chain of interconnected CDNs increases beyond two - CDNs. + CDNs. For further discussion on the RI, see + [I-D.ietf-cdni-redirection]. In support of these redirection requests, it is necessary for CDN peers to exchange additional information with each other, and this is the role of the FCI part of request routing. Depending on the method(s) supported, this might includes o The operator's unique id (operator-id) or distinguished CDN-Domain (operator-domain); o NS records for the operator's set of externally visible request @@ -1658,21 +1666,21 @@ o Additional capabilities of the dCDN, such as its ability to support different CDNI Metadata requests. Note that the set of requests that dCDN is willing to serve could in some cases be relatively static (e.g., a set of IP prefixes) which could be exchanged off-line, or might even be negotiated as part of a peering agreement. However, it may also be more dynamic, in which case the exchange supported by FCI would be be helpful. A further discussion of the Footprint & Capability Advertisement interface can - be found in [I-D.spp-cdni-rr-foot-cap-semantics]. + be found in [I-D.ietf-cdni-footprint-capabilities-semantics]. 4.4. CDNI Logging Interface It is necessary for the upstream CDN to have visibility into the delivery of content that it redirected to a downstream CDN. This allows the upstream CDN to properly bill its customers for multiple deliveries of content cached by the downstream CDN, as well as to report accurate traffic statistics to those content providers. This is one role of the LI. @@ -1693,38 +1701,38 @@ o Time zone - any time zone modifier for the end time o Method - the transfer command itself (e.g., GET, POST, HEAD) o URL - the requested URL o Version - the protocol version, such as HTTP/1.0 o Response - a numeric response code indicating transfer result - o Bytes Sent - the number of bytes in the body sent to the client o Request ID - a unique identifier for this transfer o User agent - the user agent, if supplied o Duration - the duration of the transfer in milliseconds + o Cached Bytes - the number of body bytes served from the cache o Referrer - the referrer string from the client, if supplied - Of these, only the Domain field is indirect in the downstream - CDN-\u002Dit is set to the CDN-Domain used by the upstream CDN rather - than the actual origin server. This field could then used to filter - traffic log entries so only those entries matching the upstream CDN - are reported to the corresponding operator. Further discussion of - the LI can be found in [I-D.bertrand-cdni-logging]. + Of these, only the Domain field is indirect in the downstream CDN--it + is set to the CDN-Domain used by the upstream CDN rather than the + actual origin server. This field could then used to filter traffic + log entries so only those entries matching the upstream CDN are + reported to the corresponding operator. Further discussion of the LI + can be found in [I-D.ietf-cdni-logging]. One open question is who does the filtering. One option is that the downstream CDN filters its own logs, and passes the relevant records directly to each upstream peer. This requires that the downstream CDN knows the set of CDN-Domains that belong to each upstream peer. If this information is already exchanged between peers as part of another interface, then direct peer-to-peer reporting is straightforward. If it is not available, and operators do not wish to advertise the set of CDN-Domains they serve to their peers, then the second option is for each CDN to send both its non-local traffic @@ -1765,32 +1773,33 @@ The CDNI Control interface is initially used to bootstrap the other 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 the CDNI Logging interface. It may also be used, for example, to establish security associations for the other interfaces. The other role the CI plays is to allow the uCDN to pre-position, revalidate, or purge metadata and content on a dCDN. These operations, sometimes collectively called the Trigger interface, are - discussed further in [I-D.murray-cdni-triggers]. + discussed further in [I-D.ietf-cdni-control-triggers]. 4.6. CDNI Metadata Interface The role of the CDNI Metadata interface is to enable CDNI distribution metadata to be conveyed to the downstream CDN by the - upstream CDN. For example, see [I-D.ietf-cdni-metadata]. Such - metadata includes geo-blocking restrictions, availability windows, - access control policies, and so on. It may also include information - to facilitate acquisition of content by dCDN (e.g., alternate sources - for the content, authorization information needed to acquire the - content from the source). + upstream CDN. Such metadata includes geo-blocking restrictions, + availability windows, access control policies, and so on. It may + also include information to facilitate acquisition of content by dCDN + (e.g., alternate sources for the content, authorization information + needed to acquire the content from the source). For a full + discussion of the CDNI Metadata Interface, see + [I-D.ietf-cdni-metadata] Some distribution metadata may be partially emulated using in-band mechanisms. For example, in case of any geo-blocking restrictions or availability windows, the upstream CDN can elect to redirect a request to the downstream CDN only if that CDN's advertised delivery footprint is acceptable for the requested URL. Similarly, the request could be forwarded only if the current time is within the availability window. However, such approaches typically come with shortcomings such as inability to prevent from replay outside the time window or inability to make use of a downstream CDN that covers @@ -2093,34 +2102,34 @@ is the more general concept, involving two or more CDNs serving content to each other's users, while federation implies a multi- lateral interconnection arrangement, but other CDN interconnection agreements are also possible (e.g., symmetric bilateral, asymmetric bilateral). An important conclusion is that CDNI technology should not presume (or bake in) a particular interconnection agreement, but should instead be general enough to permit alternative interconnection arrangements to evolve. The second concept often used in the context of CDN Federation is CDN - Exchange-\u002Da third party broker or exchange that is used to - facilitate a CDN federation. Our view is that a CDN exchange offers - valuable machinery to scale the number of CDN operators involved in a - multi-lateral (federated) agreement, but that this machinery is built - on top of the core CDNI interconnection mechanisms. For example, as + Exchange--a third party broker or exchange that is used to facilitate + a CDN federation. Our view is that a CDN exchange offers valuable + machinery to scale the number of CDN operators involved in a multi- + lateral (federated) agreement, but that this machinery is built on + top of the core CDNI interconnection mechanisms. For example, as illustrated in Figure 14, the exchange might aggregate and redistribute information about each CDN footprint and capacity, as well as collect, filter, and redistribute traffic logs that each participant needs for interconnection settlement, but inter-CDN request routing, inter-CDN content distribution (including inter-CDN acquisition) and inter-CDN control which fundamentally involve a - direct interaction between an upstream CDN and a downstream - CDN-\u002Doperate exactly as in a pair-wise peering arrangement. - Turning to Figure 14, we observe that in this example: + direct interaction between an upstream CDN and a downstream CDN-- + operate exactly as in a pair-wise peering arrangement. Turning to + Figure 14, we observe that in this example: o each CDN supports a direct CDNI Control interface to every other CDN o each CDN supports a direct CDNI Metadata interface to every other CDN o each CDN supports a CDNI Logging interface with the CDN Exchange o each CDN supports both a CDNI Request Routing interfaces with the @@ -2322,21 +2331,21 @@ will be specified in the relevant interface documents. 8.2. Digital Rights Management Issues of digital rights management (DRM, also sometimes called digital restrictions management) is often employed for content distributed via CDNs. In general, DRM relies on the CDN to distribute encrypted content, with decryption keys distributed to 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 - WG RFC 6707 and does not introduce additional security issues for + WG [RFC6707] and does not introduce additional security issues for CDNI. 9. Contributors The following individuals contributed to this document: o Ray van Brandenburg o Matt Caulfield @@ -2351,74 +2360,67 @@ o Ben Niven-Jenkins o Kent Leung 10. Acknowledgements We thank Huw Jones for helpful input to the draft. 11. Informative References - [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.ietf-appsawg-http-forwarded] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", draft-ietf-appsawg-http-forwarded-10 (work in progress), October 2012. + [I-D.ietf-cdni-control-triggers] + Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / + Triggers", draft-ietf-cdni-control-triggers-02 (work in + progress), December 2013. + + [I-D.ietf-cdni-footprint-capabilities-semantics] + Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., + and K. Ma, "CDNI Request Routing: Footprint and + Capabilities Semantics", draft-ietf-cdni-footprint- + capabilities-semantics-01 (work in progress), October + 2013. + + [I-D.ietf-cdni-logging] + Faucheur, F., Bertrand, G., Oprescu, I., and R. + Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- + logging-08 (work in progress), October 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-03 (work in progress), October 2013. + ietf-cdni-metadata-04 (work in progress), December 2013. + + [I-D.ietf-cdni-redirection] + Danhua, W., Niven-Jenkins, B., He, X., Chen, G., and W. + Ni, "Request Routing Redirection Interface for CDN + Interconnection", draft-ietf-cdni-redirection-01 (work in + progress), October 2013. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni- - requirements-12 (work in progress), November 2013. - - [I-D.lefaucheur-cdni-logging-delivery] - Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI - Logging Formats for HTTP and HTTP Adaptive Streaming - Deliveries", draft-lefaucheur-cdni-logging-delivery-01 - (work in progress), July 2012. - - [I-D.murray-cdni-triggers] - Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / - Triggers", draft-murray-cdni-triggers-03 (work in - progress), April 2013. - - [I-D.seedorf-alto-for-cdni] - Seedorf, J., "ALTO for CDNi Request Routing", draft- - seedorf-alto-for-cdni-00 (work in progress), October 2011. - - [I-D.spp-cdni-rr-foot-cap-semantics] - Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., - and K. Ma, "CDNI Request Routing: Footprint and - Capabilities Semantics", draft-spp-cdni-rr-foot-cap- - semantics-04 (work in progress), February 2013. + requirements-14 (work in progress), December 2013. [I-D.vandergaast-edns-client-subnet] Contavalli, C., Gaast, W., Leach, S., and E. Lewis, "Client Subnet in DNS Requests", draft-vandergaast-edns- client-subnet-02 (work in progress), July 2013. [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003. - [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic - Optimization (ALTO) Problem Statement", RFC 5693, October - 2009. - [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem 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