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