draft-ietf-cdni-framework-07.txt | draft-ietf-cdni-framework-08.txt | |||
---|---|---|---|---|
Network Working Group L. Peterson, Ed. | Network Working Group L. Peterson, Ed. | |||
Internet-Draft Akamai Technologies, Inc. | Internet-Draft Akamai Technologies, Inc. | |||
Obsoletes: 3466 (if approved) B. Davie | Obsoletes: 3466 (if approved) B. Davie | |||
Intended status: Informational VMware, Inc. | Intended status: Informational VMware, Inc. | |||
Expires: May 29, 2014 November 25, 2013 | Expires: July 23, 2014 January 19, 2014 | |||
Framework for CDN Interconnection | Framework for CDN Interconnection | |||
draft-ietf-cdni-framework-07 | draft-ietf-cdni-framework-08 | |||
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. CDN Interconnection requires the specification of interfaces | |||
and mechanisms to address issues such as request routing, | and mechanisms to address issues such as request routing, | |||
distribution metadata exchange, and logging information exchange | distribution metadata exchange, and logging information exchange | |||
skipping to change at page 1, line 41 | skipping to change at page 1, line 41 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on May 29, 2014. | This Internet-Draft will expire on July 23, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.3. Structure Of This Document . . . . . . . . . . . . . . . 7 | 1.3. Structure Of This Document . . . . . . . . . . . . . . . 8 | |||
2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 | 2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8 | 2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8 | |||
2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8 | 2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8 | |||
2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9 | 2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9 | |||
3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10 | 3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10 | |||
3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12 | 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12 | |||
3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13 | 3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13 | |||
3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18 | 3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18 | |||
3.4. Iterative DNS-based Redirection Example . . . . . . 22 | 3.4. Iterative DNS-based Redirection Example . . . . . . 22 | |||
3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25 | 3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25 | |||
3.6. Content Removal Example . . . . . . . . . . . . . . . . . 26 | 3.6. Content Removal Example . . . . . . . . . . . . . . . . . 27 | |||
3.7. Pre-Positioned Content Acquisition Example . . . . . . . 27 | 3.7. Pre-Positioned Content Acquisition Example . . . . . . . 28 | |||
3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 28 | 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 29 | |||
3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 30 | 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 31 | |||
3.10. Content and Metadata Acquisition with Multiple Upstream | 3.10. Content and Metadata Acquisition with Multiple Upstream | |||
CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 | CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33 | 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34 | 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 35 | |||
4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 34 | 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 35 | |||
4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 35 | 4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 36 | |||
4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 36 | 4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 37 | |||
4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 38 | 4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 39 | |||
4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 38 | 4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 39 | |||
4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39 | 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 40 | |||
4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 40 | 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 42 | |||
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 41 | 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 43 | |||
5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42 | 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43 | 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 44 | |||
5.3. CSP using CDNI Request Routing Interface . . . . . . . . 43 | 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 45 | |||
5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 44 | 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 46 | |||
6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 46 | 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 | |||
8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 49 | 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 51 | |||
8.2. Digital Rights Management . . . . . . . . . . . . . . . . 49 | 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 52 | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 | |||
11. Informative References . . . . . . . . . . . . . . . . . . . 50 | 11. Informative References . . . . . . . . . . . . . . . . . . . 52 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
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 RFCs 6770 and 6707. It describes the | and use cases introduced in [RFC6770] and [RFC6707]. It describes | |||
necessary interfaces and mechanisms in general terms and outlines how | the necessary interfaces and mechanisms in general terms and outlines | |||
they fit together to form a complete system for CDN Interconnection. | how they fit together to form a complete system for CDN | |||
Detailed specifications are left to other documents. This document | Interconnection. Detailed specifications are left to other | |||
makes extensive use of message flow examples to illustrate the | documents. This document makes extensive use of message flow | |||
operation of interconnected CDNs, but these examples should be | examples to illustrate the operation of interconnected CDNs, but | |||
considered illustrative rather than prescriptive. | these examples should be considered illustrative rather than | |||
prescriptive. | ||||
RFC 3466 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 | Internetworking (CDI)". It is also less prescriptive in terms of | |||
interfaces. To avoid confusion, this document obsoletes RFC 3466. | interfaces. To avoid confusion, this document obsoletes [RFC3466]. | |||
1.1. Terminology | 1.1. Terminology | |||
This document uses the core terminology defined in RFC 6707. It also | This document uses the core terminology defined in [RFC6707]. It | |||
introduces the following terms: | also introduces the following terms: | |||
CDN-Domain: a host name (FQDN) at the beginning of a URL, | CDN-Domain: a host name (FQDN) at the beginning of a URL, | |||
representing a set of content that is served by a given CDN. For | representing a set of content that is served by a given CDN. For | |||
example, in the URL http://cdn.csp.com/...rest of url..., the CDN | example, in the URL http://cdn.csp.example/...rest of url..., the CDN | |||
domain is cdn.csp.com. A major role of CDN-Domain is to identify a | domain is cdn.csp.example. A major role of CDN-Domain is to identify | |||
region (subset) of the URI space relative to which various CDN | a region (subset) of the URI space relative to which various CDN | |||
Interconnection rules and policies are to apply. For example, a | Interconnection rules and policies are to apply. For example, a | |||
record of CDN Metadata might be defined for the set of resources | record of CDN Metadata might be defined for the set of resources | |||
corresponding to some CDN-Domain. | 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 for | |||
the purposes of communication with a peer CDN, but which is not found | the purposes of communication with a peer CDN, but which is not found | |||
in client requests. Such CDN-Domains may be used for inter-CDN | in client requests. Such CDN-Domains may be used for inter-CDN | |||
acquisition, or as redirection targets, and enable a CDN to | 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. | |||
skipping to change at page 4, line 45 | skipping to change at page 4, line 48 | |||
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 CSP on the upstream CDN. | response to some action (Trigger) by the 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, respectively. | downstream CDN, respectively. | |||
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 RFC 6707. (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 and Capabilities Advertisement interface, as described | |||
below.) | below.) | |||
-------- | -------- | |||
/ \ | / \ | |||
| CSP | | | CSP | | |||
\ / | \ / | |||
-------- | -------- | |||
* | * | |||
skipping to change at page 6, line 17 | skipping to change at page 6, line 17 | |||
new protocols for those interfaces) we still need to refer to them in | new protocols for those interfaces) we still need to refer to them in | |||
this document to explain the overall operation of CDNI. | 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 RFC 6707. 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- | |||
skipping to change at page 7, line 49 | skipping to change at page 7, line 49 | |||
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 CNDI | |||
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 RFC 6983. | 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. | |||
o Section 4 describes the functionality of the main CDNI interfaces. | o Section 4 describes the functionality of the main CDNI interfaces. | |||
skipping to change at page 12, line 38 | skipping to change at page 13, line 6 | |||
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.com. We assume that Operator | behalf of a CSP with CDN-Domain cdn.csp.example. We assume that | |||
B provides a downstream CDN. An end user at some point makes a | Operator B provides a downstream CDN. An end user at some point | |||
request for URL | makes a request for URL | |||
http://cdn.csp.com/...rest of url... | http://cdn.csp.example/...rest of url... | |||
It may well be the case that cdn.csp.com 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.net). 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 | |||
skipping to change at page 13, line 25 | skipping to change at page 13, line 37 | |||
of HTTP redirection inside uCDN and dCDN; however, this is | of HTTP redirection inside 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 uCDN to dCDN but using DNS for handling of request | |||
inside each CDN. | inside each CDN. | |||
We assume for this example that Operators A and B have established an | We assume for this example that Operators A and B have established an | |||
agreement to interconnect their CDNs, with A being upstream and B | 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.net will be used as | The operators agree that a CDN-Domain peer-a.op-b.example will be | |||
the target of redirections from uCDN to dCDN. We assume the name of | used as the target of redirections from uCDN to dCDN. We assume the | |||
this domain is communicated by some means to each CDN. (This could | name of this domain is communicated by some means to each CDN. (This | |||
be established out-of-band or via a CDNI interface.) We refer to | could be established out-of-band or via a CDNI interface.) We refer | |||
this domain as a "distinguished" CDN-Domain to convey the fact that | to this domain as a "distinguished" CDN-Domain to convey the fact | |||
its use is limited to the interconnection mechanism; such a domain is | that its use is limited to the interconnection mechanism; such a | |||
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 CSP's content from | |||
uCDN by dCDN. In this example, we'll use op-b-acq.op-a.net. | uCDN by 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 dCDN is prepared to serve. For example, 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.com (or to return a CNAME for | authoritative DNS server for cdn.csp.example (or to return a CNAME | |||
cdn.csp.com for which operator A is the authoritative DNS server). | for cdn.csp.example for which operator A is the authoritative DNS | |||
server). | ||||
o Operator A is configured so that a DNS request for | o Operator A is configured so that a DNS request for | |||
op-b-acq.op-a.net 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-b.net | o Operator B is configured so that a DNS request for | |||
/cdn.csp.com 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.com/...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.com | | | |DNS cdn.csp.example | | | |||
|-------------------------------------------------->| | |-------------------------------------------------->| | |||
| | |(1) | | | |(1) | |||
|IPaddr of A's Request Router | | |IPaddr of A's Request Router | | |||
|<--------------------------------------------------| | |<--------------------------------------------------| | |||
|HTTP cdn.csp.com | | | |HTTP cdn.csp.example | | | |||
|-------------------------------------------------->| | |-------------------------------------------------->| | |||
| | |(2) | | | |(2) | |||
|302 peer-a.op-b.net/cdn.csp.com | | |302 peer-a.op-b.example/cdn.csp.example | | |||
|<--------------------------------------------------| | |<--------------------------------------------------| | |||
|DNS peer-a.op-b.net | | | |DNS peer-a.op-b.example | | | |||
|------------------------>| | | |------------------------>| | | |||
| |(3) | | | |(3) | | |||
|IPaddr of B's Request Router | | |IPaddr of B's Request Router | | |||
|<------------------------| | | |<------------------------| | | |||
| | | | | | | | |||
|HTTP peer-a.op-b.net/cdn.csp.com | | |HTTP peer-a.op-b.example/cdn.csp.example | | |||
|------------------------>| | | |------------------------>| | | |||
| |(4) | | | |(4) | | |||
|302 node1.peer-a.op-b.net/cdn.csp.com | | |302 node1.peer-a.op-b.example/cdn.csp.example | | |||
|<------------------------| | | |<------------------------| | | |||
|DNS node1.peer-a.op-b.net| | | |DNS node1.peer-a.op-b.example | | |||
|------------------------>| | | |------------------------>| | | |||
| |(5) | | | |(5) | | |||
|IPaddr of B's Delivery Node | | |IPaddr of B's Delivery Node | | |||
|<------------------------| | | |<------------------------| | | |||
| | | | | | | | |||
|HTTP node1.peer-a.op-b.net/cdn.csp.com | | |HTTP node1.peer-a.op-b.example/cdn.csp.example | | |||
|------------------------>| | | |------------------------>| | | |||
| |(6) | | | |(6) | | |||
| |DNS op-b-acq.op-a.net | | | |DNS op-b-acq.op-a.example| | |||
| |------------------------>| | | |------------------------>| | |||
| | |(7) | | | |(7) | |||
| |IPaddr of A's Request Router | | |IPaddr of A's Request Router | |||
| |<------------------------| | | |<------------------------| | |||
| |HTTP op-b-acq.op-a.net | | | |HTTP op-b-acq.op-a.example | |||
| |------------------------>| | | |------------------------>| | |||
| | |(8) | | | |(8) | |||
| |302 node2.op-b.acq.op-A.net | | |302 node2.op-b.acq.op-A.example | |||
| |<------------------------| | | |<------------------------| | |||
| |DNS node2.op-b-acq.op-a.net | | |DNS node2.op-b-acq.op-a.example | |||
| |------------------------>| | | |------------------------>| | |||
| | |(9) | | | |(9) | |||
| |IPaddr of A's Delivery Node | | |IPaddr of A's Delivery Node | |||
| |<------------------------| | | |<------------------------| | |||
| | | | | | | | |||
| |HTTP node2.op-b-acq.op-a.net | | |HTTP node2.op-b-acq.op-a.example | |||
| |------------------------>| | | |------------------------>| | |||
| | |(10) | | | |(10) | |||
| |Data | | | |Data | | |||
| |<------------------------| | | |<------------------------| | |||
|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.com. 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.net) on the | Operator B's distinguished CDN-Domain (peer-a.op-b.example) on | |||
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.net). B's DNS resolver returns the IP | CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the | |||
address of a request router for Operator B. Note that if request | IP address of a request router for Operator B. Note that if | |||
routing within dCDN was performed using DNS instead of HTTP | request routing within dCDN was performed using DNS instead of | |||
redirection, B's DNS resolver would also behave as the request | HTTP redirection, B's DNS resolver would also behave as the | |||
router and directly return the IP address of a delivery node. | request router and directly return the IP address of a delivery | |||
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 returns a 302 redirect message for a new URL constructed by | |||
replacing the hostname with a subdomain of the Operator B's | 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.net). B's DNS resolver returns the | subdomain (node1.peer-a.op-b.example). B's DNS resolver returns | |||
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 dCDN from uCDN (not the CSP). | |||
The distinguished CDN-Domain peer-a.op-b.net indicates to dCDN | The distinguished CDN-Domain peer-a.op-b.example indicates to | |||
that this content is to be acquired from uCDN; stripping the | dCDN that this content is to be acquired from uCDN; stripping | |||
CDN-Domain reveals the original CDN-Domain cdn.csp.com and dCDN | the CDN-Domain reveals the original CDN-Domain cdn.csp.example | |||
may verify that this CDN-Domain belongs to a known peer (so as | and dCDN may verify that this CDN-Domain belongs to a known peer | |||
to avoid being tricked into serving as an open proxy). It then | (so as to avoid being tricked into serving as an open proxy). | |||
does a DNS request for an inter-CDN acquisition CDN-Domain as | It then does a DNS request for an inter-CDN acquisition CDN- | |||
agreed above (in this case, op-b-acq.op-a.net). | 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 delivery node. Operator A 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.net). (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 | |||
redirecting the request back to operator B, resulting in an | risk of redirecting the request back to operator B, resulting in | |||
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 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. | |||
skipping to change at page 17, line 16 | skipping to change at page 17, line 31 | |||
correctly process. Neither CDN needs to be aware of the internal | correctly process. Neither CDN needs to 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 needs to | |||
be aware of the other's internal redirection mechanism (i.e., whether | be aware of the other's internal redirection mechanism (i.e., whether | |||
it is DNS or HTTP based). | it 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.com) if the browser | redirected URL be in the same domain (e.g., csp.example) if the | |||
is expected to send any cookies associated with that domain. As | browser is expected to send any cookies associated with that domain. | |||
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 allow for the domains involved in the CDN | domain policy that needs to allow for the domains involved in the CDN | |||
redirection. These problems are generally soluble, but the solutions | redirection. These problems are generally soluble, but the solutions | |||
complicate the example, so we do not discuss them further in this | complicate the example, so we do not discuss them further in this | |||
version of the draft. | version of the draft. | |||
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 does not require all of them. For | |||
example, obtaining information from dCDN regarding the set of client | example, obtaining information from dCDN regarding the set of client | |||
IP addresses or geographic regions it might be able to serve is an | IP addresses or geographic regions it might be able to serve is an | |||
aspect of request routing (specifically of the CDNI Footprint & | aspect of request routing (specifically of the CDNI Footprint & | |||
skipping to change at page 18, line 33 | skipping to change at page 18, line 46 | |||
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 | 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 | of CSP's content by dCDN. In this example, we'll use | |||
op-b-acq.op-a.net. | 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 dCDN is prepared to serve. For example, 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.com (or to return a CNAME for | authoritative DNS server for cdn.csp.example (or to return a CNAME | |||
cdn.csp.com for which operator A is the authoritative DNS server). | for cdn.csp.example for which operator A is the authoritative DNS | |||
server). | ||||
o Operator A is configured so that a DNS request for | o Operator A is configured so that a DNS request for | |||
op-b-acq.op-a.net 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.net/ | o Operator B is configured so that a request for node1.op-b.example/ | |||
cdn.csp.com returns the IP address of a delivery node. Note that | cdn.csp.example returns the IP address of a delivery node. Note | |||
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.com/...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.com | | | |DNS cdn.csp.example | | | |||
|-------------------------------------------------->| | |-------------------------------------------------->| | |||
| | |(1) | | | |(1) | |||
|IPaddr of A's Request Router | | |IPaddr of A's Request Router | | |||
|<--------------------------------------------------| | |<--------------------------------------------------| | |||
|HTTP cdn.csp.com | | | |HTTP cdn.csp.example | | | |||
|-------------------------------------------------->| | |-------------------------------------------------->| | |||
| | |(2) | | | |(2) | |||
| |RR/RI REQ cdn.csp.com | | | |RR/RI REQ cdn.csp.example| | |||
| |<------------------------| | | |<------------------------| | |||
| | | | | | | | |||
| |RR/RI RESP node1.op-b.net| | | |RR/RI RESP node1.op-b.example | |||
| |------------------------>| | | |------------------------>| | |||
| | |(3) | | | |(3) | |||
|302 node1.op-b.net/cdn.csp.com | | |302 node1.op-b.example/cdn.csp.example | | |||
|<--------------------------------------------------| | |<--------------------------------------------------| | |||
|DNS node1.op-b.net | | | |DNS node1.op-b.example | | | |||
|------------------------>| | | |------------------------>| | | |||
| |(4) | | | |(4) | | |||
|IPaddr of B's Delivery Node | | |IPaddr of B's Delivery Node | | |||
|<------------------------| | | |<------------------------| | | |||
|HTTP node1.op-b.net/cdn.csp.com | | |HTTP node1.op-b.example/cdn.csp.example | | |||
|------------------------>| | | |------------------------>| | | |||
| |(5) | | | |(5) | | |||
| |DNS op-b-acq.op-a.net | | | |DNS op-b-acq.op-a.example| | |||
| |------------------------>| | | |------------------------>| | |||
| | |(6) | | | |(6) | |||
| |IPaddr of A's Request Router | | |IPaddr of A's Request Router | |||
| |<------------------------| | | |<------------------------| | |||
| |HTTP op-b-acq.op-a.net | | | |HTTP op-b-acq.op-a.example | |||
| |------------------------>| | | |------------------------>| | |||
| | |(7) | | | |(7) | |||
| |302 node2.op-b.acq.op-A.net | | |302 node2.op-b.acq.op-A.example | |||
| |<------------------------| | | |<------------------------| | |||
| |DNS node2.op-b-acq.op-a.net | | |DNS node2.op-b-acq.op-a.example | |||
| |------------------------>| | | |------------------------>| | |||
| | |(8) | | | |(8) | |||
| |IPaddr of A's Delivery Node | | |IPaddr of A's Delivery Node | |||
| |<------------------------| | | |<------------------------| | |||
| | | | | | | | |||
| |HTTP node2.op-b-acq.op-a.net | | |HTTP node2.op-b-acq.op-a.example | |||
| |------------------------>| | | |------------------------>| | |||
| | |(9) | | | |(9) | |||
| |Data | | | |Data | | |||
| |<------------------------| | | |<------------------------| | |||
|Data | | | |Data | | | |||
|<------------------------| | | |<------------------------| | | |||
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.com. 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 | recognizes that the end-user is best served by another CDN-- | |||
CDN-\u002Dspecifically one provided by Operator B-\u002Dand so it | specifically one provided by Operator B--and so it queries the | |||
queries the CDNI Request Routing Redirection interface of | CDNI Request Routing Redirection interface of Operator B, | |||
Operator B, providing a set of information about the request | providing a set of information about the request including the | |||
including the URL requested. Operator B replies with the DNS | URL requested. Operator B replies with the DNS name of a | |||
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 host name of the URL | |||
just provided (node1.op-b.net). B's DNS resolver returns the IP | just provided (node1.op-b.example). B's DNS resolver returns the | |||
address of the corresponding delivery node. Note that, since the | IP address of the corresponding delivery node. Note that, since | |||
name of the delivery node was already obtained from B using the | the name of the delivery node was already obtained from B using | |||
RI, there should not be any further redirection here (in contrast | the RI, there should not be any further redirection here (in | |||
to the iterative method described above.) | contrast 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 uCDN (not the CSP.) | |||
The distinguished CDN-Domain op-b.net indicates to dCDN that this | The distinguished CDN-Domain op-b.example indicates to dCDN that | |||
content is to be acquired from another CDN; stripping the CDN- | this content is to be acquired from another CDN; stripping the | |||
Domain reveals the original CDN-Domain cdn.csp.com, dCDN may | CDN-Domain reveals the original CDN-Domain cdn.csp.example, dCDN | |||
verify that this CDN-Domain belongs to a known peer (so as to | may verify that this CDN-Domain belongs to a known peer (so as to | |||
avoid being tricked into serving as an open proxy). It then does | avoid being tricked into serving as an open proxy). It then does | |||
a DNS request for the inter-CDN Acquisition "distinguished" CDN- | a DNS request for the inter-CDN Acquisition "distinguished" CDN- | |||
Domain as agreed above (in this case, op-b-acq.op-a.net). | 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 DNS resolver processes the DNS request and returns the | |||
IP address of a request router in operator A. | 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 delivery node. Operator A request router recognizes | |||
that the request is from a peer CDN rather than an end-user | that the request is from a peer CDN rather than an end-user | |||
because of the dedicated inter-CDN acquisition domain | because of the dedicated inter-CDN acquisition domain | |||
(op-b-acq.op-a.net). (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 uCDN to serve the inter-CDN acquisition | |||
request and returns a 302 redirect message for a new URL | request and returns a 302 redirect message for a new URL | |||
constructed by replacing the hostname with a subdomain of the | 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 | |||
skipping to change at page 22, line 25 | skipping to change at page 22, line 44 | |||
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 dCDN is | |||
willing or able to serve (e.g. which client IP address prefixes or | willing or able to serve (e.g. which client IP address prefixes or | |||
geographic regions are part of the dCDN footprint). We assume | geographic regions are part of the dCDN footprint). We assume | |||
Operator has and makes known to operator A some unique identifier | Operator 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 AS number assigned to B, is one easy way to | |||
achieve that.) Also, Operator A obtains the NS records for Operator | achieve that.) Also, Operator A obtains the NS records for Operator | |||
B's externally visible redirection servers. Also, as before, a | B's externally visible redirection servers. Also, as before, a | |||
distinguished CDN-Domain, such as op-b-acq.op-a.net, must be assigned | distinguished CDN-Domain, such as op-b-acq.op-a.example, must be | |||
for inter-CDN acquisition. | 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.com (or to return a CNAME for cdn.csp.com for | server for cdn.csp.example (or to return a CNAME for | |||
which operator A is the authoritative DNS server). | cdn.csp.example for which operator A is the authoritative DNS | |||
server). | ||||
o When uCDN sees a request best served by dCDN, it returns CNAME and | o When uCDN sees a request best served by dCDN, it returns CNAME and | |||
NS records for "b.cdn.csp.com", where "b" is the unique identifier | NS records for "b.cdn.csp.example", where "b" is the unique | |||
assigned to Operator B. (It may, for example, be an AS number | identifier assigned to Operator B. (It may, for example, be an AS | |||
assigned to Operator B.) | number assigned to Operator B.) | |||
o dCDN is configured so that a request for "b.cdn.csp.com" returns a | o dCDN is configured so that a request for "b.cdn.csp.example" | |||
delivery node in dCDN. | returns a delivery node in dCDN. | |||
o uCDN is configured so that a request for "op-b-acq.op-a.net" | o uCDN is configured so that a request for "op-b-acq.op-a.example" | |||
returns a delivery node in uCDN. | returns a delivery node in 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.com | | | |DNS cdn.csp.example | | | |||
|-------------------------------------------------->| | |-------------------------------------------------->| | |||
| | |(1) | | | |(1) | |||
|CNAME b.cdn.csp.com | | | |CNAME b.cdn.csp.example | | | |||
|NS records for b.cdn.csp.com | | |NS records for b.cdn.csp.example | | |||
|<--------------------------------------------------| | |<--------------------------------------------------| | |||
|DNS b.cdn.csp.com | | | |DNS b.cdn.csp.example | | | |||
|------------------------>| | | |------------------------>| | | |||
| |(2) | | | |(2) | | |||
|IPaddr of B's Delivery Node | | |IPaddr of B's Delivery Node | | |||
|<------------------------| | | |<------------------------| | | |||
|HTTP cdn.csp.com | | | |HTTP cdn.csp.example | | | |||
|------------------------>| | | |------------------------>| | | |||
| |(3) | | | |(3) | | |||
| |DNS op-b-acq.op-a.net | | | |DNS op-b-acq.op-a.example| | |||
| |------------------------>| | | |------------------------>| | |||
| | |(4) | | | |(4) | |||
| |IPaddr of A's Delivery Node | | |IPaddr of A's Delivery Node | |||
| |<------------------------| | | |<------------------------| | |||
| |HTTP op-b-acq.op-a.net | | | |HTTP op-b-acq.op-a.example | |||
| |------------------------>| | | |------------------------>| | |||
| | |(5) | | | |(5) | |||
| |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. Request Router for Operator A processes the DNS request for CDN- | |||
Domain cdn.csp.com and recognizes that the end-user is best | Domain cdn.csp.example and recognizes that the end-user is best | |||
served by another CDN. (This may depend on the IP address of the | served by another CDN. (This may depend on the IP address of the | |||
user's local DNS resolver, or other information discussed below.) | user's local DNS resolver, or other information discussed below.) | |||
The Request Router returns a DNS CNAME response by "stacking" the | The Request Router returns a DNS CNAME response by "stacking" the | |||
distinguished identifier for Operator B onto the original CDN- | distinguished identifier for Operator B onto the original CDN- | |||
Domain (e.g., b.cdn.csp.com), plus an NS record that maps | Domain (e.g., b.cdn.csp.example), plus an NS record that maps | |||
b.cdn.csp.com to B's Request Router. | b.cdn.csp.example to B's Request Router. | |||
2. The end-user does a DNS lookup using the modified CDN-Domain | 2. The end-user does a DNS lookup using the modified CDN-Domain | |||
(i.e., b.cdn.csp.com). This causes B's Request Router to respond | (i.e., b.cdn.csp.example). This causes B's Request Router to | |||
with a suitable delivery node. | respond with a suitable delivery node. | |||
3. The end-user requests the content from B's delivery node. The | 3. The end-user requests the content from B's delivery node. The | |||
requested URL contains the name cdn.csp.com. (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.net). | Domain as agreed above (op-b-acq.op-a.example). | |||
4. Operator A recognizes that the DNS request is from a peer CDN | 4. 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. | |||
5. Operator A serves content to dCDN. Although not shown, it is at | 5. 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, uCDN will only obtain the address of the client's | |||
local DNS resolver (LDNS), which is not guaranteed to be in the same | local DNS resolver (LDNS), which is not guaranteed to be in the same | |||
network (or geographic region) as the client. If not-\u002De.g., the | network (or geographic region) as the client. If not--e.g., the end- | |||
end-user uses a global DNS service-\u002Dthen the upstream CDN cannot | user uses a global DNS service--then the upstream CDN cannot | |||
determine the appropriate downstream CDN to serve the end-user. In | determine the appropriate downstream CDN to serve the end-user. In | |||
this case, and assuming the uCDN is capable of detecting that | this case, and assuming the uCDN is capable of detecting that | |||
situation, one option is for the upstream CDN to treat the end-user | situation, one option is for the upstream CDN to treat the end-user | |||
as it would any user not connected to a peer CDN. Another option is | as it would any user not connected to a peer CDN. Another option is | |||
for the upstream CDN to "fall back" to a pure HTTP-based redirection | for the upstream CDN to "fall back" to a pure HTTP-based redirection | |||
strategy in this case (i.e., use the first method). Note that this | strategy in this case (i.e., use the first method). Note that this | |||
problem affects existing CDNs that rely on DNS to determine where to | problem affects existing CDNs that rely on DNS to determine where to | |||
redirect client requests, but the consequences are arguably less | redirect client requests, but the consequences are arguably less | |||
serious for CDNI since the LDNS is likely in the same network as the | serious for CDNI since the LDNS is likely in the same network as the | |||
dCDN serves. One approach to ensuring that the client's IP address | dCDN serves. One approach to ensuring that the client's IP address | |||
skipping to change at page 25, line 16 | skipping to change at page 26, line 5 | |||
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.com | | | |DNS cdn.csp.example | | | |||
|-------------------------------------------------->| | |-------------------------------------------------->| | |||
| | |(1) | | | |(1) | |||
| | RI REQ op-b.net | | | | RI REQ op-b.example | | |||
| |<------------------------| | | |<------------------------| | |||
| | |(2) | | | |(2) | |||
| | RI REPLY | | | | RI REPLY | | |||
| |------------------------>| | | |------------------------>| | |||
| | |(3) | | | |(3) | |||
|CNAME b.cdn.csp.com | | | |CNAME b.cdn.csp.example | | | |||
|NS records for b.cdn.csp.com | | |NS records for b.cdn.csp.example | | |||
|<--------------------------------------------------| | |<--------------------------------------------------| | |||
|DNS b.cdn.csp.com | | | |DNS b.cdn.csp.example | | | |||
|------------------------>| | | |------------------------>| | | |||
| |(2) | | | |(2) | | |||
|IPaddr of B's Delivery Node | | |IPaddr of B's Delivery Node | | |||
|<------------------------| | | |<------------------------| | | |||
|HTTP cdn.csp.com | | | |HTTP cdn.csp.example | | | |||
|------------------------>| | | |------------------------>| | | |||
| |(3) | | | |(3) | | |||
| |DNS op-b-acq.op-a.net | | | |DNS op-b-acq.op-a.example| | |||
| |------------------------>| | | |------------------------>| | |||
| | |(4) | | | |(4) | |||
| |IPaddr of A's Delivery Node | | |IPaddr of A's Delivery Node | |||
| |<------------------------| | | |<------------------------| | |||
| |HTTP op-b-acq.op-a.net | | | |HTTP op-b-acq.op-a.example | |||
| |------------------------>| | | |------------------------>| | |||
| | |(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 FCI request (step 2) and corresponding response (step 3). The RI | a FCI 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 | |||
skipping to change at page 26, line 38 | skipping to change at page 27, line 26 | |||
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. | dCDN. The following diagram illustrates the operation. | |||
End-User Operator B Operator A | End-User Operator B Operator A | |||
| |CI purge cdn.csp.com/... | | | |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 uCDN to dCDN that some | |||
previously acquired content should be deleted. The URL in the | 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.net/cdn.csp.com/... | 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 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.com/... | | |CI pre-position cdn.csp.example/... | |||
| |<------------------------| | | |<------------------------| | |||
| | |(1) | | | |(1) | |||
| |CI OK | | | |CI OK | | |||
| |------------------------>| | | |------------------------>| | |||
| | | | | | | | |||
| |DNS op-b-acq.op-a.net | | | |DNS op-b-acq.op-a.example| | |||
| |------------------------>| | | |------------------------>| | |||
| | |(2) | | | |(2) | |||
| |IPaddr of A's Delivery Node | | |IPaddr of A's Delivery Node | |||
| |<------------------------| | | |<------------------------| | |||
| |HTTP op-b-acq.op-a.net | | | |HTTP op-b-acq.op-a.example | |||
| |------------------------>| | | |------------------------>| | |||
| | |(3) | | | |(3) | |||
| |Data | | | |Data | | |||
| |<------------------------| | | |<------------------------| | |||
|DNS cdn.csp.com | | | |DNS cdn.csp.example | | | |||
|-------------------------------------------------->| | |--------------------------------------------->| | |||
| | |(4) | | | |(4) | |||
|IPaddr of A's Request Router | | |IPaddr of A's Request Router | | |||
|<--------------------------------------------------| | |<---------------------------------------------| | |||
|HTTP cdn.csp.com | | | |HTTP cdn.csp.example| | | |||
|-------------------------------------------------->| | |--------------------------------------------->| | |||
| | |(5) | | | |(5) | |||
|302 peer-a.op-b.net/cdn.csp.com | | |302 peer-a.op-b.example/cdn.csp.example | | |||
|<--------------------------------------------------| | |<---------------------------------------------| | |||
|DNS peer-a.op-b.net | | | |DNS peer-a.op-b.example | | |||
|------------------------>| | | |------------------->| | | |||
| |(6) | | | |(6) | | |||
|IPaddr of B's Delivery Node | | |IPaddr of B's Delivery Node | | |||
|<------------------------| | | |<-------------------| | | |||
|HTTP peer-a.op-b.net/cdn.csp.com | | |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-positions 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 Figure | Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of | |||
3, only this time Operator B CDN can serve the end-user request | Figure 3, only this time Operator B CDN can serve the end-user | |||
without triggering dynamic content acquisition, since the content has | request without triggering dynamic content acquisition, since the | |||
been pre-positioned in dCDN. Note that, depending on dCDN operations | content has been pre-positioned in dCDN. Note that, depending on | |||
and policies, the content pre-positioned in the dCDN may be pre- | dCDN operations and policies, the content pre-positioned in the dCDN | |||
positioned to all, or a subset of, dCDN caches. In the latter case, | may be pre-positioned to all, or a subset of, dCDN caches. In the | |||
intra-CDN dynamic content acquisition may take place inside the dCDN | latter case, intra-CDN dynamic content acquisition may take place | |||
serving requests from caches on which the content has not been pre- | inside the dCDN serving requests from caches on which the content has | |||
positioning; however, such intra-CDN dynamic acquisition would not | not been pre-positioning; however, such intra-CDN dynamic acquisition | |||
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 | |||
skipping to change at page 29, line 22 | skipping to change at page 30, line 29 | |||
| CONTENT REQUEST | | | | CONTENT REQUEST | | | |||
|-------------------------------------------------->|(5) | |-------------------------------------------------->|(5) | |||
| | | | | | | | |||
| | RI REQ | | | | RI REQ | | |||
| |<------------------------|(6) | | |<------------------------|(6) | |||
| | | | | | | | |||
| | RI RESP | | | | RI RESP | | |||
| |------------------------>|(7) | | |------------------------>|(7) | |||
| | | | | | | | |||
| CONTENT REDIRECTION | | | | CONTENT REDIRECTION | | | |||
|<--------------------------------------------------| (8) | |<--------------------------------------------------|(8) | |||
| | | | | | | | |||
| CONTENT REQUEST | | | | CONTENT REQUEST | | | |||
|------------------------>|(9) | | |------------------------>|(9) | | |||
| | | | | | | | |||
: : : | : : : | |||
| CONTENT DATA | | | | CONTENT DATA | | | |||
|<------------------------| |(10) | |<------------------------| |(10) | |||
Figure 9: Message Flow for Asynchronous CDNI Metadata | Figure 9: Message Flow for Asynchronous CDNI Metadata | |||
skipping to change at page 30, line 48 | skipping to change at page 32, line 6 | |||
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 | | |||
| |<------------------------|(4) | | |<------------------------|(4) | |||
| | | | | | | | |||
| | RI RESP | | | | RI RESP | | |||
| |------------------------>|(5) | | |------------------------>|(5) | |||
| | | | | | | | |||
| | | | | | | | |||
| CONTENT REDIRECTION | | | | CONTENT REDIRECTION | | | |||
|<--------------------------------------------------|(6) | |<--------------------------------------------------|(6) | |||
| | | | | | | | |||
| CONTENT REQUEST | | | | CONTENT REQUEST | | | |||
|------------------------>| (7) | | |------------------------>|(7) | | |||
| | | | | | | | |||
| | MI REQ | | | | MI REQ | | |||
| (8)|------------------------>| | | (8)|------------------------>| | |||
| | MI RESP | | | | MI RESP | | |||
| |<------------------------|(9) | | |<------------------------|(9) | |||
| | | | | | | | |||
: : : | : : : | |||
| CONTENT DATA | | | | CONTENT DATA | | | |||
|<------------------------| | (10) | |<------------------------| |(10) | |||
Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition | Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition | |||
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 | |||
skipping to change at page 33, line 37 | skipping to change at page 34, line 42 | |||
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 RFC 6707 and | these interfaces are left to other documents, but see [RFC6707] and | |||
[I-D.ietf-cdni-requirements] for some discussion of the interfaces. | [I-D.ietf-cdni-requirements] 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" | |||
skipping to change at page 35, line 30 | skipping to change at page 36, line 38 | |||
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. | CDNs. For further discussion on the RI, see | |||
[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 includes | method(s) supported, this might includes | |||
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 | |||
skipping to change at page 36, line 8 | skipping to change at page 37, line 18 | |||
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 dCDN is willing to serve could in | |||
some cases be relatively static (e.g., a set of IP prefixes) which | some cases be relatively static (e.g., a set of IP prefixes) which | |||
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 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.spp-cdni-rr-foot-cap-semantics]. | be found in [I-D.ietf-cdni-footprint-capabilities-semantics]. | |||
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. | |||
skipping to change at page 36, line 43 | skipping to change at page 38, line 4 | |||
o Time zone - any time zone modifier for the end time | o Time zone - any time zone modifier for the end time | |||
o Method - the transfer command itself (e.g., GET, POST, HEAD) | o Method - the transfer command itself (e.g., GET, POST, HEAD) | |||
o URL - the requested URL | o URL - the requested URL | |||
o Version - the protocol version, such as HTTP/1.0 | o Version - the protocol version, such as HTTP/1.0 | |||
o Response - a numeric response code indicating transfer result | o Response - a numeric response code indicating transfer result | |||
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 Referrer - 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 | Of these, only the Domain field is indirect in the downstream CDN--it | |||
CDN-\u002Dit is set to the CDN-Domain used by the upstream CDN rather | is set to the CDN-Domain used by the upstream CDN rather than the | |||
than the actual origin server. This field could then used to filter | actual origin server. This field could then used to filter traffic | |||
traffic log entries so only those entries matching the upstream CDN | log entries so only those entries matching the upstream CDN are | |||
are reported to the corresponding operator. Further discussion of | reported to the corresponding operator. Further discussion of the LI | |||
the LI can be found in [I-D.bertrand-cdni-logging]. | can be found in [I-D.ietf-cdni-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 knows 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 | |||
skipping to change at page 38, line 20 | skipping to change at page 39, line 28 | |||
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 dCDN to uCDN in order to bootstrap | |||
the CDNI Logging interface. It may also be used, for example, to | the CDNI Logging interface. It may also be used, for example, to | |||
establish security associations for the other interfaces. | 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, are | |||
discussed further in [I-D.murray-cdni-triggers]. | discussed further in [I-D.ietf-cdni-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. For example, see [I-D.ietf-cdni-metadata]. Such | upstream CDN. Such metadata includes geo-blocking restrictions, | |||
metadata includes geo-blocking restrictions, availability windows, | availability windows, access control policies, and so on. It may | |||
access control policies, and so on. It may also include information | also include information to facilitate acquisition of content by dCDN | |||
to facilitate acquisition of content by dCDN (e.g., alternate sources | (e.g., alternate sources for the content, authorization information | |||
for the content, authorization information needed to acquire the | needed to acquire the content from the source). For a full | |||
content from the source). | discussion of the CDNI Metadata Interface, see | |||
[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 | |||
skipping to change at page 45, line 16 | skipping to change at page 46, line 50 | |||
is the more general concept, involving two or more CDNs serving | is the more general concept, involving two or more CDNs serving | |||
content to each other's users, while federation implies a multi- | content to each other's users, while federation implies a multi- | |||
lateral interconnection arrangement, but other CDN interconnection | lateral interconnection arrangement, but other CDN interconnection | |||
agreements are also possible (e.g., symmetric bilateral, asymmetric | agreements are also possible (e.g., symmetric bilateral, asymmetric | |||
bilateral). An important conclusion is that CDNI technology should | bilateral). An important conclusion is that CDNI technology should | |||
not presume (or bake in) a particular interconnection agreement, but | not presume (or bake in) a particular interconnection agreement, but | |||
should instead be general enough to permit alternative | should instead be general enough to permit alternative | |||
interconnection arrangements to evolve. | interconnection arrangements 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-\u002Da third party broker or exchange that is used to | Exchange--a third party broker or exchange that is used to facilitate | |||
facilitate a CDN federation. Our view is that a CDN exchange offers | a CDN federation. Our view is that a CDN exchange offers valuable | |||
valuable machinery to scale the number of CDN operators involved in a | machinery to scale the number of CDN operators involved in a multi- | |||
multi-lateral (federated) agreement, but that this machinery is built | lateral (federated) agreement, but that this machinery is built on | |||
on top of the core CDNI interconnection mechanisms. For example, as | top of the core CDNI interconnection mechanisms. For example, as | |||
illustrated in Figure 14, the exchange might aggregate and | illustrated in Figure 14, the exchange might aggregate and | |||
redistribute information about each CDN footprint and capacity, as | redistribute information about each CDN footprint and capacity, as | |||
well as collect, filter, and redistribute traffic logs that each | well as collect, filter, and redistribute traffic logs that each | |||
participant needs for interconnection settlement, but inter-CDN | participant needs for interconnection settlement, but inter-CDN | |||
request routing, inter-CDN content distribution (including inter-CDN | request routing, inter-CDN content distribution (including inter-CDN | |||
acquisition) and inter-CDN control which fundamentally involve a | acquisition) and inter-CDN control which fundamentally involve a | |||
direct interaction between an upstream CDN and a downstream | direct interaction between an upstream CDN and a downstream CDN-- | |||
CDN-\u002Doperate exactly as in a pair-wise peering arrangement. | operate exactly as in a pair-wise peering arrangement. Turning to | |||
Turning to Figure 14, we observe that in this example: | Figure 14, we observe that in 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 interfaces with the | o each CDN supports both a CDNI Request Routing interfaces with the | |||
skipping to change at page 50, line 5 | skipping to change at page 52, line 15 | |||
will be specified in the relevant interface documents. | will be specified in the relevant interface documents. | |||
8.2. Digital Rights Management | 8.2. Digital Rights Management | |||
Issues of digital rights management (DRM, also sometimes called | Issues of digital rights management (DRM, also sometimes called | |||
digital restrictions management) is often employed for content | digital restrictions management) is often employed for content | |||
distributed via CDNs. In general, DRM relies on the CDN to | distributed via CDNs. In general, DRM relies on the CDN to | |||
distribute encrypted content, with decryption keys distributed to | distribute encrypted content, with decryption keys distributed to | |||
users by some other means (e.g. directly from the CSP to the end | users by some other means (e.g. directly from the CSP to the end | |||
user.) For this reason, DRM is considered out of scope for the CDNI | user.) For this reason, DRM is considered out of scope for the CDNI | |||
WG RFC 6707 and does not introduce additional security issues for | WG [RFC6707] and does not introduce additional security issues for | |||
CDNI. | CDNI. | |||
9. Contributors | 9. Contributors | |||
The following individuals contributed to this document: | The following individuals contributed to this document: | |||
o Ray van Brandenburg | o Ray van Brandenburg | |||
o Matt Caulfield | o Matt Caulfield | |||
skipping to change at page 50, line 34 | skipping to change at page 52, line 44 | |||
o Ben Niven-Jenkins | o Ben Niven-Jenkins | |||
o Kent Leung | o Kent Leung | |||
10. Acknowledgements | 10. Acknowledgements | |||
We thank Huw Jones for helpful input to the draft. | We thank Huw Jones for helpful input to the draft. | |||
11. Informative References | 11. Informative References | |||
[I-D.bertrand-cdni-logging] | ||||
Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F., | ||||
and P. Grochocki, "CDNI Logging Interface", draft- | ||||
bertrand-cdni-logging-02 (work in progress), October 2012. | ||||
[I-D.ietf-appsawg-http-forwarded] | [I-D.ietf-appsawg-http-forwarded] | |||
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", | Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", | |||
draft-ietf-appsawg-http-forwarded-10 (work in progress), | draft-ietf-appsawg-http-forwarded-10 (work in progress), | |||
October 2012. | October 2012. | |||
[I-D.ietf-cdni-control-triggers] | ||||
Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / | ||||
Triggers", draft-ietf-cdni-control-triggers-02 (work in | ||||
progress), December 2013. | ||||
[I-D.ietf-cdni-footprint-capabilities-semantics] | ||||
Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., | ||||
and K. Ma, "CDNI Request Routing: Footprint and | ||||
Capabilities Semantics", draft-ietf-cdni-footprint- | ||||
capabilities-semantics-01 (work in progress), October | ||||
2013. | ||||
[I-D.ietf-cdni-logging] | ||||
Faucheur, F., Bertrand, G., Oprescu, I., and R. | ||||
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- | ||||
logging-08 (work in progress), October 2013. | ||||
[I-D.ietf-cdni-metadata] | [I-D.ietf-cdni-metadata] | |||
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., | Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., | |||
Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- | Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- | |||
ietf-cdni-metadata-03 (work in progress), October 2013. | ietf-cdni-metadata-04 (work in progress), December 2013. | |||
[I-D.ietf-cdni-redirection] | ||||
Danhua, W., Niven-Jenkins, B., He, X., Chen, G., and W. | ||||
Ni, "Request Routing Redirection Interface for CDN | ||||
Interconnection", draft-ietf-cdni-redirection-01 (work in | ||||
progress), October 2013. | ||||
[I-D.ietf-cdni-requirements] | [I-D.ietf-cdni-requirements] | |||
Leung, K. and Y. Lee, "Content Distribution Network | Leung, K. and Y. Lee, "Content Distribution Network | |||
Interconnection (CDNI) Requirements", draft-ietf-cdni- | Interconnection (CDNI) Requirements", draft-ietf-cdni- | |||
requirements-12 (work in progress), November 2013. | requirements-14 (work in progress), December 2013. | |||
[I-D.lefaucheur-cdni-logging-delivery] | ||||
Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI | ||||
Logging Formats for HTTP and HTTP Adaptive Streaming | ||||
Deliveries", draft-lefaucheur-cdni-logging-delivery-01 | ||||
(work in progress), July 2012. | ||||
[I-D.murray-cdni-triggers] | ||||
Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / | ||||
Triggers", draft-murray-cdni-triggers-03 (work in | ||||
progress), April 2013. | ||||
[I-D.seedorf-alto-for-cdni] | ||||
Seedorf, J., "ALTO for CDNi Request Routing", draft- | ||||
seedorf-alto-for-cdni-00 (work in progress), October 2011. | ||||
[I-D.spp-cdni-rr-foot-cap-semantics] | ||||
Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., | ||||
and K. Ma, "CDNI Request Routing: Footprint and | ||||
Capabilities Semantics", draft-spp-cdni-rr-foot-cap- | ||||
semantics-04 (work in progress), February 2013. | ||||
[I-D.vandergaast-edns-client-subnet] | [I-D.vandergaast-edns-client-subnet] | |||
Contavalli, C., Gaast, W., Leach, S., and E. Lewis, | Contavalli, C., Gaast, W., Leach, S., and E. Lewis, | |||
"Client Subnet in DNS Requests", draft-vandergaast-edns- | "Client Subnet in DNS Requests", draft-vandergaast-edns- | |||
client-subnet-02 (work in progress), July 2013. | client-subnet-02 (work in progress), July 2013. | |||
[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. | |||
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic | ||||
Optimization (ALTO) Problem Statement", RFC 5693, October | ||||
2009. | ||||
[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 | |||
End of changes. 81 change blocks. | ||||
447 lines changed or deleted | 449 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/ |