summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7336.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7336.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7336.txt')
-rw-r--r--doc/rfc/rfc7336.txt3251
1 files changed, 3251 insertions, 0 deletions
diff --git a/doc/rfc/rfc7336.txt b/doc/rfc/rfc7336.txt
new file mode 100644
index 0000000..7ec6b7c
--- /dev/null
+++ b/doc/rfc/rfc7336.txt
@@ -0,0 +1,3251 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Peterson
+Request for Comments: 7336 Akamai Technologies, Inc.
+Obsoletes: 3466 B. Davie
+Category: Informational VMware, Inc.
+ISSN: 2070-1721 R. van Brandenburg, Ed.
+ TNO
+ August 2014
+
+
+ Framework for Content Distribution Network Interconnection (CDNI)
+
+Abstract
+
+ This document presents a framework for Content Distribution Network
+ Interconnection (CDNI). The purpose of the framework is to provide
+ an overall picture of the problem space of CDNI and to describe the
+ relationships among the various components necessary to interconnect
+ CDNs. CDNI requires the specification of interfaces and mechanisms
+ to address issues such as request routing, distribution metadata
+ exchange, and logging information exchange across CDNs. The intent
+ of this document is to outline what each interface needs to
+ accomplish and to describe how these interfaces and mechanisms fit
+ together, while leaving their detailed specification to other
+ documents. This document, in combination with RFC 6707, obsoletes
+ RFC 3466.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7336.
+
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 1]
+
+RFC 7336 CDNI Framework August 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 2]
+
+RFC 7336 CDNI Framework August 2014
+
+
+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 ........................................57
+
+
+
+
+
+
+Peterson, et al. Informational [Page 3]
+
+RFC 7336 CDNI Framework August 2014
+
+
+1. Introduction
+
+ This document provides an overview of the various components
+ necessary to interconnect CDNs, expanding on the problem statement
+ and use cases introduced in [RFC6770] and [RFC6707]. It describes
+ the necessary interfaces and mechanisms in general terms and outlines
+ how they fit together to form a complete system for CDN
+ Interconnection. Detailed specifications are left to other
+ documents. This document makes extensive use of message flow
+ examples to illustrate the operation of interconnected CDNs, but
+ these examples should be considered illustrative rather than
+ prescriptive.
+
+ [RFC3466] uses different terminology and models for "Content
+ (distribution) Internetworking (CDI)". It is also less prescriptive
+ in terms of interfaces. To avoid confusion, this document obsoletes
+ [RFC3466].
+
+1.1. Terminology
+
+ This document uses the core terminology defined in [RFC6707]. It
+ also introduces the following terms:
+
+ CDN-Domain: a hostname (Fully Qualified Domain Name -- FQDN) at the
+ beginning of a URL (excluding port and scheme), representing a set
+ of content that is served by a given CDN. For example, in the URL
+ http://cdn.csp.example/...rest of URL..., the CDN-Domain is
+ cdn.csp.example. A major role of CDN-Domain is to identify a
+ region (subset) of the URI space relative to which various CDNI
+ rules and policies apply. For example, a record of CDNI Metadata
+ might be defined for the set of resources corresponding to some
+ CDN-Domain.
+
+ Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN
+ for the purposes of communication with a peer CDN but that is not
+ found in client requests. Such CDN-Domains may be used for inter-
+ CDN acquisition, or as redirection targets, and enable a CDN to
+ distinguish a request from a peer CDN from an end-user request.
+
+ Delivering CDN: the CDN that ultimately delivers a piece of content
+ to the end user. The last in a potential sequence of Downstream
+ CDNs.
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 4]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ Iterative CDNI Request Redirection: When an Upstream CDN elects to
+ redirect a request towards a Downstream CDN, the Upstream CDN can
+ base its redirection purely on a local decision (and without
+ attempting to take into account how the Downstream CDN may in turn
+ redirect the user agent). In that case, the Upstream CDN
+ redirects the request to the Request Routing system in the
+ Downstream CDN, which in turn will decide how to redirect that
+ request: this approach is referred to as "Iterative" CDNI Request
+ Redirection.
+
+ Recursive CDNI Request Redirection: When an Upstream CDN elects to
+ redirect a request towards a Downstream CDN, the Upstream CDN can
+ query the Downstream CDN Request Routing system via the CDNI
+ Request Routing Redirection interface (or use information cached
+ from earlier similar queries) to find out how the Downstream CDN
+ wants the request to be redirected. This allows the Upstream CDN
+ to factor in the Downstream CDN response when redirecting the user
+ agent. This approach is referred to as "Recursive" CDNI Request
+ Redirection. Note that the Downstream CDN may elect to have the
+ request redirected directly to a Surrogate inside the Downstream
+ CDN, or to any other element in the Downstream CDN (or in another
+ CDN), to handle the redirected request appropriately.
+
+ Synchronous CDNI operations: operations between CDNs that happen
+ during the process of servicing a user request, i.e., between the
+ time that the user agent begins its attempt to obtain content and
+ the time at which that request is served.
+
+ Asynchronous CDNI operations: operations between CDNs that happen
+ independently of any given user request, such as advertisement of
+ footprint information or pre-positioning of content for later
+ delivery.
+
+ Trigger Interface: a subset of the CDNI Control interface that
+ includes operations to pre-position, revalidate, and purge both
+ metadata and content. These operations are typically called in
+ response to some action (Trigger) by the Content Service Provider
+ (CSP) on the Upstream CDN.
+
+ We also sometimes use uCDN and dCDN as shorthand for Upstream CDN and
+ Downstream CDN (see [RFC6707]), respectively.
+
+ At various points in this document, the concept of a CDN footprint is
+ used. For a discussion on what constitutes a CDN footprint, the
+ reader is referred to [FOOTPRINT-CAPABILITY].
+
+
+
+
+
+
+Peterson, et al. Informational [Page 5]
+
+RFC 7336 CDNI Framework August 2014
+
+
+1.2. Reference Model
+
+ This document uses the reference model in Figure 1, which expands the
+ reference model originally defined in [RFC6707]. (The difference is
+ that the expanded model splits the Request Routing interface into its
+ two distinct parts: the Request Routing Redirection interface and the
+ Footprint & Capabilities Advertisement interface, as described
+ below.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 6]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ --------
+ / \
+ | 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 Interfaces
+
+
+
+Peterson, et al. Informational [Page 7]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ While some interfaces in the reference model are "out of scope" for
+ the CDNI WG (in the sense that there is no need to define new
+ protocols for those interfaces), we note that we still need to refer
+ to them in this document to explain the overall operation of CDNI.
+
+ We also note that, while we generally show only one Upstream CDN
+ serving a given CSP, it is entirely possible that multiple uCDNs can
+ serve a single CSP. In fact, this situation effectively exists today
+ in the sense that a single CSP can currently delegate its content
+ delivery to more than one CDN.
+
+ The following briefly describes the five CDNI interfaces,
+ paraphrasing the definitions given in [RFC6707]. We discuss these
+ interfaces in more detail in Section 4.
+
+ o CDNI Control interface (CI): Operations to bootstrap and
+ parameterize the other CDNI interfaces, as well as operations to
+ pre-position, revalidate, and purge both metadata and content.
+ The latter subset of operations is sometimes collectively called
+ the "Trigger interface".
+
+ o CDNI Request Routing interface: Operations to determine what CDN
+ (and optionally what Surrogate within a CDN) is to serve end-user
+ requests. This interface is actually a logical bundling of two
+ separate, but related, interfaces:
+
+ * CDNI Footprint & Capabilities Advertisement interface (FCI):
+ Asynchronous operations to exchange routing information (e.g.,
+ the network footprint and capabilities served by a given CDN)
+ that enables CDN selection for subsequent user requests; and
+
+ * CDNI Request Routing Redirection interface (RI): Synchronous
+ operations to select a delivery CDN (Surrogate) for a given
+ user request.
+
+ o CDNI Metadata interface (MI): Operations to communicate metadata
+ that governs how the content is delivered by interconnected CDNs.
+ Examples of CDNI Metadata include geo-blocking directives,
+ availability windows, access control mechanisms, and purge
+ directives. It may include a combination of:
+
+ * Asynchronous operations to exchange metadata that govern
+ subsequent user requests for content; and
+
+ * Synchronous operations that govern behavior for a given user
+ request for content.
+
+
+
+
+
+Peterson, et al. Informational [Page 8]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ o CDNI Logging interface (LI): Operations that allow interconnected
+ CDNs to 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 division between the sets of Trigger-based operations in the CDNI
+ Control interface and the CDNI Metadata interface is somewhat
+ arbitrary. For both cases, the information passed from the Upstream
+ CDN to the Downstream CDN can broadly be viewed as metadata that
+ describes how content is to be managed by the Downstream CDN. For
+ example, the information conveyed by the CI to pre-position,
+ revalidate, or purge metadata is similar to the information conveyed
+ by posting updated metadata via the MI. Even the CI operation to
+ purge content could be viewed as a metadata update for that content:
+ purge simply says that the availability window for the named content
+ ends now. The two interfaces share much in common, so minimally,
+ there will need to be a consistent data model that spans both.
+
+ The distinction we draw has to do with what the uCDN knows about the
+ successful application of the metadata by the dCDN. In the case of
+ the CI, the Downstream CDN returning a successful status message
+ guarantees that the operation has been successfully completed; for
+ example, the content has been purged or pre-positioned. This implies
+ that the Downstream CDN accepts responsibility for having
+ successfully completed the requested operation. In contrast,
+ metadata passed between CDNs via the MI carries no such completion
+ guarantee. Returning success implies successful receipt of the
+ metadata, but nothing can be inferred about precisely when the
+ metadata will take effect in the Downstream CDN, only that it will
+ take effect eventually. This is because of the challenge in globally
+ synchronizing updates to metadata with end-user requests that are
+ currently in progress (or indistinguishable from currently being in
+ progress). Clearly, a CDN will not be viewed as a trusted peer if
+ "eventually" often becomes an indefinite period of time, but the
+ acceptance of responsibility cannot be as crisply defined for the MI.
+
+ Finally, there is a practical issue that impacts all of the CDNI
+ interfaces, and that is whether or not to optimize CDNI for HTTP
+ Adaptive Streaming (HAS). We highlight specific issues related to
+ delivering HAS content throughout this document, but for a more
+ thorough treatment of the topic, see [RFC6983].
+
+
+
+
+
+
+Peterson, et al. Informational [Page 9]
+
+RFC 7336 CDNI Framework August 2014
+
+
+1.3. Structure of This Document
+
+ The remainder of this document is organized as follows:
+
+ o Section 2 describes some essential building blocks for CDNI,
+ notably the various options for redirecting user requests to a
+ given CDN.
+
+ o Section 3 provides a number of illustrative examples of various
+ CDNI operations.
+
+ o Section 4 describes the functionality of the main CDNI interfaces.
+
+ o Section 5 shows how various deployment models of CDNI may be
+ achieved using the defined interfaces.
+
+ o Section 6 describes the trust model of CDNI and the issues of
+ transitive trust in particular that CDNI raises.
+
+2. Building Blocks
+
+2.1. Request Redirection
+
+ At its core, CDNI requires the redirection of requests from one CDN
+ to another. For any given request that is received by an Upstream
+ CDN, it will either respond to the request directly, or somehow
+ redirect the request to a Downstream CDN. Two main mechanisms are
+ available for redirecting a request to a Downstream CDN. The first
+ leverages the DNS name resolution process and the second uses
+ application-layer redirection mechanisms such as the HTTP 302 or
+ Real-Time Streaming Protocol (RTSP) 302 redirection responses. While
+ there exists a large variety of application-layer protocols that
+ include some form of redirection mechanism, this document will use
+ HTTP (and HTTPS) in its examples. Similar mechanisms can be applied
+ to other application-layer protocols. What follows is a short
+ discussion of both DNS- and HTTP-based redirection, before presenting
+ some examples of their use in Section 3.
+
+2.1.1. DNS Redirection
+
+ DNS redirection is based on returning different IP addresses for the
+ same DNS name, for example, to balance server load or to account for
+ the client's location in the network. A DNS server, sometimes called
+ the Local DNS (LDNS), resolves DNS names on behalf of an end user.
+ The LDNS server in turn queries other DNS servers until it reaches
+ the authoritative DNS server for the CDN-Domain. The network
+ operator typically provides the LDNS server, although the user is
+ free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).
+
+
+
+Peterson, et al. Informational [Page 10]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ This latter possibility is important because the authoritative DNS
+ server sees only the IP address of the DNS server that queries it,
+ not the IP address of the original end user.
+
+ The advantage of DNS redirection is that it is completely transparent
+ to the end user; the user sends a DNS name to the LDNS server and
+ gets back an IP address. On the other hand, DNS redirection is
+ problematic because the DNS request comes from the LDNS server, not
+ the end user. This may affect the accuracy of server selection that
+ is based on the user's location. The transparency of DNS redirection
+ is also a problem in that there is no opportunity to take the
+ attributes of the user agent or the URI path component into account.
+ We consider two main forms of DNS redirection: simple and CNAME-
+ based.
+
+ In simple DNS redirection, the authoritative DNS server for the name
+ simply returns an IP address from a set of possible IP addresses.
+ The answer is chosen from the set based on characteristics of the set
+ (e.g., the relative loads on the servers) or characteristics of the
+ client (e.g., the location of the client relative to the servers).
+ Simple redirection is straightforward. The only caveats are (1)
+ there is a limit to the number of 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 so as to preserve the freshness of the redirection.
+
+ In CNAME-based DNS redirection, the authoritative server returns a
+ CNAME response to the DNS request, telling the LDNS server to restart
+ the name lookup using a new name. A CNAME is essentially a symbolic
+ link in the DNS namespace, and like a symbolic link, redirection is
+ transparent to the client; the LDNS server gets the CNAME response
+ and re-executes the lookup. Only when the name has been resolved to
+ an IP address does it return the result to the user. Note that DNAME
+ would be preferable to CNAME if it becomes widely supported.
+
+ One of the advantages of DNS redirection compared to HTTP redirection
+ is that it can be cached, reducing load on the redirecting CDN's DNS
+ server. However, this advantage can also be a drawback, especially
+ when a given DNS resolver doesn't strictly adhere to the TTL, which
+ is a known problem in some real-world environments. In such cases,
+ an end user might end up at a dCDN without first having passed
+ through the uCDN, which might be an undesirable scenario from a uCDN
+ point of view.
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 11]
+
+RFC 7336 CDNI Framework August 2014
+
+
+2.1.2. HTTP Redirection
+
+ HTTP redirection makes use of 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 appropriately, the server can cause the user to
+ redirect to a different server. The advantages of HTTP redirection
+ are that (1) the server can change the URL fetched by the client to
+ include, for example, both the DNS name of the particular server to
+ use, as well as the original HTTP server that was being accessed; (2)
+ the client sends the HTTP request to the server, so that its IP
+ address is known and can be used in selecting the server; and (3)
+ other attributes (e.g., content type, user agent type) are visible to
+ the redirection mechanism.
+
+ Just as is the case for DNS redirection, there are some potential
+ disadvantages of using HTTP redirection. For example, it may affect
+ application behavior; web browsers will not send cookies if the URL
+ changes to a different domain. In addition, although this might also
+ be an advantage, results of HTTP redirection are not cached so that
+ all redirections must go through to the uCDN.
+
+3. Overview of CDNI Operation
+
+ To provide a big-picture overview of the various components of CDNI,
+ we walk through a "day in the life" of a content item that is made
+ available via a pair of interconnected CDNs. This will serve to
+ illustrate many of the functions that need to be supported in a
+ complete CDNI solution. We give examples using both DNS-based and
+ HTTP-based redirection. We begin with very simple examples and then
+ show how additional capabilities, such as recursive request
+ redirection and content removal, might be added.
+
+ Before walking through the specific examples, we present a high-level
+ view of the operations that may take place. This high-level overview
+ is illustrated in Figure 2. Note that most operations will involve
+ only a subset of all the messages shown below, and that the order and
+ number of operations may vary considerably, as the more detailed
+ examples illustrate.
+
+ The following shows Operator A as the Upstream CDN (uCDN) and
+ Operator B as the Downstream CDN (dCDN), where the former has a
+ relationship with a content provider and the latter is the CDN
+ selected by Operator A to deliver content to the end user. The
+ interconnection relationship may be symmetric between these two CDN
+ operators, but each direction can be considered as operating
+ independently of the other; for simplicity, we show the interaction
+ in one direction only.
+
+
+
+Peterson, et al. Informational [Page 12]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ End User Operator B Operator A
+ | | |
+ | | |
+ | | [Async FCI Push] | (1)
+ | | |
+ | | [MI pre-positioning] | (2)
+ | | |
+ | CONTENT REQUEST | |
+ |-------------------------------------------------->| (3)
+ | | |
+ | | [Sync RI Pull] | (4)
+ | | |
+ | CONTENT REQUEST REDIRECTION |
+ |<--------------------------------------------------| (5)
+ | | |
+ | | |
+ | CONTENT REQUEST | |
+ |------------------------>| | (6)
+ | | |
+ | | [Sync MI Pull] | (7)
+ | | |
+ | | ACQUISITION REQUEST |
+ | X------------------------>| (8)
+ | X |
+ | X CONTENT DATA |
+ | X<------------------------| (9)
+ | | |
+ | CONTENT DATA | |
+ |<------------------------| | (10)
+ | | |
+ : : :
+ : [Other content requests] :
+ : : :
+ | | [CI: Content Purge] | (11)
+ : : :
+ | | [LI: Log exchange] | (12)
+ | | |
+
+ Figure 2: Overview of Operation
+
+ The operations shown in the figure are as follows:
+
+ 1. The dCDN uses the FCI to advertise information relevant to its
+ delivery footprint and capabilities prior to any content
+ requests being redirected.
+
+
+
+
+
+
+Peterson, et al. Informational [Page 13]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ 2. Prior to any content request, the uCDN uses the MI to pre-
+ position CDNI Metadata to the dCDN, thereby making that metadata
+ available in readiness for later content requests.
+
+ 3. A content request from a user agent arrives at the uCDN.
+
+ 4. The uCDN may use the RI to synchronously request information
+ from the dCDN regarding its delivery capabilities to decide if
+ the dCDN is a suitable target for redirection of this request.
+
+ 5. The uCDN redirects the request to the dCDN by sending some
+ response (DNS, HTTP) to the user agent.
+
+ 6. The user agent requests the content from the dCDN.
+
+ 7. The dCDN may use the MI to synchronously request metadata
+ related to this content from uCDN, e.g., to decide whether to
+ serve it.
+
+ 8. If the content is not already in a suitable cache in the dCDN,
+ the dCDN may acquire it from the uCDN.
+
+ 9. The content is delivered to the dCDN from the uCDN.
+
+ 10. The content is delivered to the user agent by the dCDN.
+
+ 11. Some time later, perhaps at the request of the CSP (not shown)
+ the uCDN may use the CI to instruct the dCDN to purge the
+ content, thereby ensuring it is not delivered again.
+
+ 12. After one or more content delivery actions by the dCDN, a log of
+ delivery actions may be provided to the uCDN using the LI.
+
+ The following sections show some more specific examples of how these
+ operations may be combined to perform various delivery, control, and
+ logging operations across a pair of CDNs.
+
+3.1. Preliminaries
+
+ Initially, we assume that there is at least one CSP that has
+ contracted with an Upstream CDN (uCDN) to deliver content on its
+ behalf. We are not particularly concerned with the interface between
+ the CSP and uCDN, other than to note that it is expected to be the
+ same as in the "traditional" (non-interconnected) CDN case. Existing
+ mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be
+ used to direct a user request for a piece of content from the CSP
+ towards the CSP's chosen Upstream CDN.
+
+
+
+
+Peterson, et al. Informational [Page 14]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ We assume Operator A provides an Upstream CDN that serves content on
+ behalf of a CSP with CDN-Domain cdn.csp.example. We assume that
+ Operator B provides a Downstream CDN. An end user at some point
+ makes a request for URL
+
+ http://cdn.csp.example/...rest of URL...
+
+ It may well be the case that cdn.csp.example is just a CNAME for some
+ other CDN-Domain (such as csp.op-a.example). Nevertheless, the HTTP
+ request in the examples that follow is assumed to be for the example
+ URL above.
+
+ Our goal is to enable content identified by the above URL to be
+ served by the CDN of Operator B. In the following sections, we will
+ walk through some scenarios in which content is served as well as
+ other CDNI operations such as the removal of content from a
+ Downstream CDN.
+
+3.2. Iterative HTTP Redirect Example
+
+ In this section, we walk through a simple, illustrative example using
+ HTTP redirection from a uCDN to a dCDN. The example also assumes the
+ use of HTTP redirection inside the uCDN and dCDN; however, this is
+ independent of the choice of redirection approach across CDNs, so an
+ alternative example could be constructed still showing HTTP
+ redirection from the uCDN to dCDN but using DNS for the handling of
+ the request inside each CDN.
+
+ For this example, we assume that Operators A and B have established
+ an agreement to interconnect their CDNs, with A being Upstream and B
+ being Downstream.
+
+ The operators agree that a CDN-Domain peer-a.op-b.example will be
+ used as the target of redirections from the uCDN to dCDN. We assume
+ the name of this domain is communicated by some means to each CDN.
+ (This could be established out of band or via a CDNI interface.) We
+ refer to this domain as a "distinguished" CDN-Domain to convey the
+ fact that its use is limited to the interconnection mechanism; such a
+ domain is never used directly by a CSP.
+
+ We assume the operators also agree on some distinguished CDN-Domain
+ that will be used for inter-CDN acquisition of the CSP's content from
+ the uCDN by the dCDN. In this example, we'll use
+ op-b-acq.op-a.example.
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 15]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ We assume the operators also exchange information regarding which
+ requests the dCDN is prepared to serve. For example, the dCDN may be
+ prepared to serve requests from clients in a given geographical
+ region or a set of IP address prefixes. This information may again
+ be provided out of band or via a defined CDNI interface.
+
+ We assume DNS is configured in the following way:
+
+ o The content provider is configured to make Operator A the
+ authoritative DNS server for cdn.csp.example (or to return a CNAME
+ for cdn.csp.example for which Operator A is the authoritative DNS
+ server).
+
+ o Operator A is configured so that a DNS request for
+ op-b-acq.op-a.example returns a Request Router in Operator A.
+
+ o Operator B is configured so that a DNS request for
+ peer-a.op-b.example/cdn.csp.example returns a Request Router in
+ Operator B.
+
+ Figure 3 illustrates how a client request for
+
+ http://cdn.csp.example/...rest of URL...
+
+ is handled.
+
+
+ End User Operator B Operator A
+ |DNS cdn.csp.example | |
+ |-------------------------------------------------->|
+ | | |(1)
+ |IPaddr of A's Request Router |
+ |<--------------------------------------------------|
+ |HTTP cdn.csp.example | |
+ |-------------------------------------------------->|
+ | | |(2)
+ |302 peer-a.op-b.example/cdn.csp.example |
+ |<--------------------------------------------------|
+ |DNS peer-a.op-b.example | |
+ |------------------------>| |
+ | |(3) |
+ |IPaddr of B's Request Router |
+ |<------------------------| |
+ | | |
+ |HTTP peer-a.op-b.example/cdn.csp.example |
+ |------------------------>| |
+
+
+
+
+
+Peterson, et al. Informational [Page 16]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ | |(4) |
+ |302 node1.peer-a.op-b.example/cdn.csp.example |
+ |<------------------------| |
+ |DNS node1.peer-a.op-b.example |
+ |------------------------>| |
+ | |(5) |
+ |IPaddr of B's Delivery Node |
+ |<------------------------| |
+ | | |
+ |HTTP node1.peer-a.op-b.example/cdn.csp.example |
+ |------------------------>| |
+ | |(6) |
+ | |DNS op-b-acq.op-a.example|
+ | |------------------------>|
+ | | |(7)
+ | |IPaddr of A's Request Router
+ | |<------------------------|
+ | |HTTP op-b-acq.op-a.example
+ | |------------------------>|
+ | | |(8)
+ | |302 node2.op-b-acq.op-a.example
+ | |<------------------------|
+ | |DNS node2.op-b-acq.op-a.example
+ | |------------------------>|
+ | | |(9)
+ | |IPaddr of A's Delivery Node
+ | |<------------------------|
+ | | |
+ | |HTTP node2.op-b-acq.op-a.example
+ | |------------------------>|
+ | | |(10)
+ | |Data |
+ | |<------------------------|
+ |Data | |
+ |<------------------------| |
+
+ Figure 3: Message Flow for Iterative HTTP Redirection
+
+ The steps illustrated in the figure are as follows:
+
+ 1. A DNS resolver for Operator A processes the DNS request for its
+ customer based on CDN-Domain cdn.csp.example. It returns the IP
+ address of a Request Router in Operator A.
+
+ 2. A Request Router for Operator A processes the HTTP request and
+ recognizes that the end user is best served by another CDN,
+ specifically one provided by Operator B, and so it returns a 302
+ redirect message for a new URL constructed by "stacking"
+
+
+
+Peterson, et al. Informational [Page 17]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ Operator B's distinguished CDN-Domain (peer-a.op-b.example) on
+ the front of the original URL. (Note that more complex URL
+ manipulations are possible, such as replacing the initial CDN-
+ Domain by some opaque handle.)
+
+ 3. The end user does a DNS lookup using Operator B's distinguished
+ CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the
+ IP address of a Request Router for Operator B. Note that if
+ request routing within the dCDN was performed using DNS instead
+ of HTTP redirection, B's DNS resolver would also behave as the
+ Request Router and directly return the IP address of a delivery
+ node.
+
+ 4. The Request Router for Operator B processes the HTTP request and
+ selects a suitable delivery node to serve the end-user request,
+ and it returns a 302 redirect message for a new URL constructed
+ by replacing the hostname with a subdomain of the Operator B's
+ distinguished CDN-Domain that points to the selected delivery
+ node.
+
+ 5. The end user does a DNS lookup using Operator B's delivery node
+ subdomain (node1.peer-a.op-b.example). B's DNS resolver returns
+ the IP address of the delivery node.
+
+ 6. The end user requests the content from B's delivery node. In
+ the case of a cache hit, steps 6, 7, 8, 9, and 10 below do not
+ happen, and the content data is directly returned by the
+ delivery node to the end user. In the case of a cache miss, the
+ content needs to be acquired by the dCDN from the uCDN (not the
+ CSP). The distinguished CDN-Domain peer-a.op-b.example
+ indicates to the dCDN that this content is to be acquired from
+ the uCDN; stripping the CDN-Domain reveals the original CDN-
+ Domain cdn.csp.example, and the dCDN may verify that this CDN-
+ Domain belongs to a known peer (so as to avoid being tricked
+ into serving as an open proxy). It then does a DNS request for
+ an inter-CDN acquisition CDN-Domain as agreed above (in this
+ case, op-b-acq.op-a.example).
+
+ 7. Operator A's DNS resolver processes the DNS request and returns
+ the IP address of a Request Router in Operator A.
+
+ 8. The Request Router for Operator A processes the HTTP request
+ from Operator B's delivery node. Operator A's Request Router
+ recognizes that the request is from a peer CDN rather than an
+ end user because of the dedicated inter-CDN acquisition domain
+ (op-b-acq.op-a.example). (Note that without this specially
+ defined inter-CDN acquisition domain, Operator A would be at
+ risk of redirecting the request back to Operator B, resulting in
+
+
+
+Peterson, et al. Informational [Page 18]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ an infinite loop). The Request Router for Operator A selects a
+ suitable delivery node in uCDN to serve the inter-CDN
+ acquisition request and returns a 302 redirect message for a new
+ URL constructed by replacing the hostname with a subdomain of
+ the Operator A's distinguished inter-CDN acquisition domain that
+ points to the selected delivery node.
+
+ 9. Operator A's DNS resolver processes the DNS request and returns
+ the IP address of the delivery node in Operator A.
+
+ 10. Operator B requests (acquires) the content from Operator A.
+ Although not shown, Operator A processes the rest of the URL: it
+ extracts information identifying the origin server, validates
+ that this server has been registered, and determines the content
+ provider that owns the origin server. It may also perform its
+ own content acquisition steps if needed before returning the
+ content to dCDN.
+
+ The main advantage of this design is that it is simple: each CDN need
+ only know the distinguished CDN-Domain for each peer, with the
+ Upstream CDN "pushing" the Downstream CDN-Domain onto the URL as part
+ of its redirect (step 2), and the Downstream CDN "popping" its CDN-
+ Domain off the URL to expose a CDN-Domain that the Upstream CDN can
+ correctly process. Neither CDN need be aware of the internal
+ structure of the other's URLs. Moreover, the inter-CDN redirection
+ is entirely supported by a single HTTP redirect; neither CDN need be
+ aware of the other's internal redirection mechanism (i.e., whether it
+ is DNS or HTTP based).
+
+ One disadvantage is that the end user's browser is redirected to a
+ new URL that is not in the same domain of the original URL. This has
+ implications on a number of security or validation mechanisms
+ sometimes used on endpoints. For example, it is important that any
+ redirected URL be in the same domain (e.g., csp.example) if the
+ browser is expected to send any cookies associated with that domain.
+ As another example, some video players enforce validation of a cross-
+ domain policy that needs to accommodate the domains involved in the
+ CDN redirection. These problems are generally solvable, but the
+ solutions complicate the example, so we do not discuss them further
+ in this document.
+
+ We note that this example begins to illustrate some of the interfaces
+ that may be required for CDNI, but it does not require all of them.
+ For example, obtaining information from a dCDN regarding the set of
+ client IP addresses or geographic regions it might be able to serve
+ is an aspect of request routing (specifically of the CDNI Footprint &
+ Capabilities Advertisement interface). Important configuration
+ information such as the distinguished names used for redirection and
+
+
+
+Peterson, et al. Informational [Page 19]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ inter-CDN acquisition could also be conveyed via a CDNI interface
+ (e.g., perhaps the CDNI Control interface). The example also shows
+ how existing HTTP-based methods suffice for the acquisition
+ interface. Arguably, the absolute minimum metadata required for CDNI
+ is the information required to acquire the content, and this
+ information was provided "in-band" in this example by means of the
+ URI handed to the client in the HTTP 302 response. The example also
+ assumes that the CSP does not require any distribution policy (e.g.,
+ time window or geo-blocking) or delivery processing to be applied by
+ the interconnected CDNs. Hence, there is no explicit CDNI Metadata
+ interface invoked in this example. There is also no explicit CDNI
+ Logging interface discussed in this example.
+
+ We also note that the step of deciding when a request should be
+ redirected to the dCDN rather than served by the uCDN has been
+ somewhat glossed over. It may be as simple as checking the client IP
+ address against a list of prefixes, or it may be considerably more
+ complex, involving a wide range of factors, such as the geographic
+ location of the client (perhaps determined from a third-party
+ service), CDN load, or specific business rules.
+
+ This example uses the "iterative" CDNI request redirection approach.
+ That is, a uCDN performs part of the request redirection function by
+ redirecting the client to a Request Router in the dCDN, which then
+ performs the rest of the redirection function by redirecting to a
+ suitable Surrogate. If request routing is performed in the dCDN
+ using HTTP redirection, this translates in the end user experiencing
+ two successive HTTP redirections. By contrast, the alternative
+ approach of "recursive" CDNI request redirection effectively
+ coalesces these two successive HTTP redirections into a single one,
+ sending the end user directly to the right delivery node in the dCDN.
+ This "recursive" CDNI request routing approach is discussed in the
+ next section.
+
+ While the example above uses HTTP, the iterative HTTP redirection
+ mechanism would work over HTTPS in a similar fashion. In order to
+ make sure an end user's HTTPS request is not downgraded to HTTP along
+ the redirection path, it is necessary for every Request Router along
+ the path from the initial uCDN Request Router to the final Surrogate
+ in the dCDN to respond to an incoming HTTPS request with an HTTP
+ redirect containing an HTTPS URL. It should be noted that using
+ HTTPS will have the effect of increasing the total redirection
+ process time and increasing the load on the Request Routers,
+ especially when the redirection path includes many redirects and thus
+ many Secure Socket Layer/Transport Layer Security (SSL/TLS) sessions.
+ In such cases, a recursive HTTP redirection mechanism, as described
+ in an example in the next section, might help to reduce some of these
+ issues.
+
+
+
+Peterson, et al. Informational [Page 20]
+
+RFC 7336 CDNI Framework August 2014
+
+
+3.3. Recursive HTTP Redirection Example
+
+ The following example builds on the previous one to illustrate the
+ use of the request routing interface (specifically, the CDNI Request
+ Routing Redirection interface) to enable "recursive" CDNI request
+ routing. We build on the HTTP-based redirection approach because it
+ illustrates the principles and benefits clearly, but it is equally
+ possible to perform recursive redirection when DNS-based redirection
+ is employed.
+
+ In contrast to the prior example, the operators need not agree in
+ advance on a CDN-Domain to serve as the target of redirections from
+ the uCDN to dCDN. We assume that the operators agree on some
+ distinguished CDN-Domain that will be used for inter-CDN acquisition
+ of the CSP's content by dCDN. In this example, we'll use
+ op-b-acq.op-a.example.
+
+ We assume the operators also exchange information regarding which
+ requests the dCDN is prepared to serve. For example, the dCDN may be
+ prepared to serve requests from clients in a given geographical
+ region or a set of IP address prefixes. This information may again
+ be provided out of band or via a defined protocol.
+
+ We assume DNS is configured in the following way:
+
+ o The content provider is configured to make Operator A the
+ authoritative DNS server for cdn.csp.example (or to return a CNAME
+ for cdn.csp.example for which Operator A is the authoritative DNS
+ server).
+
+ o Operator A is configured so that a DNS request for
+ op-b-acq.op-a.example returns a Request Router in Operator A.
+
+ o Operator B is configured so that a request for node1.op-b.example/
+ cdn.csp.example returns the IP address of a delivery node. Note
+ that there might be a number of such delivery nodes.
+
+ Figure 3 illustrates how a client request for
+
+ http://cdn.csp.example/...rest of URL...
+
+ is handled.
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 21]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ 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)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 22]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ | |302 node2.op-b-acq.op-a.example
+ | |<------------------------|
+ | |DNS node2.op-b-acq.op-a.example
+ | |------------------------>|
+ | | |(8)
+ | |IPaddr of A's Delivery Node
+ | |<------------------------|
+ | | |
+ | |HTTP node2.op-b-acq.op-a.example
+ | |------------------------>|
+ | | |(9)
+ | |Data |
+ | |<------------------------|
+ |Data | |
+ |<------------------------| |
+
+ Figure 4: Message Flow for Recursive HTTP Redirection
+
+ The steps illustrated in the figure are as follows:
+
+ 1. A DNS resolver for Operator A processes the DNS request for its
+ customer based on CDN-Domain cdn.csp.example. It returns the IP
+ address of a Request Router in Operator A.
+
+ 2. A Request Router for Operator A processes the HTTP request and
+ recognizes that the end user is best served by another CDN --
+ specifically one provided by Operator B -- so it queries the CDNI
+ Request Routing Redirection interface of Operator B, providing a
+ set of information about the request including the URL requested.
+ Operator B replies with the DNS name of a delivery node.
+
+ 3. Operator A returns a 302 redirect message for a new URL obtained
+ from the RI.
+
+ 4. The end user does a DNS lookup using the hostname of the URL just
+ provided (node1.op-b.example). B's DNS resolver returns the IP
+ address of the corresponding delivery node. Note that, since the
+ name of the delivery node was already obtained from B using the
+ RI, there should not be any further redirection here (in contrast
+ to the iterative method described above.)
+
+ 5. The end user requests the content from B's delivery node,
+ potentially resulting in a cache miss. In the case of a cache
+ miss, the content needs to be acquired from the uCDN (not the
+ CSP.) The distinguished CDN-Domain op-b.example indicates to the
+ dCDN that this content is to be acquired from another CDN;
+ stripping the CDN-Domain reveals the original CDN-Domain
+ cdn.csp.example. The dCDN may verify that this CDN-Domain
+
+
+
+Peterson, et al. Informational [Page 23]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ belongs to a known peer (so as to avoid being tricked into
+ serving as an open proxy). It then does a DNS request for the
+ inter-CDN Acquisition "distinguished" CDN-Domain as agreed above
+ (in this case, op-b-acq.op-a.example).
+
+ 6. Operator A's DNS resolver processes the DNS request and returns
+ the IP address of a Request Router in Operator A.
+
+ 7. The Request Router for Operator A processes the HTTP request from
+ Operator B's delivery node. Operator A's Request Router
+ recognizes that the request is from a peer CDN rather than an end
+ user because of the dedicated inter-CDN acquisition domain
+ (op-b-acq.op-a.example). (Note that without this specially
+ defined inter-CDN acquisition domain, Operator A would be at risk
+ of redirecting the request back to Operator B, resulting in an
+ infinite loop). The Request Router for Operator A selects a
+ suitable delivery node in the uCDN to serve the inter-CDN
+ acquisition request and returns a 302 redirect message for a new
+ URL constructed by replacing the hostname with a subdomain of the
+ Operator A's distinguished inter-CDN acquisition domain that
+ points to the selected delivery node.
+
+ 8. Operator A recognizes that the DNS request is from a peer CDN
+ rather than an end user (due to the internal CDN-Domain) and so
+ returns the address of a delivery node. (Note that without this
+ specially defined internal domain, Operator A would be at risk of
+ redirecting the request back to Operator B, resulting in an
+ infinite loop.)
+
+ 9. Operator B requests (acquires) the content from Operator A.
+ Operator A serves content for the requested CDN-Domain to the
+ dCDN. Although not shown, it is at this point that Operator A
+ processes the rest of the URL: it extracts information
+ identifying the origin server, validates that this server has
+ been registered, and determines the content provider that owns
+ the origin server. It may also perform its own content
+ acquisition steps if needed before returning the content to the
+ dCDN.
+
+ Recursive redirection has the advantage (over iterative redirection)
+ of being more transparent from the end user's perspective but the
+ disadvantage of each CDN exposing more of its internal structure (in
+ particular, the addresses of edge caches) to peer CDNs. By contrast,
+ iterative redirection does not require the dCDN to expose the
+ addresses of its edge caches to the uCDN.
+
+
+
+
+
+
+Peterson, et al. Informational [Page 24]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ This example happens to use HTTP-based redirection in both CDN A and
+ CDN B, but a similar example could be constructed using DNS-based
+ redirection in either CDN. Hence, the key point to take away here is
+ simply that the end user only sees a single redirection of some type,
+ as opposed to the pair of redirections in the prior (iterative)
+ example.
+
+ The use of the RI requires that the request routing mechanism be
+ appropriately configured and bootstrapped, which is not shown here.
+ More discussion on the bootstrapping of interfaces is provided in
+ Section 4
+
+3.4. Iterative DNS-Based Redirection Example
+
+ In this section we walk through a simple example using DNS-based
+ redirection for request redirection from the uCDN to the dCDN (as
+ well as for request routing inside the dCDN and the uCDN). As noted
+ in Section 2.1, DNS-based redirection has certain advantages over
+ HTTP-based redirection (notably, it is transparent to the end user)
+ as well as some drawbacks (notably, the client IP address is not
+ visible to the Request Router).
+
+ As before, Operator A has to learn the set of requests that the dCDN
+ is willing or able to serve (e.g., which client IP address prefixes
+ or geographic regions are part of the dCDN footprint). We assume
+ Operator B has and makes known to Operator A some unique identifier
+ that can be used for the construction of a distinguished CDN-Domain,
+ as shown in more detail below. (This identifier strictly needs only
+ to be unique within the scope of Operator A, but a globally unique
+ identifier, such as an Autonomous System (AS) number assigned to B,
+ is one easy way to achieve that.) Also, Operator A obtains the NS
+ records for Operator B's externally visible redirection servers.
+ Also, as before, a distinguished CDN-Domain, such as
+ op-b-acq.op-a.example, must be assigned for inter-CDN acquisition.
+
+ We assume DNS is configured in the following way:
+
+ o The CSP is configured to make Operator A the authoritative DNS
+ server for cdn.csp.example (or to return a CNAME for
+ cdn.csp.example for which Operator A is the authoritative DNS
+ server).
+
+ o When uCDN sees a request best served by the dCDN, it returns CNAME
+ and NS records for "b.cdn.csp.example", where "b" is the unique
+ identifier assigned to Operator B. (It may, for example, be an AS
+ number assigned to Operator B.)
+
+
+
+
+
+Peterson, et al. Informational [Page 25]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ o The dCDN is configured so that a request for "b.cdn.csp.example"
+ returns a delivery node in the dCDN.
+
+ o The uCDN is configured so that a request for
+ "op-b-acq.op-a.example" returns a delivery node in the uCDN.
+
+ Figure 5 depicts the exchange of DNS and HTTP requests. The main
+ differences from Figure 3 are the lack of HTTP redirection and
+ transparency to the end user.
+
+ End User Operator B Operator A
+ |DNS cdn.csp.example | |
+ |-------------------------------------------------->|
+ | | |(1)
+ |CNAME b.cdn.csp.example | |
+ |<--------------------------------------------------|
+ | | |
+ |DNS b.cdn.csp.example | |
+ |-------------------------------------------------->|
+ | | |(2)
+ |NS records for b.cdn.csp.example + |
+ |Glue AAAA/A records for b.cdn.csp.example |
+ |<--------------------------------------------------|
+ | | |
+ |DNS b.cdn.csp.example | |
+ |------------------------>| |
+ | |(3) |
+ |IPaddr of B's Delivery Node |
+ |<------------------------| |
+ |HTTP cdn.csp.example | |
+ |------------------------>| |
+ | |(4) |
+ | |DNS op-b-acq.op-a.example|
+ | |------------------------>|
+ | | |(5)
+ | |IPaddr of A's Delivery Node
+ | |<------------------------|
+ | |HTTP op-b-acq.op-a.example
+ | |------------------------>|
+ | | |(6)
+ | |Data |
+ | |<------------------------|
+ |Data | |
+ |<------------------------| |
+
+ Figure 5: Message Flow for DNS-Based Redirection
+
+
+
+
+
+Peterson, et al. Informational [Page 26]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ The steps illustrated in the figure are as follows:
+
+ 1. The Request Router for Operator A processes the DNS request for
+ CDN-Domain cdn.csp.example and recognizes that the end user is
+ best served by another CDN. (This may depend on the IP address
+ of the user's LDNS resolver, or other information discussed
+ below.) The Request Router returns a DNS CNAME response by
+ "stacking" the distinguished identifier for Operator B onto the
+ original CDN-Domain (e.g., b.cdn.csp.example).
+
+ 2. The end user sends a DNS query for the modified CDN-Domain (i.e.,
+ b.cdn.csp.example) to Operator A's DNS server. The Request
+ Router for Operator A processes the DNS request and returns a
+ delegation to b.cdn.csp.example by sending an NS record plus glue
+ records pointing to Operator B's DNS server. (This extra step is
+ necessary since typical DNS implementation won't follow an NS
+ record when it is sent together with a CNAME record, thereby
+ necessitating a two-step approach.)
+
+ 3. The end user sends a DNS query for the modified CDN-Domain (i.e.,
+ b.cdn.csp.example) to Operator B's DNS server, using the NS and
+ AAAA/A records received in step 2. This causes B's Request
+ Router to respond with a suitable delivery node.
+
+ 4. The end user requests the content from B's delivery node. The
+ requested URL contains the name cdn.csp.example. (Note that the
+ returned CNAME does not affect the URL.) At this point, the
+ delivery node has the correct IP address of the end user and can
+ do an HTTP 302 redirect if the redirections in steps 2 and 3 were
+ incorrect. Otherwise, B verifies that this CDN-Domain belongs to
+ a known peer (so as to avoid being tricked into serving as an
+ open proxy). It then does a DNS request for an "internal" CDN-
+ Domain as agreed above (op-b-acq.op-a.example).
+
+ 5. Operator A recognizes that the DNS request is from a peer CDN
+ rather than an end user (due to the internal CDN-Domain) and so
+ returns the address of a delivery node in uCDN.
+
+ 6. Operator A serves content to dCDN. Although not shown, it is at
+ this point that Operator A processes the rest of the URL: it
+ extracts information identifying the origin server, validates
+ that this server has been registered, and determines the content
+ provider that owns the origin server.
+
+ The advantages of this approach are that it is more transparent to
+ the end user and requires fewer round trips than HTTP-based
+ redirection (in its worst case, i.e., when none of the needed DNS
+ information is cached). A potential problem is that the Upstream CDN
+
+
+
+Peterson, et al. Informational [Page 27]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ depends on being able to learn the correct Downstream CDN that serves
+ the end user from the client address in the DNS request. In standard
+ DNS operation, the uCDN will only obtain the address of the client's
+ LDNS resolver, which is not guaranteed to be in the same network (or
+ geographic region) as the client. If not (e.g., the end user uses a
+ global DNS service), then the Upstream CDN cannot determine the
+ appropriate Downstream CDN to serve the end user. In this case, and
+ assuming the uCDN is capable of detecting that situation, one option
+ is for the Upstream CDN to treat the end user as it would any user
+ not connected to a peer CDN. Another option is for the Upstream CDN
+ to "fall back" to a pure HTTP-based redirection strategy in this case
+ (i.e., use the first method). Note that this problem affects
+ existing CDNs that rely on DNS to determine where to redirect client
+ requests, but the consequences are arguably less serious for CDNI
+ since the LDNS is likely in the same network as the dCDN serves.
+
+ As with the prior example, this example partially illustrates the
+ various interfaces involved in CDNI. Operator A could learn
+ dynamically from Operator B the set of prefixes or regions that B is
+ willing and able to serve via the CDNI Footprint & Capabilities
+ Advertisement interface. The distinguished name used for acquisition
+ and the identifier for Operator B that is prepended to the CDN-Domain
+ on redirection are examples of information elements that might also
+ be conveyed by CDNI interfaces (or, alternatively, statically
+ configured). As before, minimal metadata sufficient to obtain the
+ content is carried "in-band" as part of the redirection process, and
+ standard HTTP is used for inter-CDN acquisition. There is no
+ explicit CDNI Logging interface discussed in this example.
+
+3.4.1. Notes on Using DNSSEC
+
+ Although it is possible to use DNSSEC in combination with the
+ Iterative DNS-based Redirection mechanism explained above, it is
+ important to note that the uCDN might have to sign records on the
+ fly, since the CNAME returned, and thus the signature provided, can
+ potentially be different for each incoming query. Although there is
+ nothing preventing a uCDN from performing such on-the-fly signing,
+ this might be computationally expensive. In the case where the
+ number of dCDNs, and thus the number of different CNAMEs to return,
+ is relatively stable, an alternative solution would be for the uCDN
+ to pre-generate signatures for all possible CNAMEs. For each
+ incoming query, the uCDN would then determine the appropriate CNAME
+ and return it together with the associated pre-generated signature.
+ Note: In the latter case, maintaining the serial number and signature
+ of Start of Authority (SOA) might be an issue since, technically, it
+ should change every time a different CNAME is used. However, since,
+
+
+
+
+
+Peterson, et al. Informational [Page 28]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ in practice, direct SOA queries are relatively rare, a uCDN could
+ defer incrementing the serial number and resigning the SOA until it
+ is queried and then do it on-the-fly.
+
+ Note also that the NS record and the glue records used in step 2 in
+ the previous section should generally be identical to those of their
+ authoritative zone managed by Operator B. Even if they differ, this
+ will not make the DNS resolution process fail, but the client DNS
+ server will prefer the authoritative data in its cache and use it for
+ subsequent queries. Such inconsistency is a general operational
+ issue of DNS, but it may be more important for this architecture
+ because the uCDN (Operator A) would rely on the consistency to make
+ the resulting redirection work as intended. In general, it is the
+ administrator's responsibility to make them consistent.
+
+3.5. Dynamic Footprint Discovery Example
+
+ There could be situations where being able to dynamically discover
+ the set of requests that a given dCDN is willing and able to serve is
+ beneficial. For example, a CDN might at one time be able to serve a
+ certain set of client IP prefixes, but that set might change over
+ time due to changes in the topology and routing policies of the IP
+ network. The following example illustrates this capability. We have
+ chosen the example of DNS-based redirection, but HTTP-based
+ redirection could equally well use this approach.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 29]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ End User Operator B Operator A
+ |DNS cdn.csp.example | |
+ |-------------------------------------------------->|
+ | | |(1)
+ | | RI REQ op-b.example |
+ | |<------------------------|
+ | | |(2)
+ | | RI REPLY |
+ | |------------------------>|
+ | | |(3)
+ |CNAME b.cdn.csp.example | |
+ |NS records for b.cdn.csp.example |
+ |<--------------------------------------------------|
+ |DNS b.cdn.csp.example | |
+ |------------------------>| |
+ | |(2) |
+ |IPaddr of B's Delivery Node |
+ |<------------------------| |
+ |HTTP cdn.csp.example | |
+ |------------------------>| |
+ | |(3) |
+ | |DNS op-b-acq.op-a.example|
+ | |------------------------>|
+ | | |(4)
+ | |IPaddr of A's Delivery Node
+ | |<------------------------|
+ | |HTTP op-b-acq.op-a.example
+ | |------------------------>|
+ | | |(5)
+ | |Data |
+ | |<------------------------|
+ |Data | |
+ |<------------------------| |
+
+ Figure 6: Message Flow for Dynamic Footprint Discovery
+
+ This example differs from the one in Figure 5 only in the addition of
+ an RI request (step 2) and corresponding response (step 3). The RI
+ REQ could be a message such as "Can you serve clients from this IP
+ Prefix?" or it could be "Provide the list of client IP prefixes you
+ can currently serve". In either case the response might be cached by
+ Operator A to avoid repeatedly asking the same question.
+ Alternatively, or in addition, Operator B may spontaneously advertise
+ to Operator A information (or changes) on the set of requests it is
+ willing and able to serve on behalf of Operator A; in that case,
+ Operator B may spontaneously issue RR/RI REPLY messages that are not
+
+
+
+
+
+Peterson, et al. Informational [Page 30]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ in direct response to a corresponding RR/RI REQ message. (Note that
+ the issues of determining the client's subnet from DNS requests, as
+ described above, are exactly the same here as in Section 3.4.)
+
+ Once Operator A obtains the RI response, it is now able to determine
+ that Operator B's CDN is an appropriate dCDN for this request and
+ therefore a valid candidate dCDN to consider in its redirection
+ decision. If that dCDN is selected, the redirection and serving of
+ the request proceeds as before (i.e., in the absence of dynamic
+ footprint discovery).
+
+3.6. Content Removal Example
+
+ The following example illustrates how the CDNI Control interface may
+ be used to achieve pre-positioning of an item of content in the dCDN.
+ In this example, user requests for a particular content, and
+ corresponding redirection of such requests from Operator A to
+ Operator B CDN, may (or may not) have taken place earlier. Then, at
+ some point in time, the uCDN (for example, in response to a
+ corresponding Trigger from the Content Provider) uses the CI to
+ request that content identified by a particular URL be removed from
+ dCDN. The following diagram illustrates the operation. It should be
+ noted that a uCDN will typically not know whether a dCDN has cached a
+ given content item; however, it may send the content removal request
+ to make sure no cached versions remain to satisfy any contractual
+ obligations it may have.
+
+ End User Operator B Operator A
+ | |CI purge cdn.csp.example/...
+ | |<------------------------|
+ | | |
+ | |CI OK |
+ | |------------------------>|
+ | | |
+
+
+ Figure 7: Message Flow for Content Removal
+
+ The CI is used to convey the request from the uCDN to the dCDN that
+ some previously acquired content should be deleted. The URL in the
+ request specifies which content to remove. This example corresponds
+ to a DNS-based redirection scenario such as Section 3.4. If HTTP-
+ based redirection had been used, the URL for removal would be of the
+ form peer-a.op-b.example/cdn.csp.example/...
+
+ The dCDN is expected to confirm to the uCDN, as illustrated by the CI
+ OK message, the completion of the removal of the targeted content
+ from all the caches in the dCDN.
+
+
+
+Peterson, et al. Informational [Page 31]
+
+RFC 7336 CDNI Framework August 2014
+
+
+3.7. Pre-positioned Content Acquisition Example
+
+ The following example illustrates how the CI may be used to pre-
+ position an item of content in the dCDN. In this example, Operator A
+ uses the CDNI Metadata interface to request that content identified
+ by a particular URL be pre-positioned into Operator B CDN.
+
+ End User Operator B Operator A
+
+ | |CI pre-position cdn.csp.example/...
+ | |<------------------------|
+ | | |(1)
+ | |CI OK |
+ | |------------------------>|
+ | | |
+ | |DNS op-b-acq.op-a.example|
+ | |------------------------>|
+ | | |(2)
+ | |IPaddr of A's Delivery Node
+ | |<------------------------|
+ | |HTTP op-b-acq.op-a.example
+ | |------------------------>|
+ | | |(3)
+ | |Data |
+ | |<------------------------|
+ |DNS cdn.csp.example | |
+ |--------------------------------------------->|
+ | | |(4)
+ |IPaddr of A's Request Router |
+ |<---------------------------------------------|
+ |HTTP cdn.csp.example| |
+ |--------------------------------------------->|
+ | | |(5)
+ |302 peer-a.op-b.example/cdn.csp.example |
+ |<---------------------------------------------|
+ |DNS peer-a.op-b.example |
+ |------------------->| |
+ | |(6) |
+ |IPaddr of B's Delivery Node |
+ |<-------------------| |
+ |HTTP peer-a.op-b.example/cdn.csp.example |
+ |------------------->| |
+ | |(7) |
+ |Data | |
+ |<-------------------| |
+
+ Figure 8: Message Flow for Content Pre-Positioning
+
+
+
+
+Peterson, et al. Informational [Page 32]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ The steps illustrated in the figure are as follows:
+
+ 1. Operator A uses the CI to request that Operator B pre-position a
+ particular content item identified by its URL. Operator B
+ responds by confirming that it is willing to perform this
+ operation.
+
+ Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only
+ this time those steps happen as the result of the Pre-positioning
+ request instead of as the result of a cache miss.
+
+ Steps 4, 5, 6, and 7 are exactly the same as steps 1, 2, 3, and 4 of
+ Figure 3, only this time, Operator B's CDN can serve the end-user
+ request without triggering dynamic content acquisition, since the
+ content has been pre-positioned in the dCDN. Note that, depending on
+ dCDN operations and policies, the content pre-positioned in the dCDN
+ may be pre-positioned to all, or a subset of, dCDN caches. In the
+ latter case, intra-CDN dynamic content acquisition may take place
+ inside the dCDN serving requests from caches on which the content has
+ not been pre-positioned; however, such intra-CDN dynamic acquisition
+ would not involve the uCDN.
+
+3.8. Asynchronous CDNI Metadata Example
+
+ In this section, we walk through a simple example illustrating a
+ scenario of asynchronously exchanging CDNI Metadata, where the
+ Downstream CDN obtains CDNI Metadata for content ahead of a
+ corresponding content request. The example that follows assumes that
+ HTTP-based inter-CDN redirection and recursive CDNI request routing
+ are used, as in Section 3.3. However, Asynchronous exchange of CDNI
+ Metadata is similarly applicable to DNS-based inter-CDN redirection
+ and iterative request routing (in which cases the CDNI Metadata may
+ be used at slightly different processing stages of the message
+ flows).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 33]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ End User Operator B Operator A
+ | | |
+ | |CI pre-position (Trigger)|
+ | |<------------------------|(1)
+ | | |
+ | |CI OK |
+ | |------------------------>|(2)
+ | | |
+ | |MI pull REQ |
+ | |------------------------>|(3)
+ | | |
+ | |MI metadata REP |(4)
+ | | |
+ | | |
+ | CONTENT REQUEST | |
+ |-------------------------------------------------->|(5)
+ | | |
+ | | RI REQ |
+ | |<------------------------|(6)
+ | | |
+ | | RI RESP |
+ | |------------------------>|(7)
+ | | |
+ | CONTENT REDIRECTION | |
+ |<--------------------------------------------------|(8)
+ | | |
+ | CONTENT REQUEST | |
+ |------------------------>|(9) |
+ | | |
+ : : :
+ | CONTENT DATA | |
+ |<------------------------| |(10)
+
+
+ Figure 9: Message Flow for Asynchronous CDNI Metadata
+
+ The steps illustrated in the figure are as follows:
+
+ 1. Operator A uses the CI to trigger the signaling of the
+ availability of CDNI Metadata to Operator B.
+
+ 2. Operator B acknowledges the receipt of this Trigger.
+
+ 3. Operator B requests the latest metadata from Operator A using
+ the MI.
+
+
+
+
+
+
+Peterson, et al. Informational [Page 34]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ 4. Operator A replies with the requested metadata. This document
+ does not constrain how the CDNI Metadata information is actually
+ represented. For the purposes of this example, we assume that
+ Operator A provides CDNI Metadata to Operator B indicating that:
+
+ * this CDNI Metadata is applicable to any content referenced by
+ some CDN-Domain.
+
+ * this CDNI Metadata consists of a distribution policy
+ requiring enforcement by the delivery node of a specific per-
+ request authorization mechanism (e.g., URI signature or token
+ validation).
+
+ 5. A Content Request occurs as usual.
+
+ 6. A CDNI Request Routing Redirection request (RI REQ) is issued by
+ Operator A's CDN, as discussed in Section 3.3. Operator B's
+ Request Router can access the CDNI Metadata that are relevant to
+ the requested content and that have been pre-positioned as per
+ Steps 1-4, which may or may not affect the response.
+
+ 7. Operator B's Request Router issues a CDNI Request Routing
+ Redirection response (RI RESP) as in Section 3.3.
+
+ 8. Operator B performs content redirection as discussed in
+ Section 3.3.
+
+ 9. On receipt of the Content Request by the end user, the delivery
+ node detects that previously acquired CDNI Metadata is
+ applicable to the requested content. In accordance with the
+ specific CDNI metadata of this example, the delivery node will
+ invoke the appropriate per-request authorization mechanism,
+ before serving the content. (Details of this authorization are
+ not shown.)
+
+ 10. Assuming successful per-request authorization, serving of
+ Content Data (possibly preceded by inter-CDN acquisition)
+ proceeds as in Section 3.3.
+
+3.9. Synchronous CDNI Metadata Acquisition Example
+
+ In this section we walk through a simple example illustrating a
+ scenario of Synchronous CDNI Metadata acquisition, in which the
+ Downstream CDN obtains CDNI Metadata for content at the time of
+ handling a first request for the corresponding content. As in the
+ preceding section, this example assumes that HTTP-based inter-CDN
+
+
+
+
+
+Peterson, et al. Informational [Page 35]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ redirection and recursive CDNI request routing are used (as in
+ Section 3.3), but dynamic CDNI Metadata acquisition is applicable to
+ other variations of request routing.
+
+ End User Operator B Operator A
+ | | |
+ | CONTENT REQUEST | |
+ |-------------------------------------------------->|(1)
+ | | |
+ | | RI REQ |
+ | (2)|<------------------------|
+ | | |
+ | | MI REQ |
+ | (3)|------------------------>|
+ | | MI RESP |
+ | |<------------------------|(4)
+ | | |
+ | | RI RESP |
+ | |------------------------>|(5)
+ | | |
+ | | |
+ | CONTENT REDIRECTION | |
+ |<--------------------------------------------------|(6)
+ | | |
+ | CONTENT REQUEST | |
+ |------------------------>|(7) |
+ | | |
+ | | MI REQ |
+ | (8)|------------------------>|
+ | | MI RESP |
+ | |<------------------------|(9)
+ | | |
+ : : :
+ | CONTENT DATA | |
+ |<------------------------| |(10)
+
+
+ Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition
+
+ The steps illustrated in the figure are as follows:
+
+ 1. A Content Request arrives as normal.
+
+ 2. An RI request occurs as in the prior example.
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 36]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ 3. On receipt of the CDNI Request Routing Request, Operator B's CDN
+ initiates Synchronous acquisition of CDNI Metadata that are
+ needed for routing of the end-user request. We assume the URI
+ for the a metadata server is known ahead of time through some
+ out-of-band means.
+
+ 4. On receipt of a CDNI Metadata request, Operator A's CDN
+ responds, making the corresponding CDNI Metadata information
+ available to Operator B's CDN. This metadata is considered by
+ Operator B's CDN before responding to the Request Routing
+ request. (In a simple case, the metadata could simply be an
+ allow or deny response for this particular request.)
+
+ 5. Response to the RI request as normal.
+
+ 6. Redirection message is sent to the end user.
+
+ 7. A delivery node of Operator B receives the end user request.
+
+ 8. The delivery node Triggers dynamic acquisition of additional
+ CDNI Metadata that are needed to process the end-user content
+ request. Note that there may exist cases where this step need
+ not happen, for example, because the metadata were already
+ acquired previously.
+
+ 9. Operator A's CDN responds to the CDNI Metadata Request and makes
+ the corresponding CDNI Metadata available to Operator B. This
+ metadata influence how Operator B's CDN processes the end-user
+ request.
+
+ 10. Content is served (possibly preceded by inter-CDN acquisition)
+ as in Section 3.3.
+
+3.10. Content and Metadata Acquisition with Multiple Upstream CDNs
+
+ A single dCDN may receive end-user requests from multiple uCDNs.
+ When a dCDN receives an end-user request, it must determine the
+ identity of the uCDN from which it should acquire the requested
+ content.
+
+ Ideally, the acquisition path of an end-user request will follow the
+ redirection path of the request. The dCDN should acquire the content
+ from the same uCDN that redirected the request.
+
+ Determining the acquisition path requires the dCDN to reconstruct the
+ redirection path based on information in the end-user request. The
+ method for reconstructing the redirection path differs based on the
+ redirection approach: HTTP or DNS.
+
+
+
+Peterson, et al. Informational [Page 37]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ With HTTP-redirection, the rewritten URI should include sufficient
+ information for the dCDN to directly or indirectly determine the uCDN
+ when the end-user request is received. The HTTP-redirection approach
+ can be further broken-down based on the how the URL is rewritten
+ during redirection: HTTP redirection with or without Site
+ Aggregation. HTTP redirection with Site Aggregation hides the
+ identity of the original CSP. HTTP redirection without Site
+ Aggregation does not attempt to hide the identity of the original
+ CSP. With both approaches, the rewritten URI includes enough
+ information to identify the immediate neighbor uCDN.
+
+ With DNS-redirection, the dCDN receives the published URI (instead of
+ a rewritten URI) and does not have sufficient information for the
+ dCDN to identify the appropriate uCDN. The dCDN may narrow the set
+ of viable uCDNs by examining the CDNI Metadata from each to determine
+ which uCDNs are hosting metadata for the requested content. If there
+ is a single uCDN hosting metadata for the requested content, the dCDN
+ can assume that the request redirection is coming from this uCDN and
+ can acquire content from that uCDN. If there are multiple uCDNs
+ hosting metadata for the requested content, the dCDN may be ready to
+ trust any of these uCDNs to acquire the content (provided the uCDN is
+ in a position to serve it). If the dCDN is not ready to trust any of
+ these uCDNs, it needs to ensure via out of band arrangements that,
+ for a given content, only a single uCDN will ever redirect requests
+ to the dCDN.
+
+ Content acquisition may be preceded by content metadata acquisition.
+ If possible, the acquisition path for metadata should also follow the
+ redirection path. Additionally, we assume metadata is indexed based
+ on rewritten URIs in the case of HTTP redirection and is indexed
+ based on published URIs in the case of DNS-redirection. Thus, the RI
+ and the MI are tightly coupled in that the result of request routing
+ (a rewritten URI pointing to the dCDN) serves as an input to metadata
+ lookup. If the content metadata includes information for acquiring
+ the content, then the MI is also tightly coupled with the acquisition
+ interface in that the result of the metadata lookup (an acquisition
+ URL likely hosted by the uCDN) should serve as input to the content
+ acquisition.
+
+4. Main Interfaces
+
+ Figure 1 illustrates the main interfaces that are in scope for the
+ CDNI WG, along with several others. The detailed specifications of
+ these interfaces are left to other documents, but see [RFC6707] and
+ [RFC7337] for some discussion of the interfaces.
+
+
+
+
+
+
+Peterson, et al. Informational [Page 38]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ One interface that is not shown in Figure 1 is the interface between
+ the user and the CSP. While for the purposes of CDNI that interface
+ is out of scope, it is worth noting that it does exist and can
+ provide useful functions, such as end-to-end performance monitoring
+ and some forms of authentication and authorization.
+
+ There is also an important interface between the user and the Request
+ Routing function of both uCDN and dCDN (shown as the "Request"
+ interface in Figure 1). As we saw in some of the preceding examples,
+ that interface can be used as a way of passing metadata, such as the
+ minimum information that is required for dCDN to obtain the content
+ from the uCDN.
+
+ In this section we will provide an overview of the functions
+ performed by each of the CDNI interfaces and discuss how they fit
+ into the overall solution. We also examine some of the design trade-
+ offs, and explore several cross-interface concerns. We begin with an
+ examination of one such trade-off that affects all the interfaces --
+ the use of in-band or out-of-band communication.
+
+4.1. In-Band versus Out-of-Band Interfaces
+
+ Before getting to the individual interfaces, we observe that there is
+ a high-level design choice for each, involving the use of existing
+ in-band communication channels versus defining new out-of-band
+ interfaces.
+
+ It is possible that the information needed to carry out various
+ interconnection functions can be communicated between peer CDNs using
+ existing in-band protocols. The use of HTTP 302 redirect is an
+ example of how certain aspects of request routing can be implemented
+ in-band (embedded in URIs). Note that using existing in-band
+ protocols does not imply that the CDNI interfaces are null; it is
+ still necessary to establish the rules (conventions) by which such
+ protocols are used to implement the various interface functions.
+
+ There are other opportunities for in-band communication beyond HTTP
+ redirects. For example, many of the HTTP directives used by proxy
+ servers can also be used by peer CDNs to inform each other of caching
+ activity. Of these, one that is particularly relevant is the
+ If-Modified-Since directive, which is used with the GET method to
+ make it conditional: if the requested object has not been modified
+ since the time specified in this field, a copy of the object will not
+ be returned, and instead, a 304 (not modified) response will be
+ returned.
+
+
+
+
+
+
+Peterson, et al. Informational [Page 39]
+
+RFC 7336 CDNI Framework August 2014
+
+
+4.2. Cross-Interface Concerns
+
+ Although the CDNI interfaces are largely independent, there are a set
+ of conventions practiced consistently across all interfaces. Most
+ important among these is how resources are named, for example, how
+ the CDNI Metadata and Control interfaces identify the set of
+ resources to which a given directive applies or the CDNI Logging
+ interface identifies the set of resources for which a summary record
+ applies.
+
+ While, theoretically, the CDNI interfaces could explicitly identify
+ every individual resource, in practice, they name resource aggregates
+ (sets of URIs) that are to be treated in a similar way. For example,
+ URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at
+ the beginning of a URI) or by a URI-Filter (i.e., a regular
+ expression that matches a subset of URIs contained in some CDN-
+ Domain). In other words, CDN-Domains and URI-Filters provide a
+ uniform means to aggregate sets (and subsets) of URIs for the purpose
+ of defining the scope for some operation in one of the CDNI
+ interfaces.
+
+4.3. Request Routing Interfaces
+
+ The Request Routing interface comprises two parts: the Asynchronous
+ interface used by a dCDN to advertise footprint and capabilities
+ (denoted FCI) to a uCDN, allowing the uCDN to decide whether to
+ redirect particular user requests to that dCDN; and the Synchronous
+ interface used by the uCDN to redirect a user request to the dCDN
+ (denoted RI). (These are somewhat analogous to the operations of
+ routing and forwarding in IP.)
+
+ As illustrated in Section 3, the RI part of request routing may be
+ implemented in part by DNS and HTTP. Naming conventions may be
+ established by which CDN peers communicate whether a request should
+ be routed or content served.
+
+ We also note that RI plays a key role in enabling recursive
+ redirection, as illustrated in Section 3.3. It enables the user to
+ be redirected to the correct delivery node in dCDN with only a single
+ redirection step (as seen by the user). This may be particularly
+ valuable as the chain of interconnected CDNs increases beyond two
+ CDNs. For further discussion on the RI, see [REDIRECTION].
+
+ In support of these redirection requests, it is necessary for CDN
+ peers to exchange additional information with each other, and this is
+ the role of the FCI part of request routing. Depending on the
+ method(s) supported, this might include:
+
+
+
+
+Peterson, et al. Informational [Page 40]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ o The operator's unique id (operator-id) or distinguished CDN-Domain
+ (operator-domain);
+
+ o NS records for the operator's set of externally visible Request
+ Routers;
+
+ o The set of requests the dCDN operator is prepared to serve (e.g.,
+ a set of client IP prefixes or geographic regions that may be
+ served by the dCDN).
+
+ o Additional capabilities of the dCDN, such as its ability to
+ support different CDNI Metadata requests.
+
+ Note that the set of requests that a dCDN is willing to serve could
+ in some cases be relatively static (e.g., a set of IP prefixes),
+ could be exchanged off-line, or might even be negotiated as part of a
+ peering agreement. However, it may also be more dynamic, in which
+ case the exchange supported by FCI would be helpful. A further
+ discussion of the Footprint & Capability Advertisement interface can
+ be found in [FOOTPRINT-CAPABILITY].
+
+4.4. CDNI Logging Interface
+
+ It is necessary for the Upstream CDN to have visibility into the
+ delivery of content that it redirected to a Downstream CDN. This
+ allows the Upstream CDN to properly bill its customers for multiple
+ deliveries of content cached by the Downstream CDN, as well as to
+ report accurate traffic statistics to those content providers. This
+ is one role of the LI.
+
+ Other operational data that may be relevant to CDNI can also be
+ exchanged by the LI. For example, a dCDN may report the amount of
+ content it has acquired from uCDN, and how much cache storage has
+ been consumed by content cached on behalf of uCDN.
+
+ Traffic logs are easily exchanged off-line. For example, the
+ following traffic log is a small deviation from the Apache log file
+ format, where entries include the following fields:
+
+ o Domain - the full domain name of the origin server
+
+ o IP address - the IP address of the client making the request
+
+ o End time - the ending time of the transfer
+
+ o Time zone - any time zone modifier for the end time
+
+ o Method - the transfer command itself (e.g., GET, POST, HEAD)
+
+
+
+Peterson, et al. Informational [Page 41]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ o URL - the requested URL
+
+ o Version - the protocol version, such as HTTP/1.0
+
+ o Response - a numeric response code indicating transfer result
+
+ o Bytes Sent - the number of bytes in the body sent to the client
+
+ o Request ID - a unique identifier for this transfer
+
+ o User agent - the user agent, if supplied
+
+ o Duration - the duration of the transfer in milliseconds
+
+ o Cached Bytes - the number of body bytes served from the cache
+
+ o Referrer - the referrer string from the client, if supplied
+
+ Of these, only the Domain field is indirect in the Downstream CDN --
+ it is set to the CDN-Domain used by the Upstream CDN rather than the
+ actual origin server. This field could then used to filter traffic
+ log entries so only those entries matching the Upstream CDN are
+ reported to the corresponding operator. Further discussion of the LI
+ can be found in [LOGGING].
+
+ One open question is who does the filtering. One option is that the
+ Downstream CDN filters its own logs and passes the relevant records
+ directly to each Upstream peer. This requires that the Downstream
+ CDN know the set of CDN-Domains that belong to each Upstream peer.
+ If this information is already exchanged between peers as part of
+ another interface, then direct peer-to-peer reporting is
+ straightforward. If it is not available, and operators do not wish
+ to advertise the set of CDN-Domains they serve to their peers, then
+ the second option is for each CDN to send both its non-local traffic
+ records and the set of CDN-Domains it serves to an independent third
+ party (i.e., a CDN Exchange), which subsequently filters, merges, and
+ distributes traffic records on behalf of each participating CDN
+ operator.
+
+ A second open question is how timely traffic information should be.
+ For example, in addition to offline traffic logs, accurate real-time
+ traffic monitoring might also be useful, but such information
+ requires that the Downstream CDN inform the Upstream CDN each time it
+ serves Upstream content from its cache. The Downstream CDN can do
+ this, for example, by sending a conditional HTTP GET request
+ (If-Modified-Since) to the Upstream CDN each time it receives an HTTP
+ GET request from one of its end users. This allows the Upstream CDN
+
+
+
+
+Peterson, et al. Informational [Page 42]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ to record that a request has been issued for the purpose of real-time
+ traffic monitoring. The Upstream CDN can also use this information
+ to validate the traffic logs received later from the Downstream CDN.
+
+ There is obviously a trade-off between accuracy of such monitoring
+ and the overhead of the Downstream CDN having to go back to the
+ Upstream CDN for every request.
+
+ Another design trade-off in the LI is the degree of aggregation or
+ summarization of data. One situation that lends itself to
+ summarization is the delivery of HTTP Adaptive Streaming (HAS), since
+ the large number of individual chunk requests potentially results in
+ large volumes of logging information. This case is discussed below,
+ but other forms of aggregation may also be useful. For example,
+ there may be situations where bulk metrics such as bytes delivered
+ per hour may suffice rather than the detailed per-request logs
+ outlined above. It seems likely that a range of granularities of
+ logging will be needed along with ways to specify the type and degree
+ of aggregation required.
+
+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 in order to
+ bootstrap the CDNI Logging interface. It may also be used, for
+ example, to establish security associations for the other interfaces.
+
+ The other role the CI plays is to allow the uCDN to 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 role of the CDNI Metadata interface is to enable CDNI
+ distribution metadata to be conveyed to the Downstream CDN by the
+ Upstream CDN. Such metadata includes geo-blocking restrictions,
+ availability windows, access-control policies, and so on. It may
+ also include information to facilitate acquisition of content by a
+ dCDN (e.g., alternate sources for the content, authorization
+ information needed to acquire the content from the source). For a
+ full discussion of the CDNI Metadata interface, see [METADATA]
+
+ Some distribution metadata may be partially emulated using in-band
+ mechanisms. For example, in case of any geo-blocking restrictions or
+ availability windows, the Upstream CDN can elect to redirect a
+ request to the Downstream CDN only if that CDN's advertised delivery
+
+
+
+Peterson, et al. Informational [Page 43]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ footprint is acceptable for the requested URL. Similarly, the
+ request could be forwarded only if the current time is within the
+ availability window. However, such approaches typically come with
+ shortcomings such as inability to prevent from replay outside the
+ time window or inability to make use of a Downstream CDN that covers
+ a broader footprint than the geo-blocking restrictions.
+
+ Similarly, some forms of access control may also be performed on a
+ per-request basis using HTTP directives. For example, being able to
+ respond to a conditional GET request gives the Upstream CDN an
+ opportunity to influence how the Downstream CDN delivers its content.
+ Minimally, the Upstream CDN can invalidate (purge) content previously
+ cached by the Downstream CDN.
+
+ All of these in-band techniques serve to illustrate that uCDNs have
+ the option of enforcing some of their access control policies
+ themselves (at the expense of increased inter-CDN signaling load),
+ rather than delegating enforcement to dCDNs using the MI. As a
+ consequence, the MI could provide a means for the uCDN to express its
+ desire to retain enforcement for itself. For example, this might be
+ done by including a "check with me" flag in the metadata associated
+ with certain content. The realization of such in-band techniques
+ over the various inter-CDN acquisition protocols (e.g., HTTP)
+ requires further investigation and may require small extensions or
+ semantic changes to the acquisition protocol.
+
+4.7. HTTP Adaptive Streaming Concerns
+
+ We consider HTTP Adaptive Streaming (HAS) and the impact it has on
+ the CDNI interfaces because large objects (e.g., videos) are broken
+ into a sequence of small, independent chunks. For each of the
+ following, a more thorough discussion, including an overview of the
+ trade-offs involved in alternative designs, can be found in RFC 6983.
+
+ First, with respect to Content Acquisition and File Management, which
+ are out of scope for the CDNI interfaces but, nonetheless, relevant
+ to the overall operation, we assume no additional measures are
+ required to deal with large numbers of chunks. This means that the
+ dCDN is not explicitly made aware of any relationship between
+ different chunks, and the dCDN handles each chunk as if it were an
+ individual and independent content item. The result is that content
+ acquisition between uCDN and dCDN also happens on a per-chunk basis.
+ This approach is in line with the recommendations made in RFC 6983,
+ which also identifies potential improvements in this area that might
+ be considered in the future.
+
+
+
+
+
+
+Peterson, et al. Informational [Page 44]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ Second, with respect to request routing, we note that HAS manifest
+ files have the potential to interfere with request routing since
+ manifest files contain URLs pointing to the location of content
+ chunks. To make sure that a manifest file does not hinder CDNI
+ request routing and does not place excessive load on CDNI resources,
+ either the use of manifest files could be limited to those containing
+ relative URLs or the uCDN could modify the URLs in the manifest. Our
+ approach for dealing with these issues is twofold. As a mandatory
+ requirement, CDNs should be able to handle unmodified manifest files
+ containing either relative or absolute URLs. To limit the number of
+ redirects, and thus the load placed on the CDNI interfaces, as an
+ optional feature uCDNs can use the information obtained through the
+ CDNI Request Routing Redirection interface to modify the URLs in the
+ manifest file. Since the modification of the manifest file is an
+ optional uCDN-internal process, this does not require any
+ standardization effort 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, including the large number of individual chunk
+ requests potentially resulting in large volumes of logging
+ information, and the desire to correlate logging information for
+ chunk requests that correspond to the same HAS session. For the
+ initial CDNI specification, our approach is to expect participating
+ CDNs 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, thereby facilitating correlation of per-chunk logs
+ into per-session logs for applications benefiting from such session
+ level information (e.g., session-based analytics). This approach is
+ in line with the recommendations made in RFC 6983, which also
+ identifies potential improvements in this area that might be
+ considered in the future.
+
+ Fourth, with respect to the CDNI Control interface, and in particular
+ purging HAS chunks from a given CDN, our approach is to expect each
+ CDN supports per-chunk content purge (e.g., purging of chunks as if
+ they were individual content items). Optionally, a CDN may support
+ content purge on the basis of a "Purge IDentifier (Purge-ID)"
+ allowing the removal of all chunks related to a given Content
+ Collection with a single reference. It is possible that this Purge-
+ ID could be merged with the CCID discussed above for HAS Logging, or
+ alternatively, they may remain distinct.
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 45]
+
+RFC 7336 CDNI Framework August 2014
+
+
+4.8. URI Rewriting
+
+ When using HTTP redirection, content URIs may be rewritten when
+ redirection takes place within a uCDN, from a uCDN to a dCDN, and
+ within the dCDN. In the case of cascaded CDNs, content URIs may be
+ rewritten at every CDN hop (e.g., between the uCDN and the dCDN
+ acting as the transit CDN, and between the transit CDN and the dCDN
+ serving the request). The content URI used between any uCDN/dCDN
+ pair becomes a common handle that can be referred to without
+ ambiguity by both CDNs in all their inter-CDN communications. This
+ handle allows the uCDN and dCDN to correlate information exchanged
+ using other CDNI interfaces in both the Downstream direction (e.g.,
+ when using the MI) and the Upstream direction (e.g., when using the
+ LI).
+
+ Consider the simple case of a single uCDN/dCDN pair using HTTP
+ redirection. We introduce the following terminology for content URIs
+ to simplify the discussion:
+
+ "u-URI" represents a content URI in a request presented to the
+ uCDN;
+
+ "ud-URI" is a content URI acting as the common handle across uCDN
+ and dCDN for requests redirected by the uCDN to a specific dCDN;
+
+ "d-URI" represents a content URI in a request made within the
+ delegate dCDN.
+
+ In our simple pair-wise example, the "ud-URI" effectively becomes the
+ handle that the uCDN/dCDN pair use to correlate all CDNI information.
+ In particular, for a given pair of CDNs executing the HTTP
+ redirection, the uCDN needs to map the u-URI to the ud-URI handle for
+ all MI message exchanges, while the dCDN needs to map the d-URI to
+ the ud-URI handle for all LI message exchanges.
+
+ In the case of cascaded CDNs, the transit CDN will rewrite the
+ content URI when redirecting to the dCDN, thereby establishing a new
+ handle between the transit CDN and the dCDN, that is different from
+ the handle between the uCDN and transit CDN. It is the
+ responsibility of the transit CDN to manage its mapping across
+ handles so the right handle for all pairs of CDNs is always used in
+ its CDNI communication.
+
+ In summary, all CDNI interfaces between a given pair of CDNs need to
+ always use the "ud-URI" handle for that specific CDN pair as their
+ content URI reference.
+
+
+
+
+
+Peterson, et al. Informational [Page 46]
+
+RFC 7336 CDNI Framework August 2014
+
+
+5. Deployment Models
+
+ In this section, we describe a number of possible deployment models
+ that may be achieved using the CDNI interfaces described above. We
+ note that these models are by no means exhaustive and that many other
+ models may be possible.
+
+ Although the reference model of Figure 1 shows all CDN functions on
+ each side of the CDNI interface, deployments can rely on entities
+ that are involved in any subset of these functions, and therefore
+ only support the relevant subset of CDNI interfaces. As already
+ noted in Section 3, effective CDNI deployments can be built without
+ necessarily implementing all the interfaces. Some examples of such
+ deployments are shown below.
+
+ Note that, while we refer to Upstream and Downstream CDNs, this
+ distinction applies to specific content items and transactions. That
+ is, a given CDN may be Upstream for some transactions and Downstream
+ for others, depending on many factors such as location of the
+ requesting client and the particular piece of content requested.
+
+5.1. Meshed CDNs
+
+ Although the reference model illustrated in Figure 1 shows a
+ unidirectional CDN interconnection with a single uCDN and a single
+ dCDN, any arbitrary CDNI meshing can be built from this, such as the
+ example meshing illustrated in Figure 11. (Support for arbitrary
+ meshing may or may not be in the initial scope for the working group,
+ but the model allows for it.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 47]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ ------------- -----------
+ / CDN A \<==CDNI===>/ CDN B \
+ \ / \ /
+ ------------- -----------
+ /\ \\ /\
+ || \\ ||
+ CDNI \==CDNI===\\ CDNI
+ || \\ ||
+ \/ \/ \/
+ ------------- -----------
+ / CDN C \===CDNI===>/ CDN D \
+ \ / \ /
+ ------------- -----------
+ /\
+ ||
+ CDNI
+ ||
+ \/
+ -------------
+ / CDN E \
+ \ /
+ -------------
+
+ ===> CDNI interfaces, with right-hand side CDN acting as dCDN
+ to left-hand side CDN
+ <==> CDNI interfaces, with right-hand side CDN acting as dCDN
+ to left-hand side CDN and with left-hand side CDN acting
+ as dCDN to right-hand side CDN
+
+ Figure 11: CDNI Deployment Model: CDN Meshing Example
+
+5.2. CSP Combined with CDN
+
+ Note that our terminology refers to functional roles and not economic
+ or business roles. That is, a given organization may be operating as
+ both a CSP and a fully fledged uCDN when we consider the functions
+ performed, as illustrated in Figure 12.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 48]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ ##################################### ##################
+ # # # #
+ # Organization A # # Organization B #
+ # # # #
+ # -------- ------------- # # ----------- #
+ # / CSP \ / uCDN \ # # / dCDN \ #
+ # | | | +----+ | # # | +----+ | #
+ # | | | | C | | # # | | C | | #
+ # | | | +----+ | # # | +----+ | #
+ # | | | +----+ | # # | +----+ | #
+ # | | | | L | | # # | | L | | #
+ # | |*****| +----+ |===CDNI===>| +----+ | #
+ # | | | +----+ | # # | +----+ | #
+ # | | | | RR | | # # | | RR | | #
+ # | | | +----+ | # # | +----+ | #
+ # | | | +----+ | # # | +----+ | #
+ # | | | | D | | # # | | D | | #
+ # | | | +----+ | # # | +----+ | #
+ # \ / \ / # # \ / #
+ # -------- ------------- # # ----------- #
+ # # # #
+ ##################################### ##################
+
+ ===> CDNI interfaces, with right-hand side CDN acting as dCDN
+ to left-hand side CDN
+ **** interfaces outside the scope of CDNI
+ C Control component of the CDN
+ L Logging component of the CDN
+ RR Request Routing component of the CDN
+ D Distribution component of the CDN
+
+ Figure 12: CDNI Deployment Model: Organization Combining CSP & uCDN
+
+5.3. CSP Using CDNI Request Routing Interface
+
+ As another example, a content provider organization may choose to run
+ its own Request Routing function as a way to select among multiple
+ candidate CDN providers; in this case, the content provider may be
+ modeled as the combination of a CSP and of a special, restricted case
+ of a CDN. In that case, as illustrated in Figure 13, the CDNI
+ Request Routing interfaces can be used between the restricted CDN
+ operated by the content provider Organization and the CDN operated by
+ the full CDN organization acting as a dCDN in the request routing
+ control plane. Interfaces outside the scope of the CDNI work can be
+ used between the CSP functional entities of the content provider
+ organization and the CDN operated by the full CDN organization acting
+ as a uCDN) in the CDNI control planes other than the request routing
+ plane (i.e., Control, Distribution, Logging).
+
+
+
+Peterson, et al. Informational [Page 49]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ ##################################### ##################
+ # # # #
+ # Organization A # # Organization B #
+ # # # #
+ # -------- ------------- # # ----------- #
+ # / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ #
+ # | | | +----+ | # # | +----+ | #
+ # | |*****| | RR |==========CDNI=====>| RR | | #
+ # | | | +----+ | # RR # | +----+ | #
+ # | | \ / # # | | #
+ # | | ------------- # # |uCDN(C,L,D)| #
+ # | | # # | +----+ | #
+ # | | # # | | C | | #
+ # | |*******************************| +----+ | #
+ # | | # # | +----+ | #
+ # | | # # | | L | | #
+ # | | # # | +----+ | #
+ # | | # # | +----+ | #
+ # | | # # | | D | | #
+ # | | # # | +----+ | #
+ # \ / # # \ / #
+ # -------- # # ----------- #
+ # # # #
+ ##################################### ##################
+
+ ===> CDNI Request Routing Interface
+ **** interfaces outside the scope of CDNI
+
+ Figure 13: CDNI Deployment Model: Organization Combining
+ CSP and Partial CDN
+
+5.4. CDN Federations and CDN Exchanges
+
+ There are two additional concepts related to, but distinct from,
+ CDNI. The first is CDN Federation. Our view is that CDNI is the
+ more general concept, involving two or more CDNs serving content to
+ each other's users, while federation implies a multi-lateral
+ interconnection arrangement, but other CDNI agreements are also
+ possible (e.g., symmetric bilateral, asymmetric bilateral). An
+ important conclusion is that CDNI technology should not presume (or
+ bake in) a particular interconnection agreement, but should instead
+ be general enough to permit alternative interconnection arrangements
+ to evolve.
+
+ The second concept often used in the context of CDN Federation is CDN
+ Exchange -- a third-party broker or exchange that is used to
+ facilitate a CDN federation. Our view is that a CDN exchange offers
+ valuable machinery to scale the number of CDN operators involved in a
+
+
+
+Peterson, et al. Informational [Page 50]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ multi-lateral (federated) agreement, but that this machinery is built
+ on top of the core CDNI mechanisms. For example, as illustrated in
+ Figure 14, the exchange might aggregate and redistribute information
+ about each CDN footprint and capacity, as well as collect, filter,
+ and redistribute traffic logs that each participant needs for
+ interconnection settlement, but inter-CDN Request Routing, inter-CDN
+ content distribution (including inter-CDN acquisition), and inter-CDN
+ control, which fundamentally involve a direct interaction between an
+ Upstream CDN and a Downstream CDN -- operate exactly as in a pair-
+ wise peering arrangement. Turning to Figure 14, we observe that in
+ this example:
+
+ o each CDN supports a direct CDNI Control interface to every other
+ CDN
+
+ o each CDN supports a direct CDNI Metadata interface to every other
+ CDN
+
+ o each CDN supports a CDNI Logging interface with the CDN Exchange
+
+ o each CDN supports both a CDNI Request Routing interface with the
+ CDN Exchange (for aggregation and redistribution of dynamic CDN
+ footprint discovery information) and a direct RI to every other
+ CDN (for actual request redirection).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 51]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ ---------- ---------
+ / CDN A \ / CDN B \
+ | +----+ | | +----+ |
+ //========>| C |<==============CDNI============>| C |<==========\\
+ || | +----+ | C | +----+ | ||
+ || | +----+ | | +----+ | ||
+ || //=====>| D |<==============CDNI============>| D |<=======\\ ||
+ || || | +----+ | M | +----+ | || ||
+ || || | | /------------\ | | || ||
+ || || | +----+ | | +--+ CDN Ex| | +----+ | || ||
+ || || //==>| RR |<===CDNI==>|RR|<=======CDNI====>| RR |<====\\ || ||
+ || || || | +----+ | RR | +--+ | RR | +----+ | || || ||
+ || || || | | | /\ | | | || || ||
+ || || || | +----+ | | || +---+ | | +----+ | || || ||
+ || || || | | L |<===CDNI=======>| L |<=CDNI====>| L | | || || ||
+ || || || | +----+ | L | || +---+ | L | +----+ | || || ||
+ || || || \ / \ || /\ / \ / || || ||
+ || || || ----------- --||----||-- ----------- || || ||
+ || || || || || || || ||
+ || || || CDNI RR || || || ||
+ || || || || CDNI L || || ||
+ || || || || || || || ||
+ || || || ---||----||---- || || ||
+ || || || / \/ || \ || || ||
+ || || || | +----+ || | || || ||
+ || || \\=====CDNI==========>| RR |<=============CDNI========// || ||
+ || || RR | +----+ \/ | RR || ||
+ || || | +----+ | || ||
+ || || | | L | | || ||
+ || || | +----+ | || ||
+ || || | +----+ | || ||
+ || \\=======CDNI===========>| D |<=============CDNI===========// ||
+ || M | +----+ | M ||
+ || | +----+ | ||
+ \\==========CDNI===========>| C |<=============CDNI==============//
+ C | +----+ | C
+ \ CDN C /
+ --------------
+
+ <=CDNI RR=> CDNI Request Routing Interface
+ <=CDNI M==> CDNI Metadata Interface
+ <=CDNI C==> CDNI Control Interface
+ <=CDNI L==> CDNI Logging Interface
+
+ Figure 14: CDNI Deployment Model: CDN Exchange
+
+
+
+
+
+
+Peterson, et al. Informational [Page 52]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ Note that a CDN exchange may alternatively support a different set of
+ functionality (e.g., Logging only, or Logging and full request
+ routing, or all the functionality of a CDN including content
+ distribution). All these options are expected to be allowed by the
+ IETF CDNI specifications.
+
+6. Trust Model
+
+ There are a number of trust issues that need to be addressed by a
+ CDNI solution. Many of them are in fact similar or identical to
+ those in a simple CDN without interconnection. In a standard CDN
+ environment (without CDNI), the CSP places a degree of trust in a
+ single CDN operator to perform many functions. The CDN is trusted to
+ deliver content with appropriate quality of experience for the end
+ user. The CSP trusts the CDN operator not to corrupt or modify the
+ content. The CSP often relies on the CDN operator to provide
+ reliable accounting information regarding the volume of delivered
+ content. The CSP may also trust the CDN operator to perform actions
+ such as timely invalidation of content and restriction of access to
+ content based on certain criteria such as location of the user and
+ time of day, and to enforce per-request authorization performed by
+ the CSP using techniques such as URI signing.
+
+ A CSP also places trust in the CDN not to distribute any information
+ that is confidential to the CSP (e.g., how popular a given piece of
+ content is) or confidential to the end user (e.g., which content has
+ been watched by which user).
+
+ A CSP does not necessarily have to place complete trust in a CDN. A
+ CSP will in some cases take steps to protect its content from
+ improper distribution by a CDN, e.g., by encrypting it and
+ distributing keys in some out of band way. A CSP also depends on
+ monitoring (possibly by third parties) and reporting to verify that
+ the CDN has performed adequately. A CSP may use techniques such as
+ client-based metering to verify that accounting information provided
+ by the CDN is reliable. HTTP conditional requests may be used to
+ provide the CSP with some checks on CDN operation. In other words,
+ while a CSP may trust a CDN to perform some functions in the short
+ term, the CSP is able, in most cases, to verify whether these actions
+ have been performed correctly and to take action (such as moving the
+ content to a different CDN) if the CDN does not live up to
+ expectations.
+
+ One of the trust issues raised by CDNI is transitive trust. A CDN
+ that has a direct relationship with a CSP can now "outsource" the
+ delivery of content to another (Downstream) CDN. That CDN may in
+ term outsource delivery to yet another Downstream CDN, and so on.
+
+
+
+
+Peterson, et al. Informational [Page 53]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ The top-level CDN in such a chain of delegation is responsible for
+ ensuring that the requirements of the CSP are met. Failure to do so
+ is presumably just as serious as in the traditional single CDN case.
+ Hence, an Upstream CDN is essentially trusting a Downstream CDN to
+ perform functions on its behalf in just the same way as a CSP trusts
+ a single CDN. Monitoring and reporting can similarly be used to
+ verify that the Downstream CDN has performed appropriately. However,
+ the introduction of multiple CDNs in the path between CSP and end
+ user complicates the picture. For example, third-party monitoring of
+ CDN performance (or other aspects of operation, such as timely
+ invalidation) might be able to identify the fact that a problem
+ occurred somewhere in the chain but not point to the particular CDN
+ at fault.
+
+ In summary, we assume that an Upstream CDN will invest a certain
+ amount of trust in a Downstream CDN, but that it will verify that the
+ Downstream CDN is performing correctly, and take corrective action
+ (including potentially breaking off its relationship with that CDN)
+ if behavior is not correct. We do not expect that the trust
+ relationship between a CSP and its "top level" CDN will differ
+ significantly from that found today in single CDN situations.
+ However, it does appear that more sophisticated tools and techniques
+ for monitoring CDN performance and behavior will be required to
+ enable the identification of the CDN at fault in a particular
+ delivery chain.
+
+ We expect that the detailed designs for the specific interfaces for
+ CDNI will need to take the transitive trust issues into account. For
+ example, explicit confirmation that some action (such as content
+ removal) has taken place in a Downstream CDN may help to mitigate
+ some issues of transitive trust.
+
+7. Privacy Considerations
+
+ In general, a CDN has the opportunity to collect detailed information
+ about the behavior of end users, e.g., by logging which files are
+ being downloaded. While the concept of interconnected CDNs as
+ described in this document doesn't necessarily allow any given CDN to
+ gather more information on any specific user, it potentially
+ facilitates sharing of this data by a CDN with more parties. As an
+ example, the purpose of the CDNI Logging interface is to allow a dCDN
+ to share some of its log records with a uCDN, both for billing
+ purposes as well as for sharing traffic statistics with the Content
+ Provider on whose behalf the content was delivered. The fact that
+ the CDNI interfaces provide mechanisms for sharing such potentially
+ sensitive user data, shows that it is necessary to include in these
+
+
+
+
+
+Peterson, et al. Informational [Page 54]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ interface appropriate privacy and confidentiality mechanisms. The
+ definition of such mechanisms is dealt with in the respective CDN
+ interface documents.
+
+8. Security Considerations
+
+ While there are a variety of security issues introduced by a single
+ CDN, we are concerned here specifically with the additional issues
+ that arise when CDNs are interconnected. For example, when a single
+ CDN has the ability to distribute content on behalf of a CSP, there
+ may be concerns that such content could be distributed to parties who
+ are not authorized to receive it, and there are mechanisms to deal
+ with such concerns. Our focus in this section is on how CDNI
+ introduces new security issues not found in the single CDN case. For
+ a more detailed analysis of the security requirements of CDNI, see
+ Section 9 of [RFC7337].
+
+ Many of the security issues that arise in CDNI are related to the
+ transitivity of trust (or lack thereof) described in Section 6. As
+ noted above, the design of the various interfaces for CDNI must take
+ account of the additional risks posed by the fact that a CDN with
+ whom a CSP has no direct relationship is now potentially distributing
+ content for that CSP. The mechanisms used to mitigate these risks
+ may be similar to those used in the single CDN case, but their
+ suitability in this more complex environment must be validated.
+
+ CDNs today offer a variety of means to control access to content,
+ such as time-of-day restrictions, geo-blocking, and URI signing.
+ These mechanisms must continue to function in CDNI environments, and
+ this consideration is likely to affect the design of certain CDNI
+ interfaces (e.g., metadata, request routing). For more information
+ on URI signing in CDNI, see [URI-SIGNING].
+
+ Just as with a single CDN, each peer CDN must ensure that it is not
+ used as an "open proxy" to deliver content on behalf of a malicious
+ CSP. Whereas a single CDN typically addresses this problem by having
+ CSPs explicitly register content (or origin servers) that are to be
+ served, simply propagating this information to peer Downstream CDNs
+ may be problematic because it reveals more information than the
+ Upstream CDN is willing to specify. (To this end, the content
+ acquisition step in the earlier examples force the dCDN to retrieve
+ content from the uCDN rather than go directly to the origin server.)
+
+ There are several approaches to this problem. One is for the uCDN to
+ encode a signed token generated from a shared secret in each URL
+ routed to a dCDN, and for the dCDN to validate the request based on
+ this token. Another one is to have each Upstream CDN advertise the
+ set of CDN-Domains they serve, where the Downstream CDN checks each
+
+
+
+Peterson, et al. Informational [Page 55]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ request against this set before caching and delivering the associated
+ object. Although straightforward, this approach requires operators
+ to reveal additional information, which may or may not be an issue.
+
+8.1. Security of CDNI Interfaces
+
+ It is noted in [RFC7337] that all CDNI interfaces must be able to
+ operate securely over insecure IP networks. Since it is expected
+ that the CDNI interfaces will be implemented using existing
+ application protocols such as 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.
+ Details of how these interfaces are 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 does not
+ introduce additional security issues for CDNI.
+
+9. Contributors
+
+ The following individuals contributed to this document:
+
+ o Matt Caulfield
+
+ o Francois Le Faucheur
+
+ o Aaron Falk
+
+ o David Ferguson
+
+ o John Hartman
+
+ o Ben Niven-Jenkins
+
+ o Kent Leung
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 56]
+
+RFC 7336 CDNI Framework August 2014
+
+
+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.
+
+
+
+Peterson, et al. Informational [Page 57]
+
+RFC 7336 CDNI Framework August 2014
+
+
+ [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.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson, et al. Informational [Page 58]
+