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/