RFC 7336
Framework for Content Distribution Network Interconnection (CDNI)
3. Overview of CDNI Operation
To provide a big-picture overview of the various components of CDNI, 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. We give examples using both DNS-based and HTTP-based redirection. We begin with very simple examples and then show how additional capabilities, such as recursive request redirection and content removal, might be added. Before walking through the 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 the more detailed examples illustrate. 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 is the CDN selected by Operator A to deliver content to the end user. The interconnection relationship may be symmetric between these two CDN operators, but each direction can be considered as operating independently of the other; for simplicity, we show the interaction in one direction only.
End User Operator B Operator A | | | | | | | | [Async FCI Push] | (1) | | | | | [MI pre-positioning] | (2) | | | | CONTENT REQUEST | | |-------------------------------------------------->| (3) | | | | | [Sync RI Pull] | (4) | | | | CONTENT REQUEST REDIRECTION | |<--------------------------------------------------| (5) | | | | | | | CONTENT REQUEST | | |------------------------>| | (6) | | | | | [Sync MI Pull] | (7) | | | | | ACQUISITION REQUEST | | X------------------------>| (8) | X | | X CONTENT DATA | | X<------------------------| (9) | | | | CONTENT DATA | | |<------------------------| | (10) | | | : : : : [Other content requests] : : : : | | [CI: Content Purge] | (11) : : : | | [LI: Log exchange] | (12) | | | Figure 2: Overview of Operation The operations shown in the figure are as follows: 1. The dCDN uses the FCI to advertise information relevant to its delivery footprint and capabilities prior to any content requests being redirected.
2. Prior to any content request, the uCDN uses the MI to pre-
position CDNI Metadata to the dCDN, thereby making that metadata
available in readiness for later content requests.
3. A content request from a user agent arrives at the uCDN.
4. The uCDN may use the RI to synchronously request information
from the dCDN regarding its delivery capabilities to decide if
the dCDN is a suitable target for redirection of this request.
5. The uCDN redirects the request to the dCDN by sending some
response (DNS, HTTP) to the user agent.
6. The user agent requests the content from the dCDN.
7. The dCDN may use the MI to synchronously request metadata
related to this content from uCDN, e.g., to decide whether to
serve it.
8. If the content is not already in a suitable cache in the dCDN,
the dCDN may acquire it from the uCDN.
9. The content is delivered to the dCDN from the uCDN.
10. The content is delivered to the user agent by the dCDN.
11. Some time later, perhaps at the request of the CSP (not shown)
the uCDN may use the CI to instruct the dCDN to purge the
content, thereby ensuring it is not delivered again.
12. After one or more content delivery actions by the dCDN, a log of
delivery actions may be provided to the uCDN using the LI.
The following sections show some more specific examples of how these
operations may be combined to perform various delivery, control, and
logging operations across a pair of CDNs.
3.1. Preliminaries
Initially, we assume that there is at least one CSP that 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 assume Operator A provides an Upstream CDN that serves content on behalf of a CSP with CDN-Domain cdn.csp.example. We assume that Operator B provides a Downstream CDN. An end user at some point makes a request for URL http://cdn.csp.example/...rest of URL... It may well be the case that cdn.csp.example is just a CNAME for some other CDN-Domain (such as csp.op-a.example). Nevertheless, the HTTP request in the examples that follow is assumed to be for the example URL above. Our goal is to enable content identified by the above URL to be served by the CDN of Operator B. In the following sections, we will walk through some scenarios in which content is served as well as other CDNI operations such as the removal of content from a Downstream CDN.3.2. Iterative HTTP Redirect Example
In this section, we walk through a simple, illustrative example using HTTP redirection from a uCDN to a dCDN. The example also assumes the use of HTTP redirection inside the 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 the uCDN to dCDN but using DNS for the handling of the request inside each CDN. For this example, we assume that Operators A and B have established an agreement to interconnect their CDNs, with A being Upstream and B being Downstream. The operators agree that a CDN-Domain peer-a.op-b.example will be used as the target of redirections from the uCDN to dCDN. We assume the name of this domain is communicated by some means to each CDN. (This could be established out of band or via a CDNI interface.) 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 used directly by a CSP. We assume the operators also agree on some distinguished CDN-Domain that will be used for inter-CDN acquisition of the CSP's content from the uCDN by the dCDN. In this example, we'll use op-b-acq.op-a.example.
We assume the operators also exchange information regarding which
requests the dCDN is prepared to serve. For example, the 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 CDNI interface.
We assume DNS is configured in the following way:
o The content provider is configured to make Operator A the
authoritative DNS server for cdn.csp.example (or to return a CNAME
for cdn.csp.example for which Operator A is the authoritative DNS
server).
o Operator A is configured so that a DNS request for
op-b-acq.op-a.example returns a Request Router in Operator A.
o Operator B is configured so that a DNS request for
peer-a.op-b.example/cdn.csp.example returns a Request Router in
Operator B.
Figure 3 illustrates how a client request for
http://cdn.csp.example/...rest of URL...
is handled.
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
|302 peer-a.op-b.example/cdn.csp.example |
|<--------------------------------------------------|
|DNS peer-a.op-b.example | |
|------------------------>| |
| |(3) |
|IPaddr of B's Request Router |
|<------------------------| |
| | |
|HTTP peer-a.op-b.example/cdn.csp.example |
|------------------------>| |
| |(4) | |302 node1.peer-a.op-b.example/cdn.csp.example | |<------------------------| | |DNS node1.peer-a.op-b.example | |------------------------>| | | |(5) | |IPaddr of B's Delivery Node | |<------------------------| | | | | |HTTP node1.peer-a.op-b.example/cdn.csp.example | |------------------------>| | | |(6) | | |DNS op-b-acq.op-a.example| | |------------------------>| | | |(7) | |IPaddr of A's Request Router | |<------------------------| | |HTTP op-b-acq.op-a.example | |------------------------>| | | |(8) | |302 node2.op-b-acq.op-a.example | |<------------------------| | |DNS node2.op-b-acq.op-a.example | |------------------------>| | | |(9) | |IPaddr of A's Delivery Node | |<------------------------| | | | | |HTTP node2.op-b-acq.op-a.example | |------------------------>| | | |(10) | |Data | | |<------------------------| |Data | | |<------------------------| | Figure 3: Message Flow for Iterative HTTP Redirection The steps illustrated in the figure are as follows: 1. A DNS resolver for Operator A processes the DNS request for its customer based on CDN-Domain cdn.csp.example. It returns the IP address of a Request Router in Operator A. 2. A Request Router for Operator A processes the HTTP request and recognizes that the end user is best served by another CDN, specifically one provided by Operator B, and so it returns a 302 redirect message for a new URL constructed by "stacking"
Operator B's distinguished CDN-Domain (peer-a.op-b.example) 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.)
3. The end user does a DNS lookup using Operator B's distinguished
CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the
IP address of a Request Router for Operator B. Note that if
request routing within the dCDN was performed using DNS instead
of HTTP redirection, B's DNS resolver would also behave as the
Request Router and directly return the IP address of a delivery
node.
4. The Request Router for Operator B processes the HTTP request and
selects a suitable delivery node to serve the end-user request,
and it returns a 302 redirect message for a new URL constructed
by replacing the hostname with a subdomain of the Operator B's
distinguished CDN-Domain that points to the selected delivery
node.
5. The end user does a DNS lookup using Operator B's delivery node
subdomain (node1.peer-a.op-b.example). B's DNS resolver returns
the IP address of the delivery node.
6. The end user requests the content from B's delivery node. In
the case of a cache hit, steps 6, 7, 8, 9, and 10 below do not
happen, and the content data is directly returned by the
delivery node to the end user. In the case of a cache miss, the
content needs to be acquired by the dCDN from the uCDN (not the
CSP). The distinguished CDN-Domain peer-a.op-b.example
indicates to the dCDN that this content is to be acquired from
the uCDN; stripping the CDN-Domain reveals the original CDN-
Domain cdn.csp.example, and the 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.example).
7. Operator A's DNS resolver processes the DNS request and returns
the IP address of a Request Router in Operator A.
8. The Request Router for Operator A processes the HTTP request
from Operator B's delivery node. Operator A's 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.example). (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 with a subdomain of
the Operator A's distinguished inter-CDN acquisition domain that
points to the selected delivery node.
9. Operator A's DNS resolver processes the DNS request and returns
the IP address of the delivery node in Operator A.
10. Operator B requests (acquires) the content from Operator A.
Although not shown, 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.
The main advantage of this design is that it is simple: each CDN need
only know the 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 need 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 need 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.example) 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 accommodate the domains involved in the
CDN redirection. These problems are generally solvable, but the
solutions complicate the example, so we do not discuss them further
in this document.
We note that this example begins to illustrate some of the interfaces
that may be required for CDNI, but it does not require all of them.
For example, obtaining information from a dCDN regarding the set of
client IP addresses or geographic regions it might be able to serve
is an aspect of request routing (specifically of the CDNI Footprint &
Capabilities Advertisement interface). Important configuration
information such as the distinguished names used for redirection and
inter-CDN acquisition could also be conveyed via a CDNI interface (e.g., perhaps the CDNI Control interface). 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 information was provided "in-band" in this example by means of the URI handed to the client in the HTTP 302 response. The example also assumes that the CSP does not require any distribution policy (e.g., time window or geo-blocking) or delivery processing to be applied by the interconnected CDNs. Hence, there is no explicit CDNI Metadata interface invoked in this example. There is also no explicit CDNI Logging interface discussed in this example. We also note that the step of deciding when a request should be redirected to the dCDN rather than served by the 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. This example uses the "iterative" CDNI request redirection approach. That is, a uCDN performs part of the request redirection function by redirecting the client to a Request Router in the dCDN, which then performs the rest of the redirection function by redirecting to a suitable Surrogate. 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 redirection effectively coalesces these two successive HTTP redirections into a single one, sending the end user directly to the right delivery node in the dCDN. This "recursive" CDNI request routing approach is discussed in the next section. While the example above uses HTTP, the iterative HTTP redirection mechanism would work over HTTPS in a similar fashion. In order to make sure an end user's HTTPS request is not downgraded to HTTP along the redirection path, it is necessary for every Request Router along the path from the initial uCDN Request Router to the final Surrogate in the dCDN to respond to an incoming HTTPS request with an HTTP redirect containing an HTTPS URL. It should be noted that using HTTPS will have the effect of increasing the total redirection process time and increasing the load on the Request Routers, especially when the redirection path includes many redirects and thus many Secure Socket Layer/Transport Layer Security (SSL/TLS) sessions. In such cases, a recursive HTTP redirection mechanism, as described in an example in the next section, might help to reduce some of these issues.
3.3. Recursive HTTP Redirection Example
The following example builds on the previous one to illustrate the use of the request routing interface (specifically, the CDNI Request Routing Redirection interface) to enable "recursive" CDNI request routing. We build on the HTTP-based redirection approach because it illustrates the principles and benefits clearly, but it is equally possible to perform recursive redirection when DNS-based redirection is employed. 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 the uCDN to dCDN. We assume that the operators agree on some distinguished CDN-Domain that will be used for inter-CDN acquisition of the CSP's content by dCDN. In this example, we'll use op-b-acq.op-a.example. We assume the operators also exchange information regarding which requests the dCDN is prepared to serve. For example, the 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. We assume DNS is configured in the following way: o The content provider is configured to make Operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which Operator A is the authoritative DNS server). o Operator A is configured so that a DNS request for op-b-acq.op-a.example returns a Request Router in Operator A. o Operator B is configured so that a request for node1.op-b.example/ cdn.csp.example returns the IP address of a delivery node. Note that there might be a number of such delivery nodes. Figure 3 illustrates how a client request for http://cdn.csp.example/...rest of URL... is handled.
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
| |RR/RI REQ cdn.csp.example|
| |<------------------------|
| | |
| |RR/RI RESP node1.op-b.example
| |------------------------>|
| | |(3)
|302 node1.op-b.example/cdn.csp.example |
|<--------------------------------------------------|
|DNS node1.op-b.example | |
|------------------------>| |
| |(4) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP node1.op-b.example/cdn.csp.example |
|------------------------>| |
| |(5) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(6)
| |IPaddr of A's Request Router
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(7)
| |302 node2.op-b-acq.op-a.example | |<------------------------| | |DNS node2.op-b-acq.op-a.example | |------------------------>| | | |(8) | |IPaddr of A's Delivery Node | |<------------------------| | | | | |HTTP node2.op-b-acq.op-a.example | |------------------------>| | | |(9) | |Data | | |<------------------------| |Data | | |<------------------------| | Figure 4: Message Flow for Recursive HTTP Redirection The steps illustrated in the figure are as follows: 1. A DNS resolver for Operator A processes the DNS request for its customer based on CDN-Domain cdn.csp.example. It returns the IP address of a Request Router in Operator A. 2. A Request Router for Operator A processes the HTTP request and recognizes that the end user is best served by another CDN -- specifically one provided by Operator B -- so it queries the CDNI Request Routing Redirection interface of Operator B, providing a set of information about the request including the URL requested. Operator B replies with the DNS name of a delivery node. 3. Operator A returns a 302 redirect message for a new URL obtained from the RI. 4. The end user does a DNS lookup using the hostname of the URL just provided (node1.op-b.example). 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 RI, there should not be any further redirection here (in contrast to the iterative method described above.) 5. The end user requests the content from B's delivery node, potentially resulting in a cache miss. In the case of a cache miss, the content needs to be acquired from the uCDN (not the CSP.) The distinguished CDN-Domain op-b.example indicates to the dCDN that this content is to be acquired from another CDN; stripping the CDN-Domain reveals the original CDN-Domain cdn.csp.example. The 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.example).
6. Operator A's DNS resolver processes the DNS request and returns
the IP address of a Request Router in Operator A.
7. The Request Router for Operator A processes the HTTP request from
Operator B's delivery node. Operator A's 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.example). (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 the uCDN to serve the inter-CDN
acquisition request and returns a 302 redirect message for a new
URL constructed by replacing the hostname with a subdomain of the
Operator A's distinguished inter-CDN acquisition domain that
points to the selected delivery node.
8. Operator A recognizes that the DNS request is from a peer CDN
rather than an end user (due to the internal CDN-Domain) and so
returns the address of a delivery node. (Note that without this
specially defined internal domain, Operator A would be at risk of
redirecting the request back to Operator B, resulting in an
infinite loop.)
9. Operator B requests (acquires) the content from Operator A.
Operator A serves content for the requested CDN-Domain to the
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 the
dCDN.
Recursive redirection has the advantage (over iterative redirection)
of being more transparent from the end user's perspective but the
disadvantage of each CDN exposing more of its internal structure (in
particular, the addresses of edge caches) to peer CDNs. By contrast,
iterative redirection does not require the dCDN to expose the
addresses of its edge caches to the uCDN.
This example happens to use HTTP-based redirection in both CDN A and CDN B, but a similar example could be constructed using DNS-based redirection in either CDN. Hence, the key point to take away here is simply that the end user only sees a single redirection of some type, as opposed to the pair of redirections in the prior (iterative) example. The use of the RI requires that the request routing mechanism be appropriately configured and bootstrapped, which is not shown here. More discussion on the bootstrapping of interfaces is provided in Section 43.4. Iterative DNS-Based Redirection Example
In this section we walk through a simple example using DNS-based redirection for request redirection from the uCDN to the dCDN (as well as for request routing inside the dCDN and the 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 has to learn the set of requests that the dCDN is willing or able to serve (e.g., which client IP address prefixes or geographic regions are part of the dCDN footprint). We assume Operator B has and makes 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 Autonomous System (AS) number assigned to B, is one easy way to achieve that.) Also, Operator A obtains 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.example, must be assigned for inter-CDN acquisition. We assume DNS is configured in the following way: o The CSP is configured to make Operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which Operator A is the authoritative DNS server). o When uCDN sees a request best served by the dCDN, it returns CNAME and NS records for "b.cdn.csp.example", where "b" is the unique identifier assigned to Operator B. (It may, for example, be an AS number assigned to Operator B.)
o The dCDN is configured so that a request for "b.cdn.csp.example"
returns a delivery node in the dCDN.
o The uCDN is configured so that a request for
"op-b-acq.op-a.example" returns a delivery node in the uCDN.
Figure 5 depicts the exchange of DNS and HTTP requests. The main
differences from Figure 3 are the lack of HTTP redirection and
transparency to the end user.
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|CNAME b.cdn.csp.example | |
|<--------------------------------------------------|
| | |
|DNS b.cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
|NS records for b.cdn.csp.example + |
|Glue AAAA/A records for b.cdn.csp.example |
|<--------------------------------------------------|
| | |
|DNS b.cdn.csp.example | |
|------------------------>| |
| |(3) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP cdn.csp.example | |
|------------------------>| |
| |(4) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(5)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(6)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 5: Message Flow for DNS-Based Redirection
The steps illustrated in the figure are as follows:
1. The Request Router for Operator A processes the DNS request for
CDN-Domain cdn.csp.example and recognizes that the end user is
best served by another CDN. (This may depend on the IP address
of the user's LDNS 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.example).
2. The end user sends a DNS query for the modified CDN-Domain (i.e.,
b.cdn.csp.example) to Operator A's DNS server. The Request
Router for Operator A processes the DNS request and returns a
delegation to b.cdn.csp.example by sending an NS record plus glue
records pointing to Operator B's DNS server. (This extra step is
necessary since typical DNS implementation won't follow an NS
record when it is sent together with a CNAME record, thereby
necessitating a two-step approach.)
3. The end user sends a DNS query for the modified CDN-Domain (i.e.,
b.cdn.csp.example) to Operator B's DNS server, using the NS and
AAAA/A records received in step 2. This causes B's Request
Router to respond with a suitable delivery node.
4. The end user requests the content from B's delivery node. The
requested URL contains the name cdn.csp.example. (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.example).
5. 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.
6. 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.
The advantages of this approach are that it is more transparent to
the end user and requires fewer round trips than HTTP-based
redirection (in its worst case, i.e., when none of the needed DNS
information is cached). A potential problem 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, the uCDN will only obtain the address of the client's LDNS 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, and assuming the uCDN is capable of detecting that situation, 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 for CDNI since the LDNS is likely in the same network as the dCDN serves. 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 CDNI Footprint & Capabilities Advertisement 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 CDNI Logging interface discussed in this example.3.4.1. Notes on Using DNSSEC
Although it is possible to use DNSSEC in combination with the Iterative DNS-based Redirection mechanism explained above, it is important to note that the uCDN might have to sign records on the fly, since the CNAME returned, and thus the signature provided, can potentially be different for each incoming query. Although there is nothing preventing a uCDN from performing such on-the-fly signing, this might be computationally expensive. In the case where the number of dCDNs, and thus the number of different CNAMEs to return, is relatively stable, an alternative solution would be for the uCDN to pre-generate signatures for all possible CNAMEs. For each incoming query, the uCDN would then determine the appropriate CNAME and return it together with the associated pre-generated signature. Note: In the latter case, maintaining the serial number and signature of Start of Authority (SOA) might be an issue since, technically, it should change every time a different CNAME is used. However, since,
in practice, direct SOA queries are relatively rare, a uCDN could defer incrementing the serial number and resigning the SOA until it is queried and then do it on-the-fly. Note also that the NS record and the glue records used in step 2 in the previous section should generally be identical to those of their authoritative zone managed by Operator B. Even if they differ, this will not make the DNS resolution process fail, but the client DNS server will prefer the authoritative data in its cache and use it for subsequent queries. Such inconsistency is a general operational issue of DNS, but it may be more important for this architecture because the uCDN (Operator A) would rely on the consistency to make the resulting redirection work as intended. In general, it is the administrator's responsibility to make them consistent.3.5. Dynamic Footprint Discovery Example
There could be 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.example | | |-------------------------------------------------->| | | |(1) | | RI REQ op-b.example | | |<------------------------| | | |(2) | | RI REPLY | | |------------------------>| | | |(3) |CNAME b.cdn.csp.example | | |NS records for b.cdn.csp.example | |<--------------------------------------------------| |DNS b.cdn.csp.example | | |------------------------>| | | |(2) | |IPaddr of B's Delivery Node | |<------------------------| | |HTTP cdn.csp.example | | |------------------------>| | | |(3) | | |DNS op-b-acq.op-a.example| | |------------------------>| | | |(4) | |IPaddr of A's Delivery Node | |<------------------------| | |HTTP op-b-acq.op-a.example | |------------------------>| | | |(5) | |Data | | |<------------------------| |Data | | |<------------------------| | Figure 6: Message Flow for Dynamic Footprint Discovery This example differs from the one in Figure 5 only in the addition of an RI request (step 2) and corresponding response (step 3). The RI 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 RR/RI REPLY messages that are not
in direct response to a corresponding RR/RI 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 RI response, it is now able to determine that Operator B's CDN is an appropriate dCDN for this request and therefore a valid candidate dCDN to consider in its redirection decision. If that dCDN is selected, the redirection and serving of the request proceeds as before (i.e., in the absence of dynamic footprint discovery).3.6. Content Removal Example
The following example illustrates how the CDNI Control interface may be used to achieve pre-positioning of an item of content in the dCDN. 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 CI to request that content identified by a particular URL be removed from dCDN. The following diagram illustrates the operation. It should be noted that a uCDN will typically not know whether a dCDN has cached a given content item; however, it may send the content removal request to make sure no cached versions remain to satisfy any contractual obligations it may have. End User Operator B Operator A | |CI purge cdn.csp.example/... | |<------------------------| | | | | |CI OK | | |------------------------>| | | | Figure 7: Message Flow for Content Removal The CI is used to convey the request from the uCDN to the 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.example/cdn.csp.example/... 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 the dCDN.
3.7. Pre-positioned Content Acquisition Example
The following example illustrates how the CI may be used to pre- position an item of content in the dCDN. In this example, Operator A uses the CDNI Metadata interface to request that content identified by a particular URL be pre-positioned into Operator B CDN. End User Operator B Operator A | |CI pre-position cdn.csp.example/... | |<------------------------| | | |(1) | |CI OK | | |------------------------>| | | | | |DNS op-b-acq.op-a.example| | |------------------------>| | | |(2) | |IPaddr of A's Delivery Node | |<------------------------| | |HTTP op-b-acq.op-a.example | |------------------------>| | | |(3) | |Data | | |<------------------------| |DNS cdn.csp.example | | |--------------------------------------------->| | | |(4) |IPaddr of A's Request Router | |<---------------------------------------------| |HTTP cdn.csp.example| | |--------------------------------------------->| | | |(5) |302 peer-a.op-b.example/cdn.csp.example | |<---------------------------------------------| |DNS peer-a.op-b.example | |------------------->| | | |(6) | |IPaddr of B's Delivery Node | |<-------------------| | |HTTP peer-a.op-b.example/cdn.csp.example | |------------------->| | | |(7) | |Data | | |<-------------------| | Figure 8: Message Flow for Content Pre-Positioning
The steps illustrated in the figure are as follows: 1. Operator A uses the CI to request that Operator B pre-position a particular content item identified by its URL. Operator B responds by confirming that it is willing to perform this operation. Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only this time those steps happen as the result of the Pre-positioning request instead of as the result of a cache miss. Steps 4, 5, 6, and 7 are exactly the same as steps 1, 2, 3, and 4 of Figure 3, only this time, Operator B's CDN can serve the end-user request without triggering dynamic content acquisition, since the content has been pre-positioned in the 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-positioned; however, such intra-CDN dynamic acquisition would not involve the uCDN.3.8. Asynchronous CDNI Metadata Example
In this section, we walk through a simple example illustrating a scenario of asynchronously exchanging CDNI Metadata, where 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, Asynchronous exchange of CDNI Metadata is 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 | | | | |CI pre-position (Trigger)| | |<------------------------|(1) | | | | |CI OK | | |------------------------>|(2) | | | | |MI pull REQ | | |------------------------>|(3) | | | | |MI metadata REP |(4) | | | | | | | CONTENT REQUEST | | |-------------------------------------------------->|(5) | | | | | RI REQ | | |<------------------------|(6) | | | | | RI RESP | | |------------------------>|(7) | | | | CONTENT REDIRECTION | | |<--------------------------------------------------|(8) | | | | CONTENT REQUEST | | |------------------------>|(9) | | | | : : : | CONTENT DATA | | |<------------------------| |(10) Figure 9: Message Flow for Asynchronous CDNI Metadata The steps illustrated in the figure are as follows: 1. Operator A uses the CI to trigger the signaling of the availability of CDNI Metadata to Operator B. 2. Operator B acknowledges the receipt of this Trigger. 3. Operator B requests the latest metadata from Operator A using the MI.
4. Operator A replies with the requested metadata. This document
does not constrain how the CDNI Metadata information is actually
represented. For the purposes of this example, we assume that
Operator A provides CDNI Metadata to Operator B indicating that:
* this CDNI Metadata is applicable to any content referenced by
some CDN-Domain.
* 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).
5. A Content Request occurs as usual.
6. A CDNI Request Routing Redirection request (RI REQ) is issued by
Operator A's CDN, as discussed in Section 3.3. Operator B's
Request Router can access the CDNI Metadata that are relevant to
the requested content and that have been pre-positioned as per
Steps 1-4, which may or may not affect the response.
7. Operator B's Request Router issues a CDNI Request Routing
Redirection response (RI RESP) as in Section 3.3.
8. Operator B performs content redirection as discussed in
Section 3.3.
9. On receipt of the Content Request by the end user, the delivery
node detects that previously acquired 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.)
10. Assuming successful per-request authorization, serving of
Content Data (possibly preceded by inter-CDN acquisition)
proceeds as in Section 3.3.
3.9. Synchronous CDNI Metadata Acquisition Example
In this section we walk through a simple example illustrating a
scenario of Synchronous CDNI Metadata acquisition, 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 | | | | CONTENT REQUEST | | |-------------------------------------------------->|(1) | | | | | RI REQ | | (2)|<------------------------| | | | | | MI REQ | | (3)|------------------------>| | | MI RESP | | |<------------------------|(4) | | | | | RI RESP | | |------------------------>|(5) | | | | | | | CONTENT REDIRECTION | | |<--------------------------------------------------|(6) | | | | CONTENT REQUEST | | |------------------------>|(7) | | | | | | MI REQ | | (8)|------------------------>| | | MI RESP | | |<------------------------|(9) | | | : : : | CONTENT DATA | | |<------------------------| |(10) Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition The steps illustrated in the figure are as follows: 1. A Content Request arrives as normal. 2. An RI request occurs as in the prior example.
3. On receipt of the CDNI Request Routing Request, Operator B's CDN
initiates Synchronous acquisition of CDNI Metadata that are
needed for routing of the end-user request. We assume the URI
for the a metadata server is known ahead of time through some
out-of-band means.
4. On receipt of a CDNI Metadata 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. (In a simple case, the metadata could simply be an
allow or deny response for this particular request.)
5. Response to the RI request as normal.
6. Redirection message is sent to the end user.
7. A delivery node of Operator B receives the end user request.
8. The delivery node Triggers dynamic acquisition of additional
CDNI Metadata that are needed to process the end-user content
request. Note that there may exist cases where this step need
not happen, for example, because the metadata were already
acquired previously.
9. 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.
10. Content is served (possibly preceded by inter-CDN acquisition)
as in Section 3.3.
3.10. Content and Metadata Acquisition with Multiple Upstream CDNs
A single dCDN may receive end-user requests from multiple uCDNs.
When a dCDN receives an end-user request, it must determine the
identity of the uCDN from which it should acquire the requested
content.
Ideally, the acquisition path of an end-user request will follow the
redirection path of the request. The dCDN should acquire the content
from the same uCDN that redirected the request.
Determining the acquisition path requires the dCDN to reconstruct the
redirection path based on information in the end-user request. The
method for reconstructing the redirection path differs based on the
redirection approach: HTTP or DNS.
With HTTP-redirection, the rewritten URI should include sufficient information for the dCDN to directly or indirectly determine the uCDN when the end-user request is received. The HTTP-redirection approach can be further broken-down based on the how the URL is rewritten during redirection: HTTP redirection with or without Site Aggregation. HTTP redirection with Site Aggregation hides the identity of the original CSP. HTTP redirection without Site Aggregation does not attempt to hide the identity of the original CSP. With both approaches, the rewritten URI includes enough information to identify the immediate neighbor uCDN. With DNS-redirection, the dCDN receives the published URI (instead of a rewritten URI) and does not have sufficient information for the dCDN to identify the appropriate uCDN. The dCDN may narrow the set of viable uCDNs by examining the CDNI Metadata from each to determine which uCDNs are hosting metadata for the requested content. If there is a single uCDN hosting metadata for the requested content, the dCDN can assume that the request redirection is coming from this uCDN and can acquire content from that uCDN. If there are multiple uCDNs hosting metadata for the requested content, the dCDN may be ready to trust any of these uCDNs to acquire the content (provided the uCDN is in a position to serve it). If the dCDN is not ready to trust any of these uCDNs, it needs to ensure via out of band arrangements that, for a given content, only a single uCDN will ever redirect requests to the dCDN. Content acquisition may be preceded by content metadata acquisition. If possible, the acquisition path for metadata should also follow the redirection path. Additionally, we assume metadata is indexed based on rewritten URIs in the case of HTTP redirection and is indexed based on published URIs in the case of DNS-redirection. Thus, the RI and the MI are tightly coupled in that the result of request routing (a rewritten URI pointing to the dCDN) serves as an input to metadata lookup. If the content metadata includes information for acquiring the content, then the MI is also tightly coupled with the acquisition interface in that the result of the metadata lookup (an acquisition URL likely hosted by the uCDN) should serve as input to the content acquisition.
(page 38 continued on part 3)
