Network Working Group B. Davie, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Informational L. Peterson, Ed.
Expires: January 2, 2012 Verivue, Inc.
July 1, 2011
Framework for CDN Interconnection
draft-davie-cdni-framework-00
Abstract
This document presents a framework for Content Distribution Network
Interconnection (CDNI). The purpose of the framework is to provide
an overall picture of the problem space of CDNI and to describe the
relationships among the various components necessary to interconnect
CDNs. CDN Interconnection requires the specification of several
interfaces and mechanisms to address issues such as request routing,
metadata exchange, and the acquisition of content by one CDN from
another. 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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 January 2, 2012.
Copyright Notice
Davie & Peterson Expires January 2, 2012 [Page 1]
Internet-Draft CDNI Framework July 2011
Copyright (c) 2011 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.
Davie & Peterson Expires January 2, 2012 [Page 2]
Internet-Draft CDNI Framework July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4
2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 6
2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 6
2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . 7
3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . . 7
3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 9
3.2. HTTP Redirect Example . . . . . . . . . . . . . . . . . . 10
3.2.1. Comments on the example . . . . . . . . . . . . . . . 14
3.3. Recursive Redirection Example . . . . . . . . . . . . . . 15
3.3.1. Comments on the example . . . . . . . . . . . . . . . 19
3.4. DNS-based redirection example . . . . . . . . . . . . . . 19
3.4.1. Comments on the example . . . . . . . . . . . . . . . 22
3.5. Dynamic Footprint Discovery . . . . . . . . . . . . . . . 23
3.6. Content Removal . . . . . . . . . . . . . . . . . . . . . 24
3.7. Pre-Positioned Content Acquisition Example . . . . . . . . 25
3.8. Pre-positioned CDNI Metadata Example . . . . . . . . . . . 27
3.9. Dynamic CDNI Metadata Acquisition Example . . . . . . . . 29
4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 32
4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 32
4.2. Request Routing Interface . . . . . . . . . . . . . . . . 33
4.3. Logging Interface . . . . . . . . . . . . . . . . . . . . 34
4.4. Control Interface . . . . . . . . . . . . . . . . . . . . 36
4.5. Metadata Interface . . . . . . . . . . . . . . . . . . . . 36
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 37
6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
11.1. Normative References . . . . . . . . . . . . . . . . . . . 46
11.2. Informative References . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Davie & Peterson Expires January 2, 2012 [Page 3]
Internet-Draft CDNI Framework July 2011
1. Introduction
The interconnection of Content Distribution Networks (CDNs) is
motivated by several use cases, such as those described in
[I-D.bertrand-cdni-use-cases]. The overall problem space for CDN
Interconnection is described in [I-D.jenkins-cdni-problem-statement].
The purpose of this document is to provide an overview of the various
components necessary to interconnect CDNs. CDN Interconnection
requires the specification of several interfaces and mechanisms to
address issues such as request routing, metadata exchange, and the
acquisition of content by one CDN from another. The intent of this
document is to describe how these interfaces and mechanisms fit
together, leaving their detailed specification to other documents.
1.1. Terminology
This document draws freely on the terminology defined in [RFC3466]
and [I-D.jenkins-cdni-problem-statement]. Since
[I-D.jenkins-cdni-problem-statement] redefines some of the terms of
[RFC3466], we will use the definitions provided in
[I-D.jenkins-cdni-problem-statement] in those cases.
We also introduce 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.
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 a standard user request.
1.2. Reference Model
Figure 1 (reproduced from [I-D.jenkins-cdni-problem-statement])
illustrates the basic model of operation with which this document is
concerned.
Davie & Peterson Expires January 2, 2012 [Page 4]
Internet-Draft CDNI Framework July 2011
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
--------------------- |CDNI| ---------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control protocol| +-------------+ |
| |CDN Control |<======|====|=======>| CDN Control | |
| +------*-*-*--+ | | | | +-*-*-*-------+ |
| * * * | | | | * * * |
| +------*------+ | Logging protocol| +-----*-------+ |
| ****| Logging |<======|====|=======>| Logging |**** |
| * --------------+ | | | | +-------------+ * |
| * * * | Request Routing | * * * |
....*...+--------*----+ | protocol | +---*---------+...*.....
. | * **|Req-Routing |<======|====|=======>| Req-Routing |** * | .
. | * * +-------------+ | | | | +-------------+ * * | .
. | * * * | CDNI Metadata | * * * | .
. | * * +----------*--+ | protocol | +-*-----------+ * * | .
. | * * |Distribution |<======|====|=======>| Distribution| * * | .
. | * * | | | \ / | | | * * | .
. | * * | | | \/ | | | * * | .
. | * ****+---------+ | | | | +---------+**** * | .
. | ******|Surrogate|*************************|Surrogate|****** | .
. | | +---------+ | | Acquisition | | +-----*---+ | | .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. --------------------- ---------*----------- .
. * .
. * Delivery .
. * .
. +------+ .
...............Request...........................| User |..Request..
| Agent|
+------+
<==> interfaces inside the scope of CDNI
**** interfaces outside the scope of CDNI
.... interfaces outside the scope of CDNI
Figure 1: Model of Operation for CDN Interconnection
Davie & Peterson Expires January 2, 2012 [Page 5]
Internet-Draft CDNI Framework July 2011
Note that while some interfaces are considered out of scope for CDNI,
because it is believed that no new protocols are needed here, the
overview of operation described below will show how those interfaces
are used as part of an overall solution.
2. Building Blocks
2.1. Request Redirection
At its core, CDN Interconnection requires the redirection of requests
from one CDN to another. Two main mechanisms are available for
redirecting a request. The first leverages the DNS name resolution
process and the second uses in-protocol redirection mechanisms such
as the HTTP 302 redirection response. We discuss these below as
background before discussing 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).
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 modify the path
component of the URL being accessed by the client. 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 delivery nodes a single DNS server
can manage; and (2) DNS responses are cached by downstream servers so
the TTL on the response must be set to an appropriate value so as to
preserve the timeliness of the redirection.
Davie & Peterson Expires January 2, 2012 [Page 6]
Internet-Draft CDNI Framework July 2011
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.
2.1.2. HTTP Redirection
HTTP redirection makes use of the "302" redirection response of the
HTTP protocol. 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 302 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; and (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.
The disadvantages of HTTP redirection are (1) it is visible to the
application, so it requires application support and may affect the
application behavior (e.g., web browsers will not send cookies if the
URL changes to a different domain); (2) HTTP is a heavy-weight
protocol layered on TCP so it has relatively high overhead; and (3)
the results of HTTP redirection are not cached so that all
redirections must go through to the server.
3. Overview of CDNI Operation
To provide a big-picture overview of the various components of CDN
Interconnection, we walk through a "day in the life" of a content
item that is made available via a pair of interconnected CDNs. This
will serve to illustrate many of the functions that need to be
supported in a complete CDNI solution. Below we cover examples using
both DNS-based and HTTP-based redirection. We begin with very simple
examples and then show some that add additional capabilities such as
recursive request redirection and content removal.
Before walking through some specific examples, we present a high-
level view of the operations that may take place. This high-level
overview is illustrated in Figure 2. Note that most operations will
involve only a subset of all the messages shown below, and that the
order and number of operations may vary considerably, as more
detailed examples illustrate below.
Davie & Peterson Expires January 2, 2012 [Page 7]
Internet-Draft CDNI Framework July 2011
The following shows Operator A as the upstream CDN (uCDN) and
Operator B as the downstream CDN (dCDN), where the former has a
relationship with a content provider and the latter being the best
CDN to deliver content to the end-user. The interconnection
relationship may be symmetric between these two CDN operators, but
for simplicity we show the interaction in one directly only.
End-User Operator B Operator A
| | |
| | |
| | [Metadata Push] | (1)
| | |
| | [RRI Push] | (2)
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->| (3)
| | |
| | [RRI Pull] | (4)
| | |
| CONTENT REDIRECTION | |
|<--------------------------------------------------| (5)
| | |
| | |
| CONTENT REQUEST | |
|------------------------>| | (6)
| | |
| | [Metadata Pull] | (7)
| | |
| | ACQUISITION REQUEST |
| X------------------------>| (8)
| X |
| X CONTENT DATA |
| X<------------------------| (9)
| | |
| CONTENT DATA | |
|<------------------------| | (10)
| | |
: : :
: [Other content requests ] :
: : :
| | [Content Purge] | (11)
: : :
| | [Logging exchange] | (12)
| | |
Davie & Peterson Expires January 2, 2012 [Page 8]
Internet-Draft CDNI Framework July 2011
Figure 2: Overview of Operation
The operations shown in the Figure are as follows:
1. Prior to any content request, metadata may be pushed from uCDN
to dCDN so that it is available in readiness for later content
requests.
2. dCDN may advertise information relevant to its delivery
capabilities (e.g. geographic footprint, reachable address
prefixes) prior to any content requests being redirected.
3. A content request from a user agent arrives at uCDN.
4. uCDN may request information from dCDN regarding its delivery
capabilities to decide if dCDN is a suitable target for
redirection of this request.
5. uCDN redirects the request to dCDN by sending some response
(DNS, HTTP) to the user agent.
6. The user agent requests the content from dCDN.
7. dCDN may request metadata related to this content from uCDN,
e.g. to decide whether to serve it.
8. If the content is not already in a suitable cache in dCDN, dCDN
may acquire it from uCDN.
9. The content is delivered to dCDN from uCDN.
10. The content is delivered to the user agent by dCDN.
11. Some time later, perhaps at the request of the CSP (not shown)
uCDN may instruct dCDN to purge the content to ensure it is not
delivered again.
12. After one or more content delivery actions by dCDN, a log of
delivery actions may be provided to uCDN.
The following sections show some more specific examples of how these
operations may be combined to perform various delivery, control and
logging operations across a pair of CDNs.
3.1. Preliminaries
Initially, we assume that there is at least one CSP which has
contracted with an upstream CDN (uCDN) to deliver content on its
Davie & Peterson Expires January 2, 2012 [Page 9]
Internet-Draft CDNI Framework July 2011
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 use the term "CDN-domain" to refer to the host name (a FQDN) at
the beginning of each URL. 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
http://cdn.csp.com/...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
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. HTTP Redirect Example
In this section we walk through a simple, illustrative example using
HTTP redirection from uCDN to dCDN. The example also assume the use
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. (It is likely that the agreement would be made in
both directions, but we focus on just one here for clarity.)
The operators agree that a CDN-domain peer-a.op-b.net will be used as
the target of redirections from uCDN to dCDN. The name of this
domain must be communicated by some means to each CDN. (This could
be configured out of band or exchanged via some defined protocol.)
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 embedded in URLs that end-users request.
Davie & Peterson Expires January 2, 2012 [Page 10]
Internet-Draft CDNI Framework July 2011
The operators must 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.
The operators must 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.
DNS must be configured in the following way:
o The content provider must be 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).
o Operator A must be configured so that a DNS request for op-b-
acq.op-a.net returns a request router in Operator A.
o Operator B must be configured so that a DNS request for peer-a.op-
b.net/cdn.csp.com returns a request router in Operator B.
Figure 3 illustrates how a client request for
http://cdn.csp.com/...rest of url...
is handled.
End-User Operator B Operator A
|DNS cdn.csp.com | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.com | |
|-------------------------------------------------->|
| | |(2)
|302 peer-a.op-b.net/cdn.csp.com |
|<--------------------------------------------------|
|DNS peer-a.op-b.net | |
|------------------------>| |
| |(3) |
|IPaddr of B's Request Router |
|<------------------------| |
| | |
|HTTP peer-a.op-b.net/cdn.csp.com |
|------------------------>| |
| |(4) |
|302 node1.peer-a.op-b.net/cdn.csp.com |
Davie & Peterson Expires January 2, 2012 [Page 11]
Internet-Draft CDNI Framework July 2011
|<------------------------| |
|DNS node1.peer-a.op-b.net| |
|------------------------>| |
| |(5) |
|IPaddr of B's Delivery Node |
|<------------------------| |
| | |
|HTTP node1.peer-a.op-b.net/cdn.csp.com |
|------------------------>| |
| |(6) |
| |DNS op-b-acq.op-a.net |
| |------------------------>|
| | |(7)
| |IPaddr of A's Request Router
| |<------------------------|
| |HTTP op-b-acq.op-a.net |
| |------------------------>|
| | |(8)
| |302 node2.op-b.acq.op-A.net
| |<------------------------|
| |DNS node2.op-b-acq.op-a.net
| |------------------------>|
| | |(9)
| |IPaddr of A's Delivery Node
| |<------------------------|
| | |(10)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 3: Request Trace for HTTP redirection method
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
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
manipulations are possible, such as replacing the initial CDN-
domain by some opaque handle.)
Davie & Peterson Expires January 2, 2012 [Page 12]
Internet-Draft CDNI Framework July 2011
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.
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 by 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.
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).
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
suitable delivery node in uCDN to serve the inter-CDN
acquisition request and returns a 302 redirect message for a new
URL constructed by replacing the hostname by a subdomain of the
Operator A's distinguished inter-CDN acquisition domain that
points to the selected delivery node.
Davie & Peterson Expires January 2, 2012 [Page 13]
Internet-Draft CDNI Framework July 2011
9. Operator A DNS resolver processes the DNS request and returns
the IP address of the delivery node in operator A.
10. Operator A serves content for the requested CDN-domain to dCDN.
Although not shown, it is at this point that Operator A
processes the rest of the URL: it extracts information
identifying the origin server, validates that this server has
been registered, and determines the content provider that owns
the origin server. It may also perform its own content
acquisition steps if needed before returning the content to
dCDN.
3.2.1. Comments on the example
The main advantage of this design is that it is simple: each CDN need
only know a single distinguished CDN-domain for each peer, with the
upstream CDN "pushing" the downstream CDN-domain onto the URL as part
of its redirect (step 2) and the downstream CDN "popping" its CDN-
domain off the URL to expose a CDN-domain that the upstream CDN can
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
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 the request routing interface. Important configuration
information such as the distinguished names used for redirection and
inter-CDN acquisition could also be conveyed via a CDNI interface.
At the same time, these pieces of information might be exchanged out
of band and configured by each operator as needed. The example also
shows how existing HTTP-based methods suffice for the acquisition
interface. Arguably, the absolute minimum metadata required for CDNI
Davie & Peterson Expires January 2, 2012 [Page 14]
Internet-Draft CDNI Framework July 2011
is the information required to acquire the content, and this metadata
was provided "in-band" in this example by means of the URI handed to
the client in the HTTP 302 response. Hence, there is no explicit
metadata interface invoked in this example. There is also no
explicit logging interface discussed in this example.
We also note that the step of deciding when a request should be
redirected to dCDN rather than served by uCDN has been somewhat
glossed over. It may be as simple as checking the client IP address
against a list of prefixes, or it may be considerably more complex,
involving a wide range of factors, such as the geographic location of
the client (perhaps determined from a third party service), CDN load,
or specific business rules.
In the terminology of [I-D.lefaucheur-cdni-requirements], this
example uses the "iterative" CDNI request routing approach. That is,
uCDN performs part of the request routing function to determine that
dCDN should serve the request, and then redirects the client to a
request router in dCDN to perform the rest of the request routing
function. If request routing is performed in the dCDN using HTTP
redirection, this translates in the end-user experiencing two
successive HTTP redirections. By contrast, the alternative approach
of "recursive" CDNI request routing allows to effectively coalesce
these two successive HTTP redirections into a single one getting the
end-user directly on the right delivery node in the dCDN. This
"recursive" CDNI request routing approach is discussed in the next
section.
3.3. Recursive Redirection Example
The following example builds on the previous one to illustrate the
use of the Request Routing interface to enable "recursive" CDNI
request routing (as defined in [I-D.lefaucheur-cdni-requirements]).
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. The operators still must 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.
The operators must 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.
DNS must be configured in the following way:
Davie & Peterson Expires January 2, 2012 [Page 15]
Internet-Draft CDNI Framework July 2011
o The content provider must be 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).
o Operator A must be configured so that a DNS request for op-b-
acq.op-a.net returns a request router in Operator A.
o Operator B must be 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.
Figure 3 illustrates how a client request for
http://cdn.csp.com/...rest of url...
is handled.
Davie & Peterson Expires January 2, 2012 [Page 16]
Internet-Draft CDNI Framework July 2011
End-User Operator B Operator A
|DNS cdn.csp.com | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.com | |
|-------------------------------------------------->|
| | |(2)
| |RRI REQ cdn.csp.com |
| |<------------------------|
| | |
| |RRI RESP node1.op-b.net |
| |------------------------>|
| | |(3)
|302 node1.op-b.net/cdn.csp.com |
|<--------------------------------------------------|
|DNS mode1.op-b.net | |
|------------------------>| |
| |(4) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP node1.op-b.net/cdn.csp.com |
|------------------------>| |
| |(5) |
| |DNS op-b-acq.op-a.net |
| |------------------------>|
| | |(6)
| |IPaddr of A's Request Router
| |<------------------------|
| |HTTP op-b-acq.op-a.net |
| |------------------------>|
| | |(7)
| |302 node2.op-b.acq.op-A.net
| |<------------------------|
| |DNS node2.op-b-acq.op-a.net
| |------------------------>|
| | |(8)
| |IPaddr of A's Delivery Node
| |<------------------------|
| | |(9)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 4: Request Trace for Recursive HTTP redirection method
Davie & Peterson Expires January 2, 2012 [Page 17]
Internet-Draft CDNI Framework July 2011
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
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 queries the
CDNI Request Routing interface of Operator B, providing a number
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 Request Routing Interface.
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
CDNI Request Routing Interface, 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
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).
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
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
Davie & Peterson Expires January 2, 2012 [Page 18]
Internet-Draft CDNI Framework July 2011
constructed by replacing the hostname by a subdomain of the
Operator A's distinguished inter-CDN acquisition domain that
points to the selected delivery node.
8. Operator A recognizes that the DNS request is from a peer CDN
rather than an end-user (due to the internal CDN-domain) and so
returns the address of a delivery node. (Note that without this
specially defined internal domain, Operator A would be at risk of
redirecting the request back to Operator B, resulting in an
infinite loop.)
9. Operator A serves content for the requested CDN-domain to dCDN.
Although not shown, it is at this point that Operator A processes
the rest of the URL: it extracts information identifying the
origin server, validates that this server has been registered,
and determines the content provider that owns the origin server.
It may also perform its own content acquisition steps if needed
before returning the content to dCDN.
3.3.1. Comments on the example
Recursive redirection has the advantage of being more transparent
from the end-user's perspective, but the disadvantage of each CDN
exposing more of its internal structure (e.g., Request Routers, edge
caches) to peer CDNs.
3.4. DNS-based redirection example
In this section we walk through a simple example using DNS-based
redirection for request redirection from uCDN to dCDN (as well as for
request routing inside dCDN and uCDN) . As noted in Section 2.1,
DNS-based redirection has certain advantages over HTTP-based
redirection (notably, it is transparent to the end-user) as well as
some drawbacks (notably the client IP address is not visible to the
request router).
As before, Operator A must 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). Operator B must
have and make 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 must obtain 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.
Davie & Peterson Expires January 2, 2012 [Page 19]
Internet-Draft CDNI Framework July 2011
DNS must be configured in the following way:
o The CSP must be 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).
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.)
o dCDN must be configured so that a request for "b.cdn.csp.com"
returns a delivery node in dCDN.
o uCDN must be configured so that a request for "op-b-acq.op-a.net"
returns a delivery node in uCDN.
Figure 5 depicts the exchange of DNS and HTTP requests. The main
differences from Figure 3are the lack of HTTP redirection and
transparency to the end-user.
Davie & Peterson Expires January 2, 2012 [Page 20]
Internet-Draft CDNI Framework July 2011
End-User Operator B Operator A
|DNS cdn.csp.com | |
|-------------------------------------------------->|
| | |(1)
|CNAME b.cdn.csp.com | |
|NS records for b.cdn.csp.com |
|<--------------------------------------------------|
|DNS b.cdn.csp.com | |
|------------------------>| |
| |(2) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP cdn.csp.com | |
|------------------------>| |
| |(3) |
| |DNS op-b-acq.op-a.net |
| |------------------------>|
| | |(4)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.net |
| |------------------------>|
| | |(5)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 5: Request Trace for DNS-based Redirection Example
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
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.
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.
3. The end-user requests the content from B's delivery node. The
requested URL contains the name cdn.csp.com. (Note that the
returned CNAME does not affect the URL.) At this point the
Davie & Peterson Expires January 2, 2012 [Page 21]
Internet-Draft CDNI Framework July 2011
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).
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.
3.4.1. Comments on the example
A potential problem with this method 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, which is not guaranteed to be in the same 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, 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. One
approach to ensuring that the client's IP address prefix is correctly
determined in such situations is described in
[I-D.vandergaast-edns-client-subnet].
As with the prior example, this example partially illustrates the
various interfaces involved in CDNI. Operator A could learn
dynamically from Operator B the set of prefixes or regions that B is
willing and able to serve via the request routing interface. The
distinguished name used for acquisition and the identifier for
Operator B that is prepended to the CDN domain on redirection are
examples of information elements that might also be conveyed by CDNI
interfaces (or, alternatively, statically configured). As before,
minimal metadata sufficient to obtain the content is carried "in-
band" as part of the redirection process, and standard HTTP is used
for inter-CDN acquisition. There is no explicit logging interface
Davie & Peterson Expires January 2, 2012 [Page 22]
Internet-Draft CDNI Framework July 2011
discussed in this example.
3.5. Dynamic Footprint Discovery
There could 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 | |
|-------------------------------------------------->|
| | |(1)
| | RRI REQ op-b.net |
| |<------------------------|
| | |(2)
| | RRI REPLY |
| |------------------------>|
| | |(3)
|CNAME b.cdn.csp.com | |
|NS records for b.cdn.csp.com |
|<--------------------------------------------------|
|DNS b.cdn.csp.com | |
|------------------------>| |
| |(2) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP cdn.csp.com | |
|------------------------>| |
| |(3) |
| |DNS op-b-acq.op-a.net |
| |------------------------>|
| | |(4)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.net |
| |------------------------>|
| | |(5)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 6: Request Trace for Dynamic Footprint Discovery Example
Davie & Peterson Expires January 2, 2012 [Page 23]
Internet-Draft CDNI Framework July 2011
This example differs from the one in Figure 5 only in the addition of
a CDNI Request Routing Interface request (step 2) and corresponding
response (step 3). The RRI Req could be a message such as "Can you
serve clients from this IP Prefix?" or it could be "Provide the list
of client IP prefixes you can currently serve". In either case the
response might be cached by operator A to avoid repeatedly asking the
same question. Alternatively, or in addition, Operator B may
spontaneously advertise to Operator A information (or changes) on the
set of requests it is willing and able to serve on behalf of operator
A; in that case, Operator B may spontaneously issue RRI REPLY
messages that are not in direct response to a corresponding RRI REQ
message. (Note that the issues of determining the client's subnet
from DNS requests, as described above, are exactly the same here as
in Section 3.4.)
Once Operator A obtains the RRI response, it is now able to determine
that Operator B's CDN is an appropriate dCDN for this request and
therefore a valid candidate dCDN to consider in its Redirection
decision. If that dCDN is selected, the redirection and serving of
the request proceeds as before (i.e. in the absence of dynamic
footprint discovery).
3.6. Content Removal
The following example illustrates how the Control interface may be
used to remove an item of content. 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 Control Interface 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 DEL cdn.csp.com/... |
| |<------------------------|
| | |(1)
| |CI OK |
| |------------------------>|
| | |(2)
Figure 7: Request Trace for Content Removal
The control interface 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.
Davie & Peterson Expires January 2, 2012 [Page 24]
Internet-Draft CDNI Framework July 2011
If HTTP-based redirection had been used, the URL for removal would be
of the form peer-a.op-b.net/cdn.csp.com/...
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 Control interface may be
used to pre-position an item of content in the dCDN. In this
example, Operator A uses the Control Interface to request that
content identified by a particular URL be pre-positioned into
Operator B CDN.
Davie & Peterson Expires January 2, 2012 [Page 25]
Internet-Draft CDNI Framework July 2011
End-User Operator B Operator A
| |CI PREP cdn.csp.com/... |
| |<------------------------|
| | |(1)
| |CI OK |
| |------------------------>|
| | |
| |DNS op-b-acq.op-a.net |
| |------------------------>|
| | |(2)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.net |
| |------------------------>|
| | |(3)
| |Data |
| |<------------------------|
|DNS cdn.csp.com | |
|-------------------------------------------------->|
| | |(4)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.com | |
|-------------------------------------------------->|
| | |(5)
|302 peer-a.op-b.net/cdn.csp.com |
|<--------------------------------------------------|
|DNS peer-a.op-b.net | |
|------------------------>| |
| |(6) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP peer-a.op-b.net/cdn.csp.com |
|------------------------>| |
| |(7) |
|Data | |
|<------------------------| |
Figure 8: Request Trace for Content Pre-Positioning
The steps illustrated in the figure are as follows:
1. Operator A uses the Control Interface to request, via a CI PREP
message, that Operator B pre-positions a particular content item
identified by its URL. Operator B responds via a CI OK message
to confirm that it is willing to perform this operation.
Davie & Peterson Expires January 2, 2012 [Page 26]
Internet-Draft CDNI Framework July 2011
Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only
this times 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.
3.8. Pre-positioned CDNI Metadata Example
In this section we walk through a simple example illustrating a
scenario of pre-positioning of CDNI metadata, as defined in
[I-D.jenkins-cdni-problem-statement], in which 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, pre-positioning of CDNI Metadata is clearly
similarly applicable to DNS-based inter-CDN redirection and iterative
request routing (in which cases the CDNI metadata may be used at
slightly different processing stages of the message flows).
Davie & Peterson Expires January 2, 2012 [Page 27]
Internet-Draft CDNI Framework July 2011
End-User Operator B Operator A
| | |
| |MI PREP (cdn.csp.com/...,|
| | distribution policy) |
| |<------------------------|(1)
| | |
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->| (2)
| | |
| |RRI REQ |
| (3)|<------------------------|
| | |
| | |
| |RRI RESP |
| |------------------------>|(4)
| | |
| CONTENT REDIRECTION | |
|<--------------------------------------------------| (5)
| | |
| CONTENT REQUEST | |
|------------------------>| (6) |
| | |
: : :
| CONTENT DATA | |
|<------------------------| | (7)
Figure 9: Request Trace for CDNI Metadata Pre-positioning
The steps illustrated in the figure are as follows:
1. Operator A uses the Metadata Interface to make CDNI metadata
available to Operator B, via a MI PREP message. The present
document does not constrain how the CDNI metadata information is
actually conveyed. In particular, the CDNI Metadata Interface
specification will define whether the MI PREP message actually
contains the CDNI metadata or contains a pointer to the
information that is then to be pulled through a separate message
exchange. But either way, in the case of pre-positioned CDNI
Metadata acquisition, the CDNI Metadata will be obtained by CDN
Operator B at that stage. For the purposes of this example, we
assume that Operator A provides CDNI metadata to Operator B
indicating that:
* this CDNI Metadata is applicable to any content referenced by
to "cdn.csp.com/op-b.net/..." (assuming HTTP redirection is
used - is would be applicable to "cdn.csp.com/..." if DNS
Davie & Peterson Expires January 2, 2012 [Page 28]
Internet-Draft CDNI Framework July 2011
redirection were used as in Section 3.4).
* this CDNI metadata consists of a distribution policy requiring
enforcement by the delivery node of a specific per-request
authorization mechanism (e.g. URI signature or token
validation).
2. A Content Request occurs as usual.
3. A CDNI Request Routing Request (RRI REQ) is issued by operator A
CDN, as discussed in Section 3.3. Operator B's request router
can access the CDNI Metadata that are relevant to the requested
content and that have been pre-positioned as per Step 1, which
may or may not affect the response.
4. Operator B's request router issues a CDNI Request Routing
Response (RRI RESP) as in Section 3.3.
5. Operator B performs content redirection as discussed in
Section 3.3.
6. On receipt of the Content Request by the end user, the delivery
node detects that pre-positioned CDNI metadata is applicable to
the requested content. In accordance with the specific CDNI
metadata of this example, the delivery node will invoke the
appropriate per-request authorization mechanism, before serving
the content. (Details of this authorization are not shown.)
7. Assuming successful per-request authorization, serving of Content
Data (possibly preceded by inter-CDN acquisition) proceeds as in
Section 3.3.
3.9. Dynamic CDNI Metadata Acquisition Example
In this section we walk through a simple example illustrating a
scenario of dynamic CDNI metadata acquisition, as defined in
[I-D.jenkins-cdni-problem-statement], in which the downstream CDN
obtains CDNI metadata for content at the time of handling a first
request for the corresponding content. As in the preceding section,
this example assumes that HTTP-based inter-CDN redirection and
recursive CDNI request-routing are used (as in Section 3.3), but
dynamic CDNI metadata acquisition is applicable to other variations
of request routing.
Davie & Peterson Expires January 2, 2012 [Page 29]
Internet-Draft CDNI Framework July 2011
End-User Operator B Operator A
| | |
| |MI SEED (cdn.csp.com/...,|
| | CDNI metadata acquisition info)
| |<------------------------|(1)
| | |
: : :
| CONTENT REQUEST | |
|-------------------------------------------------->|(2)
| | |
| |RRI REQ |
| (3)|<------------------------|
| | |
| |MI REQ |
| (4)|------------------------>|
| |MI RESP |
| |<------------------------|(5)
| | |
| |RRI RESP |
| |------------------------>|(6)
| | |
| | |
| CONTENT REDIRECTION | |
|<--------------------------------------------------|(7)
| | |
| CONTENT REQUEST | |
|------------------------>| (8) |
| | |
| |MI REQ |
| (9)|------------------------>|
| |MI RESP |
| |<------------------------|(10)
| | |
: : :
| CONTENT DATA | |
|<------------------------| | (11)
Figure 10: Request Trace for Dynamic CDNI Metadata Acquisition
The steps illustrated in the figure are as follows:
1. Operator A uses the Metadata Interface, via a MI SEED message,
to provide Operator B the information needed to enable the
acquisition of CDNI Metadata when needed. For example, the MI
SEED message may contain a URI indicating where CDNI Metadata
can later be pulled from for some content set. In this example,
CDNI Metadata are not immediately obtained by CDN Operator B.
Davie & Peterson Expires January 2, 2012 [Page 30]
Internet-Draft CDNI Framework July 2011
(There are alternative ways that this seeding information may be
provided, such as piggybacking on the CDNI RRI REQ message of
Step 3.)
2. A Content Request arrives as normal.
3. A Request Routing Interface request occurs as in the prior
example.
4. On receipt of the CDNI Request Routing Request, Operator B's CDN
initiates dynamic acquisition of CDNI Metadata that are needed
for routing of the end-user request. The seeding information
provided in Step 1 is used to determine how to obtain the
metadata. Note that there may exist cases in which this step
does not occur (e.g., because the CDNI metadata seeding
information indicates CDNI metadata are not needed at that
stage).
5. On receipt of a CDNI Metadata MI Request, Operator A's CDN
responds, making the corresponding CDNI metadata information
available to Operator B's CDN. This metadata is considered by
operator B's CDN before responding to the Request Routing
request.
6. Response to the RRI request as normal.
7. Redirection message is sent to the end user.
8. A delivery node of Operator B receives the end user request.
9. The delivery node triggers dynamic acquisition of additional
CDNI metadata that are needed to process the end-user content
request. Again the seeding information provided in Step 1 is
used to determine how to acquire the needed CDNI metadata. Note
that there may exist cases where this step need not happen,
either because the metadata were already acquired previously, or
because the seeding information indicates no metadata are
required.
10. Operator A's CDN responds to the CDNI Metadata Request and makes
the corresponding CDNI metadata available to Operator B. This
metadata influence how Operator B's CDN processes the end user
request.
11. Content is served (possibly preceded by inter-CDN acquisition)
as in Section 3.3.
Davie & Peterson Expires January 2, 2012 [Page 31]
Internet-Draft CDNI Framework July 2011
4. Main Interfaces
Figure 1 illustrates the four 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 (mostly to be
written, but see [I-D.jenkins-cdni-problem-statement] and
[I-D.lefaucheur-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. As we saw in some of the
preceding examples, that interface can be used as a way of passing
information such as the metadata that is required to obtain the
content in dCDN from uCDN.
In this section we will provide an overview of the functions
performed by each of the CDNI interfaces and discuss how they fit
into the overall solution. We also examine some of the design
tradeoffs. We begin with an examination of one such tradeoff that
affects all the interfaces - the use of in-band or out-of-band
communication.
4.1. In-Band versus Out-of-Band Interfaces
Before getting to the individual interfaces, we observe that there is
a high-level design choice for each, involving the use of existing
in-band communication channels versus defining new out-of-band
interfaces.
It is possible that the information needed to carry out various
interconnection functions can be communicated between peer CDNs using
existing in-band protocols. The use of HTTP 302 redirect is an
example of how certain aspects of request routing can be implemented
in-band (embedded in URIs). Note that using existing in-band
protocols does not imply that the CDNI interfaces are null; it is
still necessary to establish the rules (conventions) by which such
protocols are used to implement the various interface functions.
There are other opportunities for in-band communication beyond HTTP
redirects. For example, many of the HTTP directives used by proxy
servers can also be used by peer CDNs to inform each other of caching
activity. Of these, one that is particularly relevant is the If-
Davie & Peterson Expires January 2, 2012 [Page 32]
Internet-Draft CDNI Framework July 2011
Modified-Since directive, which is used with the GET method to make
it conditional: if the requested object has not been modified since
the time specified in this field, a copy of the object will not be
returned, and instead, a 304 (not modified) response will be
returned.
4.2. Request Routing Interface
As illustrated in Section 3, the request routing interface may be
implemented in part by DNS and HTTP, in which case naming conventions
must be established by which CDN peers communicate whether a request
should be routed or content served.
In support of these exchanges, it is necessary for CDN peers to
exchange additional information with each other. Depending on the
method(s) supported, this includes
o The operator's unique id (operator-id) or distinguished CDN-domain
(operator-domain);
o The set of requests the dCDN operator is prepared to serve (e.g. a
set of client IP prefixes or geographic regions that may be served
by dCDN); and
o NS records for the operator's set of externally visible request
routers.
Of these, the two operator identifiers are fixed, and can be
exchanged off-line as part of a peering agreement. The set of
requests that dCDN is willing to serve could in some cases be
relatively static (e.g., a set of IP prefixes) with 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 an
explicit protocol for its exchange would be be helpful. The NS
records potentially change with some frequency, but an existing
protocol--DNS--can be used to dynamically track this information.
That is, a peer can do a DNS lookup on operator-domain to retrieve
the set of NS records corresponding to the peer's redirection
service.
We also note that the Request Routing interface 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.
Davie & Peterson Expires January 2, 2012 [Page 33]
Internet-Draft CDNI Framework July 2011
4.3. Logging Interface
It is necessary for the upstream CDN to have visibility into the
delivery of content it originates to end-users connected to the
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 Logging interface.
Other operational data that may be relevant to CDNI can also be
exchanged by the Logging interface. For example, dCDN may report the
amount of content it has acquired from uCDN, and how much cache
storage has been consumed by content cached on behalf of uCDN.
Traffic logs are easily exchanged off-line. For example, the
following traffic log is a small deviation from the Apache log file
format, where entries include the following fields:
o Domain - the full domain name of the origin server
o IP address - the IP address of the client making the request
o End time - the ending time of the transfer
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--it
is set to the CDN-domain used by the upstream CDN rather than the
Davie & Peterson Expires January 2, 2012 [Page 34]
Internet-Draft CDNI Framework July 2011
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.
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 the
request routing 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
records and the set of CDN-domains it serves to an independent third-
party (i.e., a CDN Exchange), which subsequently filters, merges, and
distributes traffic records on behalf of each participating CDN
operator.
A second open question is how timely traffic information should be.
For example, in addition to off-line traffic logs, accurate real-time
traffic monitoring might also be useful, but such information
requires that the downstream CDN inform the upstream CDN each time it
serves upstream content from its cache. The downstream CDN can do
this, for example, by sending a conditional HTTP GET request (If-
Modified-Since) to the upstream CDN each time it receives an HTTP GET
request from one of its end-users. This allows the upstream CDN to
record that a request has been issued for the purpose of real-time
traffic monitoring. The upstream CDN can also use this information
to validate the traffic logs received later from the downstream CDN.
There is obviously a tradeoff between accuracy of such monitoring and
the overhead of the downstream CDN having to go back to the upstream
CDN for every request.
Another design tradeoff in the Logging interface is the degree of
aggregation or summarization of data. One situation that lends
itself to summarization is the delivery of HTTP-based adaptive bit-
rate video. Most schemes to deliver such video use a large number of
relatively small HTTP requests (e.g. one request per 2-second chunk
of video.) It may be desirable to aggregate logging information so
that a single log entry is provided for the entire video rather than
for each chunk. Note however that such aggregation requires a degree
of application awareness in dCDN to recognize that the many HTTP
requests correspond to a single video.
Other forms of aggregation may also be useful. For example, there
may be situations where bulk metrics such as bytes delivered per hour
may suffice rather than the detailed per-request logs outlined above.
Davie & Peterson Expires January 2, 2012 [Page 35]
Internet-Draft CDNI Framework July 2011
It seems likely that a range of granularities of logging will be
needed along with ways to specify the type and degree of aggregation
required.
4.4. Control Interface
The upstream CDN requires control over how the downstream CDN
delivers its content, for example, allowing it to purge content from
the downstream CDN's caches or control what end-users are permitted
to download its content. This is one role of the Control interface.
As noted above and in [I-D.jenkins-cdni-problem-statement], the
control interface may also be used for the bootstrapping of 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 logging interface.
Some aspects of the control interface may be implemented in-band.
For example, being able to respond to a conditional GET request gives
the upstream CDN an opportunity to influence how the downstream CDN
delivers its content. Minimally, the upstream CDN can invalidate
(purge) content previously cached by the downstream CDN.
Fine-grain control over how the downstream CDN delivers content on
behalf of the upstream CDN is also possible. For example, by
including the X-Forwarded-For HTTP header with the conditional GET
request, the downstream CDN can report the end-user's IP address to
the upstream CDN, giving it an opportunity to control whether the
downstream CDN should serve the content to this particular end-user.
The upstream CDN would communicate its control directive through its
response to the conditional GET. The downstream CDN can cache
information for a period of time specified by the upstream CDN,
thereby reducing control overhead.
Thinking beyond what control operations can be done in-line, we note
that all CDNs already export a "content purge" operation to their
customers. The CDNI control interface could support a similar
"content purge" API call. When a CSP invokes purge on the upstream
CDN, that CDN in turn invokes purge on all downstream CDNs that might
be caching the content. Of course, agreement as to the syntax and
semantics of this call is required.
4.5. Metadata Interface
The role of the metadata interface is to enable CDNI distribution
metadata to be conveyed to the downstream CDN by the upstream CDN.
Such metadata includes geo-blocking restrictions, availability
windows, access control policies, etc. It may also include policy
Davie & Peterson Expires January 2, 2012 [Page 36]
Internet-Draft CDNI Framework July 2011
information such as the desire to pre-position content rather than
fetch it on demand.
Some metadata may be able to be conveyed using in-band mechanisms.
For example, to inform the downstream CDN of any geo-blocking
restrictions or availability windows, the upstream 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. Some forms of access control may
also be performed on a per-request basis using HTTP directives, as
described earlier.
One open question is how to distinguish between what functionality is
supported by the Metadata interface and what functionality is
supported by the Control interface. For example, it is possible to
limit how content is distributed by specifying geo-blocking
restrictions as Metadata, or by denying a particular user's request
using an access control operation of the Control interface. One
possible distinction is that the Metadata interface is advisory,
whereas the Control interface is authoritative. Another possible
distinction is that the Metadata interface is used to communicate
information at content publication time, while the Control interface
controls behavior at request time.
5. Deployment Models
Although the reference model illustrated in Figure 1 shows a
unidirectional CDN interconnection with a single uCDN and a single
dCDN, any arbitrary CDNI meshing can be built from this, such as the
example meshing illustrated in Figure 11. (Support for arbitrary
meshing may or may not be in the initial scope for the working group,
but the model allows for it.)
Davie & Peterson Expires January 2, 2012 [Page 37]
Internet-Draft CDNI Framework July 2011
------------- -----------
/ CDN A \<==CDNI===>/ CDN B \
\ / \ /
------------- -----------
/\ \\ /\
|| \\ ||
CDNI \==CDNI===\\ CDNI
|| \\ ||
\/ \/ \/
------------- -----------
/ CDN C \===CDNI===>/ CDN D \
\ / \ /
------------- -----------
/\
||
CDNI
||
\/
-------------
/ CDN E \
\ /
-------------
===> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN
<==> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN and with left-hand side CDN acting
as dCDN to right-hand side CDN
Figure 11: CDNI Deployment Model: CDN Meshing Example
Although the reference model of Figure 1 shows all CDN functions on
each side of the CDNI interface, deployments can rely on entities
that are involved in any subset of these functions, and therefore
only support the relevant subset of CDNI interfaces. As already
noted in Section 3, effective CDNI deployments can be built without
necessarily implementing all four interfaces.
Note that, while we refer to upstream and downstream CDNs, this
distinction applies to specific content items and transactions. That
is, a given CDN may be upstream for some transactions and downstream
for others, depending on many factors such as location of the
requesting client and the particular piece of content requested.
Note that our terminology refers to functional roles and not economic
or business roles. That is, a given organization may be operating as
both a CSP and a fully-fledged uCDN when we consider the functions
performed, as illustrated in Figure 12.
Davie & Peterson Expires January 2, 2012 [Page 38]
Internet-Draft CDNI Framework July 2011
##################################### ##################
# # # #
# Organization A # # Organization B #
# # # #
# -------- ------------- # # ----------- #
# / CSP \ / uCDN \ # # / dCDN \ #
# | | | +----+ | # # | +----+ | #
# | | | | C | | # # | | C | | #
# | | | +----+ | # # | +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | L | | # # | | L | | #
# | |*****| +----+ |===CDNI===>| +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | RR | | # # | | RR | | #
# | | | +----+ | # # | +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | D | | # # | | D | | #
# | | | +----+ | # # | +----+ | #
# \ / \ / # # \ / #
# -------- ------------- # # ----------- #
# # # #
##################################### ##################
===> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN
**** interfaces outside the scope of CDNI
C Control component of the CDN
L Logging component of the CDN
RR Request Routing component of the CDN
D Distribution component of the CDN
Figure 12: CDNI Deployment Model: Organization combining CSP & uCDN
As another example, a content provider organization may choose to run
its own request routing function as a way to select among multiple
candidate CDN providers; In this case the content provider may be
modeled as the combination of a CSP and of a special, restricted case
of a CDN. In that case, as illustrated in Figure 13, the CDNI
Request Routing interface can be used between the restricted CDN
operated by the content provider Organization and the CDN operated by
the full-CDN organization acting as a dCDN in the request routing
control plane. Interfaces outside the scope of the CDNI work can be
used between the CSP functional entities of the content provider
organization and the CDN operated by the full-CDN organization acting
as a uCDN) in the CDNI control planes other than the request routing
plane (i.e. Control, Distribution, Logging).
Davie & Peterson Expires January 2, 2012 [Page 39]
Internet-Draft CDNI Framework July 2011
##################################### ##################
# # # #
# Organization A # # Organization B #
# # # #
# -------- ------------- # # ----------- #
# / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ #
# | | | +----+ | # # | +----+ | #
# | |*****| | RR |==========CDNI=====>| RR | | #
# | | | +----+ | # RR # | +----+ | #
# | | \ / # # | | #
# | | ------------- # # |uCDN(C,L,D)| #
# | | # # | +----+ | #
# | | # # | | C | | #
# | |*******************************| +----+ | #
# | | # # | +----+ | #
# | | # # | | L | | #
# | | # # | +----+ | #
# | | # # | +----+ | #
# | | # # | | D | | #
# | | # # | +----+ | #
# \ / # # \ / #
# -------- # # ----------- #
# # # #
##################################### ##################
===> CDNI Request Routing interface
**** interfaces outside the scope of CDNI
Figure 13: CDNI Deployment Model: Organization combining CSP and
partial CDN
There are two additional concepts related to, but distinct from CDN
Interconnection. The first is CDN Federation. Our view is that CDNI
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--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
Davie & Peterson Expires January 2, 2012 [Page 40]
Internet-Draft CDNI Framework July 2011
illustrated in Figure 14, the exchange might aggregate and
redistribute information about each CDN footprint and capacity, as
well as collect, filter, and re-distribute 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--
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 interface with the
CDN Exchange (for aggregation and redistribution of dynamic CDN
footprint discovery information) and a direct CDNI Request Routing
interface to every other CDN (for actual request redirection).
Davie & Peterson Expires January 2, 2012 [Page 41]
Internet-Draft CDNI Framework July 2011
---------- ---------
/ CDN A \ / CDN B \
| +----+ | | +----+ |
//========>| C |<==============CDNI============>| C |<==========\\
|| | +----+ | C | +----+ | ||
|| | +----+ | | +----+ | ||
|| //=====>| D |<==============CDNI============>| D |<=======\\ ||
|| || | +----+ | M | +----+ | || ||
|| || | | /------------\ | | || ||
|| || | +----+ | | +--+ CDN Ex| | +----+ | || ||
|| || //==>| RR |<===CDNI==>|RR|<=======CDNI====>| RR |<====\\ || ||
|| || || | +----+ | RR | +--+ | RR | +----+ | || || ||
|| || || | | | /\ | | | || || ||
|| || || | +----+ | | || +---+ | | +----+ | || || ||
|| || || | | L |<===CDNI=======>| L |<=CDNI====>| L | | || || ||
|| || || | +----+ | L | || +---+ | L | +----+ | || || ||
|| || || \ / \ || /\ / \ / || || ||
|| || || ----------- --||----||-- ----------- || || ||
|| || || || || || || ||
|| || || CDNI RR || || || ||
|| || || || CDNI L || || ||
|| || || || || || || ||
|| || || ---||----||---- || || ||
|| || || / \/ || \ || || ||
|| || || | +----+ || | || || ||
|| || \\=====CDNI==========>| RR |<=============CDNI========// || ||
|| || RR | +----+ \/ | RR || ||
|| || | +----+ | || ||
|| || | | L | | || ||
|| || | +----+ | || ||
|| || | +----+ | || ||
|| \\=======CDNI===========>| D |<=============CDNI===========// ||
|| M | +----+ | M ||
|| | +----+ | ||
\\==========CDNI===========>| C |<=============CDNI==============//
C | +----+ | C
\ CDN C /
--------------
<=CDNI RR=> CDNI Request Routing interface
<=CDNI M==> CDNI Metadata interface
<=CDNI C==> CDNI Control interface
<=CDNI L==> CDNI Logging interface
Figure 14: CDNI Deployment Model: CDN Exchange
Note that a CDN exchange may alternatively support a different set of
functionality (e.g. Logging only, or Logging and full request
Davie & Peterson Expires January 2, 2012 [Page 42]
Internet-Draft CDNI Framework July 2011
routing, or all the functionality of a CDN including content
distribution). All these options are expected to be allowed by the
IETF CDNI specifications.
6. Trust Model
There are a number of trust issues that need to be addressed by a
CDNI solution. Many of them are in fact similar or identical to
those in a simple CDN without interconnection. In a standard CDN
environment (without CDNI), the CSP places a degree of trust in a
single CDN operator to perform many functions. The CDN is trusted to
deliver content with appropriate quality of experience for the end
user. The CSP trusts the CDN operator not to corrupt or modify the
content. The CSP often relies on the CDN operator to provide
reliable accounting information regarding the volume of delivered
content. The CSP may also trust the CDN operator to perform actions
such as timely invalidation of content and restriction of access to
content based on certain criteria such as location of the user and
time of day, and to enforce per-request authorization performed by
the CSP using techniques such as URI signing.
A CSP also places trust in the CDN not to distribute any information
that is confidential to the CSP (e.g., how popular a given piece of
content is) or confidential to the end user (e.g., which content has
been watched by which user).
A CSP does not necessarily have to place complete trust in a CDN. A
CSP will in some cases take steps to protect its content from
improper distribution by a CDN, e.g. by encrypting it and
distributing keys in some out of band way. A CSP also depends on
monitoring (possibly by third parties) and reporting to verify that
the CDN has performed adequately. A CSP may use techniques such as
client-based metering to verify that accounting information provided
by the CDN is reliable. HTTP conditional requests may be used to
provide the CSP with some checks on CDN operation. In other words,
while a CSP may trust a CDN to perform some functions in the short
term, the CSP is able in most cases to verify whether these actions
have been performed correctly and to take action (such as moving the
content to a different CDN) if the CDN does not live up to
expectations.
The main trust issue raised by CDNI is that is introduces transitive
trust. A CDN that has a direct relationship with a CSP can now
"outsource" the delivery of content to another (downstream) CDN.
That CDN may in term outsource delivery to yet another downstream
CDN, and so on.
Davie & Peterson Expires January 2, 2012 [Page 43]
Internet-Draft CDNI Framework July 2011
The top level CDN in such a chain of delegation is responsible for
ensuring that the requirements of the CSP are met. Failure to do so
is presumably just as serious as in the traditional single CDN case.
Hence, an upstream CDN is essentially trusting a downstream CDN to
perform functions on its behalf in just the same way as a CSP trusts
a single CDN. Monitoring and reporting can similarly be used to
verify that the downstream CDN has performed appropriately. However,
the introduction of multiple CDNs in the path between CSP and end
user complicates the picture. For example, third party monitoring of
CDN performance (or other aspects of operation, such as timely
invalidation) might be able to identify the fact that a problem
occurred somewhere in the chain but not point to the particular CDN
at fault.
In summary, we assume that an upstream CDN will invest a certain
amount of trust in a downstream CDN, but that it will verify that the
downstream CDN is performing correctly, and take corrective action
(including potentially breaking off its relationship with that CDN)
if behavior is not correct. We do not expect that the trust
relationship between a CSP and its "top level" CDN will differ
significantly from that found today in single CDN situations.
However, it does appear that more sophisticated tools and techniques
for monitoring CDN performance and behavior will be required to
enable the identification of the CDN at fault in a particular
delivery chain.
We expect that the detailed designs for the specific interfaces for
CDNI will need to take the transitive trust issues into account. For
example, explicit confirmation that some action (such as content
removal) has taken place in a downstream CDN may help to mitigate
some issues of transitive trust.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
[Note: this section to be extended in future revision.]
While there is a variety of security issues introduced by a single
CDN, we are concerned here specifically with the additional issues
that arise when CDNs are interconnected. For example, when a single
CDN has the ability to distribute content on behalf of a CSP, there
may be concerns that such content could be distributed to parties who
are not authorized to receive it, and there are mechanisms to deal
Davie & Peterson Expires January 2, 2012 [Page 44]
Internet-Draft CDNI Framework July 2011
with such concerns. Our focus in this section is on how CDN
interconnection introduces new security issues not found in the
single CDN case.
Many of the security issues that arise in CDNI are related to the
transitivity of trust (or lack thereof) described in Section 6. As
noted above, the design of the various interfaces for CDNI must take
account of the additional risks posed by the fact that a CDN with
whom a CSP has no direct relationship is now potentially distributing
content for that CSP. The mechanisms used to mitigate these risks
may be similar to those used in the single CDN case, but their
suitability in this more complex environment must be validated.
Another concern that arises in any CDN is that information about the
behavior of users (what content they access, how much content they
consume, etc.) may be gathered by the CDN. This risk certainly
exists in inter-connected CDNs, but it should be possible to apply
the same techniques to mitigate it as in the single CDN case.
CDNs today offer a variety of means to control access to content,
such as time-of-day restrictions, geo-blocking, and URI signing.
These mechanisms must continue to function in CDNI environments, and
this consideration is likely to affect the design of certain CDNI
interfaces (e.g. metadata, request routing.)
Just as with a single CDN, each peer CDN must ensure that it is not
used as an "open proxy" to deliver content on behalf of a malicious
CSP. Whereas a single CDN typically addresses this problem by having
CSPs explicitly register content (or origin servers) that is to be
served, simply propagating this information to peer downstream CDNs
may be problematic because it reveals more information than the
upstream CDN is willing to specify. (To this end, the content
acquisition step in the earlier examples force the dCDN to retrieve
content from the uCDN rather than go directly to the origin server.)
There are several approaches to this problem. One is for the uCDN to
encoded a signed token generated from a shared secret in each URL
routed to a dCDN, and for the dCDN to validate the request based on
this token. Another one is to have each upstream CDN advertise the
set of CDN-domains they serve, where the downstream CDN checks each
request against this set before caching and delivering the associated
object. Although straightforward, this approach requires operators
to reveal additional information, which may or may not be an issue.
9. Contributors
The following individuals contributed to this document:
Davie & Peterson Expires January 2, 2012 [Page 45]
Internet-Draft CDNI Framework July 2011
o Francois le Faucheur
o Ben Niven-Jenkins
o David Ferguson
o John Hartman
10. Acknowledgements
We thank Huw Jones for his helpful comments on the draft.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.bertrand-cdni-use-cases]
Bertrand, G., Stephan, E., Watson, G., Burbridge, T., and
P. Eardley, "Use Cases for Content Distribution Network
Interconnection", draft-bertrand-cdni-use-cases-01 (work
in progress), January 2011.
[I-D.jenkins-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", draft-jenkins-cdni-problem-statement-02 (work
in progress), March 2011.
[I-D.lefaucheur-cdni-requirements]
Faucheur, F., Viveganandhan, M., Watson, G., and Y. Lee,
"Content Distribution Network Interconnection (CDNI)
Requirements", draft-lefaucheur-cdni-requirements-01 (work
in progress), March 2011.
[I-D.vandergaast-edns-client-subnet]
Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
"Client subnet in DNS requests",
draft-vandergaast-edns-client-subnet-00 (work in
progress), January 2011.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
Davie & Peterson Expires January 2, 2012 [Page 46]
Internet-Draft CDNI Framework July 2011
for Content Internetworking (CDI)", RFC 3466,
February 2003.
Authors' Addresses
Bruce Davie (editor)
Cisco Systems, Inc.
1414 Mass. Ave.
Boxborough, MA 01719
USA
Email: bsd@cisco.com
Larry Peterson (editor)
Verivue, Inc.
2 Research Way
Princeton, NJ
USA
Phone: +1 978 303 8032
Email: lpeterson@verivue.com
Davie & Peterson Expires January 2, 2012 [Page 47]