draft-ietf-cdni-framework-05.txt | draft-ietf-cdni-framework-06.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: March 13, 2014 September 09, 2013 | Expires: April 24, 2014 October 21, 2013 | |||
Framework for CDN Interconnection | Framework for CDN Interconnection | |||
draft-ietf-cdni-framework-05 | draft-ietf-cdni-framework-06 | |||
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 several | CDNs. CDN Interconnection requires the specification of interfaces | |||
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 | |||
across CDNs. The intent of this document is to outline what each | across CDNs. The intent of this document is to outline what each | |||
interface needs to accomplish, and to describe how these interfaces | interface needs to accomplish, and to describe how these interfaces | |||
and mechanisms fit together, while leaving their detailed | and mechanisms fit together, while leaving their detailed | |||
specification to other documents. It obsoletes RFC 3466. | specification to other documents. It obsoletes RFC 3466. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 March 13, 2014. | This Internet-Draft will expire on April 24, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 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 | |||
skipping to change at page 2, line 17 | skipping to change at page 2, line 17 | |||
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 . . . . . . . . . . . . . . . 8 | 1.3. Structure Of This Document . . . . . . . . . . . . . . . 7 | |||
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 | |||
skipping to change at page 2, line 42 | skipping to change at page 2, line 42 | |||
3.10. Content and Metadata Acquisition with Multiple Upstream | 3.10. Content and Metadata Acquisition with Multiple Upstream | |||
CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 | CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33 | 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34 | 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34 | |||
4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 34 | 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 34 | |||
4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 35 | 4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 35 | |||
4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 36 | 4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 36 | |||
4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 38 | 4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 38 | |||
4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 38 | 4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 38 | |||
4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39 | 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39 | |||
4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 41 | 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 40 | |||
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 41 | 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 41 | |||
5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42 | 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43 | 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43 | |||
5.3. CSP using CDNI Request Routing Interface . . . . . . . . 44 | 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 43 | |||
5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 45 | 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 44 | |||
6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 46 | 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 | |||
8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 49 | 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 49 | |||
8.2. Digital Rights Management . . . . . . . . . . . . . . . . 50 | 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 49 | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 | |||
11. Informative References . . . . . . . . . . . . . . . . . . . 51 | 11. Informative References . . . . . . . . . . . . . . . . . . . 50 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
1. Introduction | 1. Introduction | |||
The interconnection of Content Distribution Networks (CDNs) is | This document provides an overview of the various components | |||
motivated by several use cases, such as those described in | necessary to interconnect CDNs, expanding on the problem statement | |||
[I-D.ietf-cdni-use-cases]. The overall problem space for CDN | and use cases introduced in RFCs 6770 and 6707. It describes the | |||
Interconnection is described in RFC 6707. The purpose of this | necessary interfaces and mechanisms in general terms and outlines how | |||
document is to provide an overview of the various components | they fit together to form a complete system for CDN Interconnection. | |||
necessary to interconnect CDNs. CDN Interconnection requires the | Detailed specifications are left to other documents. This document | |||
specification of several interfaces and mechanisms to address issues | makes extensive use of message flow examples to illustrate the | |||
such as request routing, metadata exchange, and the acquisition of | operation of interconnected CDNs, but these examples should be | |||
content by one CDN from another. The intent of this document is to | considered illustrative rather than prescriptive. | |||
describe how these interfaces and mechanisms fit together, leaving | ||||
their detailed specification to other documents. We make extensive | ||||
use of message flow examples to illustrate the operation of | ||||
interconnected CDNs, but these examples should be considered | ||||
illustrative rather than prescriptive. | ||||
RFC 3466 uses different terminology and models for "Content | RFC 3466 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 RFC 3466. | |||
1.1. Terminology | 1.1. Terminology | |||
This document draws freely on the core terminology defined in RFC | This document uses the core terminology defined in RFC 6707. It also | |||
6707. It also introduce the following terms: | 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.com/...rest of url..., the CDN | |||
domain is cdn.csp.com. A major role of CDN-Domain is to identify a | domain is cdn.csp.com. A major role of CDN-Domain is to identify a | |||
region (subset) of the URI space relative to which various CDN | 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. | |||
Delivering CDN: the CDN that ultimately delivers a piece of content | Delivering CDN: the CDN that ultimately delivers a piece of content | |||
to the end-user. The last in a potential sequence of downstream | to the end-user. The last in a potential sequence of downstream | |||
CDNs. | CDNs. | |||
Recursive CDNI Request Redirection: When an Upstream CDN elects to | Recursive CDNI Request Redirection: When an upstream CDN elects to | |||
redirect a request towards a Downstream CDN, the Upstream CDN can | redirect a request towards a downstream CDN, the upstream CDN can | |||
query the Downstream CDN Request Routing system via the CDNI Request | query the downstream CDN Request Routing system via the CDNI Request | |||
Routing Redirection Interface (or use information cached from earlier | Routing Redirection Interface (or use information cached from earlier | |||
similar queries) to find out how the Downstream CDN wants the request | similar queries) to find out how the downstream CDN wants the request | |||
to be redirected, which allows the Upstream CDN to factor in the | to be redirected, which allows the upstream CDN to factor in the | |||
Downstream CDN response when redirecting the user agent. This | downstream CDN response when redirecting the user agent. This | |||
approach is referred to as "Recursive" CDNI Request Redirection. | approach is referred to as "Recursive" CDNI Request Redirection. | |||
Note that the Downstream CDN may elect to have the request redirected | Note that the downstream CDN may elect to have the request redirected | |||
directly to a Surrogate inside the Downstream CDN, to the Request | directly to a Surrogate inside the downstream CDN, to the Request | |||
Routing System of the Downstream CDN, to another CDN, or to any other | Routing System of the downstream CDN, to another CDN, or to whatever | |||
system that the Downstream CDN sees as fit for handling the | system is necessary to handle the redirected request appropriately. | |||
redirected request. | ||||
Iterative CDNI Request Redirection: When an Upstream CDN elects to | Iterative CDNI Request Redirection: When an upstream CDN elects to | |||
redirect a request towards a Downstream CDN, the Upstream CDN can | redirect a request towards a downstream CDN, the upstream CDN can | |||
base its redirection purely on a local decision (and without | base its redirection purely on a local decision (and without | |||
attempting to take into account how the Downstream CDN may in turn | attempting to take into account how the downstream CDN may in turn | |||
redirect the user agent). In that case, the Upstream CDN redirects | redirect the user agent). In that case, the upstream CDN redirects | |||
the request to the request routing system in the Downstream CDN, | the request to the request routing system in the downstream CDN, | |||
which in turn will decide how to redirect that request: this approach | which in turn will decide how to redirect that request: this approach | |||
is referred to as "Iterative" CDNI Request Redirection. | is referred to as "Iterative" CDNI Request Redirection. | |||
Synchronous CDNI operations: operations between CDNs that happen | Synchronous CDNI operations: operations between CDNs that happen | |||
during the process of servicing a user request, i.e. between the time | during the process of servicing a user request, i.e. between the time | |||
that the user agent begins its attempt to obtain content and the time | that the user agent begins its attempt to obtain content and the time | |||
at which that request is served. | at which that request is served. | |||
Asynchronous CDNI operations: operations between CDNs that happen | Asynchronous CDNI operations: operations between CDNs that happen | |||
independently of any given user request, such as advertisement of | independently of any given user request, such as advertisement of | |||
footprint information or pre-positioning of content for later | footprint information or pre-positioning of content for later | |||
delivery. | delivery. | |||
Trigger Interface: a subset of the CDNI Control interface that | Trigger Interface: a subset of the CDNI Control interface that | |||
includes operations to pre-position, revalidate, and purge both | includes operations to pre-position, revalidate, and purge both | |||
metadata and content. These operations are typically called in | metadata and content. These operations are typically called in | |||
response to some action (trigger) by the 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 | ||||
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 RFC 6707. (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.) | |||
skipping to change at page 6, line 14 | skipping to change at page 6, line 10 | |||
**** interfaces outside the scope of CDNI | **** interfaces outside the scope of CDNI | |||
.... interfaces outside the scope of CDNI | .... interfaces outside the scope of CDNI | |||
Figure 1: CDNI Expanded Model and CDNI Interfaces | Figure 1: CDNI Expanded Model and CDNI Interfaces | |||
We note that while some interfaces in the reference model are "out of | We note that while some interfaces in the reference model are "out of | |||
scope" for the CDNI WG (in the sense that there is no need to define | scope" for the CDNI WG (in the sense that there is no need to define | |||
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 uCDN serving a | We also note that, while we generally show only one upstream CDN | |||
given CSP, it is entirely possible that multiple uCDNs can serve a | serving a given CSP, it is entirely possible that multiple uCDNs can | |||
single CSP. In fact, this situation effectively exists today in the | serve a single CSP. In fact, this situation effectively exists today | |||
sense that a single CSP can currently delegate its content delivery | in the sense that a single CSP can currently delegate its content | |||
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 RFC 6707. We discuss these | |||
interfaces in more detail in Section 4. | interfaces in more detail in Section 4. | |||
o CDNI Control interface (CI): Operations to bootstrap and | o CDNI Control interface (CI): Operations to bootstrap and | |||
parameterize the other CDNI interfaces, as well as operations to | parameterize the other CDNI interfaces, as well as operations to | |||
pre-position, revalidate, and purge both metadata and content. | pre-position, revalidate, and purge both metadata and content. | |||
The latter subset of operations is sometimes collectively called | The latter subset of operations is sometimes collectively called | |||
the "trigger interface." | the "Trigger interface." | |||
o CDNI Request Routing interface: Operations to determine what CDN | o CDNI Request Routing interface: Operations to determine what CDN | |||
(and optionally what surrogate within a CDN) is to serve end- | (and optionally what surrogate within a CDN) is to serve end- | |||
user's requests. Is actually a logical bundling of two separate | user's requests. Is actually a logical bundling of two separate | |||
but related interfaces: | but related interfaces: | |||
* CDNI Footprint & Capabilities Advertisement interface (FCI): | * CDNI Footprint & Capabilities Advertisement interface (FCI): | |||
Asynchronous operations to exchange routing information (e.g., | Asynchronous operations to exchange routing information (e.g., | |||
the network footprint and capabilities served by a given CDN) | the network footprint and capabilities served by a given CDN) | |||
that enables CDN selection for subsequent user requests; and | that enables CDN selection for subsequent user requests; and | |||
* CDNI Request Routing Redirection interface (RI): Synchronous | * CDNI Request Routing Redirection interface (RI): Synchronous | |||
operations to select a delivery CDN (surrogate) for a given | operations to select a delivery CDN (surrogate) for a given | |||
user request. | user request. | |||
o CDNI Metadata interface (MI): Operations to communicate metadata | o CDNI Metadata interface (MI): Operations to communicate metadata | |||
that governs how the content is delivered by interconnected CDNs. | that governs how the content is delivered by interconnected CDNs. | |||
Examples of CDNI metadata include geo-blocking directives, | Examples of CDNI metadata include geo-blocking directives, | |||
availability windows, access control mechanisms, and purge | availability windows, access control mechanisms, and purge | |||
directives. May include a combination of: | directives. It may include a combination of: | |||
* Asynchronous operations to exchange metadata that govern | * Asynchronous operations to exchange metadata that govern | |||
subsequent user requests for content; and | subsequent user requests for content; and | |||
* Synchronous operations that govern behavior for a given user | * Synchronous operations that govern behavior for a given user | |||
request for content. | request for content. | |||
o CDNI Logging interface (LI): Operations that allow interconnected | o CDNI Logging interface (LI): Operations that allow interconnected | |||
CDNs to exchange relevant activity logs. May include a | CDNs to exchange relevant activity logs. May include a | |||
combination of: | combination of: | |||
* Real-time exchanges, suitable for runtime traffic monitoring; | * Real-time exchanges, suitable for runtime traffic monitoring; | |||
and | and | |||
* Offline exchanges, suitable for analytics and billing. | * Offline exchanges, suitable for analytics and billing. | |||
There is some potential overlap between the set of trigger-based | There is some potential overlap between the set of Trigger-based | |||
operations in the CDNI Control interface and the CDNI Metadata | operations in the CDNI Control interface and the CDNI Metadata | |||
interface. For both cases, the information passed from the upstream | interface. For both cases, the information passed from the upstream | |||
CDN to the downstream CDN can broadly be viewed as metadata that | CDN to the downstream CDN can broadly be viewed as metadata that | |||
describes how content is to be managed by the downstream CDN. For | describes how content is to be managed by the downstream CDN. For | |||
example, the information conveyed by CI to pre-position, revalidate | example, the information conveyed by CI to pre-position, revalidate | |||
or purge metadata is similar to the information conveyed by posting | or purge metadata is similar to the information conveyed by posting | |||
updated metadata via the MI. Even the CI operation to purge content | updated metadata via the MI. Even the CI operation to purge content | |||
could be viewed as an metadata update for that content: purge simply | could be viewed as an metadata update for that content: purge simply | |||
says that the availability window for the named content ends now. | says that the availability window for the named content ends now. | |||
The two interfaces share much in common, so minimally, there will | The two interfaces share much in common, so minimally, there will | |||
need to be a consistent data model that spans both. | need to be a consistent data model that spans both. | |||
The distinction we draw has to do with what the caller knows about | The distinction we draw has to do with what the uCDN knows about the | |||
the successful application of the metadata by the callee. In the | successful application of the metadata by the dCDN. In the case of | |||
case of the CI, the downstream CDN returning a successful status | the CI, the downstream CDN returning a successful status message | |||
message guarantees that the operation has been successfully | guarantees that the operation has been successfully completed; e.g., | |||
completed; e.g., the content has been purged or pre-positioned. This | the content has been purged or pre-positioned. This implies that the | |||
implies that the downstream CDN accepts responsibility for having | downstream CDN accepts responsibility for having successfully | |||
successfully completed the requested operation. In contrast, | completed the requested operation. In contrast, metadata passed | |||
metadata passed between CDNs via the MI carries no such completion | between CDNs via the MI carries no such completion guarantee. | |||
guarantee. Returning success implies successful receipt of the | Returning success implies successful receipt of the metadata, but | |||
metadata, but nothing can be inferred about precisely when the | nothing can be inferred about precisely when the metadata will take | |||
metadata will take effect in the downstream CDN, only that it will | effect in the downstream CDN, only that it will take effect | |||
take effect eventually. This is because of the challenge in globally | eventually. This is because of the challenge in globally | |||
synchronizing updates to metadata with end-user requests that are | synchronizing updates to metadata with end-user requests that are | |||
currently in progress (or indistinguishable from currently being in | currently in progress (or indistinguishable from currently being in | |||
progress). Clearly, a CDN will not be viewed as a trusted peer if | progress). Clearly, a CDN will not be viewed as a trusted peer if | |||
"eventually" often becomes an indefinite period of time, but the | "eventually" often becomes an indefinite period of time, but the | |||
acceptance of responsibility cannot be as crisply defined for the MI. | acceptance of responsibility cannot be as crisply defined for the MI. | |||
Finally, there is a practical issue that impacts all of the CNDI | Finally, there is a practical issue that impacts all of the 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 [I-D.brandenburg-cdni-has]. | thorough treatment of the topic, see RFC 6983. | |||
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 8, line 48 | skipping to change at page 8, line 45 | |||
2.1.1. DNS Redirection | 2.1.1. DNS Redirection | |||
DNS redirection is based on returning different IP addresses for the | DNS redirection is based on returning different IP addresses for the | |||
same DNS name, for example, to balance server load or to account for | same DNS name, for example, to balance server load or to account for | |||
the client's location in the network. A DNS server, sometimes called | the client's location in the network. A DNS server, sometimes called | |||
the Local DNS (LDNS), resolves DNS names on behalf of an end-user. | the Local DNS (LDNS), resolves DNS names on behalf of an end-user. | |||
The LDNS server in turn queries other DNS servers until it reaches | The LDNS server in turn queries other DNS servers until it reaches | |||
the authoritative DNS server for the CDN-Domain. The network | the authoritative DNS server for the CDN-Domain. The network | |||
operator typically provides the LDNS server, although the user is | operator typically provides the LDNS server, although the user is | |||
free to choose other DNS servers (e.g., OpenDNS, Google Public DNS). | free to choose other DNS servers (e.g., OpenDNS, Google Public DNS). | |||
This latter possibility is important because the authoritative DNS | ||||
server sees only the IP address of the DNS server that queries it, | ||||
not the IP address of the original end-user. | ||||
The advantage of DNS redirection is that it is completely transparent | The advantage of DNS redirection is that it is completely transparent | |||
to the end user-\u002Dthe user sends a DNS name to the LDNS server | to the end user; the user sends a DNS name to the LDNS server and | |||
and gets back an IP address. On the other hand, DNS redirection is | gets back an IP address. On the other hand, DNS redirection is | |||
problematic because the DNS request comes from the LDNS server, not | problematic because the DNS request comes from the LDNS server, not | |||
the end-user. This may affect the accuracy of server selection that | the end-user. This may affect the accuracy of server selection that | |||
is based on the user's location. The transparency of DNS redirection | is based on the user's location. The transparency of DNS redirection | |||
is also a problem in that there is no opportunity to take the | is also a problem in that there is no opportunity to take the | |||
attributes of the user agent or the URI path component into account. | attributes of the user agent or the URI path component into account. | |||
We consider two main forms of DNS redirection: simple and CNAME- | We consider two main forms of DNS redirection: simple and CNAME- | |||
based. | based. | |||
In simple DNS redirection, the authoritative DNS server for the name | In simple DNS redirection, the authoritative DNS server for the name | |||
simply returns an IP address from a set of possible IP addresses. | simply returns an IP address from a set of possible IP addresses. | |||
The answer is chosen from the set based on characteristics of the set | The answer is chosen from the set based on characteristics of the set | |||
(e.g., the relative loads on the servers) or characteristics of the | (e.g., the relative loads on the servers) or characteristics of the | |||
client (e.g., the location of the client relative to the servers). | client (e.g., the location of the client relative to the servers). | |||
Simple redirection is straightforward. The only caveats are (1) | Simple redirection is straightforward. The only caveats are (1) | |||
there is a limit to the number alternate IP addresses a single DNS | there is a limit to the number of alternate IP addresses a single DNS | |||
server can manage; and (2) DNS responses are cached by downstream | server can manage; and (2) DNS responses are cached by downstream | |||
servers so the TTL on the response must be set to an appropriate | servers so the TTL on the response must be set to an appropriate | |||
value so as to preserve the fresheness of the redirection. | value so as to preserve the fresheness of the redirection. | |||
In CNAME-based DNS redirection, the authoritative server returns a | In CNAME-based DNS redirection, the authoritative server returns a | |||
CNAME response to the DNS request, telling the LDNS server to restart | CNAME response to the DNS request, telling the LDNS server to restart | |||
the name lookup using a new name. A CNAME is essentially a symbolic | the name lookup using a new name. A CNAME is essentially a symbolic | |||
link in the DNS namespace, and like a symbolic link, redirection is | link in the DNS namespace, and like a symbolic link, redirection is | |||
transparent to the client-\u002Dthe LDNS server gets the CNAME | transparent to the client; the LDNS server gets the CNAME response | |||
response and re-executes the lookup. Only when the name has been | and re-executes the lookup. Only when the name has been resolved to | |||
resolved to an IP address does it return the result to the user. | an IP address does it return the result to the user. Note that DNAME | |||
Note that DNAME would be preferable to CNAME if it becomes widely | would be preferable to CNAME if it becomes widely supported. | |||
supported. | ||||
2.1.2. HTTP Redirection | 2.1.2. HTTP Redirection | |||
HTTP redirection makes use of the redirection response of the HTTP | HTTP redirection makes use of the redirection response of the HTTP | |||
protocol (e.g.,"302" or "307"). This response contains a new URL | protocol (e.g.,"302" or "307"). This response contains a new URL | |||
that the application should fetch instead of the original URL. By | that the application should fetch instead of the original URL. By | |||
changing the URL appropriately, the server can cause the user to | changing the URL appropriately, the server can cause the user to | |||
redirect to a different server. The advantages of HTTP redirection | redirect to a different server. The advantages of HTTP redirection | |||
are that (1) the server can change the URL fetched by the client to | are that (1) the server can change the URL fetched by the client to | |||
include, for example, both the DNS name of the particular server to | include, for example, both the DNS name of the particular server to | |||
skipping to change at page 15, line 29 | skipping to change at page 15, line 29 | |||
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.com. 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 | specifically one provided by Operator B, and so it returns a 302 | |||
it returns a 302 redirect message for a new URL constructed by | redirect message for a new URL constructed by "stacking" | |||
"stacking" Operator B's distinguished CDN-Domain | Operator B's distinguished CDN-Domain (peer-a.op-b.net) on the | |||
(peer-a.op-b.net) on the front of the original URL. (Note that | front of the original URL. (Note that more complex URL | |||
more complex URL manipulations are possible, such as replacing | manipulations are possible, such as replacing the initial CDN- | |||
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.net). B's DNS resolver returns the IP | |||
address of a request router for Operator B. Note that if request | address of a request router for Operator B. Note that if request | |||
routing within dCDN was performed using DNS instead of HTTP | routing within dCDN was performed using DNS instead of HTTP | |||
redirection, B's DNS resolver would also behave as the request | redirection, B's DNS resolver would also behave as the request | |||
router and directly return the IP address of a delivery node. | 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 by 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.net). B's DNS resolver returns the | |||
IP address of the delivery node. | 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 | |||
skipping to change at page 16, line 35 | skipping to change at page 16, line 35 | |||
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.net). (Note that without this specially defined | |||
inter-CDN acquisition domain, operator A would be at risk of | inter-CDN acquisition domain, operator A would be at risk of | |||
redirecting the request back to operator B, resulting in an | redirecting the request back to operator B, resulting in an | |||
infinite loop). 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 | 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 by a subdomain of the | URL constructed by replacing the hostname with a subdomain of | |||
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. | |||
Although not shown, Operator A processes the rest of the URL: it | Although not shown, Operator A processes the rest of the URL: it | |||
extracts information identifying the origin server, validates | extracts information identifying the origin server, validates | |||
that this server has been registered, and determines the content | that this server has been registered, and determines the content | |||
provider that owns the origin server. It may also perform its | provider that owns the origin server. It may also perform its | |||
skipping to change at page 21, line 15 | skipping to change at page 21, line 15 | |||
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.net). (Note that without this specially defined | |||
inter-CDN acquisition domain, operator A would be at risk of | inter-CDN acquisition domain, operator A would be at risk of | |||
redirecting the request back to operator B, resulting in an | redirecting the request back to operator B, resulting in an | |||
infinite loop). 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 by 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 | |||
specially defined internal domain, Operator A would be at risk of | specially defined internal domain, Operator A would be at risk of | |||
redirecting the request back to Operator B, resulting in an | redirecting the request back to Operator B, resulting in an | |||
infinite loop.) | infinite loop.) | |||
skipping to change at page 26, line 34 | skipping to change at page 26, line 34 | |||
footprint discovery). | footprint discovery). | |||
3.6. Content Removal Example | 3.6. Content Removal Example | |||
The following example illustrates how the CDNI Control interface may | The following example illustrates how the CDNI Control interface may | |||
be used to achieve pre-positioning of an item of content in the dCDN. | be used to achieve pre-positioning of an item of content in the dCDN. | |||
In this example, user requests for a particular content, and | In this example, user requests for a particular content, and | |||
corresponding redirection of such requests from Operator A to | corresponding redirection of such requests from Operator A to | |||
Operator B CDN, may (or may not) have taken place earlier. Then, at | Operator B CDN, may (or may not) have taken place earlier. Then, at | |||
some point in time, the uCDN (for example, in response to a | some point in time, the uCDN (for example, in response to a | |||
corresponding trigger from the Content Provider) uses the CI to | corresponding Trigger from the Content Provider) uses the CI to | |||
request that content identified by a particular URL be removed from | request that content identified by a particular URL be removed from | |||
dCDN. The following diagram illustrates the operation. | 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.com/... | | |||
| |<------------------------| | | |<------------------------| | |||
| | | | | | | | |||
| |CI OK | | | |CI OK | | |||
| |------------------------>| | | |------------------------>| | |||
| | | | | | | | |||
skipping to change at page 28, line 40 | skipping to change at page 28, line 40 | |||
positioning; however, such intra-CDN dynamic acquisition would not | positioning; however, such intra-CDN dynamic acquisition would not | |||
involve the uCDN. | involve the uCDN. | |||
3.8. Asynchronous CDNI Metadata Example | 3.8. Asynchronous CDNI Metadata Example | |||
In this section we walk through a simple example illustrating a | In this section we walk through a simple example illustrating a | |||
scenario of asynchronously exchanging CDNI metadata, where the | scenario of asynchronously exchanging CDNI metadata, where the | |||
downstream CDN obtains CDNI metadata for content ahead of a | downstream CDN obtains CDNI metadata for content ahead of a | |||
corresponding content request. The example that follows assumes that | corresponding content request. The example that follows assumes that | |||
HTTP-based inter-CDN redirection and recursive CDNI request-routing | HTTP-based inter-CDN redirection and recursive CDNI request-routing | |||
are used, as in Section 3.3. However, asynchronous exchange of CDNI | are used, as in Section 3.3. However, Asynchronous exchange of CDNI | |||
Metadata is similarly applicable to DNS-based inter-CDN redirection | Metadata is similarly applicable to DNS-based inter-CDN redirection | |||
and iterative request routing (in which cases the CDNI metadata may | and iterative request routing (in which cases the CDNI metadata may | |||
be used at slightly different processing stages of the message | be used at slightly different processing stages of the message | |||
flows). | flows). | |||
End-User Operator B Operator A | End-User Operator B Operator A | |||
| | | | | | | | |||
| |CI pre-position (trigger)| | | |CI pre-position (Trigger)| | |||
| |<------------------------|(1) | | |<------------------------|(1) | |||
| | | | | | | | |||
| |CI OK | | | |CI OK | | |||
| |------------------------>|(2) | | |------------------------>|(2) | |||
| | | | | | | | |||
| |MI pull REQ | | | |MI pull REQ | | |||
| |------------------------>|(3) | | |------------------------>|(3) | |||
| | | | | | | | |||
| |MI metadata REP |(4) | | |MI metadata REP |(4) | |||
| | | | | | | | |||
skipping to change at page 29, line 35 | skipping to change at page 29, line 35 | |||
|------------------------>|(9) | | |------------------------>|(9) | | |||
| | | | | | | | |||
: : : | : : : | |||
| CONTENT DATA | | | | CONTENT DATA | | | |||
|<------------------------| |(10) | |<------------------------| |(10) | |||
Figure 9: Message Flow for Asynchronous CDNI Metadata | Figure 9: Message Flow for Asynchronous CDNI Metadata | |||
The steps illustrated in the figure are as follows: | The steps illustrated in the figure are as follows: | |||
1. Operator A uses the CI to trigger to signal the availability of | 1. Operator A uses the CI to Trigger to signal the availability of | |||
CDNI metadata to Operator B. | CDNI metadata to Operator B. | |||
2. Operator B acknowledges the receipt of this trigger. | 2. Operator B acknowledges the receipt of this Trigger. | |||
3. Operator B requests the latest metadata from Operator A using | 3. Operator B requests the latest metadata from Operator A using | |||
the MI. | the MI. | |||
4. Operator A replies with the requested metadata. This document | 4. Operator A replies with the requested metadata. This document | |||
does not constrain how the CDNI metadata information is actually | does not constrain how the CDNI metadata information is actually | |||
represented. For the purposes of this example, we assume that | represented. For the purposes of this example, we assume that | |||
Operator A provides CDNI metadata to Operator B indicating that: | Operator A provides CDNI metadata to Operator B indicating that: | |||
* this CDNI Metadata is applicable to any content referenced by | * this CDNI Metadata is applicable to any content referenced by | |||
skipping to change at page 30, line 39 | skipping to change at page 30, line 39 | |||
before serving the content. (Details of this authorization are | before serving the content. (Details of this authorization are | |||
not shown.) | not shown.) | |||
10. Assuming successful per-request authorization, serving of | 10. Assuming successful per-request authorization, serving of | |||
Content Data (possibly preceded by inter-CDN acquisition) | Content Data (possibly preceded by inter-CDN acquisition) | |||
proceeds as in Section 3.3. | proceeds as in Section 3.3. | |||
3.9. Synchronous CDNI Metadata Acquisition Example | 3.9. Synchronous CDNI Metadata Acquisition Example | |||
In this section we walk through a simple example illustrating a | In this section we walk through a simple example illustrating a | |||
scenario of synchronous CDNI metadata acquisition, in which the | scenario of Synchronous CDNI metadata acquisition, in which the | |||
downstream CDN obtains CDNI metadata for content at the time of | downstream CDN obtains CDNI metadata for content at the time of | |||
handling a first request for the corresponding content. As in the | handling a first request for the corresponding content. As in the | |||
preceding section, this example assumes that HTTP-based inter-CDN | preceding section, this example assumes that HTTP-based inter-CDN | |||
redirection and recursive CDNI request-routing are used (as in | redirection and recursive CDNI request-routing are used (as in | |||
Section 3.3), but dynamic CDNI metadata acquisition is applicable to | Section 3.3), but dynamic CDNI metadata acquisition is applicable to | |||
other variations of request routing. | other variations of request routing. | |||
End-User Operator B Operator A | End-User Operator B Operator A | |||
| | | | | | | | |||
| CONTENT REQUEST | | | | CONTENT REQUEST | | | |||
skipping to change at page 31, line 39 | skipping to change at page 31, line 39 | |||
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 | |||
initiates synchronous acquisition of CDNI Metadata that are | initiates Synchronous acquisition of CDNI Metadata that are | |||
needed for routing of the end-user request. We assume the URI | needed for routing of the end-user request. We assume the URI | |||
for the a Metadata server is known ahead of time through some | for the a Metadata server is known ahead of time through some | |||
out-of-band means. | out-of-band means. | |||
4. On receipt of a CDNI Metadata Request, Operator A's CDN | 4. On receipt of a CDNI Metadata Request, Operator A's CDN | |||
responds, making the corresponding CDNI metadata information | responds, making the corresponding CDNI metadata information | |||
available to Operator B's CDN. This metadata is considered by | available to Operator B's CDN. This metadata is considered by | |||
operator B's CDN before responding to the Request Routing | operator B's CDN before responding to the Request Routing | |||
request. (In a simple case, the metadata could simply be an | request. (In a simple case, the metadata could simply be an | |||
allow or deny response for this particular request.) | allow or deny response for this particular request.) | |||
5. Response to the RI request as normal. | 5. Response to the RI request as normal. | |||
6. Redirection message is sent to the end user. | 6. Redirection message is sent to the end user. | |||
7. A delivery node of Operator B receives the end user request. | 7. A delivery node of Operator B receives the end user request. | |||
8. The delivery node triggers dynamic acquisition of additional | 8. The delivery node Triggers dynamic acquisition of additional | |||
CDNI metadata that are needed to process the end-user content | CDNI metadata that are needed to process the end-user content | |||
request. Note that there may exist cases where this step need | request. Note that there may exist cases where this step need | |||
not happen, for example because the metadata were already | not happen, for example because the metadata were already | |||
acquired previously. | acquired previously. | |||
9. Operator A's CDN responds to the CDNI Metadata Request and makes | 9. Operator A's CDN responds to the CDNI Metadata Request and makes | |||
the corresponding CDNI metadata available to Operator B. This | the corresponding CDNI metadata available to Operator B. This | |||
metadata influence how Operator B's CDN processes the end-user | metadata influence how Operator B's CDN processes the end-user | |||
request. | request. | |||
skipping to change at page 35, line 12 | skipping to change at page 35, line 12 | |||
URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at | URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at | |||
the beginning of a URI) or by a URI-Filter (i.e., a regular | the beginning of a URI) or by a URI-Filter (i.e., a regular | |||
expression that matches a subset of URIs contained in some CDN- | expression that matches a subset of URIs contained in some CDN- | |||
Doman). In other words, CDN-Domains and URI-Filters provide a | Doman). In other words, CDN-Domains and URI-Filters provide a | |||
uniform means to aggregate sets (and subsets) of URIs for the purpose | uniform means to aggregate sets (and subsets) of URIs for the purpose | |||
of defining the scope for some operation in one of the CDNI | of defining the scope for some operation in one of the CDNI | |||
interfaces. | interfaces. | |||
4.3. Request Routing Interfaces | 4.3. Request Routing Interfaces | |||
The Request Routing interface comprises two parts: the asynchronous | The Request Routing interface comprises two parts: the Asynchronous | |||
interface used by a dCDN to advertize footprint and capabilities | interface used by a dCDN to advertize footprint and capabilities | |||
(denoted FCI) to a uCDN, allowing the uCDN to decide whether to | (denoted FCI) to a uCDN, allowing the uCDN to decide whether to | |||
redirect particular user requests to that dCDN; and the synchronous | redirect particular user requests to that dCDN; and the Synchronous | |||
interface used by the uCDN to redirect a user request to the dCDN | interface used by the uCDN to redirect a user request to the dCDN | |||
(denoted RI). (These are somewhat analogous to the operations of | (denoted RI). (These are somewhat analogous to the operations of | |||
routing and forwarding in IP.) | routing and forwarding in IP.) | |||
As illustrated in Section 3, the RI part of request routing may be | As illustrated in Section 3, the RI part of request routing may be | |||
implemented in part by DNS and HTTP. Naming conventions may be | implemented in part by DNS and HTTP. Naming conventions may be | |||
established by which CDN peers communicate whether a request should | established by which CDN peers communicate whether a request should | |||
be routed or content served. | be routed or content served. | |||
We also note that RI plays a key role in enabling recursive | We also note that RI plays a key role in enabling recursive | |||
skipping to change at page 38, line 19 | skipping to change at page 38, line 19 | |||
4.5. CDNI Control Interface | 4.5. CDNI Control Interface | |||
The CDNI Control interface is initially used to bootstrap the other | The CDNI Control interface is initially used to bootstrap the other | |||
interfaces. As a simple example, it could be used to provide the | interfaces. As a simple example, it could be used to provide the | |||
address of the logging server in dCDN to uCDN in order to bootstrap | address of the logging server in 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.murray-cdni-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. For example, see [I-D.ietf-cdni-metadata]. Such | |||
metadata includes geo-blocking restrictions, availability windows, | metadata includes geo-blocking restrictions, availability windows, | |||
access control policies, and so on. It may also include information | access control policies, and so on. It may also include information | |||
to facilitate acquisition of content by dCDN (e.g., alternate sources | to facilitate acquisition of content by dCDN (e.g., alternate sources | |||
skipping to change at page 39, line 36 | skipping to change at page 39, line 36 | |||
over the various inter-CDN acquisition protocols (e.g., HTTP) | over the various inter-CDN acquisition protocols (e.g., HTTP) | |||
requires further investigation and may require small extensions or | requires further investigation and may require small extensions or | |||
semantic changes to the acquisition protocol. | semantic changes to the acquisition protocol. | |||
4.7. HTTP Adaptive Streaming Concerns | 4.7. HTTP Adaptive Streaming Concerns | |||
We consider HTTP Adaptive Streaming (HAS) and the impact it has on | We consider HTTP Adaptive Streaming (HAS) and the impact it has on | |||
the CDNI interfaces because large objects (e.g., videos) are broken | the CDNI interfaces because large objects (e.g., videos) are broken | |||
into a sequence of small, independent chunks. For each of the | into a sequence of small, independent chunks. For each of the | |||
following, a more thorough discussion, including an overview of the | following, a more thorough discussion, including an overview of the | |||
tradeoffs involved in alternative designs, can be found in | tradeoffs involved in alternative designs, can be found in RFC 6983. | |||
[I-D.brandenburg-cdni-has]. | ||||
First, with respect to Content Acquisition and File Management, which | First, with respect to Content Acquisition and File Management, which | |||
are out-of-scope for the CDNI interfaces but nontheless relevant to | are out-of-scope for the CDNI interfaces but nontheless relevant to | |||
the overall operation, we assume no additional measures are required | the overall operation, we assume no additional measures are required | |||
to deal with large numbers of chunks. This means that the dCDN is | to deal with large numbers of chunks. This means that the dCDN is | |||
not explicitly made aware of any relationship between different | not explicitly made aware of any relationship between different | |||
chunks and the dCDN handles each chunk as if it were an individual | chunks and the dCDN handles each chunk as if it were an individual | |||
and independent content item. The result is that content acquisition | and independent content item. The result is that content acquisition | |||
between uCDN and dCDN also happens on a per-chunk basis. This | between uCDN and dCDN also happens on a per-chunk basis. This | |||
approach is in line with the recommendations made in | approach is in line with the recommendations made in RFC 6983, which | |||
[I-D.brandenburg-cdni-has], which also identifies potential | also identifies potential improvements in this area that might be | |||
improvements in this area that might be considered in the future. | considered in the future. | |||
Second, with respect to Request Routing, we note that HAS manifest | Second, with respect to Request Routing, we note that HAS manifest | |||
files have the potential to interfere with request routing since | files have the potential to interfere with request routing since | |||
manifest files contain URLs pointing to the location of content | manifest files contain URLs pointing to the location of content | |||
chunks. To make sure that a manifest file does not hinder CDNI | chunks. To make sure that a manifest file does not hinder CDNI | |||
request routing and does not place excessive load on CDNI resources, | request routing and does not place excessive load on CDNI resources, | |||
the use of manifest files could either be limited to those containing | the use of manifest files could either be limited to those containing | |||
relative URLs or the uCDN could modify the URLs in the manifest. Our | relative URLs or the uCDN could modify the URLs in the manifest. Our | |||
approach for dealing with these issues is twofold. As a mandatory | approach for dealing with these issues is twofold. As a mandatory | |||
requirement, CDNs should be able to handle unmodified manifest files | requirement, CDNs should be able to handle unmodified manifest files | |||
skipping to change at page 40, line 33 | skipping to change at page 40, line 32 | |||
information, and the desire to correlate logging information for | information, and the desire to correlate logging information for | |||
chunk requests that correspond to the same HAS session. For the | chunk requests that correspond to the same HAS session. For the | |||
initial CDNI specification, our approach is to expect participating | initial CDNI specification, our approach is to expect participating | |||
CDNs to support per-chunk logging (e.g. logging each chunk request as | CDNs to support per-chunk logging (e.g. logging each chunk request as | |||
if it were an independent content request) over the CDNI Logging | if it were an independent content request) over the CDNI Logging | |||
interface. Optionally, the LI may include a Content Collection | interface. Optionally, the LI may include a Content Collection | |||
IDentifier (CCID) and/or a Session IDentifier (SID) as part of the | IDentifier (CCID) and/or a Session IDentifier (SID) as part of the | |||
logging fields, thereby facilitating correlation of per-chunk logs | logging fields, thereby facilitating correlation of per-chunk logs | |||
into per-session logs for applications benefiting from such session | into per-session logs for applications benefiting from such session | |||
level information (e.g. session-based analytics). This approach is | level information (e.g. session-based analytics). This approach is | |||
in line with the recommendations made in [I-D.brandenburg-cdni-has], | in line with the recommendations made in RFC 6983, which also | |||
which also identifies potential improvements in this area that might | identifies potential improvements in this area that might be | |||
be considered in the future. | considered in the future. | |||
Fourth, with respect to the CDNI Control interface, and in particular | Fourth, with respect to the CDNI Control interface, and in particular | |||
purging HAS chunks from a given CDN, our approach is to expect each | purging HAS chunks from a given CDN, our approach is to expect each | |||
CDN supports per-chunk content purge (e.g. purging of chunks as if | CDN supports per-chunk content purge (e.g. purging of chunks as if | |||
they were individual content items). Optionally, a CDN may support | they were individual content items). Optionally, a CDN may support | |||
content purge on the basis of a "Purge IDentifier (Purge-ID)" | content purge on the basis of a "Purge IDentifier (Purge-ID)" | |||
allowing the removal of all chunks related to a given Content | allowing the removal of all chunks related to a given Content | |||
Collection with a single reference. It is possible that this Purge- | Collection with a single reference. It is possible that this Purge- | |||
ID could be merged with the CCID discussed above for HAS Logging, or | ID could be merged with the CCID discussed above for HAS Logging, or | |||
alternatively, they may remain distinct. | alternatively, they may remain distinct. | |||
skipping to change at page 50, line 27 | skipping to change at page 50, line 12 | |||
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 RFC 6707 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 Brandenburg | o Ray van Brandenburg | |||
o Matt Caulfield | o Matt Caulfield | |||
o Francois le Faucheur | o Francois le Faucheur | |||
o Aaron Falk | o Aaron Falk | |||
o David Ferguson | o David Ferguson | |||
o John Hartman | o John Hartman | |||
skipping to change at page 51, line 12 | skipping to change at page 50, line 39 | |||
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] | [I-D.bertrand-cdni-logging] | |||
Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F., | Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F., | |||
and P. Grochocki, "CDNI Logging Interface", draft- | and P. Grochocki, "CDNI Logging Interface", draft- | |||
bertrand-cdni-logging-02 (work in progress), October 2012. | bertrand-cdni-logging-02 (work in progress), October 2012. | |||
[I-D.brandenburg-cdni-has] | ||||
Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung, | ||||
"Models for adaptive-streaming-aware CDN Interconnection", | ||||
draft-brandenburg-cdni-has-05 (work in progress), April | ||||
2013. | ||||
[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-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-02 (work in progress), July 2013. | ietf-cdni-metadata-02 (work in progress), July 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-09 (work in progress), July 2013. | requirements-10 (work in progress), September 2013. | |||
[I-D.ietf-cdni-use-cases] | ||||
Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, | ||||
K., and G. Watson, "Use Cases for Content Delivery Network | ||||
Interconnection", draft-ietf-cdni-use-cases-10 (work in | ||||
progress), August 2012. | ||||
[I-D.lefaucheur-cdni-logging-delivery] | [I-D.lefaucheur-cdni-logging-delivery] | |||
Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI | Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI | |||
Logging Formats for HTTP and HTTP Adaptive Streaming | Logging Formats for HTTP and HTTP Adaptive Streaming | |||
Deliveries", draft-lefaucheur-cdni-logging-delivery-01 | Deliveries", draft-lefaucheur-cdni-logging-delivery-01 | |||
(work in progress), July 2012. | (work in progress), July 2012. | |||
[I-D.murray-cdni-triggers] | [I-D.murray-cdni-triggers] | |||
Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / | Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / | |||
Triggers", draft-murray-cdni-triggers-03 (work in | Triggers", draft-murray-cdni-triggers-03 (work in | |||
skipping to change at page 52, line 28 | skipping to change at page 51, line 46 | |||
2003. | 2003. | |||
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic | [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic | |||
Optimization (ALTO) Problem Statement", RFC 5693, October | Optimization (ALTO) Problem Statement", RFC 5693, October | |||
2009. | 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, | ||||
K., and G. Watson, "Use Cases for Content Delivery Network | ||||
Interconnection", RFC 6770, November 2012. | ||||
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., | ||||
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware | ||||
Content Distribution Network Interconnection (CDNI)", RFC | ||||
6983, July 2013. | ||||
Authors' Addresses | Authors' Addresses | |||
Larry Peterson (editor) | Larry Peterson (editor) | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
8 Cambridge Center | 8 Cambridge Center | |||
Cambridge, MA 02142 | Cambridge, MA 02142 | |||
USA | USA | |||
Email: lapeters@akamai.com | Email: lapeters@akamai.com | |||
End of changes. 50 change blocks. | ||||
118 lines changed or deleted | 112 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/ |