RFC 7336
Framework for Content Distribution Network Interconnection (CDNI)
Framework for Content Distribution Network Interconnection (CDNI) 💖
Okay bestie, this is RFC 7336 from the IETF, the Internet Engineering Task Force 🌸 It's an Informational doc, which means it's published for info and is not an Internet Standards Track spec. It came out in August 2014 with ISSN 2070-1721 ✨ Three authors wrote it: L. Peterson from Akamai Technologies, Inc., B. Davie from VMware, Inc., and R. van Brandenburg (the Ed. means editor 🧚) from TNO. The big news is that it obsoletes RFC 3466 😭 It doesn't list any Updates, so nothing gets updated by it.
Abstract
Okay so this doc gives you the big picture of Content Distribution Network Interconnection (CDNI) 🦋 It explains the problem space and how all the different pieces of connecting CDNs fit together. CDNI needs interfaces and mechanisms for stuff like request routing, distribution metadata exchange, and logging information exchange across CDNs. The goal is to say what each interface needs to accomplish and how they all work together, while leaving the detailed specs to other docs. This document, together with RFC 6707, obsoletes RFC 3466, and it's giving full main character energy 👑
Status of This Memo
Real talk, this is not an Internet Standards Track spec. It's just published for informational purposes 🎀
It is a product of the IETF, so it does represent the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the deets 💅
If you want the current status, any errata, or to give feedback, go to http://www.rfc-editor.org/info/rfc7336 ✨
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🙈 Any Code Components pulled out of this document have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥
Table of Contents
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Reference Model ............................................6
1.3. Structure of This Document ................................10
2. Building Blocks ................................................10
2.1. Request Redirection .......................................10
2.1.1. DNS Redirection ....................................10
2.1.2. HTTP Redirection ...................................12
3. Overview of CDNI Operation .....................................12
3.1. Preliminaries .............................................14
3.2. Iterative HTTP Redirect Example ...........................15
3.3. Recursive HTTP Redirection Example ........................21
3.4. Iterative DNS-Based Redirection Example ...................25
3.4.1. Notes on Using DNSSEC ..............................28
3.5. Dynamic Footprint Discovery Example .......................29
3.6. Content Removal Example ...................................31
3.7. Pre-positioned Content Acquisition Example ................32
3.8. Asynchronous CDNI Metadata Example ........................33
3.9. Synchronous CDNI Metadata Acquisition Example .............35
3.10. Content and Metadata Acquisition with Multiple
Upstream CDNs ............................................37
4. Main Interfaces ................................................38
4.1. In-Band versus Out-of-Band Interfaces .....................39
4.2. Cross-Interface Concerns ..................................40
4.3. Request Routing Interfaces ................................40
4.4. CDNI Logging Interface ....................................41
4.5. CDNI Control Interface ....................................43
4.6. CDNI Metadata Interface ...................................43
4.7. HTTP Adaptive Streaming Concerns ..........................44
4.8. URI Rewriting .............................................46
5. Deployment Models ..............................................47
5.1. Meshed CDNs ...............................................47
5.2. CSP Combined with CDN .....................................48
5.3. CSP Using CDNI Request Routing Interface ..................49
5.4. CDN Federations and CDN Exchanges .........................50
6. Trust Model ....................................................53
7. Privacy Considerations .........................................54
8. Security Considerations ........................................55
8.1. Security of CDNI Interfaces ...............................56
8.2. Digital Rights Management .................................56
9. Contributors ...................................................56
10. Acknowledgements ..............................................57
11. Informative References ........................................571. Introduction ✨
Okay so this section sets up the whole overview 🌈 It covers the parts you need to interconnect CDNs, and it builds on the problem statement and use cases from [RFC6770] and [RFC6707]. It describes the interfaces and mechanisms in general terms and shows how they fit together into a full system for CDN Interconnection. The detailed specs are left to other docs, but this one has tons of message flow examples to show how interconnected CDNs run. Those examples are just illustrative, not prescriptive, so don't treat them as the rulebook 🎀
[RFC3466] uses different terminology and models for "Content (distribution) Internetworking (CDI)" 🙈 It's also less prescriptive when it comes to interfaces. To avoid confusion, this document obsoletes [RFC3466] 💅
1.1. Terminology
This doc uses the core terminology from [RFC6707] 💖 It also adds some new terms, so let's go through them 🦋
CDN-Domain: This is a hostname (a Fully Qualified Domain Name, or FQDN) at the start of a URL, not counting the port and scheme. It represents a set of content served by a given CDN. For example, in the URL http://cdn.csp.example/...rest of URL..., the CDN-Domain is cdn.csp.example. Its big job is to identify a region (a subset) of the URI space that various CDNI rules and policies apply to. For instance, a record of CDNI Metadata might be defined for the set of resources that correspond to some CDN-Domain 🧚
Distinguished CDN-Domain: This is a CDN-Domain that a CDN allocates to talk to a peer CDN, but it never shows up in client requests 🌸 These can be used for inter-CDN acquisition or as redirection targets, and they let a CDN tell a request from a peer CDN apart from an end-user request 👑
Delivering CDN: This is the CDN that ultimately delivers a piece of content to the end user. It's the last one in a potential sequence of Downstream CDNs 💜
Iterative CDNI Request Redirection: When an Upstream CDN decides to redirect a request to a Downstream CDN, it can base that redirect purely on its own local decision. It doesn't have to think about how the Downstream CDN might redirect the user agent after that. In this case, the Upstream CDN sends the request to the Request Routing system in the Downstream CDN, and that system decides how to redirect it. This is called "Iterative" CDNI Request Redirection 🔥
Recursive CDNI Request Redirection: When an Upstream CDN decides to redirect a request to a Downstream CDN, it can query the Downstream CDN's Request Routing system through the CDNI Request Routing Redirection interface. (It can also use info cached from earlier similar queries.) That tells it how the Downstream CDN wants the request redirected 👀 This lets the Upstream CDN factor the Downstream response into how it redirects the user agent, and it's called "Recursive" CDNI Request Redirection ✨ Also, the Downstream CDN can choose to send the request straight to a Surrogate inside the Downstream CDN, or to any other element in the Downstream CDN (or in another CDN), so it gets handled properly 🫶
Synchronous CDNI operations: These are operations between CDNs that happen while a user request is being served. That means from the moment the user agent starts trying to get content until the moment that request is served 😭
Asynchronous CDNI operations: These are operations between CDNs that happen independently of any given user request, like advertising footprint info or pre-positioning content for later delivery 🌈
Trigger Interface: This is a subset of the CDNI Control interface that includes operations to pre-position, revalidate, and purge both metadata and content. These operations are usually called in response to some action (a Trigger) by the Content Service Provider (CSP) on the Upstream CDN 🎀
We also sometimes say uCDN and dCDN as shorthand for Upstream CDN and Downstream CDN (see [RFC6707]) 💅
Lastly, a few spots in this doc talk about a CDN footprint. For what actually counts as a CDN footprint, check out [FOOTPRINT-CAPABILITY] 🧚✨
1.2. Reference Model
okay bestie, this section is where we get the big picture 🗺️✨ the doc uses the reference model in Figure 1, which is basically an expanded version of the one from [RFC6707]. the glow-up is that the expanded model splits the Request Routing interface into two distinct parts: the Request Routing Redirection interface and the Footprint & Capabilities Advertisement interface 💅 (more on that below, don't worry)
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | | CI | | +-------------+ |
|******* Control |<======|====|=======>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *|
|* +------*------+ | | LI | | +------*------+ *|
|* ***** Logging |<======|====|=======>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | | | | * * * *|
.....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*...
. |* * | |<======|====|=======>| | * *| .
. |* * | Req-Routing | | |FCI | | | Req-Routing | * *| .
. |* * *** |<======|====|=======>| |** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . | | | * * *| .
. |* * * +-------------+ |. | MI | | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ...Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|***********************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. ---------------------- ---------*------------ .
. * .
. * Delivery .
. * .
. +--*---+ .
...............Request............................| User |..Request..
| Agent|
+------+
<==> interfaces inside the scope of CDNI
**** and .... interfaces outside the scope of CDNI
Figure 1: CDNI Expanded Model and CDNI Interfacesngl the diagram looks chaotic but it's giving organized 🦋 some of the interfaces are "out of scope" for the CDNI WG, which means there's no need to define brand new protocols for them 🙈 BUT we still have to mention them, because otherwise you can't explain how CDNI works overall 🧚
also, while we usually only draw one Upstream CDN serving a given CSP, it's totally possible for multiple uCDNs to serve a single CSP 👑 honestly this is already happening, because a single CSP can currently hand off its content delivery to more than one CDN 💜
here are the five CDNI interfaces in brief (these are paraphrased from [RFC6707], and we go deeper in Section 4 🎀):
- CDNI Control interface (CI): operations to bootstrap and parameterize the other CDNI interfaces, plus operations to pre-position, revalidate, and purge both metadata and content. The latter subset is sometimes collectively called the "Trigger interface" ⚡
- CDNI Request Routing interface: operations to determine which CDN (and optionally which Surrogate within that CDN) is going to serve end-user requests. This one is really a logical bundle of two separate but related interfaces:
- CDNI Footprint & Capabilities Advertisement interface (FCI): asynchronous operations to exchange routing information (for example, the network footprint and capabilities served by a given CDN) that enables CDN selection for later user requests; and
- CDNI Request Routing Redirection interface (RI): synchronous operations to select a delivery CDN (Surrogate) for a given user request.
- CDNI Metadata interface (MI): operations to communicate the metadata that governs how content is delivered by interconnected CDNs. Examples include geo-blocking directives, availability windows, access control mechanisms, and purge directives 🍓 It may include a combination of:
- asynchronous operations to exchange metadata that governs later user requests for content; and
- synchronous operations that govern behavior for a given user request for content.
- CDNI Logging interface (LI): operations that let interconnected CDNs exchange relevant activity logs 📊 It may include a combination of:
- real-time exchanges, suitable for runtime traffic monitoring; and
- offline exchanges, suitable for analytics and billing.
the line between the Trigger-based operations in the CDNI Control interface and the CDNI Metadata interface is kinda arbitrary, not gonna lie 🙃 in both cases, the info going from the Upstream CDN to the Downstream CDN can broadly be seen as metadata describing how content should be managed by the Downstream CDN. for example, the info the CI conveys to pre-position, revalidate, or purge is similar to the info the MI conveys when it posts updated metadata. even a CI purge could be viewed as a metadata update for that content, because purge simply says the availability window for the named content ends now ⏰ the two interfaces have a lot in common, so at minimum there will need to be a consistent data model spanning both 💖
but here's the difference that matters 👀 it's about what the uCDN knows about whether the dCDN successfully applied the metadata. with the CI, when the Downstream CDN returns a successful status message, that guarantees the operation was completed. for example, the content has been purged or pre-positioned ✅ this means the dCDN takes responsibility for having successfully completed the requested operation. the MI is different 🫠 metadata passed between CDNs over the MI carries no such completion guarantee. success means the metadata was received, but you can't infer exactly when it will take effect in the Downstream CDN, only that it will take effect eventually. this is because it's really hard to globally synchronize metadata updates with end-user requests that are currently in progress (or that can't be told apart from requests in progress) 😭 and honestly? a CDN won't be seen as a trusted peer if "eventually" turns into an indefinite period of time 💀 so the acceptance of responsibility just can't be defined as crisply for the MI.
last but not least, there's a practical issue that affects ALL of the CDNI interfaces: whether or not to optimize CDNI for HTTP Adaptive Streaming (HAS) 🎬 we point out HAS-specific issues throughout this document, but if you want a more thorough treatment of the topic, check out [RFC6983] ✨
1.3. Structure of This Document
the rest of this doc is laid out like this 🧚
- Section 2 covers some essential building blocks for CDNI, especially the different options for redirecting user requests to a given CDN 🔀
- Section 3 gives a bunch of illustrative examples of different CDNI operations 🖼️
- Section 4 describes what the main CDNI interfaces do 🔍
- Section 5 shows how various CDNI deployment models can be achieved using the defined interfaces 🏗️
- Section 6 describes the CDNI trust model, and especially the transitive trust issues that CDNI raises 🤝
2. Building Blocks
2.1. Request Redirection
okay this is the core of CDNI 🫶 at its heart, CDNI needs to redirect requests from one CDN to another. for any given request received by an Upstream CDN, it will either respond to the request directly, or somehow redirect it to a Downstream CDN 🔁 there are two main mechanisms for redirecting a request to a Downstream CDN. the first leverages the DNS name resolution process, and the second uses application-layer redirection mechanisms like the HTTP 302 or Real-Time Streaming Protocol (RTSP) 302 redirection responses 🌈 there's a huge variety of application-layer protocols with some form of redirection, but this document uses HTTP (and HTTPS) in its examples. similar mechanisms can be applied to other application-layer protocols 💜 so, next up, here's a short discussion of both DNS-based and HTTP-based redirection, before we see some examples of their use in Section 3 🦋
2.1.1. DNS Redirection ✨
okay so DNS redirection is all about returning different IP addresses for the same DNS name 💖 (to balance server load, or to account for where the client is in the network). A DNS server, sometimes called the Local DNS (LDNS), resolves DNS names on behalf of an end user. The LDNS server then queries other DNS servers until it reaches the authoritative DNS server for the CDN-Domain. The network operator usually provides the LDNS server, but the user is free to pick other DNS servers (e.g., OpenDNS, Google Public DNS) 🌸
this last part is actually a big deal, bestie 👀 because the authoritative DNS server only sees the IP address of the DNS server asking it, NOT the IP address of the original end user.
the upside of DNS redirection is that it's completely transparent to the end user 🦋 the user sends a DNS name to the LDNS server and gets back an IP address, done. but it's also kinda problematic because the DNS request comes from the LDNS server and not the end user. that can mess with the accuracy of server selection that's based on the user's location 😭 and the transparency is a problem too, since there's no chance to take the user agent's attributes or the URI path component into account. we're going to look at two main forms: simple and CNAME-based.
simple DNS redirection: the authoritative DNS server for the name just returns an IP address from a set of possible IP addresses. the answer gets picked from that 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). honestly it's straightforward ✨ the only caveats are (1) there's a limit to how many alternate IP addresses a single DNS server can manage, and (2) DNS responses are cached by Downstream servers, so the Time to Live (TTL) on the response must be set to an appropriate value to keep the redirection fresh 🍓
CNAME-based DNS redirection: the authoritative server returns a CNAME response to the DNS request, which tells the LDNS server to restart the name lookup using a new name 🧚 a CNAME is basically a symbolic link in the DNS namespace, and just like a symbolic link, the redirection is transparent to the client. the LDNS server gets the CNAME response and re-runs the lookup, and only once the name resolves to an IP address does it hand the result back to the user. also, DNAME would be preferable to CNAME if it becomes widely supported 💅
one of the perks of DNS redirection compared to HTTP redirection is that it can be cached, which takes some load off the redirecting CDN's DNS server 💜 but this perk can also be a drawback, especially when a given DNS resolver doesn't strictly stick to the TTL (which is a known problem in some real-world environments) 💀 in that case, an end user might end up at a dCDN without ever passing through the uCDN, and that could be a seriously undesirable scenario from the uCDN's point of view.
2.1.2. HTTP Redirection
HTTP redirection uses the redirection response of the HTTP protocol (e.g.,"302" or "307") 🎀 this response contains a new URL that the application should fetch instead of the original URL. by changing the URL, the server can move the user over to a different server. the advantages are that (1) the server can change the URL the client fetches so it includes, for example, both the DNS name of the particular server to use and the original HTTP server that was being accessed 🙌 (2) the client sends the HTTP request to the server, so its IP address is known and can be used when picking a server, and (3) other attributes (e.g., content type, user agent type) are visible to the redirection mechanism. main character energy, honestly 👑
just like with DNS redirection, there are some potential downsides too 🙈 for example, it may affect application behavior, since web browsers won't send cookies if the URL changes to a different domain. also, although this might be an advantage too, the results of HTTP redirection aren't cached, so every redirection has to go through to the uCDN 🫶
3. Overview of CDNI Operation ✨
okay this section is the big-picture tour 🗺️ we walk through a "day in the life" of a content item that's made available through a pair of interconnected CDNs. it's gonna illustrate a lot of the functions that need to be supported in a complete CDNI solution. we'll use both DNS-based and HTTP-based redirection in the examples, starting super simple and then layering in extra capabilities, like recursive request redirection and content removal 🌈
before we get into the specific examples, here's a high-level view of the operations that may take place. this overview is shown in Figure 2 🦋 most operations will only involve a subset of the messages below, and the order and number of operations may vary a lot, as the more detailed examples show.
the diagram shows Operator A as the Upstream CDN (uCDN) and Operator B as the Downstream CDN (dCDN). the uCDN has a relationship with a content provider, and the dCDN is the CDN that Operator A picked to deliver content to the end user. the interconnection relationship may be symmetric between these two CDN operators, but each direction can be treated as operating independently of the other. to keep things simple, we only show the interaction in one direction 💖
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 Operationhere's what each step in the figure is doing 👇
- the dCDN uses the FCI to advertise info about its delivery footprint and capabilities, before any content requests get redirected 📣
- before any content request, the uCDN uses the MI to pre-position CDNI Metadata to the dCDN, so that metadata is ready to go for later content requests 🧁
- a content request from a user agent shows up at the uCDN 👋
- the uCDN may use the RI to synchronously ask the dCDN about its delivery capabilities, to decide if the dCDN is a suitable target for redirecting this request 🤔
- the uCDN redirects the request to the dCDN by sending some response (DNS, HTTP) to the user agent ↪️
- the user agent requests the content from the dCDN 🙋
- the dCDN may use the MI to synchronously request metadata related to this content from the uCDN, e.g., to decide whether to serve it 🧐
- if the content isn't already in a suitable cache in the dCDN, the dCDN may acquire it from the uCDN 📦
- the content gets delivered to the dCDN from the uCDN 🚚
- the content gets delivered to the user agent by the dCDN 🎉
- some time later, maybe at the request of the CSP (not shown), the uCDN may use the CI to tell the dCDN to purge the content, so it's not delivered again 🧹
- after one or more content delivery actions by the dCDN, a log of those delivery actions may be provided to the uCDN using the LI 📝
the next sections show more specific examples of how these operations can be combined to do different delivery, control, and logging stuff across a pair of CDNs 💅
3.1. Preliminaries
okay so we start with the assumption that there's at least one CSP that has contracted with an Upstream CDN (uCDN) to deliver content on its behalf 🌸 we're not super focused on the interface between the CSP and the uCDN, other than noting that it's expected to be the same as in the "traditional" (non-interconnected) CDN case. existing mechanisms like 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 also assume Operator B provides a Downstream CDN. an end user at some point makes a request for this 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) 👀 but either way, the HTTP request in the examples that follow is assumed to be for the example URL above.
our goal is to let the content behind that URL be served by Operator B's CDN 🎯 in the following sections, we'll walk through scenarios where content gets served, plus other CDNI operations like removing content from a Downstream CDN.
3.2. Iterative HTTP Redirect Example
Okay bestie, let's walk through a super simple example 💖 using HTTP redirection from a uCDN to a dCDN. It assumes HTTP redirection inside each CDN too, but that's independent of the redirect between CDNs, so you could totally build a different example that still does HTTP redirects from uCDN to dCDN and uses DNS inside each CDN 🦋
Our cast: Operators A and B have agreed to interconnect their CDNs, with A as the Upstream and B as the Downstream ✨
The operators agree that peer-a.op-b.example is the CDN-Domain that gets used as the target of redirects from the uCDN to the dCDN 🎀 We assume each CDN somehow learns this name (out of band or through a CDNI interface, your call). We call it a "distinguished" CDN-Domain because its whole job is the interconnection thing, and a CSP never uses it directly 🙈
They also agree on a distinguished CDN-Domain for inter-CDN acquisition, which is how the dCDN gets the CSP's content from the uCDN: op-b-acq.op-a.example 💅
The operators also swap info about which requests the dCDN is prepared to serve. Like, maybe it's clients in a certain geographic region, or a set of IP address prefixes 🌈 That info can also travel out of band or over a defined CDNI interface.
DNS is set up like this:
- The content provider makes Operator A the authoritative DNS server for
cdn.csp.example(or returns a CNAME forcdn.csp.examplewhere Operator A is the authoritative DNS server) 🧚 - Operator A is configured so a DNS request for
op-b-acq.op-a.examplereturns a Request Router in Operator A ⭐ - Operator B is configured so a DNS request for
peer-a.op-b.example/cdn.csp.examplereturns a Request Router in Operator B 🍓
Figure 3 shows how a client request for http://cdn.csp.example/...rest of URL... gets 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 🌸
Here's what happens at each step:
- A DNS resolver for Operator A handles the DNS request for its customer based on the CDN-Domain
cdn.csp.example. It returns the IP address of a Request Router in Operator A 💖 - A Request Router for Operator A handles the HTTP request and realizes the end user is better served by another CDN, specifically the one run by Operator B. So it sends back a 302 redirect for a new URL made by "stacking" Operator B's distinguished CDN-Domain (
peer-a.op-b.example) onto the front of the original URL 🦋 (Side note: fancier URL tricks are possible too, like swapping the initial CDN-Domain for some opaque handle.) - The end user does a DNS lookup on 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 🧚 (Also, if request routing inside the dCDN was done with DNS instead of HTTP redirection, B's DNS resolver would act as the Request Router and hand back the IP address of a delivery node directly.) - The Request Router for Operator B handles the HTTP request, picks a good delivery node for the end user, and sends back a 302 redirect for a new URL. That URL is made by swapping the hostname for a subdomain of Operator B's distinguished CDN-Domain that points at the chosen delivery node 🍓
- The end user does a DNS lookup on Operator B's delivery node subdomain (
node1.peer-a.op-b.example). B's DNS resolver returns the IP address of the delivery node ⭐ - The end user requests the content from Operator B's delivery node 🫶 If it's a cache hit, steps 6, 7, 8, 9, and 10 below don't happen, and the delivery node sends the content straight back to the end user. If it's a cache miss, the dCDN has to get the content from the uCDN (not the CSP) 😭 The distinguished CDN-Domain
peer-a.op-b.exampletells the dCDN that this content comes from the uCDN. Stripping that CDN-Domain reveals the original CDN-Domaincdn.csp.example, and the dCDN can check that this CDN-Domain belongs to a known peer (so it doesn't get tricked into being an open proxy, which would be a total disaster 💀). Then it does a DNS request for the inter-CDN acquisition CDN-Domain agreed above (here,op-b-acq.op-a.example). - Operator A's DNS resolver handles that DNS request and returns the IP address of a Request Router in Operator A 🔥
- The Request Router for Operator A handles the HTTP request coming from Operator B's delivery node. It knows this is a peer CDN and not an end user because of the dedicated inter-CDN acquisition domain (
op-b-acq.op-a.example). Without that special domain, Operator A could end up redirecting the request back to Operator B, and then you'd have an infinite loop 🌀 The Request Router for Operator A picks a good delivery node in the uCDN to serve the inter-CDN acquisition request, then sends back a 302 redirect for a new URL. That URL is made by swapping the hostname for a subdomain of Operator A's distinguished inter-CDN acquisition domain that points at the chosen delivery node 🎀 - Operator A's DNS resolver handles the DNS request and returns the IP address of the delivery node in Operator A 🌈
- Operator B requests (acquires) the content from Operator A 🏆 Although it isn't shown in the figure, Operator A handles the rest of the URL: it pulls out the info identifying the origin server, checks that this server has been registered, and figures out which content provider owns the origin server. It might also run its own content acquisition steps if needed before handing the content back to the dCDN 💜
The main upside of this design is that it's simple ✨ Each CDN only needs to know the distinguished CDN-Domain for each peer. The Upstream CDN "pushes" the Downstream CDN-Domain onto the URL as part of its redirect (step 2), and the Downstream CDN "pops" its CDN-Domain off the URL to expose a CDN-Domain the Upstream CDN can correctly process 💅 Neither CDN has to know the internal structure of the other's URLs. Plus, the inter-CDN redirection is handled entirely by a single HTTP redirect, so neither CDN has to know how the other one does its internal redirection (whether that's DNS or HTTP based) 👑
There's one downside, though 🙈 The end user's browser gets redirected to a new URL that isn't in the same domain as the original URL. That messes with some security or validation mechanisms that endpoints sometimes use. For example, if the browser is supposed to send any cookies tied to that domain, the redirected URL has to be in the same domain (like csp.example). Also, some video players enforce validation of a cross-domain policy, which has to account for the domains involved in the CDN redirection. These problems are generally solvable, but the fixes would make this example way more complicated, so we won't go into them further in this document 🦋
okay so this example is giving us a little peek at some of the interfaces CDNI might need 👀, but it doesn't use all of them 💅. like, getting info from a dCDN about which client IP addresses or geographic regions it could serve is part of request routing (specifically the CDNI Footprint & Capabilities Advertisement interface) 🗺️. important config stuff, like the distinguished names used for redirection and inter-CDN acquisition, could also be passed over a CDNI interface (maybe the CDNI Control interface 🤔✨). the example also shows how existing HTTP-based methods are enough for the acquisition interface 🙌. honestly, the absolute bare minimum metadata for CDNI is the info needed to acquire the content 🎀, and here it got delivered "in-band" 🦋 through the URI handed to the client in the HTTP 302 response. the example also assumes the CSP doesn't need any distribution policy (like a time window or geo-blocking) or delivery processing applied by the interconnected CDNs 🌸. so no explicit CDNI Metadata interface shows up here 🫶, and there's no explicit CDNI Logging interface discussed either 🙈.
ngl we kinda glossed over one thing 👀: deciding when a request should be redirected to the dCDN instead of being served by the uCDN. it could be as simple as checking the client IP address against a list of prefixes 💖, or it could get way more complicated, with factors like the client's geographic location (perhaps from a third-party service 🌍), CDN load, or specific business rules 💼. wild 💀.
this example uses the "iterative" CDNI request redirection approach 🔁. so a uCDN does part of the request redirection function by redirecting the client to a Request Router in the dCDN, and then that Request Router does the rest by redirecting to a suitable Surrogate 🧚. if request routing happens in the dCDN using HTTP redirection, the end user ends up experiencing two successive HTTP redirections 😭. the alternative, "recursive" CDNI request redirection, coalesces those two successive redirects into a single one, sending the end user straight to the right delivery node in the dCDN ✨. we'll get into this "recursive" approach in the next section 👑.
the iterative HTTP redirection mechanism would work over HTTPS in a similar way, even though the example above uses HTTP 🔒. to make sure an end user's HTTPS request isn't downgraded to HTTP along the redirection path, every Request Router on the path from the initial uCDN Request Router to the final Surrogate in the dCDN has to respond to an incoming HTTPS request with an HTTP redirect containing an HTTPS URL 🫶.
heads up bestie 🥺: using HTTPS increases the total redirection process time and 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 those cases, a recursive HTTP redirection mechanism (see the example in the next section) might help reduce some of these issues 💜.
3.3. Recursive HTTP Redirection Example
okay so this example is literally a sequel to the last one ✨ it shows off the request routing interface (specifically the CDNI Request Routing Redirection interface) so the CDNs can do "recursive" request routing 🦋 we use HTTP-based redirection here because it makes the ideas super clear, but recursive redirection works just as well when DNS-based redirection is in play 💅
the big difference from the iterative example is that the operators don't have to agree ahead of time on a CDN-Domain to be the target of redirects from the uCDN to the dCDN 🙈 instead, they just agree on some distinguished CDN-Domain for inter-CDN acquisition of the CSP's content by the dCDN 💜 in this example that's op-b-acq.op-a.example 🎀
the operators also swap info about which requests the dCDN is willing to serve 🌸 like, the dCDN might handle requests from clients in a certain geographic region or from a set of IP address prefixes 🗺️ this info can be shared out of band or through a defined protocol, totally up to them ✨
here's how DNS is set up:
- the content provider is set up to make Operator A the authoritative DNS server for
cdn.csp.example(or it returns a CNAME forcdn.csp.examplewhere Operator A is the authoritative DNS server) 🫶 - Operator A is set up so a DNS request for
op-b-acq.op-a.examplereturns a Request Router in Operator A 💖 - Operator B is set up so a request for
node1.op-b.example/cdn.csp.examplereturns the IP address of a delivery node 🍓 there could be a bunch of these delivery nodes, btw
Figure 3 shows how a client request for
http://cdn.csp.example/...rest of URL...gets 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 🦋
here are the steps from the figure 📝
- A DNS resolver for Operator A handles 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 ✨ - A Request Router for Operator A handles the HTTP request and notices the end user is better served by another CDN, specifically the one run by Operator B 👀 so it queries the CDNI Request Routing Redirection interface of Operator B, giving it a bunch of info about the request, including the URL requested 📦 Operator B replies with the DNS name of a delivery node 🌸
- Operator A sends back a 302 redirect for a new URL it got from the RI 🔁
- the end user does a DNS lookup on the hostname of that URL (
node1.op-b.example) 🔍 B's DNS resolver returns the IP address of the matching delivery node 💜 since the delivery node's name was already obtained from B through the RI, there SHOULD NOT be any further redirection here, unlike the iterative method we looked at above 🙅♀️ - the end user requests the content from B's delivery node, which could result in a cache miss 🥺 if that happens, the content has to be acquired from the uCDN, not the CSP 🫠 the distinguished CDN-Domain
op-b.exampletells the dCDN that this content should be acquired from another CDN 🎯 stripping that CDN-Domain reveals the original CDN-Domaincdn.csp.example🪄 the dCDN MAY verify that this CDN-Domain belongs to a known peer, so it doesn't get tricked into being an open proxy 🛡️ then it does a DNS request for the inter-CDN Acquisition "distinguished" CDN-Domain agreed on above (in this caseop-b-acq.op-a.example) 💖 - Operator A's DNS resolver handles the DNS request and returns the IP address of a Request Router in Operator A 🧚
- the Request Router for Operator A handles the HTTP request from Operator B's delivery node 📬 Operator A's Request Router knows it's a peer CDN and not an end user because of the dedicated inter-CDN acquisition domain (
op-b-acq.op-a.example) 🕵️♀️ (heads up: without this specially defined inter-CDN acquisition domain, Operator A would be at risk of redirecting the request back to Operator B, which would cause an infinite loop 🌀) the Request Router for Operator A picks a suitable delivery node in the uCDN to serve the inter-CDN acquisition request and sends back a 302 redirect for a new URL 🔀 built by replacing the hostname with a subdomain of Operator A's distinguished inter-CDN acquisition domain that points to the selected delivery node 🎀 - Operator A recognizes that the DNS request is from a peer CDN and not an end user (because of the internal CDN-Domain) so it returns the address of a delivery node 💌 (again, 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 🌀)
- Operator B requests (acquires) the content from Operator A 🫶 Operator A serves content for the requested CDN-Domain to the dCDN 🎁 although it isn't shown, this is the point where Operator A processes the rest of the URL: it pulls out info identifying the origin server, checks that this server has been registered, and figures out which content provider owns the origin server 🕵️ it may also do 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 downside is that each CDN exposes more of its internal structure (in particular, the addresses of edge caches) to peer CDNs 😬 iterative redirection, on the other hand, doesn't 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 built with DNS-based redirection in either CDN ✨ so the key takeaway is that the end user only sees a single redirection of some type, instead of the pair of redirections in the prior (iterative) example 🦋
using the RI requires the request routing mechanism to be properly configured and bootstrapped, which isn't shown here 🛠️ more discussion on bootstrapping the interfaces is in Section 4 🫶
3.4. Iterative DNS-Based Redirection Example ✨
okay bestie, let's walk through a simple example that uses DNS-based redirection for request redirection from the uCDN to the dCDN 💅. The same idea also covers request routing inside the dCDN and the uCDN. As we said in Section 2.1, DNS-based redirection has perks over HTTP-based redirection (the big one: it's transparent to the end user 🦋) but also some drawbacks (the big one: the client IP address is not visible to the Request Router 😭).
Same as before, Operator A has to learn which requests the dCDN is willing or able to serve, like which client IP address prefixes or geographic regions are part of the dCDN footprint 🗺️. We assume Operator B has a unique identifier and makes it known to Operator A. That identifier gets used to build a distinguished CDN-Domain, which we'll get into below 🎀. This identifier really only needs to be unique within Operator A's scope, but a globally unique one, like an Autonomous System (AS) number assigned to B, is one easy way to get there. Operator A also grabs the NS records for Operator B's externally visible redirection servers. And, as before, a distinguished CDN-Domain, like op-b-acq.op-a.example, has to be set up for inter-CDN acquisition 🧚.
We assume DNS is set up like this:
- The CSP is configured to make Operator A the authoritative DNS server for
cdn.csp.example(or to return a CNAME forcdn.csp.examplefor which Operator A is the authoritative DNS server). - 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.) - The dCDN is configured so that a request for
"b.cdn.csp.example"returns a delivery node in the dCDN. - The uCDN is configured so that a request for
"op-b-acq.op-a.example"returns a delivery node in the uCDN.
Figure 5 shows the exchange of DNS and HTTP requests. The big differences from Figure 3 are that there's no HTTP redirection, and it's transparent 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 RedirectionHere are the steps in the figure, in order:
- The Request Router for Operator A processes the DNS request for CDN-Domain
cdn.csp.exampleand 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). - 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 tob.cdn.csp.exampleby 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. 🙈) - 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. - 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). - 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.
- 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's 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 one partially shows 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 gets 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's possible to use DNSSEC together with the Iterative DNS-based Redirection mechanism explained above, it's really important to know that the uCDN might have to sign records on the fly. The CNAME returned, and therefore the signature provided, can be different for each incoming query. Nothing stops a uCDN from doing that on-the-fly signing, but it might be computationally expensive 💀. If the number of dCDNs (and so the number of different CNAMEs to return) is pretty stable, an alternative would be for the uCDN to pre-generate signatures for all possible CNAMEs. Then, for each incoming query, the uCDN determines the right CNAME and returns it together with its 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 direct SOA queries are pretty rare in practice, a uCDN could defer incrementing the serial number and resigning the SOA until it's queried, and then do it on-the-fly. 🫶
Also, 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 won't 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. This kind of inconsistency is a general operational issue of DNS, but it may matter even more for this architecture, because the uCDN (Operator A) would rely on that consistency to make the redirection work as intended. In general, it is the administrator's responsibility to make them consistent. 👑
3.5. Dynamic Footprint Discovery Example 🦋
Okay so sometimes it's super useful to be able to dynamically discover which requests a dCDN is willing and able to serve 👀. Like, a CDN could totally be able to serve a certain set of client IP prefixes one day, and then that set changes because the topology and routing policies of the IP network shift 🌊. This example shows how that works. We picked DNS-based redirection for it, but HTTP-based redirection could do the same thing 💅.
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 ✨
Okay so this is basically the same flow as Figure 5, just with one extra bit: an RI request (step 2) and its response (step 3) 🧚. The RI REQ could be something like "Can you serve clients from this IP Prefix?" or it could be "Provide the list of client IP prefixes you can currently serve" 🤔. Either way, Operator A might cache the response so it doesn't keep asking the same question over and over 🙈.
Also, Operator B can spontaneously advertise info (or changes) about the set of requests it can serve for Operator A, or it can do this instead of asking 💖. So Operator B might send RR/RI REPLY messages that aren't a direct reply to a RR/RI REQ message at all. Main character behavior 👑. (Note that figuring out the client's subnet from DNS requests works exactly the same here as it does in Section 3.4, so no surprises there 🫶.)
Once Operator A gets the RI response, it can tell that Operator B's CDN is a legit dCDN for this request, which makes it a valid candidate to consider in its redirection decision 🎀. If that dCDN gets picked, then the redirection and serving of the request just goes ahead like normal, as if there was no dynamic footprint discovery at all 🌈.
3.6. Content Removal Example 🗑️
This example shows how the CDNI Control interface can be used to pre-position content in the dCDN, but in reverse, like, removing it 😭. So user requests for some content, and the redirection of those requests from Operator A to the Operator B CDN, may or may not have happened earlier 🤷♀️. Then at some point, the uCDN (for example, because the Content Provider sent a Trigger) uses the CI to ask that the content at a particular URL be removed from the dCDN 💅. Here's the diagram. Fun fact, a uCDN usually won't know whether a dCDN has cached a given content item 👀. But it can still send the removal request just to make sure no cached copies are left floating around, which might matter for any contractual obligations it has 📜.
End User Operator B Operator A
| |CI purge cdn.csp.example/...
| |<------------------------|
| | |
| |CI OK |
| |------------------------>|
| | |Figure 7: Message Flow for Content Removal 🧹
So the CI is what carries the uCDN's request to the dCDN, asking it to delete some content it got earlier 🫧. The URL in the request tells the dCDN exactly which content to remove 🎯. This example matches a DNS-based redirection scenario like the one in Section 3.4 💕. If HTTP-based redirection was used instead, then the URL for removal would look like peer-a.op-b.example/cdn.csp.example/... 🦋.
The dCDN is expected to confirm to the uCDN, using the CI OK message shown in the diagram, that the targeted content has been removed from all the caches in the dCDN ✅. Ngl that's the whole point of the check 🫶.
3.7. Pre-positioned Content Acquisition Example 🌸
This example shows how the CI can be used to pre-position a piece of content in the dCDN, so it's ready and waiting before anyone asks for it 🍓. Here Operator A uses the CDNI Metadata interface to ask that the content at a particular URL be pre-positioned into the 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 🎀
Here's the step-by-step tea ☕:
- Operator A uses the CI to ask Operator B to pre-position a specific content item, identified by its URL 📦. Operator B replies by confirming that it's totally willing to do this 💅.
Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3 🔁. The only difference is that they happen because of the pre-positioning request instead of a cache miss 🧠.
Steps 4, 5, 6, and 7 are exactly the same as steps 1, 2, 3, and 4 of Figure 3 🌈. Again, the one difference is that Operator B's CDN can serve the end-user request without triggering dynamic content acquisition, since the content was already pre-positioned in the dCDN 🙌. Depending on dCDN operations and policies, the pre-positioned content might go to all of the dCDN caches, or just a subset of them 🧚. In that second case, intra-CDN dynamic content acquisition can happen inside the dCDN for requests hitting caches that don't have the content yet 🌸. But that internal acquisition wouldn't involve the uCDN at all 🫶✨.
3.8. Asynchronous CDNI Metadata Example 🎀
okay so this section walks through a scenario where the Downstream CDN gets its CDNI Metadata before anyone even asks for the content 🧚 Like, it's already prepped and waiting. The example assumes HTTP-based inter-CDN redirection and recursive CDNI request routing, same as Section 3.3 🦋 Async metadata exchange works for DNS-based redirection and iterative request routing too, it's just that the CDNI Metadata might get used at slightly different points in 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 Metadatahere's the play-by-play 👑
- Operator A uses the CI to trigger the signaling of the availability of CDNI Metadata to Operator B. 📣
- Operator B acknowledges the receipt of this Trigger. 🫶
- Operator B requests the latest metadata from Operator A using the MI. 🙏
- 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). 🔐
- A Content Request occurs as usual. 💌
- 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. 👀
- Operator B's Request Router issues a CDNI Request Routing Redirection response (RI RESP) as in Section 3.3. 📬
- Operator B performs content redirection as discussed in Section 3.3. ↪️
- 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.) 🛡️
- 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 💜
this one is the opposite vibe 😭 The Downstream CDN doesn't prep anything ahead of time. It grabs the CDNI Metadata for the content right when it's handling the first request for that content. Same deal as the last section: HTTP-based redirection and recursive request routing as in Section 3.3, but dynamic metadata acquisition also works with other request routing setups 🌸
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 Acquisitionstep by step, bestie 🍓
- A Content Request arrives as normal. 💖
- An RI request occurs as in the prior example. 🔁
- 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. 🗝️
- 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.) ✅
- Response to the RI request as normal. 📨
- Redirection message is sent to the end user. ➡️
- A delivery node of Operator B receives the end user request. 🙌
- 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. 🧠
- 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. ✨
- Content is served (possibly preceded by inter-CDN acquisition) as in Section 3.3. 🌈 that's the whole vibe, periodt 🌈
3.10. Content and Metadata Acquisition with Multiple Upstream CDNs ✨
okay so a single dCDN can get end-user requests from multiple uCDNs 👀 which means the dCDN has to figure out which uCDN it should pull the requested content from. bestie this is the whole plot 💅
ideally, the acquisition path follows the redirection path 🦋 like the dCDN should grab the content from the same uCDN that redirected the request. no cap, that's the vibe.
to do that, the dCDN has to rebuild the redirection path using info inside the end-user request 🧩 and HOW it does that depends on the redirection approach: HTTP or DNS.
HTTP redirection: the rewritten URI should include enough info for the dCDN to directly or indirectly figure out the uCDN when the request shows up 🎀 this approach splits again based on how the URL gets rewritten: HTTP redirection with Site Aggregation or without it. with Site Aggregation, the identity of the original CSP is hidden 🙈 without it, the CSP's identity is NOT hidden (it's not trying to be sneaky). in both cases, the rewritten URI still carries enough info to identify the immediate neighbor uCDN ✨
DNS redirection: here the dCDN gets the published URI (not a rewritten one) 😭 so it doesn't have enough info to pinpoint the right uCDN. the move is to narrow things down by checking the CDNI Metadata from each uCDN to see which ones are hosting metadata for the requested content 🔍
- if only ONE uCDN is hosting metadata for that content, the dCDN can assume the redirection is coming from that uCDN and grab the content from it 🫶
- if MULTIPLE uCDNs are hosting metadata for it, the dCDN may be ready to trust any of them to acquire the content (as long as that uCDN is in a position to serve it) 🌈
- if the dCDN is NOT ready to trust any of them, it needs to make sure, through out-of-band arrangements, that for a given piece of content only a single uCDN will ever redirect requests to the dCDN 🔐 like one bestie per content, periodt.
content acquisition can be preceded by content metadata acquisition 📚 and if possible, the metadata's acquisition path should also follow the redirection path. also, we assume metadata is indexed by rewritten URIs for HTTP redirection and by published URIs for DNS redirection 🗂️ so the RI and the MI are tightly coupled 🔗: the result of request routing (a rewritten URI pointing at the dCDN) is the input to the metadata lookup. and if the content metadata includes info for acquiring the content, the MI is also tightly coupled with the acquisition interface 💜 the result of the metadata lookup (an acquisition URL, likely hosted by the uCDN) becomes the input to the content acquisition. it's a whole chain, iykyk 😭
4. Main Interfaces 🧚
4.1. In-Band versus Out-of-Band Interfaces
Figure 1 shows the main interfaces that are in scope for the CDNI WG, plus several others 🗺️ the detailed specs of these interfaces are left to other documents, but check out [RFC6707] and [RFC7337] for some discussion of them 📖
one interface that is NOT in Figure 1 is the one between the user and the CSP. for CDNI purposes that interface is out of scope, but it's still worth knowing it exists, since it can provide useful stuff like end-to-end performance monitoring and some forms of authentication and authorization 💅
there's also an important interface between the user and the Request Routing function of both uCDN and dCDN (the "Request" interface in Figure 1) 🌸 like we saw in some of the earlier examples, that interface can be used to pass metadata, such as the minimum info the dCDN needs to get the content from the uCDN.
in this section we'll give an overview of what each CDNI interface does and how they fit into the overall solution ✨ we'll also look at some design trade-offs and explore a few cross-interface concerns. we start with one trade-off that affects ALL the interfaces: whether to use in-band or out-of-band communication 🦋
4.1. In-Band versus Out-of-Band Interfaces
Before we get to the individual interfaces, there's a high-level design choice for each one 👑 you can either use existing in-band communication channels or define brand new out-of-band interfaces.
it's possible that the info needed for various interconnection functions can be shared between peer CDNs using existing in-band protocols 🍓 the HTTP 302 redirect is an example of how some aspects of request routing can be done in-band (embedded in URIs). and note that using existing in-band protocols does NOT mean the CDNI interfaces are null 🙅♀️ it's still necessary to set the rules (conventions) for how those protocols get used to implement the various interface functions.
there are other chances for in-band communication beyond HTTP redirects too 🌈 for example, many of the HTTP directives that proxy servers use can also be used by peer CDNs to tell each other about caching activity. one that's especially relevant is the If-Modified-Since directive, used with the GET method to make a request conditional: if the requested object hasn't been modified since the time given in this field, a copy of the object will NOT be returned, and instead you get a 304 (not modified) response 🙈 very efficient, very iconic.
4.2. Cross-Interface Concerns
Although the CDNI interfaces are mostly independent, there's a set of conventions practiced consistently across ALL of them 🤝 the biggest one is how resources get named. for example, how the CDNI Metadata and Control interfaces identify the set of resources a given directive applies to, or how the CDNI Logging interface identifies the set of resources a summary record applies to 📝
in theory, the CDNI interfaces could name every single individual resource 🤯 but in practice, they name resource aggregates (sets of URIs) that should be treated in a similar way. for example, URI aggregates can be identified by a CDN-Domain (the FQDN at the beginning of a URI) or by a URI-Filter (a regular expression that matches a subset of URIs contained in some CDN-Domain) 🎀 so basically, CDN-Domains and URI-Filters give us a uniform way to aggregate sets (and subsets) of URIs to define the scope of an operation in one of the CDNI interfaces. main character energy for naming 👑
4.3. Request Routing Interfaces
The Request Routing interface has two parts 🧭: the Asynchronous interface, which a dCDN uses to advertise its footprint and capabilities (denoted FCI) to a uCDN, so the uCDN can decide whether to redirect particular user requests to that dCDN; and the Synchronous interface, which the uCDN uses to redirect a user request to the dCDN (denoted RI). (these are kinda like routing and forwarding in IP, iykyk 🦋)
as illustrated in Section 3, the RI part of request routing may be implemented partly by DNS and partly by HTTP 🌸 naming conventions can be set up so CDN peers can tell each other whether a request should be routed or the content should be served.
we also note that RI plays a key role in enabling recursive redirection, as shown in Section 3.3 💖 it lets the user get redirected to the correct delivery node in the dCDN with only a single redirection step (as the user sees it). this gets especially valuable as the chain of interconnected CDNs grows beyond two CDNs 😭 for more on the RI, see [REDIRECTION].
and in support of these redirection requests, CDN peers need to swap some extra info with each other 🫶 that's the job of the FCI part of request routing. depending on which method(s) are supported, this might include:
- The operator's unique id (operator-id) or distinguished CDN-Domain (operator-domain);
- NS records for the operator's set of externally visible Request Routers;
- The set of requests the dCDN operator is prepared to serve (e.g., a set of client IP prefixes or geographic regions that may be served by the dCDN).
- Additional capabilities of the dCDN, such as its ability to support different CDNI Metadata requests.
note that the set of requests a dCDN is willing to serve could in some cases be pretty static (e.g., a set of IP prefixes), could be exchanged offline, or might even be negotiated as part of a peering agreement 🤓 but it can also be more dynamic, in which case the exchange supported by FCI would be super helpful. a further discussion of the Footprint & Capability Advertisement interface can be found in [FOOTPRINT-CAPABILITY] 💜
4.4. CDNI Logging Interface ✨
okay so the upstream CDN (uCDN) really needs to see what happened when it redirected content over to a downstream CDN (dCDN) 👀. Why? So it can bill its customers properly for every delivery of content the dCDN cached, and report accurate traffic stats to the content providers 💅. That's one job of the LI (Logging Interface) 🎀.
The LI can also swap other operational data that's relevant to CDNI 🧚. For example, a dCDN might report how much content it has acquired from the uCDN, and how much cache storage has been eaten up by content it's caching on the uCDN's behalf 💜.
Traffic logs are super easy to trade offline 📝. The following traffic log is a little remix of the Apache log file format 🍓, and each entry has these fields:
- Domain - the full domain name of the origin server
- IP address - the IP address of the client making the request
- End time - the ending time of the transfer
- Time zone - any time zone modifier for the end time
- Method - the transfer command itself (e.g., GET, POST, HEAD)
- URL - the requested URL
- Version - the protocol version, such as HTTP/1.0
- Response - a numeric response code indicating transfer result
- Bytes Sent - the number of bytes in the body sent to the client
- Request ID - a unique identifier for this transfer
- User agent - the user agent, if supplied
- Duration - the duration of the transfer in milliseconds
- Cached Bytes - the number of body bytes served from the cache
- Referrer - the referrer string from the client, if supplied
Of these, only the Domain field is indirect in the Downstream CDN 🫣. It gets set to the CDN-Domain used by the Upstream CDN, not the actual origin server. That's the bit that makes it useful, because this field can be used to filter traffic log entries so only the ones matching the Upstream CDN get reported to the right operator 🔥. More on the LI can be found in [LOGGING] 📚.
Now here's the open question, and it's kind of a big one 🤔: 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. The catch is that the dCDN has to know the set of CDN-Domains that belongs to each Upstream peer. If peers already swap that info through another interface, direct peer-to-peer reporting is totally straightforward ✨. But if it's not available, and operators don't want to advertise the CDN-Domains they serve to their peers, then the second option kicks in. Each CDN sends both its non-local traffic records and its set of CDN-Domains to an independent third party (a CDN Exchange) 🦋. That exchange then filters, merges, and distributes the traffic records on behalf of each participating CDN operator 🫶.
Another open question: how timely should traffic info be? ⏰ Offline logs are great, but accurate real-time traffic monitoring could also be useful. The catch is that real-time info means the dCDN has to tell the uCDN every single time it serves upstream content out of its cache 😭. One way to do this is for the dCDN to send a conditional HTTP GET request (If-Modified-Since) to the uCDN each time it gets an HTTP GET request from one of its end users. That lets the uCDN record that a request was issued for real-time traffic monitoring 📈. The uCDN can also use this info to validate the traffic logs it gets later from the dCDN ✅.
Obviously there's a trade-off here 🙃. More accurate monitoring means more overhead, because the dCDN has to go back to the uCDN for every request.
Another design trade-off in the LI is how much the data gets aggregated or summarized 🧁. HTTP Adaptive Streaming (HAS) is a prime example of a situation that begs for summarizing, since the huge number of individual chunk requests can create huge volumes of logging info 📦. We'll talk about this case below, but other forms of aggregation could be useful too. For instance, there may be situations where bulk metrics, like bytes delivered per hour, are enough instead of the detailed per-request logs outlined above 🕐. It seems likely that a range of logging granularities will be needed, along with ways to specify the type and degree of aggregation required 💖.
4.5. CDNI Control Interface 🎛️
The CDNI Control interface is initially used to bootstrap the other interfaces 👑. As a simple example, it could be used to provide the address of the logging server in the dCDN to the uCDN, so the CDNI Logging interface can get set up. It may also be used to establish security associations for the other interfaces 🔐.
The other role the CI plays is letting the uCDN pre-position, revalidate, or purge metadata and content on a dCDN 🧹. These operations, sometimes collectively called the "Trigger interface", are discussed further in [CONTROL-TRIGGERS] 🎀.
4.6. CDNI Metadata Interface 🗂️
The CDNI Metadata interface is all about letting the uCDN convey CDNI distribution metadata to the dCDN 💌. That metadata includes stuff like geo-blocking restrictions, availability windows, access-control policies, and so on 🌍. It can also include info that helps the dCDN acquire content, like alternate sources for the content or the authorization info needed to get it from the source 🔑. For a full discussion of the CDNI Metadata interface, see [METADATA] 📖.
Some distribution metadata can be partially copied using in-band mechanisms 🧩. For example, for geo-blocking restrictions or availability windows, the uCDN can choose to redirect a request to the dCDN 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 ⏳. Honestly though, these approaches usually come with shortcomings 😬. For example, you can't stop replay outside the time window, and you can't make use of a dCDN that covers a broader footprint than the geo-blocking restrictions allow.
Some forms of access control can also be done on a per-request basis using HTTP directives 🙌. For example, being able to respond to a conditional GET request gives the uCDN a chance to influence how the dCDN delivers its content 🎯. At the very least, the uCDN can invalidate (purge) content the dCDN previously cached 🧼.
All of these in-band techniques show that uCDNs have the option of enforcing some of their access control policies themselves 💅. That comes at the expense of more inter-CDN signaling load, but it means they don't have to delegate enforcement to dCDNs through the MI. Because of that, the MI could give the uCDN a way to say it wants to keep enforcement for itself 🙈. For example, this might be done by including a "check with me" flag in the metadata for certain content 🚩. Making these in-band techniques work over the various inter-CDN acquisition protocols (e.g., HTTP) needs more investigation, and it may require small extensions or semantic changes to the acquisition protocol 🔬.
4.7. HTTP Adaptive Streaming Concerns 🎬
We're looking at HTTP Adaptive Streaming (HAS) and how it affects the CDNI interfaces, because large objects (like videos) get broken into a sequence of small, independent chunks 🧩. For each of the points below, a more thorough discussion, including an overview of the trade-offs in alternative designs, can be found in RFC 6983 📚.
First, Content Acquisition and File Management are out of scope for the CDNI interfaces, but they're still relevant to the overall operation 🧠. We assume no extra measures are required to deal with large numbers of chunks 🙌. That means the dCDN isn't explicitly told about any relationship between different chunks, and it handles each chunk as if it were an individual, independent content item 📦. So content acquisition between the uCDN and dCDN also happens on a per-chunk basis 🔁. This approach lines up with the recommendations in RFC 6983, which also points out possible improvements in this area for the future 🔮.
Second, let's talk request routing 🧭. HAS manifest files can potentially mess with request routing, since manifest files contain URLs pointing to where the content chunks live 😵💫. To make sure a manifest file doesn't hinder CDNI request routing and doesn't put excessive load on CDNI resources, either the use of manifest files could be limited to ones containing relative URLs, or the uCDN could modify the URLs in the manifest 🛠️. Our approach is twofold 💜. As a mandatory requirement, CDNs should be able to handle unmodified manifest files containing either relative or absolute URLs 🫶. Then, as an optional feature, to limit the number of redirects (and the load placed on the CDNI interfaces), uCDNs can use the info obtained through the CDNI Request Routing Redirection interface to modify the URLs in the manifest file ✨. Since modifying the manifest is an optional uCDN-internal process, it doesn't need any standardization beyond being able to communicate chunk locations in the CDNI Request Routing Redirection interface 🎀.
Third, with respect to the CDNI Logging interface, there are several potential issues 😩. One is the large number of individual chunk requests, which can result in large volumes of logging info. Another is the desire to correlate logging info for chunk requests that belong to the same HAS session 🔗. For the initial CDNI specification, participating CDNs are expected to support per-chunk logging (e.g., logging each chunk request as if it were an independent content request) over the CDNI Logging interface 📝. Optionally, the LI may include a Content Collection IDentifier (CCID) and/or a Session IDentifier (SID) as part of the logging fields 🏷️. That makes it easier to correlate per-chunk logs into per-session logs, which is great for apps that benefit from session-level info, like session-based analytics 📊. This approach also lines up with the recommendations in RFC 6983, which again identifies potential improvements in this area for later 🔭.
Fourth, with respect to the CDNI Control interface, and especially purging HAS chunks from a given CDN, our approach is to expect each CDN to support per-chunk content purge (e.g., purging chunks as if they were individual content items) 🧹. Optionally, a CDN may support content purge based on a "Purge IDentifier (Purge-ID)", which lets you remove all the chunks related to a given Content Collection with a single reference 🪄. It's possible that this Purge-ID could be merged with the CCID discussed above for HAS logging, or they may stay distinct 🤷♀️.
4.8. URI Rewriting ✨
okay so when HTTP redirection is happening, content URIs can get rewritten 🔁 That can happen inside a uCDN, between a uCDN and a dCDN, and inside the dCDN itself. With cascaded CDNs it gets even more fun, because the URI can get rewritten at every CDN hop: between the uCDN and the dCDN acting as the transit CDN, and then again between the transit CDN and the dCDN that actually serves the request 🫶 The content URI used between any uCDN/dCDN pair turns into a shared handle. Both CDNs can point at it without any confusion in all their inter-CDN chats. That handle is what lets the two CDNs match up info sent over other CDNI interfaces, both Downstream (like with the MI) and Upstream (like with the LI) 💜
Let's keep it simple with one uCDN/dCDN pair doing HTTP redirection. We're gonna use three names for content URIs so the convo doesn't get messy:
u-URIis a content URI in a request that shows up at the uCDN 📥ud-URIis a content URI acting as the shared handle between the uCDN and the dCDN for requests the uCDN redirects to one specific dCDN 🤝d-URIis a content URI in a request made inside the delegate dCDN 🚀
In this basic pair-wise setup, the ud-URI is basically the handle that the uCDN/dCDN pair use to tie together all their CDNI info ✨ So for any given pair of CDNs doing the redirection, the uCDN has to map the u-URI to the ud-URI handle for every MI message exchange 🍓 Meanwhile the dCDN has to map the d-URI to that same ud-URI handle for every LI message exchange 💅
Now the cascaded case. The transit CDN rewrites the content URI when it redirects to the dCDN, which sets up a brand new handle between the transit CDN and the dCDN. That handle is different from the one between the uCDN and the transit CDN, so it's a whole new situation 👀 The transit CDN is responsible for managing its mapping across those handles, so the right handle is always the one used for each pair of CDNs in its CDNI communication. Very main character responsibility 👑
The short version: every CDNI interface between a given pair of CDNs must always use that pair's ud-URI handle as its content URI reference. No mixing and matching, bestie! 🚫
5. Deployment Models 🌈
Okay, so this section walks through a bunch of deployment models you can actually build with the CDNI interfaces we just covered 🦋 Just know these are by no means the full list, and loads of other models could totally exist ✨
Even though Figure 1 shows every CDN function on each side of the CDNI interface, real deployments can rely on entities doing only some of those functions. That means they only need to support the matching subset of CDNI interfaces 💖 Like we said back in Section 3, you can build a legit CDNI deployment without implementing every single interface. Some examples are coming right up 🎀
Also, we keep saying "Upstream" and "Downstream CDNs," but that label applies to specific content items and specific transactions, not to whole CDNs 🙈 So one CDN can be the Upstream for some transactions and the Downstream for others. It depends on stuff like where the requesting client is and which piece of content they want 🌸
5.1. Meshed CDNs 🕸️
Figure 1 is a unidirectional interconnection with one uCDN and one dCDN, but you can take that and build any arbitrary CDNI mesh out of it. Figure 11 is one example of that 💜 (Whether arbitrary meshing is in the working group's initial scope is a separate question, but the model leaves room 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
Figure 11: CDNI Deployment Model: CDN Meshing Example5.2. CSP Combined with CDN 🧁
Quick reminder: our terminology is about functional roles, not business or economic ones 💅 So one organization can be a CSP and a fully fledged uCDN at the same time, depending on which functions it's doing. Figure 12 shows exactly that 🫶
##################################### ##################
# # # #
# Organization A # # Organization B #
# # # #
# -------- ------------- # # ----------- #
# / CSP \ / uCDN \ # # / dCDN \ #
# | | | +----+ | # # | +----+ | #
# | | | | C | | # # | | C | | #
# | | | +----+ | # # | +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | L | | # # | | L | | #
# | |*****| +----+ |===CDNI===>| +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | RR | | # # | | RR | | #
# | | | +----+ | # # | +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | D | | # # | | D | | #
# | | | +----+ | # # | +----+ | #
# \ / \ / # # \ / #
# -------- ------------- # # ----------- #
# # # #
##################################### ################## ===> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN
**** interfaces outside the scope of CDNI
C Control component of the CDN
L Logging component of the CDN
RR Request Routing component of the CDN
D Distribution component of the CDN
Figure 12: CDNI Deployment Model: Organization Combining CSP & uCDN5.3. CSP Using CDNI Request Routing Interface 🎯
Here's another one. A content provider might decide to run its own Request Routing function so it can pick between several candidate CDN providers 💖 In that case, the content provider counts as a CSP plus a special, restricted kind of CDN. Figure 13 shows the CDNI Request Routing interfaces hooking up that restricted CDN (run by the content provider's organization) to the full CDN organization acting as a dCDN in the request routing control plane 🦋 Meanwhile, interfaces outside the CDNI work can handle the stuff between the content provider's CSP functional entities and the full CDN acting as a uCDN, across the other CDNI control planes (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
Figure 13: CDNI Deployment Model: Organization Combining
CSP and Partial CDN5.4. CDN Federations and CDN Exchanges 🌸
okay so there are two more ideas that are related to CDNI but are NOT the same thing 🫶 first up is CDN Federation. our take is that CDNI is the more general concept, where two or more CDNs serve content to each other's users. federation is more specific, because it means a multi-lateral interconnection arrangement. but other CDNI agreements are totally possible too, like symmetric bilateral or asymmetric bilateral ✨ the big takeaway here is that CDNI tech should not presume (or bake in) any one particular interconnection agreement. it should stay general enough that alternative arrangements can evolve over time 💅
the second concept that gets thrown around with CDN Federation is CDN Exchange 🦋 that's a third-party broker or exchange that helps facilitate a CDN federation. our view is that a CDN exchange offers really valuable machinery for scaling the number of CDN operators in a multi-lateral (federated) agreement. but that machinery is built on top of the core CDNI mechanisms, not instead of them 🔥 for example, as shown in Figure 14, the exchange might aggregate and redistribute information about each CDN footprint and capacity. it might also collect, filter, and redistribute the 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 all fundamentally involve a direct interaction between an Upstream CDN and a Downstream CDN. those operate exactly as they would in a pair-wise peering arrangement 🧚 okay now let's look at Figure 14, because in this example:
- each CDN supports a direct CDNI Control interface to every other CDN
- each CDN supports a direct CDNI Metadata interface to every other CDN
- each CDN supports a CDNI Logging interface with the CDN Exchange
- each CDN supports both a CDNI Request Routing interface with the CDN Exchange (for aggregation and redistribution of dynamic CDN footprint discovery information) and a direct RI to every other CDN (for actual request redirection)
---------- ---------
/ CDN A \ / CDN B \
| +----+ | | +----+ |
//========>| C |<==============CDNI============>| C |<==========\\
|| | +----+ | C | +----+ | ||
|| | +----+ | | +----+ | ||
|| //=====>| D |<==============CDNI============>| D |<=======\\ ||
|| || | +----+ | M | +----+ | || ||
|| || | | /------------\ | | || ||
|| || | +----+ | | +--+ CDN Ex| | +----+ | || ||
|| || //==>| RR |<===CDNI==>|RR|<=======CDNI====>| RR |<====\\ || ||
|| || || | +----+ | RR | +--+ | RR | +----+ | || || ||
|| || || | | | /\ | | | || || ||
|| || || | +----+ | | || +---+ | | +----+ | || || ||
|| || || | | L |<===CDNI=======>| L |<=CDNI====>| L | | || || ||
|| || || | +----+ | L | || +---+ | L | +----+ | || || ||
|| || || \ / \ || /\ / \ / || || ||
|| || || ----------- --||----||-- ----------- || || ||
|| || || || || || || ||
|| || || CDNI RR || || || ||
|| || || || CDNI L || || ||
|| || || || || || || ||
|| || || ---||----||---- || || ||
|| || || / \/ || \ || || ||
|| || || | +----+ || | || || ||
|| || \\=====CDNI==========>| RR |<=============CDNI========// || ||
|| || RR | +----+ \/ | RR || ||
|| || | +----+ | || ||
|| || | | L | | || ||
|| || | +----+ | || ||
|| || | +----+ | || ||
|| \\=======CDNI===========>| D |<=============CDNI===========// ||
|| M | +----+ | M ||
|| | +----+ | ||
\\==========CDNI===========>| C |<=============CDNI==============//
C | +----+ | C
\ CDN C /
--------------
<=CDNI RR=> CDNI Request Routing Interface
<=CDNI M==> CDNI Metadata Interface
<=CDNI C==> CDNI Control Interface
<=CDNI L==> CDNI Logging Interface
Figure 14: CDNI Deployment Model: CDN ExchangeNote that a CDN exchange may alternatively support a different set of functionality 🍓 for instance, Logging only, or Logging and full request routing, or all the functionality of a CDN including content distribution. all of these options are expected to be allowed by the IETF CDNI specifications 🎀
6. Trust Model 🔐
okay the trust stuff is a BIG deal 😭 there are a number of trust issues a CDNI solution needs to address, and lots of them are similar or identical to the ones in a simple CDN without any interconnection. in a standard CDN environment (no CDNI), the CSP places a degree of trust in a single CDN operator to do a bunch of things. 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 for reliable accounting info about how much content was delivered. the CSP may also trust the CDN operator to do things like timely invalidation of content and restricting access to content based on criteria such as the user's location and time of day. it can also trust the CDN to enforce per-request authorization done by the CSP, using techniques like URI signing 💜
a CSP also places trust in the CDN not to distribute any info that's confidential to the CSP (for example, how popular a given piece of content is) or confidential to the end user (for example, which content has been watched by which user) 🙈
a CSP doesn't necessarily have to place complete trust in a CDN though ✨ a CSP will sometimes take steps to protect its content from improper distribution by a CDN, for example 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 like client-based metering to verify that the accounting info provided by the CDN is reliable. HTTP conditional requests may be used to give the CSP some checks on CDN operation. in other words, even though a CSP may trust a CDN to perform some functions in the short term, the CSP is usually able to verify whether those actions were performed correctly. if the CDN doesn't live up to expectations, the CSP can take action, like moving the content to a different CDN 🫶
one of the trust issues CDNI raises is transitive trust 🧚 a CDN that has a direct relationship with a CSP can now "outsource" delivery of content to another (Downstream) CDN. that CDN may in turn outsource delivery to yet another Downstream CDN, and so on, like a whole chain 🔗
the top-level CDN in that chain of delegation is responsible for making sure the requirements of the CSP are met. failing to do so is presumably just as serious as in the traditional single CDN case 💀 so an Upstream CDN is basically trusting a Downstream CDN to perform functions on its behalf in the exact same way a CSP trusts a single CDN. monitoring and reporting can similarly be used to verify that the Downstream CDN is performing appropriately. however, introducing multiple CDNs in the path between the CSP and the end user makes the picture way more complicated 😵💫 for example, third-party monitoring of CDN performance (or other aspects of operation, such as timely invalidation) might be able to identify that a problem occurred somewhere in the chain, but it might 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 the Downstream CDN is performing correctly. and if behavior isn't correct, it will take corrective action, which could include breaking off its relationship with that CDN 💅 we don't expect the trust relationship between a CSP and its "top level" CDN to differ significantly from what's found today in single CDN situations. BUT it does appear that more sophisticated tools and techniques for monitoring CDN performance and behavior will be needed to identify which CDN is at fault in a particular delivery chain 🔍
we expect that the detailed designs for the specific CDNI interfaces will need to take 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 transitive trust issues 🌈
7. Privacy Considerations 🙈
in general, a CDN has the opportunity to collect detailed info about end user behavior, for example by logging which files are being downloaded 👀 while interconnected CDNs as described in this document don't necessarily let any given CDN gather more info on any specific user, they potentially make it easier for a CDN to share this data with more parties. as an example, the whole purpose of the CDNI Logging interface is to let a dCDN share some of its log records with a uCDN. that's for billing purposes, and also for sharing traffic statistics with the Content Provider on whose behalf the content was delivered 📊 the fact that the CDNI interfaces provide ways to share potentially sensitive user data shows that appropriate privacy and confidentiality mechanisms need to be included in these interfaces. the definition of those mechanisms is handled in the respective CDN interface documents 🎀
8. Security Considerations 🔐✨
okay bestie, security time 😭🔐 a single CDN already has its own security drama, but this section is only about the extra stuff that shows up when CDNs get interconnected 🫶. like, if one CDN can distribute content on behalf of a CSP, there could be worries that the content ends up with people who aren't allowed to get it, and there are mechanisms for dealing with that 🔒. our focus here is how CDNI brings in new security issues that the single CDN case just doesn't have. for a deeper dive into the security requirements of CDNI, go check Section 9 of [RFC7337] 📖.
Lots of the CDNI security issues come down to the transitivity of trust (or lack of it) from Section 6 🤝. as we said earlier, the interface designs have to account for the extra risk that a CDN with whom a CSP has no direct relationship is now potentially distributing that CSP's content 💅. the mechanisms that handle this might look similar to the single CDN ones, but their suitability in this messier setup must be validated 🧐.
CDNs already offer ways to control access to content, like time-of-day restrictions, geo-blocking, and URI signing 🕰️🌍. these must keep working in CDNI environments, and that's gonna affect how certain CDNI interfaces get designed (metadata and request routing, for example) 🎀. for more on URI signing in CDNI, see [URI-SIGNING] 🔑.
Just like with a single CDN, each peer CDN must make sure it's not being used as an "open proxy" to deliver content on behalf of a malicious CSP 🚨. a single CDN usually handles this by having CSPs explicitly register the content (or origin servers) that are to be served. but simply passing that info along to peer Downstream CDNs can be sketchy, because it reveals more info than the Upstream CDN is willing to specify 🙈. (to that end, the content acquisition step in the earlier examples has the dCDN retrieve content from the uCDN instead of going directly to the origin server 💡.)
There are a few approaches to this problem 🛠️. one is for the uCDN to encode a signed token, generated from a shared secret, in each URL routed to a dCDN, and then the dCDN validates the request based on that token 🔐. another is for each Upstream CDN to advertise the set of CDN-Domains it serves, so the Downstream CDN checks each request against this set before caching and delivering the associated object 📋. it's super straightforward, but this approach requires operators to reveal additional information, which may or may not be an issue 🤷♀️.
8.1. Security of CDNI Interfaces
it's noted in [RFC7337] that all CDNI interfaces must be able to operate securely over insecure IP networks 🌐🔒. since the CDNI interfaces are expected to be implemented using existing application protocols like HTTP or Extensible Messaging and Presence Protocol (XMPP), we also expect that the security mechanisms available to those protocols may be used by the CDNI interfaces 💜. the details of how these interfaces get secured will be specified in the relevant interface documents 📝.
8.2. Digital Rights Management
Digital Rights Management (DRM), also sometimes called digital restrictions management 🎬, is often employed for content distributed via CDNs 🍿. in general, DRM relies on the CDN to distribute encrypted content, with decryption keys distributed to users by some other means (e.g., directly from the CSP to the end user) 🗝️. for this reason, DRM is considered out of scope [RFC6707] and doesn't introduce any additional security issues for CDNI 🙌.
9. Contributors 🌟
The following individuals contributed to this document 💖:
- Matt Caulfield
- Francois Le Faucheur
- Aaron Falk
- David Ferguson
- John Hartman
- Ben Niven-Jenkins
- Kent Leung
10. Acknowledgements 🌸
The authors would like to thank Huw Jones and Jinmei Tatuya for their helpful input to this document 🧚. in addition, the authors would like to thank Stephen Farrell, Ted Lemon, and Alissa Cooper for their reviews, which have helped to improve this document 👑.
11. Informative References 📚
[CONTROL-TRIGGERS]Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / Triggers", Work in Progress, July 2014. 🦋[FOOTPRINT-CAPABILITY]Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., and K. Ma, "CDNI Request Routing: Footprint and Capabilities Semantics", Work in Progress, July 2014. 🌈[LOGGING]Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., and R. Peterkofsky, "CDNI Logging Interface", Work in Progress, July 2014. 🪵[METADATA]Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K., and K. Ma, "CDN Interconnection Metadata", Work in Progress, July 2014. 🍓[REDIRECTION]Niven-Jenkins, B., Ed. and R. Brandenburg, Ed., "Request Routing Redirection Interface for CDN Interconnection", Work in Progress, April 2014. ↪️[RFC3466]Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003. 📜[RFC6707]Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012. 📜[RFC6770]Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, November 2012. 📜[RFC6983]van Brandenburg, R., van Deventer, O., Le Faucheur, F., and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)", RFC 6983, July 2013. 📜[RFC7337]Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, August 2014. 📜[URI-SIGNING]Leung, K., Faucheur, F., Downey, B., Brandenburg, R., and S. Leibrand, "URI Signing for CDN Interconnection (CDNI)", Work in Progress, March 2014. 🔏
Authors' Addresses 💌
Larry Peterson
Akamai Technologies, Inc.
8 Cambridge Center
Cambridge, MA 02142
USA
EMail: lapeters@akamai.com
Bruce Davie
VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
USA
EMail: bdavie@vmware.com
Ray van Brandenburg (editor)
TNO
Brassersplein 2
Delft 2612CT
the Netherlands
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nlthat's the whole spec, bestie!! 🎉💅 you survived all 14 parts and we are SO proud of you 😭💜
📦 where this page comes from
- ietf: rfc7336 2014-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms