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.
August 2014 Framework for Content Distribution Network Interconnection (CDNI)
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
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
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.
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
[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
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
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
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
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
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
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
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
* Real-time exchanges, suitable for runtime traffic monitoring;
* 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
o Section 3 provides a number of illustrative examples of various
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-
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.