| Network Working Group | B. Davie, Ed. |
| Internet-Draft | Cisco Systems, Inc. |
| Intended status: Informational | L. . Peterson, Ed. |
| Expires: January 03, 2012 | Verivue, Inc. |
| July 02, 2011 |
Framework for CDN Interconnection
draft-davie-cdni-framework-00
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.
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].
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 03, 2012.
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.
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.
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.
Figure 1 (reproduced from [I-D.jenkins-cdni-problem-statement]) illustrates the basic model of operation with which this document is concerned.
--------
/ \
| 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
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.
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.
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.
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.
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.
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.
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)
| | |
The operations shown in the Figure are as follows:
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.
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 (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.
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.
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:
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 |
|<------------------------| |
|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 | |
|<------------------------| |
The steps illustrated in the figure are as follows:
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 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.
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:
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)
| |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 | |
|<------------------------| |
The steps illustrated in the figure are as follows:
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.
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.
DNS must be configured in the following way:
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.
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 | |
|<------------------------| |
The steps illustrated in the figure are as follows:
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 discussed in this example.
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 | |
|<------------------------| |
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).
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)
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. 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.
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.
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 | |
|<------------------------| |
The steps illustrated in the figure are as follows: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 2 and 3 are exactly the same as steps 5 and 6 of
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.
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).
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)
The steps illustrated in the figure are as follows:
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.
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)
The steps illustrated in the figure are as follows:
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.
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-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.
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
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.
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:
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.
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. 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.
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.
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.
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.
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.)
------------- -----------
/ 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
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.
##################################### ##################
# # # #
# 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
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).
##################################### ################## # # # # # 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
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 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:
---------- ---------
/ 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
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.
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.
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.
This memo includes no request to IANA.
[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 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.
The following individuals contributed to this document:
We thank Huw Jones for his helpful comments on the draft.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3466] | Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003. |
| [I-D.jenkins-cdni-problem-statement] | Niven-Jenkins, B, Faucheur, F and N Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", Internet-Draft draft-jenkins-cdni-problem-statement-02, March 2011. |
| [I-D.bertrand-cdni-use-cases] | Bertrand, G, Stephan, E, Watson, G, Burbridge, T, Eardley, P and K Ma, "Use Cases for Content Delivery Network Interconnection", Internet-Draft draft-bertrand-cdni-use-cases-02, July 2011. |
| [I-D.vandergaast-edns-client-subnet] | Contavalli, C, Gaast, W, Leach, S and D Rodden, "Client subnet in DNS requests", Internet-Draft draft-vandergaast-edns-client-subnet-00, January 2011. |
| [I-D.lefaucheur-cdni-requirements] | Leung, K, Lee, Y, Faucheur, F, Viveganandhan, M and G Watson, "Content Distribution Network Interconnection (CDNI) Requirements", Internet-Draft draft-lefaucheur-cdni-requirements-02, July 2011. |