One document matched: draft-davie-cdni-framework-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-davie-cdni-framework-00" ipr="trust200902">
<front>
<title abbrev="CDNI Framework">Framework for CDN Interconnection</title>
<author fullname="Bruce Davie" initials="B." role="editor" surname="Davie">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1414 Mass. Ave.</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>USA</country>
</postal>
<email>bsd@cisco.com</email>
</address>
</author>
<author fullname="Larry Peterson" initials="L. " role="editor"
surname="Peterson">
<organization>Verivue, Inc.</organization>
<address>
<postal>
<street>2 Research Way</street>
<city>Princeton</city>
<region>NJ</region>
<code></code>
<country>USA</country>
</postal>
<phone>+1 978 303 8032</phone>
<email>lpeterson@verivue.com</email>
</address>
</author>
<date day="1" month="July" year="2011" />
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The interconnection of Content Distribution Networks (CDNs) is
motivated by several use cases, such as those described in <xref
target="I-D.bertrand-cdni-use-cases"></xref>. The overall problem space
for CDN Interconnection is described in <xref
target="I-D.jenkins-cdni-problem-statement"></xref>. 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.</t>
<section title="Terminology">
<t>This document draws freely on the terminology defined in <xref
target="RFC3466"></xref> and <xref
target="I-D.jenkins-cdni-problem-statement"></xref>. Since <xref
target="I-D.jenkins-cdni-problem-statement"></xref> redefines some of
the terms of <xref target="RFC3466"></xref>, we will use the
definitions provided in <xref
target="I-D.jenkins-cdni-problem-statement"> </xref> in those
cases.</t>
<t>We also introduce the following terms:</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Reference Model">
<t></t>
<t><xref target="refmod"></xref> (reproduced from <xref
target="I-D.jenkins-cdni-problem-statement"></xref>) illustrates the
basic model of operation with which this document is concerned.</t>
<figure anchor="refmod"
title="Model of Operation for CDN Interconnection">
<artwork><![CDATA[
--------
/ \
| 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
]]></artwork>
</figure>
<t>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.</t>
</section>
</section>
<section anchor="blocks" title="Building Blocks">
<section anchor="redirection" title="Request Redirection">
<t>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 <xref
target="operation"></xref>.</t>
<section title="DNS Redirection">
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="HTTP Redirection">
<t>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.</t>
<t>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.</t>
</section>
</section>
</section>
<section anchor="operation" title="Overview of CDNI Operation">
<t>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.</t>
<t>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 <xref target="high-level-ops"></xref>. 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. </t>
<t>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.</t>
<figure anchor="high-level-ops"
title="Overview of Operation">
<artwork><![CDATA[
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)
| | |
]]></artwork>
</figure>
<t>The operations shown in the Figure are as follows:
<list style="numbers">
<t>Prior to any content request, metadata may be pushed from
uCDN to dCDN so that it is available in readiness for later
content requests.</t>
<t>dCDN may advertise information relevant to its delivery
capabilities (e.g. geographic footprint, reachable address
prefixes) prior to any content requests being redirected.</t>
<t>A content request from a user agent arrives at uCDN.</t>
<t>uCDN may request information from dCDN regarding its
delivery capabilities to decide if dCDN is a suitable target
for redirection of this request.</t>
<t>uCDN redirects the request to dCDN by sending some response
(DNS, HTTP) to the user agent.</t>
<t>The user agent requests the content from dCDN.</t>
<t>dCDN may request metadata related to this content from
uCDN, e.g. to decide whether to serve it.</t>
<t>If the content is not already in a suitable cache in dCDN,
dCDN may acquire it from uCDN.</t>
<t>The content is delivered to dCDN from uCDN.</t>
<t>The content is delivered to the user agent by dCDN.</t>
<t>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.</t>
<t>After one or more content delivery actions by dCDN, a log
of delivery actions may be provided to uCDN.</t>
</list></t>
<t>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.</t>
<section title="Preliminaries">
<t>Initially, we assume that there is at least one CSP which has
contracted with an upstream CDN (uCDN) to deliver content on its
behalf. We are not particularly concerned with the interface between
the CSP and uCDN, other than to note that it is expected to be the
same as in the "traditional" (non-interconnected) CDN case. Existing
mechanisms such as DNS CNAMEs or HTTP redirects (<xref
target="blocks"></xref>) can be used to direct a user request for a
piece of content from the CSP towards the CSP's chosen upstream
CDN.</t>
<t>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</t>
<t>http://cdn.csp.com/...rest of url...</t>
<t>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.</t>
<t>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.</t>
<t></t>
</section>
<section anchor="http-redir" title="HTTP Redirect Example">
<t>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.</t>
<t>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.)</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>DNS must be configured in the following way:<list style="symbols">
<t>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).</t>
<t>Operator A must be configured so that a DNS request for
op-b-acq.op-a.net returns a request router in Operator A.</t>
<t>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.</t>
</list></t>
<t><xref target="simple-http"></xref> illustrates how a client request
for</t>
<t>http://cdn.csp.com/...rest of url...</t>
<t>is handled.</t>
<figure anchor="simple-http"
title="Request Trace for HTTP redirection method">
<artwork><![CDATA[ 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 |
|<------------------------| |
|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 | |
|<------------------------| |
]]></artwork>
</figure>
<t>The steps illustrated in the figure are as follows:<list
style="numbers">
<t>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.</t>
<t>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.)</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
<t>Operator A's DNS resolver processes the DNS request and returns
the IP address of a request router in operator A.</t>
<t>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.</t>
<t>Operator A DNS resolver processes the DNS request and returns
the IP address of the delivery node in operator A.</t>
<t>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.</t>
</list></t>
<section title="Comments on the example">
<t>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).</t>
<t>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.</t>
<t>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 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.</t>
<t>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.</t>
<t>In the terminology of <xref
target="I-D.lefaucheur-cdni-requirements"></xref>, 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.</t>
</section>
</section>
<section anchor="recurse" title="Recursive Redirection Example">
<t>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 <xref
target="I-D.lefaucheur-cdni-requirements"></xref>).</t>
<t>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.</t>
<t>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.</t>
<t>DNS must be configured in the following way:<list style="symbols">
<t>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).</t>
<t>Operator A must be configured so that a DNS request for
op-b-acq.op-a.net returns a request router in Operator A.</t>
<t>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.</t>
</list></t>
<t><xref target="simple-http"></xref> illustrates how a client request
for</t>
<t>http://cdn.csp.com/...rest of url...</t>
<t>is handled.</t>
<figure anchor="recurse-http"
title="Request Trace for Recursive HTTP redirection method">
<artwork><![CDATA[ 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 | |
|<------------------------| |
]]></artwork>
</figure>
<t>The steps illustrated in the figure are as follows:<list
style="numbers">
<t>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.</t>
<t>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.</t>
<t>Operator A returns a 302 redirect message for a new URL
obtained from the Request Routing Interface.</t>
<t>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.)</t>
<t>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).</t>
<t>Operator A DNS resolver processes the DNS request and returns
the IP address of a request router in operator A.</t>
<t>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.</t>
<t>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.)</t>
<t>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.</t>
</list></t>
<section title="Comments on the example">
<t>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.</t>
</section>
</section>
<section anchor="DNS-eg" title="DNS-based redirection example">
<t>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 <xref
target="redirection"></xref>, 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).</t>
<t>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.</t>
<t>DNS must be configured in the following way:<list style="symbols">
<t>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).</t>
<t>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.)</t>
<t>dCDN must be configured so that a request for "b.cdn.csp.com"
returns a delivery node in dCDN.</t>
<t>uCDN must be configured so that a request for
"op-b-acq.op-a.net" returns a delivery node in uCDN.</t>
</list></t>
<t><xref target="simple-DNS"></xref> depicts the exchange of DNS and
HTTP requests. The main differences from <xref
target="simple-http"></xref>are the lack of HTTP redirection and
transparency to the end-user.</t>
<figure anchor="simple-DNS"
title="Request Trace for DNS-based Redirection Example">
<artwork><![CDATA[ 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 | |
|<------------------------| |
]]></artwork>
</figure>
<t>The steps illustrated in the figure are as follows:<list
style="numbers">
<t>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.</t>
<t>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.</t>
<t>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
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).</t>
<t>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.</t>
<t>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.</t>
</list></t>
<section title="Comments on the example">
<t>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 <xref
target="I-D.vandergaast-edns-client-subnet"></xref>.</t>
<t>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 discussed in this example.</t>
</section>
</section>
<section title="Dynamic Footprint Discovery">
<t>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.</t>
<t></t>
<figure anchor="dynamic-footprint"
title="Request Trace for Dynamic Footprint Discovery Example">
<artwork><![CDATA[ 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 | |
|<------------------------| |
]]></artwork>
</figure>
<t>This example differs from the one in <xref
target="simple-DNS"></xref> 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 <xref
target="DNS-eg"></xref>.)</t>
<t>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).</t>
</section>
<section title="Content Removal">
<t>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.</t>
<figure anchor="removal" title="Request Trace for Content Removal">
<artwork><![CDATA[ End-User Operator B Operator A
| |CI DEL cdn.csp.com/... |
| |<------------------------|
| | |(1)
| |CI OK |
| |------------------------>|
| | |(2)
]]></artwork>
</figure>
<t>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 <xref target="DNS-eg"></xref>. If HTTP-based
redirection had been used, the URL for removal would be of
the form peer-a.op-b.net/cdn.csp.com/...</t>
<t>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.</t>
</section>
<section title="Pre-Positioned Content Acquisition Example">
<t>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.</t>
<t></t>
<t><figure anchor="pre-positioning"
title="Request Trace for Content Pre-Positioning">
<artwork><![CDATA[ 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 | |
|<------------------------| |
]]></artwork>
</figure></t>
<t>The steps illustrated in the figure are as follows:<list
style="numbers">
<t>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.</t>
</list>Steps 2 and 3 are exactly the same as steps 5 and 6 of <xref
target="simple-http"></xref>, only this times those steps happen as
the result of the Pre-positioning request instead of as the result of a
cache miss.</t>
<t>Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of <xref
target="simple-http"></xref>, 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.</t>
<t></t>
</section>
<section title="Pre-positioned CDNI Metadata Example">
<t>In this section we walk through a simple example
illustrating a scenario of pre-positioning of CDNI metadata, as defined
in <xref target="I-D.jenkins-cdni-problem-statement"></xref>,
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
<xref target="recurse"></xref>. 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). </t>
<t><figure anchor="meta-pre-positioning"
title="Request Trace for CDNI Metadata Pre-positioning">
<artwork><![CDATA[
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)
]]></artwork>
</figure></t>
<t>
The steps illustrated in the figure are as follows:<list
style="numbers">
<t> 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:
<list style="symbols">
<t>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 redirection were used as
in <xref target="DNS-eg"></xref>).</t>
<t> 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).</t>
</list>
</t>
<t>A Content Request occurs as usual.</t>
<t>A CDNI Request Routing Request (RRI REQ) is issued by
operator A CDN, as discussed
in <xref target="recurse"></xref>. 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.</t>
<t>
Operator B's request router issues a CDNI Request Routing
Response (RRI RESP) as in <xref target="recurse"></xref>.</t>
<t> Operator B performs content redirection as
discussed in <xref target="recurse"></xref>.</t>
<t> 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.)</t>
<t> Assuming successful per-request authorization,
serving of Content Data (possibly preceded by inter-CDN
acquisition) proceeds as in <xref target="recurse"></xref>. </t>
</list>
</t>
</section>
<section title="Dynamic CDNI Metadata Acquisition Example">
<t>In this section we walk through a simple example
illustrating a scenario of dynamic CDNI metadata acquisition,
as defined
in <xref target="I-D.jenkins-cdni-problem-statement"></xref>,
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
<xref target="recurse"></xref>), but
dynamic CDNI metadata acquisition is applicable to other
variations of request routing.</t>
<t><figure anchor="meta-pull"
title="Request Trace for Dynamic CDNI Metadata Acquisition">
<artwork><![CDATA[
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)
]]></artwork></figure>
</t>
<t>The steps illustrated in the figure are as follows:</t>
<t><list style="numbers">
<t>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.
(There are alternative ways that this seeding
information may be provided, such as piggybacking on the
CDNI RRI REQ message of Step
3.) </t>
<t>A Content Request arrives as normal.</t>
<t>A Request Routing Interface request occurs as in the
prior example.</t>
<t>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).</t>
<t>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.</t>
<t>Response to the RRI request as normal.</t>
<t>Redirection message is sent to the end user.</t>
<t>A delivery node of Operator B receives the end user
request.</t>
<t>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.</t>
<t>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.</t>
<t>Content is served (possibly preceded by inter-CDN
acquisition) as in <xref target="recurse"></xref>.</t>
</list></t>
</section>
</section>
<section title="Main Interfaces">
<t><xref target="refmod"></xref> 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 <xref
target="I-D.jenkins-cdni-problem-statement"></xref> and <xref
target="I-D.lefaucheur-cdni-requirements"></xref> for some discussion of
the interfaces).</t>
<t>One interface that is not shown in <xref target="refmod"></xref> 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.</t>
<t>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.</t>
<t>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.</t>
<section title="In-Band versus Out-of-Band Interfaces">
<t>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.</t>
<t>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.</t>
<t>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-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.</t>
</section>
<section title="Request Routing Interface">
<t>As illustrated in <xref target="operation"></xref>, 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.</t>
<t>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 <list style="symbols">
<t>The operator’s unique id (operator-id) or distinguished
CDN-domain (operator-domain);</t>
<t>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</t>
<t>NS records for the operator’s set of externally visible
request routers.</t>
</list></t>
<t>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.</t>
<t>We also note that the Request Routing interface plays a key role in
enabling recursive redirection, as illustrated in <xref
target="recurse"></xref>. 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.</t>
</section>
<section title="Logging Interface">
<t>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.</t>
<t>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.</t>
<t>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: <list
style="symbols">
<t hangText="Domain:">Domain – the full domain name of the
origin server</t>
<t hangText="Domain:">IP address – the IP address of the
client making the request</t>
<t hangText="Domain:">End time – the ending time of the
transfer</t>
<t hangText="Domain:">Time zone – any time zone modifier for
the end time</t>
<t hangText="Domain:">Method – the transfer command itself
(e.g., GET, POST, HEAD)</t>
<t hangText="Domain:">URL – the requested URL</t>
<t hangText="Domain:">Version – the protocol version, such
as HTTP/1.0</t>
<t hangText="Domain:">Response – a numeric response code
indicating transfer result</t>
<t hangText="Domain:">Bytes Sent – the number of bytes in
the body sent to the client</t>
<t hangText="Domain:">Request ID – a unique identifier for
this transfer</t>
<t hangText="Domain:">User agent – the user agent, if
supplied</t>
<t hangText="Domain:">Duration – the duration of the
transfer in milliseconds</t>
<t hangText="Domain:">Cached Bytes – the number of body
bytes served from the cache</t>
<t hangText="Domain:">Referrer – the referrer string from
the client, if supplied</t>
</list></t>
<t>Of these, only the Domain field is indirect in the downstream
CDN—it is set to the CDN-domain used by the upstream CDN rather
than the actual origin server. This field could then used to filter
traffic log entries so only those entries matching the upstream CDN
are reported to the corresponding operator.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.
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.</t>
</section>
<section title="Control Interface">
<t>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.</t>
<t>As noted above and in <xref
target="I-D.jenkins-cdni-problem-statement"></xref>, 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Metadata Interface">
<t>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 information
such as the desire to pre-position content rather than fetch it on
demand.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="Deployment Models">
<t>Although the reference model illustrated in <xref
target="refmod"></xref> 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 <xref
target="depmodmesh"></xref>. (Support for arbitrary meshing may or may
not be in the initial scope for the working group, but the model allows
for it.)</t>
<t><figure anchor="depmodmesh"
title="CDNI Deployment Model: CDN Meshing Example">
<artwork><![CDATA[
------------- -----------
/ 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
]]></artwork>
</figure></t>
<t>Although the reference model of <xref target="refmod"></xref> 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 <xref target="operation"></xref>, effective CDNI
deployments can be built without necessarily implementing all four
interfaces.</t>
<t>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.</t>
<t>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 <xref target="depmodcombined"></xref>.</t>
<t><figure anchor="depmodcombined"
title="CDNI Deployment Model: Organization combining CSP & uCDN">
<artwork><![CDATA[##################################### ##################
# # # #
# 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
]]></artwork>
</figure></t>
<t>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 <xref
target="depmodsplit"></xref>, 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).</t>
<t></t>
<t><figure anchor="depmodsplit"
title="CDNI Deployment Model: Organization combining CSP and partial CDN">
<artwork><![CDATA[##################################### ##################
# # # #
# 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
]]></artwork>
</figure></t>
<t>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.</t>
<t>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
illustrated in <xref target="depmodexchange"></xref>, 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 <xref target="depmodexchange"></xref>, we observe that in this
example:</t>
<t><list style="symbols">
<t>each CDN supports a direct CDNI Control interface to every other
CDN</t>
<t>each CDN supports a direct CDNI Metadata interface to every other
CDN</t>
<t>each CDN supports a CDNI Logging interface with the CDN
Exchange</t>
<t>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).</t>
</list></t>
<t><figure anchor="depmodexchange"
title="CDNI Deployment Model: CDN Exchange">
<artwork><![CDATA[
---------- ---------
/ 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
]]></artwork>
</figure></t>
<t>Note that a CDN exchange may alternatively support a different set of
functionality (e.g. Logging only, or Logging and full request routing,
or all the functionality of a CDN including content distribution). All
these options are expected to be allowed by the IETF CDNI
specifications.</t>
<t></t>
</section>
<section anchor="trust" title="Trust Model">
<t>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.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>[Note: this section to be extended in future revision.]</t>
<t> 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 with such concerns. Our focus in this
section is on how CDN interconnection introduces new security
issues not found in the single CDN case. </t>
<t>Many of the security issues that arise in CDNI are related to the
transitivity of trust (or lack thereof) described
in <xref target="trust"></xref>. 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. </t>
<t> 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. </t>
<t>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.)</t>
<t>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.)</t>
<t>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.</t>
</section>
<section title="Contributors">
<t>The following individuals contributed to this document:</t>
<t><list style="symbols">
<t>Francois le Faucheur</t>
<t>Ben Niven-Jenkins</t>
<t>David Ferguson</t>
<t>John Hartman</t>
</list></t>
</section>
<section title="Acknowledgements">
<t>
We thank Huw Jones for his helpful comments on the draft.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3466'?>
<?rfc include='reference.I-D.jenkins-cdni-problem-statement'?>
<?rfc include='reference.I-D.bertrand-cdni-use-cases'?>
<?rfc include='reference.I-D.vandergaast-edns-client-subnet'?>
<?rfc include='reference.I-D.lefaucheur-cdni-requirements'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:11:53 |