draft-ietf-cdni-framework-01.txt   draft-ietf-cdni-framework-02.txt 
Network Working Group L. Peterson, Ed. Network Working Group L. Peterson, Ed.
Internet-Draft Verivue, Inc. Internet-Draft Akamai Technologies, Inc.
Obsoletes: 3466 (if approved) B. Davie Obsoletes: 3466 (if approved) B. Davie
Intended status: Informational Nicira Networks, Inc. Intended status: Informational VMware, Inc.
Expires: January 17, 2013 July 16, 2012 Expires: June 20, 2013 December 17, 2012
Framework for CDN Interconnection Framework for CDN Interconnection
draft-ietf-cdni-framework-01 draft-ietf-cdni-framework-02
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 several
interfaces and mechanisms to address issues such as request routing, interfaces and mechanisms to address issues such as request routing,
metadata exchange, and the acquisition of content by one CDN from distribution metadata exchange, and logging information exchange
another. 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.
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 January 17, 2013. This Internet-Draft will expire on June 20, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 3, line 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 5 1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 5
1.3. Structure Of This Document . . . . . . . . . . . . . . . . 8 1.3. Structure Of This Document . . . . . . . . . . . . . . . . 9
2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 9 2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 9
2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 9 2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 9
2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . 10 2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . 10
3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . . 10 3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . . 11
3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 13
3.2. HTTP Redirect Example . . . . . . . . . . . . . . . . . . 14 3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 14
3.2.1. Comments on the example . . . . . . . . . . . . . . . 18 3.3. Recursive HTTP Redirection Example . . . . . . . . . . . . 19
3.3. Recursive Redirection Example . . . . . . . . . . . . . . 19 3.4. Iterative DNS-based Redirection Example . . . . . . . . . 23
3.3.1. Comments on the example . . . . . . . . . . . . . . . 23 3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 27
3.4. DNS-based redirection example . . . . . . . . . . . . . . 23 3.6. Content Removal Example . . . . . . . . . . . . . . . . . 29
3.4.1. Comments on the example . . . . . . . . . . . . . . . 26
3.5. Dynamic Footprint Discovery . . . . . . . . . . . . . . . 27
3.6. Content Removal . . . . . . . . . . . . . . . . . . . . . 29
3.7. Pre-Positioned Content Acquisition Example . . . . . . . . 29 3.7. Pre-Positioned Content Acquisition Example . . . . . . . . 29
3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . . 31 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . . 31
3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 33 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 33
3.10. Content Acquisition with Multiple Upstream CDNs . . . . . 36 3.10. Content and Metadata Acquisition with Multiple
4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 37 Upstream CDNs . . . . . . . . . . . . . . . . . . . . . . 35
4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 36
4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 37 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 37
4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . . 38 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . . 37
4.3. Request Routing Interface . . . . . . . . . . . . . . . . 38 4.3. Request Routing Interface . . . . . . . . . . . . . . . . 38
4.4. Logging Interface . . . . . . . . . . . . . . . . . . . . 40 4.4. Logging Interface . . . . . . . . . . . . . . . . . . . . 39
4.5. Control Interface . . . . . . . . . . . . . . . . . . . . 42 4.5. Control Interface . . . . . . . . . . . . . . . . . . . . 41
4.6. Metadata Interface . . . . . . . . . . . . . . . . . . . . 42 4.6. Metadata Interface . . . . . . . . . . . . . . . . . . . . 41
4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . . 42
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 43 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 43
5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 44 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 44
5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 44 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 45
5.3. CSP using CDNI Request Routing Interface . . . . . . . . . 45 5.3. CSP using CDNI Request Routing Interface . . . . . . . . . 46
5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 46 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 47
6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 49 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 50
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 8. Security Considerations . . . . . . . . . . . . . . . . . . . 51
8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 51 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 52
8.2. Digital Rights Management . . . . . . . . . . . . . . . . 52 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 53
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
11. Informative References . . . . . . . . . . . . . . . . . . . . 52 11. Informative References . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
The interconnection of Content Distribution Networks (CDNs) is The interconnection of Content Distribution Networks (CDNs) is
motivated by several use cases, such as those described in motivated by several use cases, such as those described in
[I-D.ietf-cdni-use-cases]. The overall problem space for CDN [I-D.ietf-cdni-use-cases]. The overall problem space for CDN
Interconnection is described in [I-D.ietf-cdni-problem-statement]. Interconnection is described in RFC 6707. The purpose of this
The purpose of this document is to provide an overview of the various document is to provide an overview of the various components
components necessary to interconnect CDNs. CDN Interconnection necessary to interconnect CDNs. CDN Interconnection requires the
requires the specification of several interfaces and mechanisms to specification of several interfaces and mechanisms to address issues
address issues such as request routing, metadata exchange, and the such as request routing, metadata exchange, and the acquisition of
acquisition of content by one CDN from another. The intent of this content by one CDN from another. The intent of this document is to
document is to describe how these interfaces and mechanisms fit describe how these interfaces and mechanisms fit together, leaving
together, leaving their detailed specification to other documents. their detailed specification to other documents. We make extensive
We make extensive use of message flow examples to illustrate the use of message flow examples to illustrate the operation of
operation of interconnected CDNs, but these examples should be interconnected CDNs, but these examples should be considered
considered illustrative rather than prescriptive. 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 This document draws freely on the core terminology defined in RFC
[I-D.ietf-cdni-problem-statement]. It also introduce the following 6707. It also introduce the following terms:
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 routing: 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 interface (or use information cached from earlier similar Routing Redirection Interface (or use information cached from earlier
queries) to find out how the Downstream CDN wants the request to be similar queries) to find out how the Downstream CDN wants the request
redirected, which allows the Upstream CDN to factor in the Downstream to be redirected, which allows the Upstream CDN to factor in the
CDN response when redirecting the user agent. This approach is Downstream CDN response when redirecting the user agent. This
referred to as "recursive" CDNI request routing. Note that the approach is referred to as "Recursive" CDNI Request Redirection.
Downstream CDN may elect to have the request redirected directly to a Note that the Downstream CDN may elect to have the request redirected
Surrogate inside the Downstream CDN, to the Request-Routing System of directly to a Surrogate inside the Downstream CDN, to the Request-
the Downstream CDN, to another CDN, or to any other system that the Routing System of the Downstream CDN, to another CDN, or to any other
Downstream CDN sees as fit for handling the redirected request. system that the Downstream CDN sees as fit for handling the
redirected request.
Iterative CDNI Request Routing: 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 routing. 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 sub-set of the Control Interface that includes Trigger Interface: a sub-set of the Control Interface that includes
operations to pre-position, revalidate, and purge both metadata and operations to pre-position, revalidate, and purge both metadata and
content. These operations are typically called in response to some content. These operations are typically called in response to some
action (trigger) by the CSP on the upstream CDN. action (trigger) by the CSP on the upstream CDN.
1.2. Reference Model 1.2. Reference Model
This document uses the reference model in Figure 1 as originally This document uses the reference model in Figure 1 as originally
created in [I-D.ietf-cdni-problem-statement]. created in RFC 6707.
-------- --------
/ \ / \
| CSP | | CSP |
\ / \ /
-------- --------
* *
* *
* /\ * /\
* / \ * / \
skipping to change at page 7, line 13 skipping to change at page 7, line 13
Figure 1: CDNI Model and CDNI Interfaces Figure 1: CDNI 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 uCDN serving a
given CSP, it is entirely possible that multiple uCDNs can serve a given CSP, it is entirely possible that multiple uCDNs can serve a
single CSP. In fact, this situation effectively exists today in the single CSP. In fact, this situation effectively exists today in the
sense that a single CSP can currently connect to more than one CDN. sense that a single CSP can currently delegate its content delivery
to more than one CDN.
Definitions of the four CDNI interfaces follow. More discussion of The following briefly describes the four CDNI interfaces,
these interfaces appears in Section 4. paraphrasing the definitions given in RFC 6707. We discuss these
interfaces in more detail in Section 4.
o Control Interface: Operations to discover, initialize, 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 sub-set of operations is sometimes collectively called The latter sub-set of operations is sometimes collectively called
the "trigger interface." the "trigger interface."
o Request Routing Interface: Operations to determine what CDN (and o CDNI Request Routing Interface: Operations to determine what CDN
optionally what surrogate within a CDN) is to serve end-user's (and optionally what surrogate within a CDN) is to serve end-
requests. May include a combination of: user's requests. Is actually a logical bundling of two separate
but related interfaces:
* Asynchronous operations to exchange routing information (e.g., * Footprint & Capability Interface (FCI): Asynchronous operations
the network footprint served by a given CDN) that enables CDN to exchange routing information (e.g., the network footprint
and capabilities served by a given CDN) that enables CDN
selection for subsequent user requests; and selection for subsequent user requests; and
* Synchronous operations to select a delivery CDN (surrogate) for * Request Routing Redirection (RI): Synchronous operations to
a given user request. select a delivery CDN (surrogate) for a given user request.
o Metadata Interface: Operations to communicate metadata that o CDNI Metadata Interface (MI): Operations to communicate metadata
governs the how content is delivered by interconnected CDNs. that governs the how 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. 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 Logging Interface: Operations that allow interconnected CDNs to o CDNI Logging Interface (LI): Operations that allow interconnected
exchange relevant activity logs. May include a combination of: CDNs to exchange relevant activity logs. May include a
combination of:
* Real-time exchanges, suitable for runtime traffic monitoring; * Real-time exchanges, suitable for runtime traffic monitoring;
and and
* Off-line exchanges, suitable for analytics and billing. * Off-line exchanges, suitable for analytics and billing.
There is some ambiguity as to the line between the set of trigger- There is some potential overlap between the set of trigger-based
based operations in the Control interface and the Metadata interface. operations in the Control Interface and the Metadata Interface. For
For both cases, the information passed from the upstream CDN to the both cases, the information passed from the upstream CDN to the
downstream CDN can broadly be viewed as metadata that describes how downstream CDN can broadly be viewed as metadata that describes how
content is to be managed by the downstream CDN. For example, the content is to be managed by the downstream CDN. For example, the
information conveyed by Control operations to pre-position, information conveyed by Control operations to pre-position,
revalidate or purge metadata is similar to the information conveyed revalidate or purge metadata is similar to the information conveyed
by posting updated metadata via the Metadata interface? Even the by posting updated metadata via the Metadata Interface. Even the
Control operation to purge content could be viewed as an metadata Control operation to purge content could be viewed as an metadata
update for that content: purge simply says that the availability update for that content: purge simply says that the availability
window for the named content ends now. The two interfaces share much window for the named content ends now. The two interfaces share much
in common, so minimally, there will need to be a consistent data in common, so minimally, there will need to be a consistent data
model that spans both. model that spans both.
The distinction we draw has to do with what the caller knows the The distinction we draw has to do with what the caller knows about
metadata being applied to content delivery by the callee. In the the successful application of the metadata by the callee. In the
case of the Control interface, the downstream CDN returning a case of the Control Interface, the downstream CDN returning a
successful status message guarantees that the operation has been successful status message guarantees that the operation has been
successfully completed; e.g., the content has been purged or pre- successfully completed; e.g., the content has been purged or pre-
positioned. This implies that the downstream CDN accepts positioned. This implies that the downstream CDN accepts
responsibility for having successfully completed the requested responsibility for having successfully completed the requested
operation. In contrast, metadata passed between CDNs via the operation. In contrast, metadata passed between CDNs via the
Metadata interface carries no such completion guarantee. Returning Metadata Interface carries no such completion guarantee. Returning
success implies successful receipt of the metadata, but nothing can success implies successful receipt of the metadata, but nothing can
be inferred about precisely when the metadata will take effect in the be inferred about precisely when the metadata will take effect in the
downstream CDN, only that it will take effect eventually. This is downstream CDN, only that it will take effect eventually. This is
because of the challenge in globally synchronizing updates to because of the challenge in globally synchronizing updates to
metadata with end-user requests that are currently in progress (or metadata with end-user requests that are currently in progress (or
indistinguishable from currently being in progress). Clearly, a CDN indistinguishable from currently being in progress). Clearly, a CDN
will not be viewed as a trusted peer if "eventually" often becomes an will not be viewed as a trusted peer if "eventually" often becomes an
indefinite period of time, but the acceptance of responsibility indefinite period of time, but the acceptance of responsibility
cannot be as crisp for the Metadata interface. cannot be as crisply defined for the Metadata Interface.
Finally, there is a practical issue that impacts all of the CNDI
interfaces, and that is whether or not to optimize CDNI for HTTP
Adaptive Streaming (HAS). We highlight specific issues related to
delivering HAS content throughout this document, but for a more
thorough treatment of the topic, see [I-D.brandenburg-cdni-has].
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
skipping to change at page 9, line 22 skipping to change at page 9, line 36
2.1. Request Redirection 2.1. Request Redirection
At its core, CDN Interconnection requires the redirection of requests At its core, CDN Interconnection requires the redirection of requests
from one CDN to another. For any given request that is received by from one CDN to another. For any given request that is received by
an upstream CDN, it will either respond to the request directly, or an upstream CDN, it will either respond to the request directly, or
somehow redirect the request to a downstream CDN. Two main somehow redirect the request to a downstream CDN. Two main
mechanisms are available for redirecting a request to a downstream mechanisms are available for redirecting a request to a downstream
CDN. The first leverages the DNS name resolution process and the CDN. The first leverages the DNS name resolution process and the
second uses in-protocol redirection mechanisms such as the HTTP 302 second uses in-protocol redirection mechanisms such as the HTTP 302
redirection response. We discuss these below as background before or 307 redirection response. We discuss these below as background
discussing some examples of their use in Section 3. before discussing some examples of their use in Section 3.
2.1.1. DNS Redirection 2.1.1. DNS Redirection
DNS redirection is based on returning different IP addresses for the DNS redirection is based on returning different IP addresses for the
same DNS name, for example, to balance server load or to account for same DNS name, for example, to balance server load or to account for
the client's location in the network. A DNS server, sometimes called the client's location in the network. A DNS server, sometimes called
the Local DNS (LDNS), resolves DNS names on behalf of an end-user. the Local DNS (LDNS), resolves DNS names on behalf of an end-user.
The LDNS server in turn queries other DNS servers until it reaches The LDNS server in turn queries other DNS servers until it reaches
the authoritative DNS server for the CDN-domain. The network the authoritative DNS server for the CDN-Domain. The network
operator typically provides the LDNS server, although the user is operator typically provides the LDNS server, although the user is
free to choose other DNS servers (e.g., OpenDNS, Google Public DNS). free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).
The advantage of DNS redirection is that it is completely transparent The advantage of DNS redirection is that it is completely transparent
to the end user--the user sends a DNS name to the LDNS server and to the end user--the user sends a DNS name to the LDNS server and
gets back an IP address. On the other hand, DNS redirection is gets back an IP address. On the other hand, DNS redirection is
problematic because the DNS request comes from the LDNS server, not problematic because the DNS request comes from the LDNS server, not
the end-user. This may affect the accuracy of server selection that the end-user. This may affect the accuracy of server selection that
is based on the user's location. The transparency of DNS redirection is based on the user's location. The transparency of DNS redirection
is also a problem in that there is no opportunity to modify the path is also a problem in that there is no opportunity to take the
component of the URL being accessed by the client. We consider two attributes of the user agent or the URI path component into account.
main forms of DNS redirection: simple and CNAME-based. We consider two main forms of DNS redirection: simple and CNAME-
based.
In simple DNS redirection, the authoritative DNS server for the name In simple DNS redirection, the authoritative DNS server for the name
simply returns an IP address from a set of possible IP addresses. simply returns an IP address from a set of possible IP addresses.
The answer is chosen from the set based on characteristics of the set The answer is chosen from the set based on characteristics of the set
(e.g., the relative loads on the servers) or characteristics of the (e.g., the relative loads on the servers) or characteristics of the
client (e.g., the location of the client relative to the servers). client (e.g., the location of the client relative to the servers).
Simple redirection is straightforward. The only caveats are (1) Simple redirection is straightforward. The only caveats are (1)
there is a limit to the number of delivery nodes a single DNS server there is a limit to the number alternate IP addresses a single DNS
can manage; and (2) DNS responses are cached by downstream servers so server can manage; and (2) DNS responses are cached by downstream
the TTL on the response must be set to an appropriate value so as to servers so the TTL on the response must be set to an appropriate
preserve the timeliness 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--the LDNS server gets the CNAME response transparent to the client--the LDNS server gets the CNAME response
and re-executes the lookup. Only when the name has been resolved to and re-executes the lookup. Only when the name has been resolved to
an IP address does it return the result to the user. Note that DNAME an IP address does it return the result to the user. Note that DNAME
would be preferable to CNAME if it becomes widely supported. would be preferable to CNAME if it becomes widely supported.
2.1.2. HTTP Redirection 2.1.2. HTTP Redirection
HTTP redirection makes use of the "302" redirection response of the HTTP redirection makes use of the redirection response of the HTTP
HTTP protocol. This response contains a new URL that the application protocol (e.g.,"302" or "307"). This response contains a new URL
should fetch instead of the original URL. By changing the URL that the application should fetch instead of the original URL. By
appropriately, the server can cause the user to redirect to a changing the URL appropriately, the server can cause the user to
different server. The advantages of 302 redirection are that (1) the redirect to a different server. The advantages of HTTP redirection
server can change the URL fetched by the client to include, for are that (1) the server can change the URL fetched by the client to
example, both the DNS name of the particular server to use, as well include, for example, both the DNS name of the particular server to
as the original HTTP server that was being accessed; and (2) the use, as well as the original HTTP server that was being accessed; (2)
client sends the HTTP request to the server, so that its IP address the client sends the HTTP request to the server, so that its IP
is known and can be used in selecting the server. address is known and can be used in selecting the server; and (3)
other attributes (e.g., content type, user-agent type) are visible to
the redirection mechanism.
The disadvantages of HTTP redirection are (1) it is visible to the The disadvantages of HTTP redirection are (1) it is visible to the
application, so it requires application support and may affect the application, so it requires application support and may affect the
application behavior (e.g., web browsers will not send cookies if the application behavior (e.g., web browsers will not send cookies if the
URL changes to a different domain); (2) HTTP is a heavy-weight URL changes to a different domain); (2) HTTP is a heavy-weight
protocol layered on TCP so it has relatively high overhead; and (3) protocol layered on TCP so it has relatively high overhead; and (3)
the results of HTTP redirection are not cached so that all the results of HTTP redirection are not cached so that all
redirections must go through to the server. redirections must go through to the server.
3. Overview of CDNI Operation 3. Overview of CDNI Operation
skipping to change at page 11, line 12 skipping to change at page 11, line 28
Before walking through some specific examples, we present a high- Before walking through some specific examples, we present a high-
level view of the operations that may take place. This high-level level view of the operations that may take place. This high-level
overview is illustrated in Figure 2. Note that most operations will overview is illustrated in Figure 2. Note that most operations will
involve only a subset of all the messages shown below, and that the involve only a subset of all the messages shown below, and that the
order and number of operations may vary considerably, as more order and number of operations may vary considerably, as more
detailed examples illustrate below. detailed examples illustrate below.
The following shows Operator A as the upstream CDN (uCDN) and The following shows Operator A as the upstream CDN (uCDN) and
Operator B as the downstream CDN (dCDN), where the former has a Operator B as the downstream CDN (dCDN), where the former has a
relationship with a content provider and the latter being the best relationship with a content provider and the latter being the CDN
CDN to deliver content to the end-user. The interconnection selected by Operator A to deliver content to the end-user. The
relationship may be symmetric between these two CDN operators, but interconnection relationship may be symmetric between these two CDN
for simplicity we show the interaction in one direction only. operators, but each direction can be considered as operating
independently of the other so for simplicity we show the interaction
in one direction only.
End-User Operator B Operator A End-User Operator B Operator A
| | | | | |
| | | | | |
| | [Async Metadata Push] | (1) | | [Async FCI Push] | (1)
| | | | | |
| | [Async RRI Push] | (2) | | [MI pre-positioning] | (2)
| | | | | |
| CONTENT REQUEST | | | CONTENT REQUEST | |
|-------------------------------------------------->| (3) |-------------------------------------------------->| (3)
| | | | | |
| | [Sync RRI Pull] | (4) | | [Sync RI Pull] | (4)
| | | | | |
| CONTENT REDIRECTION | | | [RI REPLY] | |
|<--------------------------------------------------| (5) |<--------------------------------------------------| (5)
| | | | | |
| | | | | |
| CONTENT REQUEST | | | CONTENT REQUEST | |
|------------------------>| | (6) |------------------------>| | (6)
| | | | | |
| | [Sync Metadata Pull] | (7) | | [Sync MI Pull] | (7)
| | | | | |
| | ACQUISITION REQUEST | | | ACQUISITION REQUEST |
| X------------------------>| (8) | X------------------------>| (8)
| X | | X |
| X CONTENT DATA | | X CONTENT DATA |
| X<------------------------| (9) | X<------------------------| (9)
| | | | | |
| CONTENT DATA | | | CONTENT DATA | |
|<------------------------| | (10) |<------------------------| | (10)
| | | | | |
: : : : : :
: [Other content requests ] : : [Other content requests] :
: : : : : :
| | [Content Purge] | (11) | | [CI: Content Purge] | (11)
: : : : : :
| | [Logging exchange] | (12) | | [LI: Log exchange] | (12)
| | | | | |
Figure 2: Overview of Operation Figure 2: Overview of Operation
The operations shown in the Figure are as follows: The operations shown in the Figure are as follows:
1. Prior to any content request, metadata may be asynchronously 1. dCDN uses the FCI to advertise information relevant to its
pushed from uCDN to dCDN so that it is available in readiness delivery footprint and capabilities prior to any content
for later content requests. requests being redirected.
2. dCDN may advertise information relevant to its delivery 2. Prior to any content request, the uCDN uses the MI to
capabilities (e.g. geographic footprint, reachable address pre=position CDNI metadata to the dCDN, thereby making that
prefixes) prior to any content requests being redirected. metadata available in readiness for later content requests.
3. A content request from a user agent arrives at uCDN. 3. A content request from a user agent arrives at uCDN.
4. uCDN may synchronously request information from dCDN regarding 4. uCDN may use the RI to synchronously request information from
its delivery capabilities to decide if dCDN is a suitable target dCDN regarding its delivery capabilities to decide if dCDN is a
for redirection of this request. suitable target for redirection of this request.
5. uCDN redirects the request to dCDN by sending some response 5. uCDN redirects the request to dCDN by sending some response
(DNS, HTTP) to the user agent. (DNS, HTTP) to the user agent.
6. The user agent requests the content from dCDN. 6. The user agent requests the content from dCDN.
7. dCDN may synchronously request metadata related to this content 7. dCDN may use the MI to synchronously request metadata related to
from uCDN, e.g. to decide whether to serve it. this content from uCDN, e.g. to decide whether to serve it.
8. If the content is not already in a suitable cache in dCDN, dCDN 8. If the content is not already in a suitable cache in dCDN, dCDN
may acquire it from uCDN. may acquire it from uCDN.
9. The content is delivered to dCDN from uCDN. 9. The content is delivered to dCDN from uCDN.
10. The content is delivered to the user agent by dCDN. 10. The content is delivered to the user agent by dCDN.
11. Some time later, perhaps at the request of the CSP (not shown) 11. Some time later, perhaps at the request of the CSP (not shown)
uCDN may instruct dCDN to purge the content to ensure it is not uCDN may use the CI to instruct dCDN to purge the content,
delivered again. thereby ensuring it is not delivered again.
12. After one or more content delivery actions by dCDN, a log of 12. After one or more content delivery actions by dCDN, a log of
delivery actions may be provided to uCDN. delivery actions may be provided to uCDN using the LI.
The following sections show some more specific examples of how these The following sections show some more specific examples of how these
operations may be combined to perform various delivery, control and operations may be combined to perform various delivery, control and
logging operations across a pair of CDNs. logging operations across a pair of CDNs.
3.1. Preliminaries 3.1. Preliminaries
Initially, we assume that there is at least one CSP that has Initially, we assume that there is at least one CSP that has
contracted with an upstream CDN (uCDN) to deliver content on its contracted with an upstream CDN (uCDN) to deliver content on its
behalf. We are not particularly concerned with the interface between behalf. We are not particularly concerned with the interface between
the CSP and uCDN, other than to note that it is expected to be the the CSP and uCDN, other than to note that it is expected to be the
same as in the "traditional" (non-interconnected) CDN case. Existing same as in the "traditional" (non-interconnected) CDN case. Existing
mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be
used to direct a user request for a piece of content from the CSP used to direct a user request for a piece of content from the CSP
towards the CSP's chosen upstream CDN. towards the CSP's chosen upstream CDN.
We use the term "CDN-domain" to refer to the host name (a FQDN) at We assume Operator A provides an upstream CDN that serves content on
the beginning of each URL. We assume Operator A provides an upstream behalf of a CSP with CDN-Domain cdn.csp.com. We assume that Operator
CDN that serves content on behalf of a CSP with CDN-domain B provides a downstream CDN. An end user at some point makes a
cdn.csp.com. We assume that Operator B provides a downstream CDN. request for URL
An end user at some point makes a request for URL
http://cdn.csp.com/...rest of url... http://cdn.csp.com/...rest of url...
It may well be the case that cdn.csp.com is just a CNAME for some It may well be the case that cdn.csp.com is just a CNAME for some
other CDN-domain (such as csp.op-a.net). Nevertheless, the HTTP other CDN-Domain (such as csp.op-a.net). Nevertheless, the HTTP
request in the examples that follow is assumed to be for the example request in the examples that follow is assumed to be for the example
URL above. URL above.
Our goal is to enable content identified by the above URL to be Our goal is to enable content identified by the above URL to be
served by the CDN of operator B. In the following sections we will served by the CDN of operator B. In the following sections we will
walk through some scenarios in which content is served, as well as walk through some scenarios in which content is served, as well as
other CDNI operations such as the removal of content from a other CDNI operations such as the removal of content from a
downstream CDN. downstream CDN.
3.2. HTTP Redirect Example 3.2. Iterative HTTP Redirect Example
In this section we walk through a simple, illustrative example using In this section we walk through a simple, illustrative example using
HTTP redirection from uCDN to dCDN. The example also assumes the use HTTP redirection from uCDN to dCDN. The example also assumes the use
of HTTP redirection inside uCDN and dCDN; however, this is of HTTP redirection inside uCDN and dCDN; however, this is
independent of the choice of redirection approach across CDNs, so an independent of the choice of redirection approach across CDNs, so an
alternative example could be constructed still showing HTTP alternative example could be constructed still showing HTTP
redirection from uCDN to dCDN but using DNS for handling of request redirection from uCDN to dCDN but using DNS for handling of request
inside each CDN. inside each CDN.
We assume for this example that Operators A and B have established an We assume for this example that Operators A and B have established an
agreement to interconnect their CDNs, with A being upstream and B agreement to interconnect their CDNs, with A being upstream and B
being downstream. (It is likely that the agreement would be made in being downstream.
both directions, but we focus on just one here for clarity.)
The operators agree that a CDN-domain peer-a.op-b.net will be used as The operators agree that a CDN-Domain peer-a.op-b.net will be used as
the target of redirections from uCDN to dCDN. The name of this the target of redirections from uCDN to dCDN. We assume the name of
domain must be communicated by some means to each CDN. (This could this domain is communicated by some means to each CDN. (This could
be established out-of-band or via a CDNI interface.) We refer to be established out-of-band or via a CDNI interface.) We refer to
this domain as a "distinguished" CDN domain to convey the fact that this domain as a "distinguished" CDN-Domain to convey the fact that
its use is limited to the interconnection mechanism; such a domain is its use is limited to the interconnection mechanism; such a domain is
never embedded in URLs that end-users request. never used directly by a CSP.
The operators must also agree on some distinguished CDN-domain that We assume the operators also agree on some distinguished CDN-Domain
will be used for inter-CDN acquisition of CSP's content from uCDN by that will be used for inter-CDN acquisition of CSP's content from
dCDN. In this example, we'll use op-b-acq.op-a.net. uCDN by dCDN. In this example, we'll use op-b-acq.op-a.net.
The operators must also exchange information regarding which requests We assume the operators also exchange information regarding which
dCDN is prepared to serve. For example, dCDN may be prepared to requests dCDN is prepared to serve. For example, dCDN may be
serve requests from clients in a given geographical region or a set prepared to serve requests from clients in a given geographical
of IP address prefixes. This information may again be provided out region or a set of IP address prefixes. This information may again
of band or via a defined interface. be provided out of band or via a defined CDNI interface.
DNS must be configured in the following way: We assume DNS is configured in the following way:
o The content provider must be configured to make operator A the o The content provider is configured to make operator A the
authoritative DNS server for cdn.csp.com (or to return a CNAME for authoritative DNS server for cdn.csp.com (or to return a CNAME for
cdn.csp.com for which operator A is the authoritative DNS server). cdn.csp.com for which operator A is the authoritative DNS server).
o Operator A must be configured so that a DNS request for op-b- o Operator A is configured so that a DNS request for op-b-acq.op-
acq.op-a.net returns a request router in Operator A. a.net returns a request router in Operator A.
o Operator B must be configured so that a DNS request for peer-a.op- o Operator B is configured so that a DNS request for peer-a.op-
b.net/cdn.csp.com returns a request router in Operator B. b.net/cdn.csp.com returns a request router in Operator B.
Figure 3 illustrates how a client request for Figure 3 illustrates how a client request for
http://cdn.csp.com/...rest of url... http://cdn.csp.com/...rest of url...
is handled. is handled.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.com | |
skipping to change at page 16, line 29 skipping to change at page 16, line 26
| |------------------------>| | |------------------------>|
| | |(9) | | |(9)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| | |(10) | | |(10)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 3: Request Trace for HTTP redirection method 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 CDN-- recognizes that the end-user is best served by another CDN--
specifically one provided by Operator B--and so it returns a 302 specifically one provided by Operator B--and so it returns a 302
redirect message for a new URL constructed by "stacking" redirect message for a new URL constructed by "stacking"
Operator B's distinguished CDN-domain (peer-a.op-b.net) on the Operator B's distinguished CDN-Domain (peer-a.op-b.net) on the
front of the original URL. (Note that more complex URL front of the original URL. (Note that more complex URL
manipulations are possible, such as replacing the initial CDN- manipulations are possible, such as replacing the initial CDN-
domain by some opaque handle.) Domain by some opaque handle.)
3. The end-user does a DNS lookup using Operator B's distinguished 3. The end-user does a DNS lookup using Operator B's distinguished
CDN-domain (peer-a.op-b.net). B's DNS resolver returns the IP CDN-Domain (peer-a.op-b.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 by 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
delivery node to the end-user. In the case of a cache miss, the delivery node to the end-user. In the case of a cache miss, the
content needs to be acquired by dCDN from uCDN (not the CSP). content needs to be acquired by dCDN from uCDN (not the CSP).
The distinguished CDN-domain peer-a.op-b.net indicates to dCDN The distinguished CDN-Domain peer-a.op-b.net indicates to dCDN
that this content is to be acquired from uCDN; stripping the that this content is to be acquired from uCDN; stripping the
CDN-domain reveals the original CDN-domain cdn.csp.com and dCDN CDN-Domain reveals the original CDN-Domain cdn.csp.com and dCDN
may verify that this CDN-domain belongs to a known peer (so as may verify that this CDN-Domain belongs to a known peer (so as
to avoid being tricked into serving as an open proxy). It then to avoid being tricked into serving as an open proxy). It then
does a DNS request for an inter-CDN acquisition CDN-domain as does a DNS request for an inter-CDN acquisition CDN-Domain as
agreed above (in this case, op-b-acq.op-a.net). agreed above (in this case, op-b-acq.op-a.net).
7. Operator A's DNS resolver processes the DNS request and returns 7. Operator A's DNS resolver processes the DNS request and returns
the IP address of a request router in operator A. the IP address of a request router in operator A.
8. The request router for Operator A processes the HTTP request 8. The request router for Operator A processes the HTTP request
from Operator B delivery node. Operator A request router from Operator B delivery node. Operator A request router
recognizes that the request is from a peer CDN rather than an recognizes that the request is from a peer CDN rather than an
end-user because of the dedicated inter-CDN acquisition domain end-user because of the dedicated inter-CDN acquisition domain
(op-b-acq.op-a.net). (Note that without this specially defined (op-b-acq.op-a.net). (Note that without this specially defined
skipping to change at page 17, line 49 skipping to change at page 17, line 46
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 by 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.
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 A serves content for the requested CDN-domain to dCDN. 10. Operator A serves content for the requested CDN-Domain to dCDN.
Although not shown, it is at this point that Operator A Although not shown, Operator A processes the rest of the URL: it
processes the rest of the URL: it extracts information extracts information identifying the origin server, validates
identifying the origin server, validates that this server has that this server has been registered, and determines the content
been registered, and determines the content provider that owns provider that owns the origin server. It may also perform its
the origin server. It may also perform its own content own content acquisition steps if needed before returning the
acquisition steps if needed before returning the content to content to dCDN.
dCDN.
3.2.1. Comments on the example
The main advantage of this design is that it is simple: each CDN need The main advantage of this design is that it is simple: each CDN need
only know the distinguished CDN-domain for each peer, with the only know the distinguished CDN-Domain for each peer, with the
upstream CDN "pushing" the downstream CDN-domain onto the URL as part upstream CDN "pushing" the downstream CDN-Domain onto the URL as part
of its redirect (step 2) and the downstream CDN "popping" its CDN- of its redirect (step 2) and the downstream CDN "popping" its CDN-
domain off the URL to expose a CDN-domain that the upstream CDN can Domain off the URL to expose a CDN-Domain that the upstream CDN can
correctly process. Neither CDN needs to be aware of the internal correctly process. Neither CDN needs to be aware of the internal
structure of the other's URLs. Moreover, the inter-CDN redirection structure of the other's URLs. Moreover, the inter-CDN redirection
is entirely supported by a single HTTP redirect; neither CDN needs to is entirely supported by a single HTTP redirect; neither CDN needs to
be aware of the other's internal redirection mechanism (i.e., whether be aware of the other's internal redirection mechanism (i.e., whether
it is DNS or HTTP based). it is DNS or HTTP based).
One disadvantage is that the end-user's browser is redirected to a One disadvantage is that the end-user's browser is redirected to a
new URL that is not in the same domain of the original URL. This has new URL that is not in the same domain of the original URL. This has
implications on a number of security or validation mechanisms implications on a number of security or validation mechanisms
sometimes used on endpoints. For example, it is important that any sometimes used on endpoints. For example, it is important that any
skipping to change at page 18, line 38 skipping to change at page 18, line 33
another example, some video players enforce validation of a cross another example, some video players enforce validation of a cross
domain policy that needs to allow for the domains involved in the CDN domain policy that needs to allow for the domains involved in the CDN
redirection. These problems are generally soluble, but the solutions redirection. These problems are generally soluble, but the solutions
complicate the example, so we do not discuss them further in this complicate the example, so we do not discuss them further in this
version of the draft. version of the draft.
We note that this example begins to illustrate some of the interfaces We note that this example begins to illustrate some of the interfaces
that may be required for CDNI, but does not require all of them. For that may be required for CDNI, but does not require all of them. For
example, obtaining information from dCDN regarding the set of client example, obtaining information from dCDN regarding the set of client
IP addresses or geographic regions it might be able to serve is an IP addresses or geographic regions it might be able to serve is an
aspect of the request routing interface. Important configuration aspect of the CDNI request routing interface (specifically of the
CDNI Footprint and Capabilities Interface). Important configuration
information such as the distinguished names used for redirection and information such as the distinguished names used for redirection and
inter-CDN acquisition could also be conveyed via a CDNI interface inter-CDN acquisition could also be conveyed via a CDNI interface
(e.g., perhaps the control interface). The example also shows how (e.g., perhaps the Control Interface). The example also shows how
existing HTTP-based methods suffice for the acquisition interface. existing HTTP-based methods suffice for the acquisition interface.
Arguably, the absolute minimum metadata required for CDNI is the Arguably, the absolute minimum metadata required for CDNI is the
information required to acquire the content, and this information was information required to acquire the content, and this information was
provided "in-band" in this example by means of the URI handed to the provided "in-band" in this example by means of the URI handed to the
client in the HTTP 302 response. Hence, there is no explicit client in the HTTP 302 response. The example also assumes that the
metadata interface invoked in this example. There is also no CSP does not require any distribution policy (e.g. time window, geo-
explicit logging interface discussed in this example. blocking) or delivery processing to be applied by the interconnected
CDNs. Hence, there is no explicit Metadata Interface invoked in this
example. There is also no explicit Logging Interface discussed in
this example.
We also note that the step of deciding when a request should be We also note that the step of deciding when a request should be
redirected to dCDN rather than served by uCDN has been somewhat redirected to dCDN rather than served by uCDN has been somewhat
glossed over. It may be as simple as checking the client IP address glossed over. It may be as simple as checking the client IP address
against a list of prefixes, or it may be considerably more complex, against a list of prefixes, or it may be considerably more complex,
involving a wide range of factors, such as the geographic location of involving a wide range of factors, such as the geographic location of
the client (perhaps determined from a third party service), CDN load, the client (perhaps determined from a third party service), CDN load,
or specific business rules. or specific business rules.
This example uses the "iterative" CDNI request routing approach. This example uses the "iterative" CDNI request redirection approach.
That is, uCDN performs part of the request routing function to That is, uCDN performs part of the request redirection function by
determine that dCDN should serve the request, and then redirects the redirecting the client to a request router in the dCDN, which then
client to a request router in dCDN to perform the rest of the request performs the rest of the redirection function by redirecting to a
routing function. If request routing is performed in the dCDN using suitable surrogate. If request routing is performed in the dCDN
HTTP redirection, this translates in the end-user experiencing two using HTTP redirection, this translates in the end-user experiencing
successive HTTP redirections. By contrast, the alternative approach two successive HTTP redirections. By contrast, the alternative
of "recursive" CDNI request routing effectively coalesces these two approach of "recursive" CDNI request redirection effectively
successive HTTP redirections into a single one, sending the end-user coalesces these two successive HTTP redirections into a single one,
directly to the right delivery node in the dCDN. This "recursive" sending the end-user directly to the right delivery node in the dCDN.
CDNI request routing approach is discussed in the next section. This "recursive" CDNI request routing approach is discussed in the
next section.
3.3. Recursive Redirection Example 3.3. Recursive HTTP Redirection Example
The following example builds on the previous one to illustrate the The following example builds on the previous one to illustrate the
use of the Request Routing interface to enable "recursive" CDNI use of the Request Routing Interface (specifically the CDNI Request
request routing. We build on the HTTP-based redirection approach Routing Redirection Interface) to enable "recursive" CDNI request
because it illustrates the principles and benefits clearly, but it is routing. We build on the HTTP-based redirection approach because it
equally possible to perform recursive redirection when DNS-based illustrates the principles and benefits clearly, but it is equally
redirection is employed. possible to perform recursive redirection when DNS-based redirection
is employed.
In contrast to the prior example, the operators need not agree in In contrast to the prior example, the operators need not agree in
advance on a CDN-domain to serve as the target of redirections from advance on a CDN-Domain to serve as the target of redirections from
uCDN to dCDN. The operators still must agree on some distinguished uCDN to dCDN. We assume that the operators agree on some
CDN-domain that will be used for inter-CDN acquisition of CSP's distinguished CDN-Domain that will be used for inter-CDN acquisition
content by dCDN. In this example, we'll use op-b-acq.op-a.net. of CSP's content by dCDN. In this example, we'll use op-b-acq.op-
a.net.
The operators must also exchange information regarding which requests We assume the operators also exchange information regarding which
dCDN is prepared to serve. For example, dCDN may be prepared to requests dCDN is prepared to serve. For example, dCDN may be
serve requests from clients in a given geographical region or a set prepared to serve requests from clients in a given geographical
of IP address prefixes. This information may again be provided out region or a set of IP address prefixes. This information may again
of band or via a defined protocol. be provided out of band or via a defined protocol.
DNS must be configured in the following way: We assume DNS is configured in the following way:
o The content provider must be configured to make operator A the o The content provider is configured to make operator A the
authoritative DNS server for cdn.csp.com (or to return a CNAME for authoritative DNS server for cdn.csp.com (or to return a CNAME for
cdn.csp.com for which operator A is the authoritative DNS server). cdn.csp.com for which operator A is the authoritative DNS server).
o Operator A must be configured so that a DNS request for op-b- o Operator A is configured so that a DNS request for op-b-acq.op-
acq.op-a.net returns a request router in Operator A. a.net returns a request router in Operator A.
o Operator B must be configured so that a request for node1.op- o Operator B is configured so that a request for node1.op-b.net/
b.net/cdn.csp.com returns the IP address of a delivery node. Note cdn.csp.com returns the IP address of a delivery node. Note that
that there might be a number of such delivery nodes. there might be a number of such delivery nodes.
Figure 3 illustrates how a client request for Figure 3 illustrates how a client request for
http://cdn.csp.com/...rest of url... http://cdn.csp.com/...rest of url...
is handled. is handled.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.com | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
|IPaddr of A's Request Router | |IPaddr of A's Request Router |
|<--------------------------------------------------| |<--------------------------------------------------|
|HTTP cdn.csp.com | | |HTTP cdn.csp.com | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(2) | | |(2)
| |RRI REQ cdn.csp.com | | |RR/RI REQ cdn.csp.com |
| |<------------------------| | |<------------------------|
| | | | | |
| |RRI RESP node1.op-b.net | | |RR/RI RESP node1.op-b.net|
| |------------------------>| | |------------------------>|
| | |(3) | | |(3)
|302 node1.op-b.net/cdn.csp.com | |302 node1.op-b.net/cdn.csp.com |
|<--------------------------------------------------| |<--------------------------------------------------|
|DNS mode1.op-b.net | | |DNS mode1.op-b.net | |
|------------------------>| | |------------------------>| |
| |(4) | | |(4) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
|HTTP node1.op-b.net/cdn.csp.com | |HTTP node1.op-b.net/cdn.csp.com |
skipping to change at page 21, line 51 skipping to change at page 21, line 51
| |------------------------>| | |------------------------>|
| | |(8) | | |(8)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| | |(9) | | |(9)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 4: Request Trace for Recursive HTTP redirection method Figure 4: Message Flow for Recursive HTTP Redirection
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. A DNS resolver for Operator A processes the DNS request for its 1. A DNS resolver for Operator A processes the DNS request for its
customer based on CDN-domain cdn.csp.com. It returns the IP customer based on CDN-Domain cdn.csp.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 CDN-- recognizes that the end-user is best served by another CDN--
specifically one provided by Operator B--and so it queries the specifically one provided by Operator B--and so it queries the
CDNI Request Routing interface of Operator B, providing a set of CDNI Request Routing Redirection Interface of Operator B,
information about the request including the URL requested. providing a set of information about the request including the
Operator B replies with the DNS name of a delivery node. URL requested. Operator B replies with the DNS name of a
delivery node.
3. Operator A returns a 302 redirect message for a new URL obtained 3. Operator A returns a 302 redirect message for a new URL obtained
from the Request Routing Interface. from the Request Routing Interface.
4. The end-user does a DNS lookup using the host name of the URL 4. The end-user does a DNS lookup using the host name of the URL
just provided (node1.op-b.net). B's DNS resolver returns the IP just provided (node1.op-b.net). B's DNS resolver returns the IP
address of the corresponding delivery node. Note that, since the address of the corresponding delivery node. Note that, since the
name of the delivery node was already obtained from B using the name of the delivery node was already obtained from B using the
CDNI Request Routing Interface, there should not be any further CDNI Request Routing Interface, there should not be any further
redirection here (in contrast to the iterative method described redirection here (in contrast to the iterative method described
above.) above.)
5. The end-user requests the content from B's delivery node, 5. The end-user requests the content from B's delivery node,
potentially resulting in a cache miss. In the case of a cache potentially resulting in a cache miss. In the case of a cache
miss, the content needs to be acquired from uCDN (not the CSP.) miss, the content needs to be acquired from uCDN (not the CSP.)
The distinguished CDN-domain op-b.net indicates to dCDN that this The distinguished CDN-Domain op-b.net indicates to dCDN that this
content is to be acquired from another CDN; stripping the CDN- content is to be acquired from another CDN; stripping the CDN-
domain reveals the original CDN-domain cdn.csp.com, dCDN may Domain reveals the original CDN-Domain cdn.csp.com, dCDN may
verify that this CDN-domain belongs to a known peer (so as to verify that this CDN-Domain belongs to a known peer (so as to
avoid being tricked into serving as an open proxy). It then does avoid being tricked into serving as an open proxy). It then does
a DNS request for the inter-CDN Acquisition "distinguished" CDN- a DNS request for the inter-CDN Acquisition "distinguished" CDN-
domain as agreed above (in this case, op-b-acq.op-a.net). Domain as agreed above (in this case, op-b-acq.op-a.net).
6. Operator A DNS resolver processes the DNS request and returns the 6. Operator A DNS resolver processes the DNS request and returns the
IP address of a request router in operator A. IP address of a request router in operator A.
7. The request router for Operator A processes the HTTP request from 7. The request router for Operator A processes the HTTP request from
Operator B delivery node. Operator A request router recognizes Operator B delivery node. Operator A request router recognizes
that the request is from a peer CDN rather than an end-user that the request is from a peer CDN rather than an end-user
because of the dedicated inter-CDN acquisition domain (op-b- because of the dedicated inter-CDN acquisition domain (op-b-
acq.op-a.net). (Note that without this specially defined inter- acq.op-a.net). (Note that without this specially defined inter-
CDN acquisition domain, operator A would be at risk of 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 by a subdomain of the
Operator A's distinguished inter-CDN acquisition domain that Operator A's distinguished inter-CDN acquisition domain that
points to the selected delivery node. points to the selected delivery node.
8. Operator A recognizes that the DNS request is from a peer CDN 8. Operator A recognizes that the DNS request is from a peer CDN
rather than an end-user (due to the internal CDN-domain) and so rather than an end-user (due to the internal CDN-Domain) and so
returns the address of a delivery node. (Note that without this returns the address of a delivery node. (Note that without this
specially defined internal domain, Operator A would be at risk of specially defined internal domain, Operator A would be at risk of
redirecting the request back to Operator B, resulting in an redirecting the request back to Operator B, resulting in an
infinite loop.) infinite loop.)
9. Operator A serves content for the requested CDN-domain to dCDN. 9. Operator A serves content for the requested CDN-Domain to dCDN.
Although not shown, it is at this point that Operator A processes Although not shown, it is at this point that Operator A processes
the rest of the URL: it extracts information identifying the the rest of the URL: it extracts information identifying the
origin server, validates that this server has been registered, origin server, validates that this server has been registered,
and determines the content provider that owns the origin server. and determines the content provider that owns the origin server.
It may also perform its own content acquisition steps if needed It may also perform its own content acquisition steps if needed
before returning the content to dCDN. before returning the content to dCDN.
3.3.1. Comments on the example
Recursive redirection has the advantage over iterative of being more Recursive redirection has the advantage over iterative of being more
transparent from the end-user's perspective, but the disadvantage of transparent from the end-user's perspective, but the disadvantage of
each CDN exposing more of its internal structure (in particular, the each CDN exposing more of its internal structure (in particular, the
addresses of edge caches) to peer CDNs. By contrast, iterative addresses of edge caches) to peer CDNs. By contrast, iterative
redirection does not require dCDN to expose the addresses of its edge redirection does not require dCDN to expose the addresses of its edge
caches to uCDN. caches to uCDN.
This example happens to use HTTP-based redirection in both CDN A and This example happens to use HTTP-based redirection in both CDN A and
CDN B, but a similar example could be constructed using DNS-based CDN B, but a similar example could be constructed using DNS-based
redirection in either CDN. Hence, the key point to take away here is redirection in either CDN. Hence, the key point to take away here is
simply that the end user only sees a single redirection of some type, simply that the end user only sees a single redirection of some type,
as opposed to the pair of redirections in the prior (iterative) as opposed to the pair of redirections in the prior (iterative)
example. example.
The use of the Request Routing Interface requires that interface to The use of the Request Routing Interface requires that interface to
be appropriately configured and bootstrapped, which is not shown be appropriately configured and bootstrapped, which is not shown
here. More discussion on the bootstrapping of interfaces is provided here. More discussion on the bootstrapping of interfaces is provided
in Section 4 in Section 4
3.4. DNS-based redirection example 3.4. Iterative DNS-based Redirection Example
In this section we walk through a simple example using DNS-based In this section we walk through a simple example using DNS-based
redirection for request redirection from uCDN to dCDN (as well as for redirection for request redirection from uCDN to dCDN (as well as for
request routing inside dCDN and uCDN). As noted in Section 2.1, DNS- request routing inside dCDN and uCDN). As noted in Section 2.1, DNS-
based redirection has certain advantages over HTTP-based redirection based redirection has certain advantages over HTTP-based redirection
(notably, it is transparent to the end-user) as well as some (notably, it is transparent to the end-user) as well as some
drawbacks (notably the client IP address is not visible to the drawbacks (notably the client IP address is not visible to the
request router). request router).
As before, Operator A must learn the set of requests that dCDN is As before, Operator A has to learn the set of requests that dCDN is
willing or able to serve (e.g. which client IP address prefixes or willing or able to serve (e.g. which client IP address prefixes or
geographic regions are part of the dCDN footprint). Operator B must geographic regions are part of the dCDN footprint). We assume
have and make known to operator A some unique identifier that can be Operator has and makes known to operator A some unique identifier
used for the construction of a distinguished CDN domain, as shown in that can be used for the construction of a distinguished CDN-Domain,
more detail below. (This identifier strictly needs only to be unique as shown in more detail below. (This identifier strictly needs only
within the scope of Operator A, but a globally unique identifier, to be unique within the scope of Operator A, but a globally unique
such as an AS number assigned to B, is one easy way to achieve that.) identifier, such as an AS number assigned to B, is one easy way to
Also, Operator A must obtain the NS records for Operator B's achieve that.) Also, Operator A obtains the NS records for Operator
externally visible redirection servers. Also, as before, a B's externally visible redirection servers. Also, as before, a
distinguished CDN-domain, such as op-b-acq.op-a.net, must be assigned distinguished CDN-Domain, such as op-b-acq.op-a.net, must be assigned
for inter-CDN acquisition. for inter-CDN acquisition.
DNS must be configured in the following way: We assume DNS is configured in the following way:
o The CSP must be configured to make Operator A the authoritative o The CSP is configured to make Operator A the authoritative DNS
DNS server for cdn.csp.com (or to return a CNAME for cdn.csp.com server for cdn.csp.com (or to return a CNAME for cdn.csp.com for
for which operator A is the authoritative DNS server). which operator A is the authoritative DNS server).
o When uCDN sees a request best served by dCDN, it returns CNAME and o When uCDN sees a request best served by dCDN, it returns CNAME and
NS records for "b.cdn.csp.com", where "b" is the unique identifier NS records for "b.cdn.csp.com", where "b" is the unique identifier
assigned to Operator B. (It may, for example, be an AS number assigned to Operator B. (It may, for example, be an AS number
assigned to Operator B.) assigned to Operator B.)
o dCDN must be configured so that a request for "b.cdn.csp.com" o dCDN is configured so that a request for "b.cdn.csp.com" returns a
returns a delivery node in dCDN. delivery node in dCDN.
o uCDN must be configured so that a request for "op-b-acq.op-a.net" o uCDN is configured so that a request for "op-b-acq.op-a.net"
returns a delivery node in uCDN. returns a delivery node in uCDN.
Figure 5 depicts the exchange of DNS and HTTP requests. The main Figure 5 depicts the exchange of DNS and HTTP requests. The main
differences from Figure 3 are the lack of HTTP redirection and differences from Figure 3 are the lack of HTTP redirection and
transparency to the end-user. transparency to the end-user.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.com | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
skipping to change at page 25, line 33 skipping to change at page 25, line 33
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.net |
| |------------------------>| | |------------------------>|
| | |(5) | | |(5)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 5: Request Trace for DNS-based Redirection Example Figure 5: Message Flow for DNS-based Redirection
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. Request Router for Operator A processes the DNS request for CDN- 1. Request Router for Operator A processes the DNS request for CDN-
domain cdn.csp.com and recognizes that the end-user is best Domain cdn.csp.com and recognizes that the end-user is best
served by another CDN. (This may depend on the IP address of the served by another CDN. (This may depend on the IP address of the
user's local DNS resolver, or other information discussed below.) user's local DNS resolver, or other information discussed below.)
The Request Router returns a DNS CNAME response by "stacking" the The Request Router returns a DNS CNAME response by "stacking" the
distinguished identifier for Operator B onto the original CDN- distinguished identifier for Operator B onto the original CDN-
domain (e.g., b.cdn.csp.com), plus an NS record that maps Domain (e.g., b.cdn.csp.com), plus an NS record that maps
b.cdn.csp.com to B's Request Router. b.cdn.csp.com to B's Request Router.
2. The end-user does a DNS lookup using the modified CDN-domain 2. The end-user does a DNS lookup using the modified CDN-Domain
(i.e., b.cdn.csp.com). This causes B's Request Router to respond (i.e., b.cdn.csp.com). This causes B's Request Router to respond
with a suitable delivery node. with a suitable delivery node.
3. The end-user requests the content from B's delivery node. The 3. The end-user requests the content from B's delivery node. The
requested URL contains the name cdn.csp.com. (Note that the requested URL contains the name cdn.csp.com. (Note that the
returned CNAME does not affect the URL.) At this point the returned CNAME does not affect the URL.) At this point the
delivery node has the correct IP address of the end-user and can delivery node has the correct IP address of the end-user and can
do an HTTP 302 redirect if the redirections in steps 2 and 3 were do an HTTP 302 redirect if the redirections in steps 2 and 3 were
incorrect. Otherwise B verifies that this CDN-domain belongs to incorrect. Otherwise B verifies that this CDN-Domain belongs to
a known peer (so as to avoid being tricked into serving as an a known peer (so as to avoid being tricked into serving as an
open proxy). It then does a DNS request for an "internal" CDN- open proxy). It then does a DNS request for an "internal" CDN-
domain as agreed above (op-b-acq.op-a.net). Domain as agreed above (op-b-acq.op-a.net).
4. Operator A recognizes that the DNS request is from a peer CDN 4. Operator A recognizes that the DNS request is from a peer CDN
rather than an end-user (due to the internal CDN-domain) and so rather than an end-user (due to the internal CDN-Domain) and so
returns the address of a delivery node in uCDN. returns the address of a delivery node in uCDN.
5. Operator A serves content to dCDN. Although not shown, it is at 5. Operator A serves content to dCDN. Although not shown, it is at
this point that Operator A processes the rest of the URL: it this point that Operator A processes the rest of the URL: it
extracts information identifying the origin server, validates extracts information identifying the origin server, validates
that this server has been registered, and determines the content that this server has been registered, and determines the content
provider that owns the origin server. provider that owns the origin server.
3.4.1. Comments on the example
The advantages of this approach are that it is more transparent to The advantages of this approach are that it is more transparent to
the end-user and requires fewer round trips than HTTP-based the end-user and requires fewer round trips than HTTP-based
redirection. A potential problem is that the upstream CDN depends on redirection (in its worst case, i.e., when none of the needed DNS
being able to learn the correct downstream CDN that serves the end- information is cached). A potential problem is that the upstream CDN
user from the client address in the DNS request. In standard DNS depends on being able to learn the correct downstream CDN that serves
operation, uCDN will only obtain the address of the client's local the end-user from the client address in the DNS request. In standard
DNS resolver (LDNS), which is not guaranteed to be in the same DNS operation, uCDN will only obtain the address of the client's
local DNS resolver (LDNS), which is not guaranteed to be in the same
network (or geographic region) as the client. If not--e.g., the end- network (or geographic region) as the client. If not--e.g., the end-
user uses a global DNS service--then the upstream CDN cannot user uses a global DNS service--then the upstream CDN cannot
determine the appropriate downstream CDN to serve the end-user. In determine the appropriate downstream CDN to serve the end-user. In
this case, one option is for the upstream CDN to treat the end-user this case, and assuming the uCDN is capable of detecting that
situation, one option is for the upstream CDN to treat the end-user
as it would any user not connected to a peer CDN. Another option is as it would any user not connected to a peer CDN. Another option is
for the upstream CDN to "fall back" to a pure HTTP-based redirection for the upstream CDN to "fall back" to a pure HTTP-based redirection
strategy in this case (i.e., use the first method). Note that this strategy in this case (i.e., use the first method). Note that this
problem affects existing CDNs that rely on DNS to determine where to problem affects existing CDNs that rely on DNS to determine where to
redirect client requests, but the consequences are arguably less redirect client requests, but the consequences are arguably less
serious since the LDNS is likely in the same network as the dCDN serious for CDNI since the LDNS is likely in the same network as the
serves. One approach to ensuring that the client's IP address prefix dCDN serves. One approach to ensuring that the client's IP address
is correctly determined in such situations is described in prefix is correctly determined in such situations is described in
[I-D.vandergaast-edns-client-subnet]. [I-D.vandergaast-edns-client-subnet].
As with the prior example, this example partially illustrates the As with the prior example, this example partially illustrates the
various interfaces involved in CDNI. Operator A could learn various interfaces involved in CDNI. Operator A could learn
dynamically from Operator B the set of prefixes or regions that B is dynamically from Operator B the set of prefixes or regions that B is
willing and able to serve via the request routing interface. The willing and able to serve via the Footprint & Capabilities Interface.
distinguished name used for acquisition and the identifier for The distinguished name used for acquisition and the identifier for
Operator B that is prepended to the CDN domain on redirection are Operator B that is prepended to the CDN-Domain on redirection are
examples of information elements that might also be conveyed by CDNI examples of information elements that might also be conveyed by CDNI
interfaces (or, alternatively, statically configured). As before, interfaces (or, alternatively, statically configured). As before,
minimal metadata sufficient to obtain the content is carried "in- minimal metadata sufficient to obtain the content is carried "in-
band" as part of the redirection process, and standard HTTP is used band" as part of the redirection process, and standard HTTP is used
for inter-CDN acquisition. There is no explicit logging interface for inter-CDN acquisition. There is no explicit Logging Interface
discussed in this example. discussed in this example.
3.5. Dynamic Footprint Discovery 3.5. Dynamic Footprint Discovery Example
There could be situations where being able to dynamically discover There could be situations where being able to dynamically discover
the set of requests that a given dCDN is willing and able to serve is the set of requests that a given dCDN is willing and able to serve is
beneficial. For example, a CDN might at one time be able to serve a beneficial. For example, a CDN might at one time be able to serve a
certain set of client IP prefixes, but that set might change over certain set of client IP prefixes, but that set might change over
time due to changes in the topology and routing policies of the IP time due to changes in the topology and routing policies of the IP
network. The following example illustrates this capability. We have network. The following example illustrates this capability. We have
chosen the example of DNS-based redirection, but HTTP-based chosen the example of DNS-based redirection, but HTTP-based
redirection could equally well use this approach. redirection could equally well use this approach.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.com | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
| | RRI REQ op-b.net | | | RI REQ op-b.net |
| |<------------------------| | |<------------------------|
| | |(2) | | |(2)
| | RRI REPLY | | | RI REPLY |
| |------------------------>| | |------------------------>|
| | |(3) | | |(3)
|CNAME b.cdn.csp.com | | |CNAME b.cdn.csp.com | |
|NS records for b.cdn.csp.com | |NS records for b.cdn.csp.com |
|<--------------------------------------------------| |<--------------------------------------------------|
|DNS b.cdn.csp.com | | |DNS b.cdn.csp.com | |
|------------------------>| | |------------------------>| |
| |(2) | | |(2) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
skipping to change at page 28, line 39 skipping to change at page 28, line 39
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.net |
| |------------------------>| | |------------------------>|
| | |(5) | | |(5)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 6: Request Trace for Dynamic Footprint Discovery Example Figure 6: Message Flow for Dynamic Footprint Discovery
This example differs from the one in Figure 5 only in the addition of This example differs from the one in Figure 5 only in the addition of
a CDNI Request Routing Interface request (step 2) and corresponding a CDNI Request Routing Interface Footprint request (step 2) and
response (step 3). The RRI Req could be a message such as "Can you corresponding response (step 3). The RI REQ could be a message such
serve clients from this IP Prefix?" or it could be "Provide the list as "Can you serve clients from this IP Prefix?" or it could be
of client IP prefixes you can currently serve". In either case the "Provide the list of client IP prefixes you can currently serve". In
response might be cached by operator A to avoid repeatedly asking the either case the response might be cached by operator A to avoid
same question. Alternatively, or in addition, Operator B may repeatedly asking the same question. Alternatively, or in addition,
spontaneously advertise to Operator A information (or changes) on the Operator B may spontaneously advertise to Operator A information (or
set of requests it is willing and able to serve on behalf of operator changes) on the set of requests it is willing and able to serve on
A; in that case, Operator B may spontaneously issue RRI REPLY behalf of operator A; in that case, Operator B may spontaneously
messages that are not in direct response to a corresponding RRI REQ issue RR/RI REPLY messages that are not in direct response to a
message. (Note that the issues of determining the client's subnet corresponding RR/RI REQ message. (Note that the issues of
from DNS requests, as described above, are exactly the same here as determining the client's subnet from DNS requests, as described
in Section 3.4.) above, are exactly the same here as in Section 3.4.)
Once Operator A obtains the RRI response, it is now able to determine Once Operator A obtains the RI response, it is now able to determine
that Operator B's CDN is an appropriate dCDN for this request and that Operator B's CDN is an appropriate dCDN for this request and
therefore a valid candidate dCDN to consider in its Redirection therefore a valid candidate dCDN to consider in its Redirection
decision. If that dCDN is selected, the redirection and serving of decision. If that dCDN is selected, the redirection and serving of
the request proceeds as before (i.e. in the absence of dynamic the request proceeds as before (i.e. in the absence of dynamic
footprint discovery). footprint discovery).
3.6. Content Removal 3.6. Content Removal Example
The following example illustrates how the Control interface may be The following example illustrates how the Control Interface may be
used to remove an item of content. In this example, user requests used to achieve pre-positioning of an item of content in the dCDN.
for a particular content, and corresponding redirection of such In this example, user requests for a particular content, and
requests from Operator A to Operator B CDN, may (or may not) have corresponding redirection of such requests from Operator A to
taken place earlier. Then, at some point in time, the uCDN (for Operator B CDN, may (or may not) have taken place earlier. Then, at
example, in response to a corresponding trigger from the Content some point in time, the uCDN (for example, in response to a
Provider) uses the Control Interface to request that content corresponding trigger from the Content Provider) uses the Control
identified by a particular URL be removed from dCDN. The following Interface to request that content identified by a particular URL be
diagram illustrates the operation. removed from 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/... |
| |<------------------------| | |<------------------------|
| | |(1) | | |
| |CI OK | | |CI OK |
| |------------------------>| | |------------------------>|
| | |(2) | | |
Figure 7: Request Trace for Content Removal Figure 7: Message Flow for Content Removal
The Control interface is used to convey the request from uCDN to dCDN The Control Interface is used to convey the request from uCDN to dCDN
that some previously acquired content should be deleted. The URL in that some previously acquired content should be deleted. The URL in
the request specifies which content to remove. This example the request specifies which content to remove. This example
corresponds to a DNS-based redirection scenario such as Section 3.4. corresponds to a DNS-based redirection scenario such as Section 3.4.
If HTTP-based redirection had been used, the URL for removal would be If HTTP-based redirection had been used, the URL for removal would be
of the form peer-a.op-b.net/cdn.csp.com/... of the form peer-a.op-b.net/cdn.csp.com/...
The dCDN is expected to confirm to the uCDN, as illustrated by the CI The dCDN is expected to confirm to the uCDN, as illustrated by the CI
OK message, the completion of the removal of the targeted content OK message, the completion of the removal of the targeted content
from all the caches in dCDN. from all the caches in dCDN.
3.7. Pre-Positioned Content Acquisition Example 3.7. Pre-Positioned Content Acquisition Example
The following example illustrates how the Control interface may be The following example illustrates how the Control Interface may be
used to pre-position an item of content in the dCDN. In this used to pre-position an item of content in the dCDN. In this
example, Operator A uses the Metadata interface to request that example, Operator A uses the Metadata Interface to request that
content identified by a particular URL be pre-positioned into content identified by a particular URL be pre-positioned into
Operator B CDN. Operator B CDN.
End-User Operator B Operator A End-User Operator B Operator A
| |CI pre-position cdn.csp.com/... | |CI pre-position cdn.csp.com/...
| |<------------------------| | |<------------------------|
| | |(1) | | |(1)
| |CI OK | | |CI OK |
| |------------------------>| | |------------------------>|
skipping to change at page 30, line 46 skipping to change at page 30, line 46
|------------------------>| | |------------------------>| |
| |(6) | | |(6) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
|HTTP peer-a.op-b.net/cdn.csp.com | |HTTP peer-a.op-b.net/cdn.csp.com |
|------------------------>| | |------------------------>| |
| |(7) | | |(7) |
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 8: Request Trace for Content Pre-Positioning Figure 8: Message Flow for Content Pre-Positioning
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. Operator A uses the Control Interface to request that Operator B 1. Operator A uses the Control Interface to request that Operator B
pre-positions a particular content item identified by its URL. pre-positions a particular content item identified by its URL.
Operator B responds by confirming that it is willing to perform Operator B responds by confirming that it is willing to perform
this operation. this operation.
Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only
skipping to change at page 32, line 7 skipping to change at page 32, line 7
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
| | | | | |
| |MI push (cdn.csp.com/...,| | |CI pre-position (trigger)|
| | distribution policy) |
| |<------------------------|(1) | |<------------------------|(1)
| | | | | |
| |CI OK |
| |------------------------>|(2)
| | |
| |MI pull REQ |
| |------------------------>|(3)
| | | | | |
| CONTENT REQUEST | | | |MI metadata REP |(4)
|-------------------------------------------------->| (2)
| | | | | |
| |RRI REQ |
| (3)|<------------------------|
| | | | | |
| CONTENT REQUEST | |
|-------------------------------------------------->|(5)
| | | | | |
| |RRI RESP | | | RI REQ |
| |------------------------>|(4) | |<------------------------|(6)
| | |
| | RI RESP |
| |------------------------>|(7)
| | | | | |
| CONTENT REDIRECTION | | | CONTENT REDIRECTION | |
|<--------------------------------------------------| (5) |<--------------------------------------------------| (8)
| | | | | |
| CONTENT REQUEST | | | CONTENT REQUEST | |
|------------------------>| (6) | |------------------------>|(9) |
| | | | | |
: : : : : :
| CONTENT DATA | | | CONTENT DATA | |
|<------------------------| | (7) |<------------------------| |(10)
Figure 9: Request Trace 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 Metadata Interface to asynchronously push 1. Operator A uses the Control Interface to trigger to signal the
CDNI metadata to Operator B. The present document does not availability of CDNI metadata to Operator B.
constrain how the CDNI metadata information is actually
represented. For the purposes of this example, we assume that
Operator A provides CDNI metadata to Operator B indicating that:
* this CDNI Metadata is applicable to any content referenced by 2. Operator B acknowledges the receipt of this trigger.
"cdn.csp.com/op-b.net/..." (assuming HTTP redirection is used
- it would be applicable to "cdn.csp.com/..." if DNS
redirection were used as in Section 3.4).
* this CDNI metadata consists of a distribution policy requiring 3. Operator B requests the latest metadata from Operator A using
enforcement by the delivery node of a specific per-request the Metadata Interface.
authorization mechanism (e.g. URI signature or token
validation).
2. A Content Request occurs as usual. 4. Operator A replies with the requested metadata. This document
does not constrain how the CDNI metadata information is actually
represented. For the purposes of this example, we assume that
Operator A provides CDNI metadata to Operator B indicating that:
3. A CDNI Request Routing Request (RRI REQ) is issued by operator A * this CDNI Metadata is applicable to any content referenced by
CDN, as discussed in Section 3.3. Operator B's request router some CDN-Domain.
can access the CDNI Metadata that are relevant to the requested
content and that have been pre-positioned as per Step 1, which
may or may not affect the response.
4. Operator B's request router issues a CDNI Request Routing * this CDNI metadata consists of a distribution policy
Response (RRI RESP) as in Section 3.3. requiring enforcement by the delivery node of a specific per-
request authorization mechanism (e.g. URI signature or token
validation).
5. Operator B performs content redirection as discussed in 5. A Content Request occurs as usual.
Section 3.3.
6. On receipt of the Content Request by the end user, the delivery 6. A CDNI Request Routing Redirection request (RI REQ) is issued by
node detects that previously acquired CDNI metadata is applicable operator A CDN, as discussed in Section 3.3. Operator B's
to the requested content. In accordance with the specific CDNI request router can access the CDNI Metadata that are relevant to
metadata of this example, the delivery node will invoke the the requested content and that have been pre-positioned as per
appropriate per-request authorization mechanism, before serving Steps 1-4, which may or may not affect the response.
the content. (Details of this authorization are not shown.)
7. Assuming successful per-request authorization, serving of Content 7. Operator B's request router issues a CDNI Request Routing
Data (possibly preceded by inter-CDN acquisition) proceeds as in Redirection response (RI RESP) as in Section 3.3.
Section 3.3.
8. Operator B performs content redirection as discussed in
Section 3.3.
9. On receipt of the Content Request by the end user, the delivery
node detects that previously acquired CDNI metadata is
applicable to the requested content. In accordance with the
specific CDNI metadata of this example, the delivery node will
invoke the appropriate per-request authorization mechanism,
before serving the content. (Details of this authorization are
not shown.)
10. Assuming successful per-request authorization, serving of
Content Data (possibly preceded by inter-CDN acquisition)
proceeds as in Section 3.3.
3.9. Synchronous CDNI Metadata Acquisition Example 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
| | | | | |
| |MI push (cdn.csp.com/...,| | CONTENT REQUEST | |
| | CDNI metadata acquisition info) |-------------------------------------------------->|(1)
| |<------------------------|(1) | | |
| | | | | RI REQ |
: : : | (2)|<------------------------|
| CONTENT REQUEST | | | | |
|-------------------------------------------------->|(2) | | MI REQ |
| | | | (3)|------------------------>|
| |RRI REQ | | | MI RESP |
| (3)|<------------------------| | |<------------------------|(4)
| | | | | |
| |MI REQ | | | RI RESP |
| (4)|------------------------>| | |------------------------>|(5)
| |MI RESP | | | |
| |<------------------------|(5) | | |
| | | | CONTENT REDIRECTION | |
| |RRI RESP | |<--------------------------------------------------|(6)
| |------------------------>|(6) | | |
| | | | CONTENT REQUEST | |
| | | |------------------------>| (7) |
| CONTENT REDIRECTION | | | | |
|<--------------------------------------------------|(7) | | MI REQ |
| | | | (8)|------------------------>|
| CONTENT REQUEST | | | | MI RESP |
|------------------------>| (8) | | |<------------------------|(9)
| | | | | |
| |MI REQ | : : :
| (9)|------------------------>| | CONTENT DATA | |
| |MI RESP | |<------------------------| | (10)
| |<------------------------|(10)
| | |
: : :
| CONTENT DATA | |
|<------------------------| | (11)
Figure 10: Request Trace 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. Operator A initially uses the Metadata Interface to 1. A Content Request arrives as normal.
asynchronously push seed metadata to Operator B. For example,
this seed information may include a URI indicating where CDNI
Metadata can later be pulled from for some content set. (There
are alternative ways that this seeding information may be
provided, such as piggybacking on the CDNI RRI REQ message of
Step 3.)
2. A Content Request arrives as normal.
3. A Request Routing Interface request occurs as in the prior 2. A Request Routing Interface request occurs as in the prior
example. example.
4. 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. The seeding needed for routing of the end-user request. We assume the URI
information provided in Step 1 is used to determine how to for the a Metadata server is known ahead of time through some
obtain the metadata. Note that there may exist cases in which out-of-band means.
this step does not occur (e.g., because the CDNI metadata
seeding information indicates CDNI metadata are not needed at
that stage).
5. On receipt of a CDNI Metadata MI 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.)
6. Response to the RRI request as normal. 5. Response to the RI request as normal.
7. Redirection message is sent to the end user. 6. Redirection message is sent to the end user.
8. A delivery node of Operator B receives the end user request. 7. A delivery node of Operator B receives the end user request.
9. 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. Again the seeding information provided in Step 1 is request. Note that there may exist cases where this step need
used to determine how to acquire the needed CDNI metadata. Note not happen, for example because the metadata were already
that there may exist cases where this step need not happen, acquired previously.
either because the metadata were already acquired previously, or
because the seeding information indicates no metadata are
required.
10. 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.
11. Content is served (possibly preceded by inter-CDN acquisition) 10. Content is served (possibly preceded by inter-CDN acquisition)
as in Section 3.3. as in Section 3.3.
3.10. Content Acquisition with Multiple Upstream CDNs 3.10. Content and Metadata Acquisition with Multiple Upstream CDNs
A single dCDN may receive end-user requests from multiple uCDNs. A single dCDN may receive end-user requests from multiple uCDNs.
When a dCDN receives an end-user request, it must determine the When a dCDN receives an end-user request, it must determine the
identity of the uCDN from which it should acquire the requested identity of the uCDN from which it should acquire the requested
content. content.
Ideally, the acquisition path of an end-user request will follow the Ideally, the acquisition path of an end-user request will follow the
redirection path of the request. The dCDN should acquire the content redirection path of the request. The dCDN should acquire the content
from the same uCDN which redirected the request. from the same uCDN which redirected the request.
Determining the acquisition path requires the dCDN to reconstruct the Determining the acquisition path requires the dCDN to reconstruct the
redirection path based on information in the end-user request. The redirection path based on information in the end-user request. The
method for reconstructing the redirection path differs based on the method for reconstructing the redirection path differs based on the
redirection approach: HTTP or DNS. redirection approach: HTTP or DNS.
With HTTP-redirection, the rewritten URI must include sufficient With HTTP-redirection, the rewritten URI should include sufficient
information for the dCDN to directly or indirectly determine the uCDN information for the dCDN to directly or indirectly determine the uCDN
when the end-user request is received. The HTTP-redirection approach when the end-user request is received. The HTTP-redirection approach
can be further broken-down based on the how the URL is rewritten can be further broken-down based on the how the URL is rewritten
during redirection: HTTP-redirection with or without Site during redirection: HTTP-redirection with or without Site
Aggregation. HTTP-redirection with Site Aggregation hides the Aggregation. HTTP-redirection with Site Aggregation hides the
identity of the original CSP. HTTP-redirection without Site identity of the original CSP. HTTP-redirection without Site
Aggregation does not attempt to hide the identity of the original Aggregation does not attempt to hide the identity of the original
CSP. With both approaches, the rewritten URI must include enough CSP. With both approaches, the rewritten URI includes enough
information to identify the immediate neighbor uCDN. information to identify the immediate neighbor uCDN.
With DNS-redirection, the dCDN receives the published URI (instead of With DNS-redirection, the dCDN receives the published URI (instead of
a rewritten URI) and does not have sufficient information for the a rewritten URI) and does not have sufficient information for the
dCDN to identify the appropriate uCDN. Given that the dCDN has dCDN to identify the appropriate uCDN. The dCDN may narrow the set
established a business relationship with each of its uCDNs, assume of viable uCDNs by examining the CDNI metadata from each to determine
that the dCDN can trust any uCDN to acquire the content. The dCDN which uCDNs are hosting metadata for the requested content. If there
may narrow the set of viable uCDNs by examining the CDNI metadata is a single uCDN hosting metadata for the requested content, the dCDN
from each to determine which uCDNs are hosting metadata for the can assume that the request redirection is coming from this uCDN and
requested content. can acquire content from that uCDN. If there are multiple uCDNs
hosting metadata for the requested content, the dCDN may be ready to
trust any of these uCDNs to acquire the content (provided the uCDN is
in a position to serve it). If the dCDN is not ready to trust any of
these uCDNs, it needs to ensure via out of band arrangements that,
for a given content, only a single uCDN will ever redirect requests
to the dCDN.
Content acquisition may be preceded by content metadata acquisition. Content acquisition may be preceded by content metadata acquisition.
If possible, the acquisition path for metadata should also follow the If possible, the acquisition path for metadata should also follow the
redirection path. Additionally, metadata must be indexed based on redirection path. Additionally, we assume metadata is indexed based
rewritten URIs in the case of HTTP-redirection and must be indexed on rewritten URIs in the case of HTTP-redirection and is indexed
based on published URIs in the case of DNS-redirection. Thus, the based on published URIs in the case of DNS-redirection. Thus, the
request routing interface and the metadata interface are tightly c Request Routing Interface and the Metadata Interface are tightly
coupled in that the result of request routing (a rewritten URI coupled in that the result of request routing (a rewritten URI
pointing to the dCDN) must serve as a input to metadata lookup. If pointing to the dCDN) serves as an input to metadata lookup. If the
the content metadata includes information for acquiring the content, content metadata includes information for acquiring the content, then
then the metadata interface is also tightly coupled with the the Metadata Interface is also tightly coupled with the acquisition
acquisition interface in that the result of the metadata lookup (an interface in that the result of the metadata lookup (an acquisition
acquisition URL likely hosted by the uCDN) should serve as input to URL likely hosted by the uCDN) should serve as input to the content
the content acquisition. acquisition.
4. Main Interfaces 4. Main Interfaces
Figure 1 illustrates the four main interfaces that are in scope for Figure 1 illustrates the four main interfaces that are in scope for
the CDNI WG, along with several others. The detailed specifications the CDNI WG, along with several others. The detailed specifications
of these interfaces are left to other documents (mostly still to be of these interfaces are left to other documents, but see RFC 6707 and
written, but see [I-D.ietf-cdni-problem-statement] and [I-D.ietf-cdni-requirements] for some discussion of the interfaces.
[I-D.ietf-cdni-requirements] for some discussion of the interfaces).
One interface that is not shown in Figure 1 is the interface between One interface that is not shown in Figure 1 is the interface between
the user and the CSP. While for the purposes of CDNI that interface the user and the CSP. While for the purposes of CDNI that interface
is out of scope, it is worth noting that it does exist and can is out of scope, it is worth noting that it does exist and can
provide useful functions, such as end-to-end performance monitoring provide useful functions, such as end-to-end performance monitoring
and some forms of authentication and authorization. and some forms of authentication and authorization.
There is also an important interface between the user and the Request There is also an important interface between the user and the Request
Routing function of both uCDN and dCDN. As we saw in some of the Routing function of both uCDN and dCDN (shown as the "Request"
preceding examples, that interface can be used as a way of passing Interface in Figure 1). As we saw in some of the preceding examples,
information such as the metadata that is required to obtain the that interface can be used as a way of passing information a subset
content in dCDN from uCDN. of metadata such as the minimum information that is required for dCDN
to obtain the content from uCDN.
In this section we will provide an overview of the functions In this section we will provide an overview of the functions
performed by each of the CDNI interfaces and discuss how they fit performed by each of the CDNI interfaces and discuss how they fit
into the overall solution. We also examine some of the design into the overall solution. We also examine some of the design
tradeoffs. We begin with an examination of one such tradeoff that tradeoffs. We begin with an examination of one such tradeoff that
affects all the interfaces - the use of in-band or out-of-band affects all the interfaces - the use of in-band or out-of-band
communication. communication.
4.1. In-Band versus Out-of-Band Interfaces 4.1. In-Band versus Out-of-Band Interfaces
skipping to change at page 38, line 17 skipping to change at page 37, line 50
it conditional: if the requested object has not been modified since it conditional: if the requested object has not been modified since
the time specified in this field, a copy of the object will not be the time specified in this field, a copy of the object will not be
returned, and instead, a 304 (not modified) response will be returned, and instead, a 304 (not modified) response will be
returned. returned.
4.2. Cross Interface Concerns 4.2. Cross Interface Concerns
Although the CDNI interfaces are largely independent, there are a set Although the CDNI interfaces are largely independent, there are a set
of conventions practiced consistently across all interfaces. Most of conventions practiced consistently across all interfaces. Most
important among these is how resources are named, for exampmle, how important among these is how resources are named, for exampmle, how
the Metadata and Control interfaces identify the set of resources to the Metadata and Control Interfaces identify the set of resources to
which a given directive applies, or the Logging interface identifies which a given directive applies, or the Logging Interface identifies
the set of resources for which a summary record applies. the set of resources for which a summary record applies.
While in the the limit the CDNI interfaces could explicitly identify While in the limit the CDNI interfaces could explicitly identify
every individual resource, in practice, they name resource aggregates every individual resource, in practice, they name resource aggregates
(sets of URIs) that are to be treated in a similar way. For example, (sets of URIs) that are to be treated in a similar way. For example,
URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at
the beginning of a URI) or by a URI-Filter (i.e., a regular the beginning of a URI) or by a URI-Filter (i.e., a regular
expression that matches a subset of URIs contained in some CDN- expression that matches a subset of URIs contained in some CDN-
Doman). In other words, CDN-Domains and URI-Filters provide a 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 Interface 4.3. Request Routing Interface
We may think of the request routing interface as comprising two The Request Routing Interface comprises two parts: the asynchronous
parts: the asynchronous advertisement of footprint and capabilities interface used by a dCDN to advertize footprint and capabilities
by a dCDN that allows a uCDN to decide whether to redirect particular (denoted FCI) to a uCDN, allowing the uCDN to decide whether to
user requests to that dCDN; and the synchronous operation of actually redirect particular user requests to that dCDN; and the synchronous
redirecting a user request. (These are somewhat analogous to the interface used by the uCDN to redirect a user request to the dCDN
operations of routing and forwarding in IP.) (denoted RI). (These are somewhat analogous to the operations of
routing and forwarding in IP.)
As illustrated in Section 3, the synchronous part of the request As illustrated in Section 3, the RI part of request routing may be
routing interface may be implemented in part by DNS and HTTP. Naming implemented in part by DNS and HTTP. Naming conventions may be
conventions may be established by which CDN peers communicate whether established by which CDN peers communicate whether a request should
a request should be routed or content served. be routed or content served.
In support of these exchanges, it is necessary for CDN peers to We also note that RI plays a key role in enabling recursive
exchange additional information with each other. Depending on the redirection, as illustrated in Section 3.3. It enables the user to
method(s) supported, this includes be redirected to the correct delivery node in dCDN with only a single
redirection step (as seen by the user). This may be particularly
valuable as the chain of interconnected CDNs increases beyond two
CDNs.
o The operator's unique id (operator-id) or distinguished CDN-domain In support of these redirection requests, it is necessary for CDN
peers to exchange additional information with each other, and this is
the role of the FCI part of request routing. Depending on the
method(s) supported, this might includes
o The operator's unique id (operator-id) or distinguished CDN-Domain
(operator-domain); (operator-domain);
o NS records for the operator's set of externally visible request o NS records for the operator's set of externally visible request
routers; routers;
o The set of requests the dCDN operator is prepared to serve (e.g. a o The set of requests the dCDN operator is prepared to serve (e.g. a
set of client IP prefixes or geographic regions that may be served set of client IP prefixes or geographic regions that may be served
by dCDN). by dCDN).
Of these, the two operator identifiers are fixed, and can be o Additional capabilities of the dCDN, such as its ability to
exchanged off-line as part of a peering agreement. The NS records support different CDNI Metadata requests.
potentially change with some frequency, but an existing protocol--
DNS--can be used to dynamically track this information. That is, a
peer can do a DNS lookup on operator-domain to retrieve the set of NS
records corresponding to the peer's redirection service.
The set of requests that dCDN is willing to serve could in some cases
be relatively static (e.g., a set of IP prefixes) which could be
exchanged off-line, or might even be negotiated as part of a peering
agreement. However, it may also be more dynamic, in which case an
explicit protocol for its exchange would be be helpful.
A variety of options exist for the dCDN operator to advertise its
footprint to uCDN. As discussed in
[I-D.previdi-cdni-footprint-advertisement], footprint is comprised of
two components:
o a class of end user requests (represented, for example, by a set
of IP prefixes, or a geographic region) that the dCDN is willing
and able to serve directly, without use of another dCDN;
o the connectivity of the dCDN to other CDNs that may be able to
serve content to users on behalf of dCDN.
[I-D.previdi-cdni-footprint-advertisement] describes an approach to
advertising such footprint information asynchronously using BGP. In
addition to this sort of information, a dCDN might also advertise
"capabilities" such as the ability to handle certain types of content
(e.g. specific streaming formats) or quality of service (QoS)
capabilities. [I-D.xiaoyan-cdni-request-routing-protocol] describes
an approach that exchanges CDN "capabilities" over HTTP, while
[I-D.seedorf-alto-for-cdni] describes how ALTO [RFC5693] may be used
to obtain request routing information.
We also note that the Request Routing interface plays a key role in
enabling recursive redirection, as illustrated in Section 3.3. It
enables the user to be redirected to the correct delivery node in
dCDN with only a single redirection step (as seen by the user). This
may be particularly valuable as the chain of interconnected CDNs
increases beyond two CDNs.
One final issue is how HTTP adaptive streaming impacts the Request Note that the set of requests that dCDN is willing to serve could in
Routing interface, and in particular, the interplay between the some cases be relatively static (e.g., a set of IP prefixes) which
request router and manifest files, which may contain either absolute could be exchanged off-line, or might even be negotiated as part of a
or relative URLs. These issues are discussed in more detail in peering agreement. However, it may also be more dynamic, in which
[I-D.brandenburg-cdni-has]. case the exchange supported by FCI would be be helpful. A further
discussion of the Footprint & Capability Advertisement Interface can
be found in [I-D.spp-cdni-rr-foot-cap-semantics].
4.4. Logging Interface 4.4. Logging Interface
It is necessary for the upstream CDN to have visibility into the It is necessary for the upstream CDN to have visibility into the
delivery of content it originates to end-users connected to the delivery of content that it redirected to a downstream CDN. This
downstream CDN. This allows the upstream CDN to properly bill its allows the upstream CDN to properly bill its customers for multiple
customers for multiple deliveries of content cached by the downstream deliveries of content cached by the downstream CDN, as well as to
CDN, as well as to report accurate traffic statistics to those report accurate traffic statistics to those content providers. This
content providers. This is one role of the Logging interface. is one role of the Logging Interface.
Other operational data that may be relevant to CDNI can also be Other operational data that may be relevant to CDNI can also be
exchanged by the Logging interface. For example, dCDN may report the exchanged by the Logging Interface. For example, dCDN may report the
amount of content it has acquired from uCDN, and how much cache amount of content it has acquired from uCDN, and how much cache
storage has been consumed by content cached on behalf of uCDN. storage has been consumed by content cached on behalf of uCDN.
Traffic logs are easily exchanged off-line. For example, the Traffic logs are easily exchanged off-line. For example, the
following traffic log is a small deviation from the Apache log file following traffic log is a small deviation from the Apache log file
format, where entries include the following fields: format, where entries include the following fields:
o Domain - the full domain name of the origin server o Domain - the full domain name of the origin server
o IP address - the IP address of the client making the request o IP address - the IP address of the client making the request
skipping to change at page 40, line 46 skipping to change at page 40, line 4
o Method - the transfer command itself (e.g., GET, POST, HEAD) o Method - the transfer command itself (e.g., GET, POST, HEAD)
o URL - the requested URL o URL - the requested URL
o Version - the protocol version, such as HTTP/1.0 o Version - the protocol version, such as HTTP/1.0
o Response - a numeric response code indicating transfer result o Response - a numeric response code indicating transfer result
o Bytes Sent - the number of bytes in the body sent to the client o Bytes Sent - the number of bytes in the body sent to the client
o Request ID - a unique identifier for this transfer o Request ID - a unique identifier for this transfer
o User agent - the user agent, if supplied o User agent - the user agent, if supplied
o Duration - the duration of the transfer in milliseconds o Duration - the duration of the transfer in milliseconds
o Cached Bytes - the number of body bytes served from the cache o Cached Bytes - the number of body bytes served from the cache
o Referrer - the referrer string from the client, if supplied o Referrer - the referrer string from the client, if supplied
Of these, only the Domain field is indirect in the downstream CDN--it Of these, only the Domain field is indirect in the downstream CDN--it
is set to the CDN-domain used by the upstream CDN rather than the is set to the CDN-Domain used by the upstream CDN rather than the
actual origin server. This field could then used to filter traffic actual origin server. This field could then used to filter traffic
log entries so only those entries matching the upstream CDN are log entries so only those entries matching the upstream CDN are
reported to the corresponding operator. Further discussion of the reported to the corresponding operator. Further discussion of the
Logging interface can be found in [I-D.bertrand-cdni-logging] and Logging Interface can be found in [I-D.bertrand-cdni-logging].
[I-D.lefaucheur-cdni-logging-delivery].
One open question is who does the filtering. One option is that the One open question is who does the filtering. One option is that the
downstream CDN filters its own logs, and passes the relevant records downstream CDN filters its own logs, and passes the relevant records
directly to each upstream peer. This requires that the downstream directly to each upstream peer. This requires that the downstream
CDN knows the set of CDN-domains that belong to each upstream peer. CDN knows the set of CDN-Domains that belong to each upstream peer.
If this information is already exchanged between peers as part of the If this information is already exchanged between peers as part of
request routing interface, then direct peer-to-peer reporting is another interface, then direct peer-to-peer reporting is
straightforward. If it is not available, and operators do not wish straightforward. If it is not available, and operators do not wish
to advertise the set of CDN-domains they serve to their peers, then to advertise the set of CDN-Domains they serve to their peers, then
the second option is for each CDN to send both its non-local traffic the second option is for each CDN to send both its non-local traffic
records and the set of CDN-domains it serves to an independent third- records and the set of CDN-Domains it serves to an independent third-
party (i.e., a CDN Exchange), which subsequently filters, merges, and party (i.e., a CDN Exchange), which subsequently filters, merges, and
distributes traffic records on behalf of each participating CDN distributes traffic records on behalf of each participating CDN
operator. operator.
A second open question is how timely traffic information should be. A second open question is how timely traffic information should be.
For example, in addition to off-line traffic logs, accurate real-time For example, in addition to off-line traffic logs, accurate real-time
traffic monitoring might also be useful, but such information traffic monitoring might also be useful, but such information
requires that the downstream CDN inform the upstream CDN each time it requires that the downstream CDN inform the upstream CDN each time it
serves upstream content from its cache. The downstream CDN can do serves upstream content from its cache. The downstream CDN can do
this, for example, by sending a conditional HTTP GET request (If- this, for example, by sending a conditional HTTP GET request (If-
Modified-Since) to the upstream CDN each time it receives an HTTP GET Modified-Since) to the upstream CDN each time it receives an HTTP GET
request from one of its end-users. This allows the upstream CDN to request from one of its end-users. This allows the upstream CDN to
record that a request has been issued for the purpose of real-time record that a request has been issued for the purpose of real-time
traffic monitoring. The upstream CDN can also use this information traffic monitoring. The upstream CDN can also use this information
to validate the traffic logs received later from the downstream CDN. to validate the traffic logs received later from the downstream CDN.
There is obviously a tradeoff between accuracy of such monitoring and There is obviously a tradeoff between accuracy of such monitoring and
the overhead of the downstream CDN having to go back to the upstream the overhead of the downstream CDN having to go back to the upstream
CDN for every request. CDN for every request.
Another design tradeoff in the Logging interface is the degree of Another design tradeoff in the Logging Interface is the degree of
aggregation or summarization of data. One situation that lends aggregation or summarization of data. One situation that lends
itself to summarization is the delivery of HTTP-based adaptive bit- itself to summarization is the delivery of HTTP adaptive streaming
rate video. Most schemes to deliver such video use a large number of (HAS), since the large number of individual chunk requests
relatively small HTTP requests (e.g. one request per two-second chunk potentially results in large volumes of logging information. This
of video.) It may be desirable to aggregate logging information so case is discussed below, but other forms of aggregation may also be
that a single log entry is provided for the entire video rather than useful. For example, there may be situations where bulk metrics such
for each chunk. Note however that such aggregation requires a degree as bytes delivered per hour may suffice rather than the detailed per-
of application awareness in dCDN to recognize that the many HTTP request logs outlined above. It seems likely that a range of
requests correspond to a single video. The implications of HTTP granularities of logging will be needed along with ways to specify
adaptive streaming are discussed further in the type and degree of aggregation required.
[I-D.brandenburg-cdni-has].
Other forms of aggregation may also be useful. For example, there
may be situations where bulk metrics such as bytes delivered per hour
may suffice rather than the detailed per-request logs outlined above.
It seems likely that a range of granularities of logging will be
needed along with ways to specify the type and degree of aggregation
required.
4.5. Control Interface 4.5. Control Interface
The control interface is initially used to bootstrap the other The 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 logging interface. It may also be used, for example, to the 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 Control interface plays is to allow the uCDN to The other role the Control Interface plays is to allow the uCDN to
pre-position, revalidate, or purge metadata and content on a dCDN. pre-position, revalidate, or purge metadata and content on a dCDN.
These operations, sometimes collectively called the trigger These operations, sometimes collectively called the trigger
interface, are discussed further in [I-D.murray-cdni-triggers]. interface, are discussed further in [I-D.murray-cdni-triggers].
4.6. Metadata Interface 4.6. Metadata Interface
The role of the metadata interface is to enable CDNI distribution The role of the CDNI Metadata Interface is to enable CDNI
metadata to be conveyed to the downstream CDN by the upstream CDN. distribution metadata to be conveyed to the downstream CDN by the
For example, see [I-D.ma-cdni-metadata] and upstream CDN. For example, see [I-D.ietf-cdni-metadata]. Such
[I-D.cjlmw-cdni-metadata]. Such metadata includes geo-blocking metadata includes geo-blocking restrictions, availability windows,
restrictions, availability windows, access control policies, and so access control policies, and so on. It may also include information
on. It may also include policy information such as the desire to to facilitate acquisition of content by dCDN (e.g., alternate sources
pre-position content rather than fetch it on demand. for the content, authorization information needed to acquire the
content from the source).
Some metadata may be able to be conveyed using in-band mechanisms. Some distribution metadata may be partially emulated using in-band
For example, to inform the downstream CDN of any geo-blocking mechanisms. For example, in case of any geo-blocking restrictions or
restrictions or availability windows, the upstream can elect to availability windows, the upstream CDN can elect to redirect a
redirect a request to the downstream CDN only if that CDN's request to the downstream CDN only if that CDN's advertised delivery
advertised delivery footprint is acceptable for the requested URL. footprint is acceptable for the requested URL. Similarly, the
Similarly, the request could be forwarded only if the current time is request could be forwarded only if the current time is within the
within the availability window. availability window. However, such approaches typically come with
shortcomings such as inability to prevent from replay outside the
time window or inability to make use of a downstream CDN that covers
a broader footprint than the geo-blocking restrictions.
Similarly, some forms of access control may also be performed on a Similarly, some forms of access control may also be performed on a
per-request basis using HTTP directives. For example, being able to per-request basis using HTTP directives. For example, being able to
respond to a conditional GET request gives the upstream CDN an respond to a conditional GET request gives the upstream CDN an
opportunity to influence how the downstream CDN delivers its content. opportunity to influence how the downstream CDN delivers its content.
Minimally, the upstream CDN can invalidate (purge) content previously Minimally, the upstream CDN can invalidate (purge) content previously
cached by the downstream CDN. cached by the downstream CDN.
Fine-grain control over how the downstream CDN delivers content on Fine-grain control over how the downstream CDN delivers content on
behalf of the upstream CDN is also possible. For example, by behalf of the upstream CDN is also possible. For example, by
including the X-Forwarded-For HTTP header with the conditional GET including the X-Forwarded-For HTTP header with the conditional GET
request, the downstream CDN can report the end-user's IP address to request, the downstream CDN can report the end-user's IP address to
the upstream CDN, giving it an opportunity to control whether the the upstream CDN, giving it an opportunity to control whether the
downstream CDN should serve the content to this particular end-user. downstream CDN should serve the content to this particular end-user.
The upstream CDN would communicate its directive through its response The upstream CDN would communicate its directive through its response
to the conditional GET. The downstream CDN can cache information for to the conditional GET. The downstream CDN can cache information for
a period of time specified by the upstream CDN, thereby reducing a period of time specified by the upstream CDN, thereby reducing
control overhead. control overhead.
All of these in-band techniques serve to illustrate that uCDNs have All of these in-band techniques serve to illustrate that uCDNs have
the option of enforcing their access control policies themselves, the option of enforcing some of their access control policies
themselves (at the expense of increased inter-CDN signaling load),
rather than delegating enforcement to dCDNs using the Metadata rather than delegating enforcement to dCDNs using the Metadata
interface. As a consequence, the Metadata interface must provide a Interface. As a consequence, the Metadata Interface should provide a
means for the uCDN to express this its desire to retain enforcement means for the uCDN to express its desire to retain enforcement for
for itself. For example, this might be done by including a "check itself. For example, this might be done by including a "check with
with me" flag in the metadata associated with certain content. me" flag in the metadata associated with certain content.
4.7. HTTP Adaptive Streaming Concerns
We consider HTTP Adaptive Streaming (HAS) and the impact it has on
the CDNI interfaces because large objects (e.g., videos) are broken
into a sequence of small, independent chunks. For each of the
following, a more thorough discussion, including an overview of the
tradeoffs involved in alternative designs, can be found in
[I-D.brandenburg-cdni-has].
First, with respect to Content Acquisition and File Management, which
are out-of-scope for the CDNI interfaces but nontheless relevant to
the overall operation, we assume no additional measures are required
to deal with large numbers of chunks. This means that the dCDN is
not explicitly made aware of any relationship between different
chunks and the dCDN handles each chunk as if it were an individual
and independent content item. The result is that content acquisition
between uCDN and dCDN also happens on a per-chunk basis. This
approach is in line with the recommendations made in
[I-D.brandenburg-cdni-has], which also identifies potential
improvements in this area that might be considered in the future.
Second, with respect to Request Routing, we note that HAS manifest
files have the potential to interfere with request routing since
manifest files contain URLs pointing to the location of content
chunks. To make sure that a manifest file does not hinder CDNI
request routing and does not place excessive load on CDNI resources,
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
approach for dealing with these issues is twofold. As a mandatory
requirement, CDNs should be able to handle unmodified manifest files
containing either relative or absolute URLs. To limit the number of
redirects, and thus the load placed on the CDNI Interfaces, as an
optional feature uCDNs can use the information obtained through the
CNDI Request Routing Redirection Interface to modify the URLs in the
manifest file. Since the modification of the manifest file is an
optional uCDN-internal process, this does not require any
standardization effort beyond being able to communicate chunk
locations in the CDNI Request Routing Redirection Interface.
Third, with respect to the Logging Interface, there are several
potential issues, including the large number of individual chunk
requests potentially resulting in large volumes of logging
information, and the desire to correlate logging information for
chunk requests that correspond to the same HAS session. For the
initial CDNI specification, our approach is to expect participating
CDNs to support per-chunk logging (e.g. logging each chunk request as
if it were an independent content request) over the CDNI Logging
Interface. Optionally, the Logging Interface may include a Content
Collection IDentifier (CCID) and/or a Session IDentifier (SID) as
part of the logging fields, thereby facilitating correlation of per-
chunk logs into per-session logs for applications benefiting from
such session level information (e.g. session-based analytics). This
approach is in line with the recommendations made in
[I-D.brandenburg-cdni-has], which also identifies potential
improvements in this area that might be considered in the future.
Fourth, with respect to the Control Interface, and in particular
purging HAS chunks from a given CDN, our approach is to expect each
CDN supports per-chunk content purge (e.g. purging of chunks as if
they were individual content items). Optionally, a CDN may support
content purge on the basis of a "Purge IDentifier (Purge-ID)"
allowing the removal of all chunks related to a given Content
Collection with a single reference. It is possible that this
Purge-ID could be merged with the CCID discussed above for HAS
Logging, or alternatively, they may remain distinct.
5. Deployment Models 5. Deployment Models
In this section we describe a number of possible deployment models In this section we describe a number of possible deployment models
that may be achieved using the CDNI interfaces described above. We that may be achieved using the CDNI interfaces described above. We
note that these models are by no means exhaustive, and that may other note that these models are by no means exhaustive, and that many
models may be possible. other models may be possible.
Although the reference model of Figure 1 shows all CDN functions on Although the reference model of Figure 1 shows all CDN functions on
each side of the CDNI interface, deployments can rely on entities each side of the CDNI interface, deployments can rely on entities
that are involved in any subset of these functions, and therefore that are involved in any subset of these functions, and therefore
only support the relevant subset of CDNI interfaces. As already only support the relevant subset of CDNI interfaces. As already
noted in Section 3, effective CDNI deployments can be built without noted in Section 3, effective CDNI deployments can be built without
necessarily implementing all four interfaces. Some examples of such necessarily implementing all four interfaces. Some examples of such
deployments are shown below. deployments are shown below.
Note that, while we refer to upstream and downstream CDNs, this Note that, while we refer to upstream and downstream CDNs, this
skipping to change at page 45, line 45 skipping to change at page 46, line 45
Figure 12: CDNI Deployment Model: Organization combining CSP & uCDN Figure 12: CDNI Deployment Model: Organization combining CSP & uCDN
5.3. CSP using CDNI Request Routing Interface 5.3. CSP using CDNI Request Routing Interface
As another example, a content provider organization may choose to run As another example, a content provider organization may choose to run
its own request routing function as a way to select among multiple its own request routing function as a way to select among multiple
candidate CDN providers; In this case the content provider may be candidate CDN providers; In this case the content provider may be
modeled as the combination of a CSP and of a special, restricted case modeled as the combination of a CSP and of a special, restricted case
of a CDN. In that case, as illustrated in Figure 13, the CDNI of a CDN. In that case, as illustrated in Figure 13, the CDNI
Request Routing interface can be used between the restricted CDN Request Routing Interfaces can be used between the restricted CDN
operated by the content provider Organization and the CDN operated by operated by the content provider Organization and the CDN operated by
the full-CDN organization acting as a dCDN in the request routing the full-CDN organization acting as a dCDN in the request routing
control plane. Interfaces outside the scope of the CDNI work can be control plane. Interfaces outside the scope of the CDNI work can be
used between the CSP functional entities of the content provider used between the CSP functional entities of the content provider
organization and the CDN operated by the full-CDN organization acting organization and the CDN operated by the full-CDN organization acting
as a uCDN) in the CDNI control planes other than the request routing as a uCDN) in the CDNI control planes other than the request routing
plane (i.e. Control, Distribution, Logging). plane (i.e. Control, Distribution, Logging).
##################################### ################## ##################################### ##################
# # # # # # # #
skipping to change at page 46, line 30 skipping to change at page 47, line 30
# | | # # | | L | | # # | | # # | | L | | #
# | | # # | +----+ | # # | | # # | +----+ | #
# | | # # | +----+ | # # | | # # | +----+ | #
# | | # # | | D | | # # | | # # | | D | | #
# | | # # | +----+ | # # | | # # | +----+ | #
# \ / # # \ / # # \ / # # \ / #
# -------- # # ----------- # # -------- # # ----------- #
# # # # # # # #
##################################### ################## ##################################### ##################
===> CDNI Request Routing interface ===> CDNI Request Routing Interface
**** interfaces outside the scope of CDNI **** interfaces outside the scope of CDNI
Figure 13: CDNI Deployment Model: Organization combining CSP and Figure 13: CDNI Deployment Model: Organization combining CSP and
partial CDN partial CDN
5.4. CDN Federations and CDN Exchanges 5.4. CDN Federations and CDN Exchanges
There are two additional concepts related to, but distinct from CDN There are two additional concepts related to, but distinct from CDN
Interconnection. The first is CDN Federation. Our view is that CDNI Interconnection. The first is CDN Federation. Our view is that CDNI
is the more general concept, involving two or more CDNs serving is the more general concept, involving two or more CDNs serving
skipping to change at page 47, line 16 skipping to change at page 48, line 16
illustrated in Figure 14, the exchange might aggregate and illustrated in Figure 14, the exchange might aggregate and
redistribute information about each CDN footprint and capacity, as redistribute information about each CDN footprint and capacity, as
well as collect, filter, and re-distribute traffic logs that each well as collect, filter, and re-distribute traffic logs that each
participant needs for interconnection settlement, but inter-CDN participant needs for interconnection settlement, but inter-CDN
request routing, inter-CDN content distribution (including inter-CDN request routing, inter-CDN content distribution (including inter-CDN
acquisition) and inter-CDN control which fundamentally involve a acquisition) and inter-CDN control which fundamentally involve a
direct interaction between an upstream CDN and a downstream CDN-- direct interaction between an upstream CDN and a downstream CDN--
operate exactly as in a pair-wise peering arrangement. Turning to operate exactly as in a pair-wise peering arrangement. Turning to
Figure 14, we observe that in this example: Figure 14, we observe that in this example:
o each CDN supports a direct CDNI Control interface to every other o each CDN supports a direct CDNI Control Interface to every other
CDN CDN
o each CDN supports a direct CDNI Metadata interface to every other o each CDN supports a direct CDNI Metadata Interface to every other
CDN CDN
o each CDN supports a CDNI Logging interface with the CDN Exchange o each CDN supports a CDNI Logging Interface with the CDN Exchange
o each CDN supports both a CDNI request Routing interface with the o each CDN supports both a CDNI Request Routing Interface with the
CDN Exchange (for aggregation and redistribution of dynamic CDN CDN Exchange (for aggregation and redistribution of dynamic CDN
footprint discovery information) and a direct CDNI Request Routing footprint discovery information) and a direct CDNI Request Routing
interface to every other CDN (for actual request redirection). Interface to every other CDN (for actual request redirection).
---------- --------- ---------- ---------
/ CDN A \ / CDN B \ / CDN A \ / CDN B \
| +----+ | | +----+ | | +----+ | | +----+ |
//========>| C |<==============CDNI============>| C |<==========\\ //========>| C |<==============CDNI============>| C |<==========\\
|| | +----+ | C | +----+ | || || | +----+ | C | +----+ | ||
|| | +----+ | | +----+ | || || | +----+ | | +----+ | ||
|| //=====>| D |<==============CDNI============>| D |<=======\\ || || //=====>| D |<==============CDNI============>| D |<=======\\ ||
|| || | +----+ | M | +----+ | || || || || | +----+ | M | +----+ | || ||
|| || | | /------------\ | | || || || || | | /------------\ | | || ||
skipping to change at page 48, line 44 skipping to change at page 49, line 44
|| || | +----+ | || || || || | +----+ | || ||
|| || | +----+ | || || || || | +----+ | || ||
|| \\=======CDNI===========>| D |<=============CDNI===========// || || \\=======CDNI===========>| D |<=============CDNI===========// ||
|| M | +----+ | M || || M | +----+ | M ||
|| | +----+ | || || | +----+ | ||
\\==========CDNI===========>| C |<=============CDNI==============// \\==========CDNI===========>| C |<=============CDNI==============//
C | +----+ | C C | +----+ | C
\ CDN C / \ CDN C /
-------------- --------------
<=CDNI RR=> CDNI Request Routing interface <=CDNI RR=> CDNI Request Routing Interface
<=CDNI M==> CDNI Metadata interface <=CDNI M==> CDNI Metadata Interface
<=CDNI C==> CDNI Control interface <=CDNI C==> CDNI Control Interface
<=CDNI L==> CDNI Logging interface <=CDNI L==> CDNI Logging Interface
Figure 14: CDNI Deployment Model: CDN Exchange Figure 14: CDNI Deployment Model: CDN Exchange
Note that a CDN exchange may alternatively support a different set of Note that a CDN exchange may alternatively support a different set of
functionality (e.g. Logging only, or Logging and full request functionality (e.g. Logging only, or Logging and full request
routing, or all the functionality of a CDN including content routing, or all the functionality of a CDN including content
distribution). All these options are expected to be allowed by the distribution). All these options are expected to be allowed by the
IETF CDNI specifications. IETF CDNI specifications.
6. Trust Model 6. Trust Model
skipping to change at page 51, line 41 skipping to change at page 52, line 41
served, simply propagating this information to peer downstream CDNs served, simply propagating this information to peer downstream CDNs
may be problematic because it reveals more information than the may be problematic because it reveals more information than the
upstream CDN is willing to specify. (To this end, the content upstream CDN is willing to specify. (To this end, the content
acquisition step in the earlier examples force the dCDN to retrieve acquisition step in the earlier examples force the dCDN to retrieve
content from the uCDN rather than go directly to the origin server.) content from the uCDN rather than go directly to the origin server.)
There are several approaches to this problem. One is for the uCDN to There are several approaches to this problem. One is for the uCDN to
encoded a signed token generated from a shared secret in each URL encoded a signed token generated from a shared secret in each URL
routed to a dCDN, and for the dCDN to validate the request based on routed to a dCDN, and for the dCDN to validate the request based on
this token. Another one is to have each upstream CDN advertise the this token. Another one is to have each upstream CDN advertise the
set of CDN-domains they serve, where the downstream CDN checks each set of CDN-Domains they serve, where the downstream CDN checks each
request against this set before caching and delivering the associated request against this set before caching and delivering the associated
object. Although straightforward, this approach requires operators object. Although straightforward, this approach requires operators
to reveal additional information, which may or may not be an issue. to reveal additional information, which may or may not be an issue.
8.1. Security of CDNI Interfaces 8.1. Security of CDNI Interfaces
It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces
must be able to operate securely over insecure IP networks. Since it must be able to operate securely over insecure IP networks. Since it
is expected that the CDNI interfaces will be implemented using is expected that the CDNI interfaces will be implemented using
existing application protocols such as HTTP or XMPP, we also expect existing application protocols such as HTTP or XMPP, we also expect
skipping to change at page 52, line 16 skipping to change at page 53, line 16
will be specified in the relevant interface documents. will be specified in the relevant interface documents.
8.2. Digital Rights Management 8.2. Digital Rights Management
Issues of digital rights management (DRM, also sometimes called Issues of digital rights management (DRM, also sometimes called
digital restrictions management) is often employed for content digital restrictions management) is often employed for content
distributed via CDNs. In general, DRM relies on the CDN to distributed via CDNs. In general, DRM relies on the CDN to
distribute encrypted content, with decryption keys distributed to distribute encrypted content, with decryption keys distributed to
users by some other means (e.g. directly from the CSP to the end users by some other means (e.g. directly from the CSP to the end
user.) For this reason, DRM is considered out of scope for the CDNI user.) For this reason, DRM is considered out of scope for the CDNI
WG [I-D.ietf-cdni-problem-statement] and does not introduce WG RFC 6707 and does not introduce additional security issues for
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 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 52, line 44 skipping to change at page 53, line 46
o Kent Leung o Kent Leung
10. Acknowledgements 10. Acknowledgements
We thank Huw Jones for helpful input to the draft. We thank Huw Jones for helpful input to the draft.
11. Informative References 11. Informative References
[I-D.bertrand-cdni-logging] [I-D.bertrand-cdni-logging]
Bertrand, G. and S. Emile, "CDNI Logging Interface", Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F.,
draft-bertrand-cdni-logging-00 (work in progress), and P. Grochocki, "CDNI Logging Interface",
February 2012. draft-bertrand-cdni-logging-02 (work in progress),
October 2012.
[I-D.brandenburg-cdni-has] [I-D.brandenburg-cdni-has]
Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung, Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung,
"Models for adaptive-streaming-aware CDN Interconnection", "Models for adaptive-streaming-aware CDN Interconnection",
draft-brandenburg-cdni-has-03 (work in progress), draft-brandenburg-cdni-has-03 (work in progress),
July 2012. July 2012.
[I-D.cjlmw-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.,
and K. Leung, "CDN Interconnect Metadata", Leung, K., and K. Ma, "CDN Interconnect Metadata",
draft-cjlmw-cdni-metadata-00 (work in progress), draft-ietf-cdni-metadata-00 (work in progress),
July 2012. October 2012.
[I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", draft-ietf-cdni-problem-statement-08 (work in
progress), June 2012.
[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", Interconnection (CDNI) Requirements",
draft-ietf-cdni-requirements-03 (work in progress), draft-ietf-cdni-requirements-04 (work in progress),
June 2012. December 2012.
[I-D.ietf-cdni-use-cases] [I-D.ietf-cdni-use-cases]
Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", draft-ietf-cdni-use-cases-09 (work in Interconnection", draft-ietf-cdni-use-cases-10 (work in
progress), July 2012. 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.ma-cdni-metadata]
Ma, K., "Content Distribution Network Interconnection
(CDNI) Metadata Interface", draft-ma-cdni-metadata-03
(work in progress), July 2012.
[I-D.murray-cdni-triggers] [I-D.murray-cdni-triggers]
Murray, R. and B. Niven-Jenkins, "CDN Interconnect Murray, R. and B. Niven-Jenkins, "CDN Interconnect
Triggers", draft-murray-cdni-triggers-00 (work in Triggers", draft-murray-cdni-triggers-01 (work in
progress), February 2012. progress), August 2012.
[I-D.previdi-cdni-footprint-advertisement]
Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and
L. Faucheur, "CDNI Footprint Advertisement",
draft-previdi-cdni-footprint-advertisement-01 (work in
progress), March 2012.
[I-D.seedorf-alto-for-cdni] [I-D.seedorf-alto-for-cdni]
Seedorf, J., "ALTO for CDNi Request Routing", Seedorf, J., "ALTO for CDNi Request Routing",
draft-seedorf-alto-for-cdni-00 (work in progress), draft-seedorf-alto-for-cdni-00 (work in progress),
October 2011. October 2011.
[I-D.spp-cdni-rr-foot-cap-semantics]
Seedorf, J., Peterson, J., and S. Previdi, "CDNI Request
Routing: Footprint and Capabilities Semantics",
draft-spp-cdni-rr-foot-cap-semantics-02 (work in
progress), October 2012.
[I-D.vandergaast-edns-client-subnet] [I-D.vandergaast-edns-client-subnet]
Contavalli, C., Gaast, W., Leach, S., and E. Lewis, Contavalli, C., Gaast, W., Leach, S., and E. Lewis,
"Client subnet in DNS requests", "Client subnet in DNS requests",
draft-vandergaast-edns-client-subnet-01 (work in draft-vandergaast-edns-client-subnet-01 (work in
progress), April 2012. progress), April 2012.
[I-D.xiaoyan-cdni-request-routing-protocol]
He, X., Dawkins, S., Li, J., and G. Chen, "Request Routing
Protocol for CDN Interconnection",
draft-xiaoyan-cdni-request-routing-protocol-00 (work in
progress), October 2011.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466, for Content Internetworking (CDI)", RFC 3466,
February 2003. February 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, Optimization (ALTO) Problem Statement", RFC 5693,
October 2009. October 2009.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012.
Authors' Addresses Authors' Addresses
Larry Peterson (editor) Larry Peterson (editor)
Verivue, Inc. Akamai Technologies, Inc.
2 Technology Park Drive 8 Cambridge Center
Westford, MA Cambridge, MA 02142
USA USA
Phone: +1 978 303 8032 Email: lapeters@akamai.com
Email: lpeterson@verivue.com
Bruce Davie Bruce Davie
Nicira Networks, Inc. VMware, Inc.
3460 W. Bayshore Rd. 3401 Hillview Ave.
Palo Alto, CA 94303 Palo Alto, CA 94304
USA USA
Email: bsd@nicira.com Email: bdavie@vmware.com
 End of changes. 234 change blocks. 
629 lines changed or deleted 668 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/