RFC 7336
Framework for Content Distribution Network Interconnection (CDNI)
Internet Engineering Task Force (IETF) L. Peterson Request for Comments: 7336 Akamai Technologies, Inc. Obsoletes: 3466 B. Davie Category: Informational VMware, Inc. ISSN: 2070-1721 R. van Brandenburg, Ed. TNO August 2014 Framework for Content Distribution Network Interconnection (CDNI)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. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7336.
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 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 ....................................................4 1.1. Terminology ................................................4 1.2. Reference Model ............................................6 1.3. Structure of This Document ................................10 2. Building Blocks ................................................10 2.1. Request Redirection .......................................10 2.1.1. DNS Redirection ....................................10 2.1.2. HTTP Redirection ...................................12 3. Overview of CDNI Operation .....................................12 3.1. Preliminaries .............................................14 3.2. Iterative HTTP Redirect Example ...........................15 3.3. Recursive HTTP Redirection Example ........................21 3.4. Iterative DNS-Based Redirection Example ...................25 3.4.1. Notes on Using DNSSEC ..............................28 3.5. Dynamic Footprint Discovery Example .......................29 3.6. Content Removal Example ...................................31 3.7. Pre-positioned Content Acquisition Example ................32 3.8. Asynchronous CDNI Metadata Example ........................33 3.9. Synchronous CDNI Metadata Acquisition Example .............35 3.10. Content and Metadata Acquisition with Multiple Upstream CDNs ............................................37 4. Main Interfaces ................................................38 4.1. In-Band versus Out-of-Band Interfaces .....................39 4.2. Cross-Interface Concerns ..................................40 4.3. Request Routing Interfaces ................................40 4.4. CDNI Logging Interface ....................................41 4.5. CDNI Control Interface ....................................43 4.6. CDNI Metadata Interface ...................................43 4.7. HTTP Adaptive Streaming Concerns ..........................44 4.8. URI Rewriting .............................................46 5. Deployment Models ..............................................47 5.1. Meshed CDNs ...............................................47 5.2. CSP Combined with CDN .....................................48 5.3. CSP Using CDNI Request Routing Interface ..................49 5.4. CDN Federations and CDN Exchanges .........................50 6. Trust Model ....................................................53 7. Privacy Considerations .........................................54 8. Security Considerations ........................................55 8.1. Security of CDNI Interfaces ...............................56 8.2. Digital Rights Management .................................56 9. Contributors ...................................................56 10. Acknowledgements ..............................................57 11. Informative References ........................................57
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 [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. [RFC3466] uses different terminology and models for "Content (distribution) Internetworking (CDI)". It is also less prescriptive in terms of interfaces. To avoid confusion, this document obsoletes [RFC3466].1.1. Terminology
This document uses the core terminology defined in [RFC6707]. It also introduces the following terms: CDN-Domain: a hostname (Fully Qualified Domain Name -- FQDN) at the beginning of a URL (excluding port and scheme), representing a set of content that is served by a given CDN. For 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 CDNI rules and policies apply. For example, a record of CDNI 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 that 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.
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 Content Service Provider
(CSP) on the Upstream CDN.
We also sometimes use uCDN and dCDN as shorthand for Upstream CDN and
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 [FOOTPRINT-CAPABILITY].
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 that the expanded model splits the Request Routing interface into its two distinct parts: the Request Routing Redirection interface and the Footprint & Capabilities Advertisement interface, as described below.)
-------- / \ | CSP | \ / -------- * * * /\ * / \ ---------------------- |CDNI| ---------------------- / Upstream CDN \ | | / Downstream CDN \ | +-------------+ | | CI | | +-------------+ | |******* Control |<======|====|=======>| Control *******| |* +------*----*-+ | | | | +-*----*------+ *| |* * * | | | | * * *| |* +------*------+ | | LI | | +------*------+ *| |* ***** Logging |<======|====|=======>| Logging ***** *| |* * +-*-----------+ | | | | +-----------*-+ * *| |* * * * | | | | * * * *| .....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*... . |* * | |<======|====|=======>| | * *| . . |* * | Req-Routing | | |FCI | | | Req-Routing | * *| . . |* * *** |<======|====|=======>| |** * *| . . |* * * +-------------+.| | | | +-------------+ * * *| . . |* * * . | | | * * *| . . |* * * +-------------+ |. | MI | | +-------------+ * * *| . . |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| . . |* * * | | | . \ / | | | * * *| . . |* * * |+---------+ | | . \/ | | +---------+| * * *| . . |* * ***| +---------+| | ...Request......+---------+ |*** * *| . . |* *****+-|Surrogate|***********************|Surrogate|-+***** *| . . |******* +---------+| | Acquisition | |+----------+ *******| . . | +-------------+ | | +-------*-----+ | . . \ / \ * / . . ---------------------- ---------*------------ . . * . . * Delivery . . * . . +--*---+ . ...............Request............................| User |..Request.. | Agent| +------+ <==> interfaces inside the scope of CDNI **** and .... interfaces outside the scope of CDNI Figure 1: CDNI Expanded Model and CDNI Interfaces
While some interfaces in the reference model are "out of scope" for the CDNI WG (in the sense that there is no need to define new protocols for those interfaces), we note that 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 [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-user requests. This interface is actually a logical bundling of two separate, but related, interfaces: * CDNI Footprint & Capabilities Advertisement interface (FCI): Asynchronous operations to exchange routing information (e.g., the network footprint and capabilities served by a given CDN) that enables CDN selection for subsequent user requests; and * CDNI Request Routing Redirection interface (RI): Synchronous operations to select a delivery CDN (Surrogate) for a given user request. o CDNI Metadata interface (MI): Operations to communicate metadata that governs how the content is delivered by interconnected CDNs. Examples of CDNI Metadata include geo-blocking directives, availability windows, access control mechanisms, and purge directives. It may include a combination of: * Asynchronous operations to exchange metadata that govern subsequent user requests for content; and * Synchronous operations that govern behavior for a given user request for content.
o CDNI Logging interface (LI): Operations that allow interconnected
CDNs to exchange relevant activity logs. It may include a
combination of:
* Real-time exchanges, suitable for runtime traffic monitoring;
and
* Offline exchanges, suitable for analytics and billing.
The division between the sets of Trigger-based operations in the CDNI
Control interface and the CDNI Metadata interface is somewhat
arbitrary. For both cases, the information passed from the Upstream
CDN to the Downstream CDN can broadly be viewed as metadata that
describes how content is to be managed by the Downstream CDN. For
example, the information conveyed by the CI to pre-position,
revalidate, or purge metadata is similar to the information conveyed
by posting updated metadata via the MI. Even the CI operation to
purge content could be viewed as a metadata update for that content:
purge simply says that the availability window for the named content
ends now. The two interfaces share much in common, so minimally,
there will need to be a consistent data model that spans both.
The distinction we draw has to do with what the uCDN knows about the
successful application of the metadata by the dCDN. In the case of
the CI, the Downstream CDN returning a successful status message
guarantees that the operation has been successfully completed; for
example, the content has been purged or pre-positioned. This implies
that the Downstream CDN accepts responsibility for having
successfully completed the requested operation. In contrast,
metadata passed between CDNs via the MI carries no such completion
guarantee. Returning success implies successful receipt of the
metadata, but nothing can be inferred about precisely when the
metadata will take effect in the Downstream CDN, only that it will
take effect eventually. This is because of the challenge in globally
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 CDNI
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 [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. o Section 5 shows how various deployment models of CDNI may be achieved using the defined interfaces. o Section 6 describes the trust model of CDNI and the issues of transitive trust in particular that CDNI raises.2. Building Blocks
2.1. Request Redirection
At its core, CDNI requires the redirection of requests from one CDN to another. For any given request that is received by an Upstream CDN, it will either respond to the request directly, or somehow redirect the request to a Downstream CDN. Two main mechanisms are available for redirecting a request to a Downstream CDN. The first leverages the DNS name resolution process and the second uses application-layer redirection mechanisms such as the HTTP 302 or Real-Time Streaming Protocol (RTSP) 302 redirection responses. While there exists a large variety of application-layer protocols that include some form of redirection mechanism, this document will use HTTP (and HTTPS) in its examples. Similar mechanisms can be applied to other application-layer protocols. What follows is a short discussion of both DNS- and HTTP-based redirection, before presenting some examples of their use in Section 3.2.1.1. DNS Redirection
DNS redirection is based on returning different IP addresses for the same DNS name, for example, to balance server load or to account for the client's location in the network. A DNS server, sometimes called the Local DNS (LDNS), resolves DNS names on behalf of an end user. The LDNS server in turn queries other DNS servers until it reaches the authoritative DNS server for the CDN-Domain. The network operator typically provides the LDNS server, although the user is free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).
This latter possibility is important because the authoritative DNS server sees only the IP address of the DNS server that queries it, not the IP address of the original end user. The advantage of DNS redirection is that it is completely transparent to the end user; the user sends a DNS name to the LDNS server and gets back an IP address. On the other hand, DNS redirection is problematic because the DNS request comes from the LDNS server, not the end user. This may affect the accuracy of server selection that is based on the user's location. The transparency of DNS redirection is also a problem in that there is no opportunity to take the attributes of the user agent or the URI path component into account. We consider two main forms of DNS redirection: simple and CNAME- based. In simple DNS redirection, the authoritative DNS server for the name simply returns an IP address from a set of possible IP addresses. The answer is chosen from the set based on characteristics of the set (e.g., the relative loads on the servers) or characteristics of the client (e.g., the location of the client relative to the servers). Simple redirection is straightforward. The only caveats are (1) there is a limit to the number of alternate IP addresses a single DNS server can manage; and (2) DNS responses are cached by Downstream servers so the Time to Live (TTL) on the response must be set to an appropriate value so as to preserve the freshness of the redirection. In CNAME-based DNS redirection, the authoritative server returns a CNAME response to the DNS request, telling the LDNS server to restart the name lookup using a new name. A CNAME is essentially a symbolic link in the DNS namespace, and like a symbolic link, redirection is transparent to the client; the LDNS server gets the CNAME response and re-executes the lookup. Only when the name has been resolved to an IP address does it return the result to the user. Note that DNAME would be preferable to CNAME if it becomes widely supported. One of the advantages of DNS redirection compared to HTTP redirection is that it can be cached, reducing load on the redirecting CDN's DNS server. However, this advantage can also be a drawback, especially when a given DNS resolver doesn't strictly adhere to the TTL, which is a known problem in some real-world environments. In such cases, an end user might end up at a dCDN without first having passed through the uCDN, which might be an undesirable scenario from a uCDN point of view.
2.1.2. HTTP Redirection
HTTP redirection makes use of the redirection response of the HTTP protocol (e.g.,"302" or "307"). This response contains a new URL that the application should fetch instead of the original URL. By changing the URL appropriately, the server can cause the user to redirect to a different server. The advantages of HTTP redirection are that (1) the server can change the URL fetched by the client to include, for example, both the DNS name of the particular server to use, as well as the original HTTP server that was being accessed; (2) the client sends the HTTP request to the server, so that its IP address is known and can be used in selecting the server; and (3) other attributes (e.g., content type, user agent type) are visible to the redirection mechanism. Just as is the case for DNS redirection, there are some potential disadvantages of using HTTP redirection. For example, it may affect application behavior; web browsers will not send cookies if the URL changes to a different domain. In addition, although this might also be an advantage, results of HTTP redirection are not cached so that all redirections must go through to the uCDN.
(page 12 continued on part 2)
