draft-ietf-cdni-framework-07.txt   draft-ietf-cdni-framework-08.txt 
Network Working Group L. Peterson, Ed. Network Working Group L. Peterson, Ed.
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Obsoletes: 3466 (if approved) B. Davie Obsoletes: 3466 (if approved) B. Davie
Intended status: Informational VMware, Inc. Intended status: Informational VMware, Inc.
Expires: May 29, 2014 November 25, 2013 Expires: July 23, 2014 January 19, 2014
Framework for CDN Interconnection Framework for CDN Interconnection
draft-ietf-cdni-framework-07 draft-ietf-cdni-framework-08
Abstract Abstract
This document presents a framework for Content Distribution Network This document presents a framework for Content Distribution Network
Interconnection (CDNI). The purpose of the framework is to provide Interconnection (CDNI). The purpose of the framework is to provide
an overall picture of the problem space of CDNI and to describe the an overall picture of the problem space of CDNI and to describe the
relationships among the various components necessary to interconnect relationships among the various components necessary to interconnect
CDNs. CDN Interconnection requires the specification of interfaces CDNs. CDN Interconnection requires the specification of interfaces
and mechanisms to address issues such as request routing, and mechanisms to address issues such as request routing,
distribution metadata exchange, and logging information exchange distribution metadata exchange, and logging information exchange
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 29, 2014. This Internet-Draft will expire on July 23, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4 1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4
1.3. Structure Of This Document . . . . . . . . . . . . . . . 7 1.3. Structure Of This Document . . . . . . . . . . . . . . . 8
2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8 2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8
2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8 2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8
2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9 2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9
3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10 3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10
3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13 3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13
3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18 3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18
3.4. Iterative DNS-based Redirection Example . . . . . . 22 3.4. Iterative DNS-based Redirection Example . . . . . . 22
3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25 3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25
3.6. Content Removal Example . . . . . . . . . . . . . . . . . 26 3.6. Content Removal Example . . . . . . . . . . . . . . . . . 27
3.7. Pre-Positioned Content Acquisition Example . . . . . . . 27 3.7. Pre-Positioned Content Acquisition Example . . . . . . . 28
3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 28 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 29
3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 30 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 31
3.10. Content and Metadata Acquisition with Multiple Upstream 3.10. Content and Metadata Acquisition with Multiple Upstream
CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 34
4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 35
4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 34 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 35
4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 35 4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 36
4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 36 4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 37
4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 38 4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 39
4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 38 4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 39
4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 40
4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 40 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 42
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 41 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 43
5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 43
5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 44
5.3. CSP using CDNI Request Routing Interface . . . . . . . . 43 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 45
5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 44 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 46
6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 46 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 49
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50
8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 49 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 51
8.2. Digital Rights Management . . . . . . . . . . . . . . . . 49 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 52
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
11. Informative References . . . . . . . . . . . . . . . . . . . 50 11. Informative References . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
This document provides an overview of the various components This document provides an overview of the various components
necessary to interconnect CDNs, expanding on the problem statement necessary to interconnect CDNs, expanding on the problem statement
and use cases introduced in RFCs 6770 and 6707. It describes the and use cases introduced in [RFC6770] and [RFC6707]. It describes
necessary interfaces and mechanisms in general terms and outlines how the necessary interfaces and mechanisms in general terms and outlines
they fit together to form a complete system for CDN Interconnection. how they fit together to form a complete system for CDN
Detailed specifications are left to other documents. This document Interconnection. Detailed specifications are left to other
makes extensive use of message flow examples to illustrate the documents. This document makes extensive use of message flow
operation of interconnected CDNs, but these examples should be examples to illustrate the operation of interconnected CDNs, but
considered illustrative rather than prescriptive. these examples should be considered illustrative rather than
prescriptive.
RFC 3466 uses different terminology and models for "Content [RFC3466] uses different terminology and models for "Content
Internetworking (CDI)". It is also less prescriptive in terms of Internetworking (CDI)". It is also less prescriptive in terms of
interfaces. To avoid confusion, this document obsoletes RFC 3466. interfaces. To avoid confusion, this document obsoletes [RFC3466].
1.1. Terminology 1.1. Terminology
This document uses the core terminology defined in RFC 6707. It also This document uses the core terminology defined in [RFC6707]. It
introduces the following terms: also introduces the following terms:
CDN-Domain: a host name (FQDN) at the beginning of a URL, CDN-Domain: a host name (FQDN) at the beginning of a URL,
representing a set of content that is served by a given CDN. For representing a set of content that is served by a given CDN. For
example, in the URL http://cdn.csp.com/...rest of url..., the CDN example, in the URL http://cdn.csp.example/...rest of url..., the CDN
domain is cdn.csp.com. A major role of CDN-Domain is to identify a domain is cdn.csp.example. A major role of CDN-Domain is to identify
region (subset) of the URI space relative to which various CDN a region (subset) of the URI space relative to which various CDN
Interconnection rules and policies are to apply. For example, a Interconnection rules and policies are to apply. For example, a
record of CDN Metadata might be defined for the set of resources record of CDN Metadata might be defined for the set of resources
corresponding to some CDN-Domain. corresponding to some CDN-Domain.
Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for
the purposes of communication with a peer CDN, but which is not found the purposes of communication with a peer CDN, but which is not found
in client requests. Such CDN-Domains may be used for inter-CDN in client requests. Such CDN-Domains may be used for inter-CDN
acquisition, or as redirection targets, and enable a CDN to acquisition, or as redirection targets, and enable a CDN to
distinguish a request from a peer CDN from an end-user request. distinguish a request from a peer CDN from an end-user request.
skipping to change at page 4, line 45 skipping to change at page 4, line 48
includes operations to pre-position, revalidate, and purge both includes operations to pre-position, revalidate, and purge both
metadata and content. These operations are typically called in metadata and content. These operations are typically called in
response to some action (Trigger) by the CSP on the upstream CDN. response to some action (Trigger) by the CSP on the upstream CDN.
We also sometimes use uCDN and dCDN as shorthand for upstream CDN and We also sometimes use uCDN and dCDN as shorthand for upstream CDN and
downstream CDN, respectively. downstream CDN, respectively.
1.2. Reference Model 1.2. Reference Model
This document uses the reference model in Figure 1, which expands the This document uses the reference model in Figure 1, which expands the
reference model originally defined in RFC 6707. (The difference is reference model originally defined in [RFC6707]. (The difference is
that the expanded model splits the Request Routing Interface into its that the expanded model splits the Request Routing Interface into its
two distinct parts: the Request Routing Redirection interface and the two distinct parts: the Request Routing Redirection interface and the
Footprint and Capabilities Advertisement interface, as described Footprint and Capabilities Advertisement interface, as described
below.) below.)
-------- --------
/ \ / \
| CSP | | CSP |
\ / \ /
-------- --------
* *
skipping to change at page 6, line 17 skipping to change at page 6, line 17
new protocols for those interfaces) we still need to refer to them in new protocols for those interfaces) we still need to refer to them in
this document to explain the overall operation of CDNI. this document to explain the overall operation of CDNI.
We also note that, while we generally show only one upstream CDN We also note that, while we generally show only one upstream CDN
serving a given CSP, it is entirely possible that multiple uCDNs can serving a given CSP, it is entirely possible that multiple uCDNs can
serve a single CSP. In fact, this situation effectively exists today serve a single CSP. In fact, this situation effectively exists today
in the sense that a single CSP can currently delegate its content in the sense that a single CSP can currently delegate its content
delivery to more than one CDN. delivery to more than one CDN.
The following briefly describes the five CDNI interfaces, The following briefly describes the five CDNI interfaces,
paraphrasing the definitions given in RFC 6707. We discuss these paraphrasing the definitions given in [RFC6707]. We discuss these
interfaces in more detail in Section 4. interfaces in more detail in Section 4.
o CDNI Control interface (CI): Operations to bootstrap and o CDNI Control interface (CI): Operations to bootstrap and
parameterize the other CDNI interfaces, as well as operations to parameterize the other CDNI interfaces, as well as operations to
pre-position, revalidate, and purge both metadata and content. pre-position, revalidate, and purge both metadata and content.
The latter subset of operations is sometimes collectively called The latter subset of operations is sometimes collectively called
the "Trigger interface." the "Trigger interface."
o CDNI Request Routing interface: Operations to determine what CDN o CDNI Request Routing interface: Operations to determine what CDN
(and optionally what surrogate within a CDN) is to serve end- (and optionally what surrogate within a CDN) is to serve end-
skipping to change at page 7, line 49 skipping to change at page 7, line 49
synchronizing updates to metadata with end-user requests that are synchronizing updates to metadata with end-user requests that are
currently in progress (or indistinguishable from currently being in currently in progress (or indistinguishable from currently being in
progress). Clearly, a CDN will not be viewed as a trusted peer if progress). Clearly, a CDN will not be viewed as a trusted peer if
"eventually" often becomes an indefinite period of time, but the "eventually" often becomes an indefinite period of time, but the
acceptance of responsibility cannot be as crisply defined for the MI. acceptance of responsibility cannot be as crisply defined for the MI.
Finally, there is a practical issue that impacts all of the CNDI Finally, there is a practical issue that impacts all of the CNDI
interfaces, and that is whether or not to optimize CDNI for HTTP interfaces, and that is whether or not to optimize CDNI for HTTP
Adaptive Streaming (HAS). We highlight specific issues related to Adaptive Streaming (HAS). We highlight specific issues related to
delivering HAS content throughout this document, but for a more delivering HAS content throughout this document, but for a more
thorough treatment of the topic, see RFC 6983. thorough treatment of the topic, see [RFC6983].
1.3. Structure Of This Document 1.3. Structure Of This Document
The remainder of this document is organized as follows: The remainder of this document is organized as follows:
o Section 2 describes some essential building blocks for CDNI, o Section 2 describes some essential building blocks for CDNI,
notably the various options for redirecting user requests to a notably the various options for redirecting user requests to a
given CDN. given CDN.
o Section 3 provides a number of illustrative examples of various o Section 3 provides a number of illustrative examples of various
CDNI operations. CDNI operations.
o Section 4 describes the functionality of the main CDNI interfaces. o Section 4 describes the functionality of the main CDNI interfaces.
skipping to change at page 12, line 38 skipping to change at page 13, line 6
Initially, we assume that there is at least one CSP that has Initially, we assume that there is at least one CSP that has
contracted with an upstream CDN (uCDN) to deliver content on its contracted with an upstream CDN (uCDN) to deliver content on its
behalf. We are not particularly concerned with the interface between behalf. We are not particularly concerned with the interface between
the CSP and uCDN, other than to note that it is expected to be the the CSP and uCDN, other than to note that it is expected to be the
same as in the "traditional" (non-interconnected) CDN case. Existing same as in the "traditional" (non-interconnected) CDN case. Existing
mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be
used to direct a user request for a piece of content from the CSP used to direct a user request for a piece of content from the CSP
towards the CSP's chosen upstream CDN. towards the CSP's chosen upstream CDN.
We assume Operator A provides an upstream CDN that serves content on We assume Operator A provides an upstream CDN that serves content on
behalf of a CSP with CDN-Domain cdn.csp.com. We assume that Operator behalf of a CSP with CDN-Domain cdn.csp.example. We assume that
B provides a downstream CDN. An end user at some point makes a Operator B provides a downstream CDN. An end user at some point
request for URL makes a request for URL
http://cdn.csp.com/...rest of url... http://cdn.csp.example/...rest of url...
It may well be the case that cdn.csp.com is just a CNAME for some It may well be the case that cdn.csp.example is just a CNAME for some
other CDN-Domain (such as csp.op-a.net). Nevertheless, the HTTP other CDN-Domain (such as csp.op-a.example). Nevertheless, the HTTP
request in the examples that follow is assumed to be for the example request in the examples that follow is assumed to be for the example
URL above. URL above.
Our goal is to enable content identified by the above URL to be Our goal is to enable content identified by the above URL to be
served by the CDN of operator B. In the following sections we will served by the CDN of operator B. In the following sections we will
walk through some scenarios in which content is served, as well as walk through some scenarios in which content is served, as well as
other CDNI operations such as the removal of content from a other CDNI operations such as the removal of content from a
downstream CDN. downstream CDN.
3.2. Iterative HTTP Redirect Example 3.2. Iterative HTTP Redirect Example
skipping to change at page 13, line 25 skipping to change at page 13, line 37
of HTTP redirection inside uCDN and dCDN; however, this is of HTTP redirection inside uCDN and dCDN; however, this is
independent of the choice of redirection approach across CDNs, so an independent of the choice of redirection approach across CDNs, so an
alternative example could be constructed still showing HTTP alternative example could be constructed still showing HTTP
redirection from uCDN to dCDN but using DNS for handling of request redirection from uCDN to dCDN but using DNS for handling of request
inside each CDN. inside each CDN.
We assume for this example that Operators A and B have established an We assume for this example that Operators A and B have established an
agreement to interconnect their CDNs, with A being upstream and B agreement to interconnect their CDNs, with A being upstream and B
being downstream. being downstream.
The operators agree that a CDN-Domain peer-a.op-b.net will be used as The operators agree that a CDN-Domain peer-a.op-b.example will be
the target of redirections from uCDN to dCDN. We assume the name of used as the target of redirections from uCDN to dCDN. We assume the
this domain is communicated by some means to each CDN. (This could name of this domain is communicated by some means to each CDN. (This
be established out-of-band or via a CDNI interface.) We refer to could be established out-of-band or via a CDNI interface.) We refer
this domain as a "distinguished" CDN-Domain to convey the fact that to this domain as a "distinguished" CDN-Domain to convey the fact
its use is limited to the interconnection mechanism; such a domain is that its use is limited to the interconnection mechanism; such a
never used directly by a CSP. domain is never used directly by a CSP.
We assume the operators also agree on some distinguished CDN-Domain We assume the operators also agree on some distinguished CDN-Domain
that will be used for inter-CDN acquisition of CSP's content from that will be used for inter-CDN acquisition of CSP's content from
uCDN by dCDN. In this example, we'll use op-b-acq.op-a.net. uCDN by dCDN. In this example, we'll use op-b-acq.op-a.example.
We assume the operators also exchange information regarding which We assume the operators also exchange information regarding which
requests dCDN is prepared to serve. For example, dCDN may be requests dCDN is prepared to serve. For example, dCDN may be
prepared to serve requests from clients in a given geographical prepared to serve requests from clients in a given geographical
region or a set of IP address prefixes. This information may again region or a set of IP address prefixes. This information may again
be provided out of band or via a defined CDNI interface. be provided out of band or via a defined CDNI interface.
We assume DNS is configured in the following way: We assume DNS is configured in the following way:
o The content provider is configured to make operator A the o The content provider is configured to make operator A the
authoritative DNS server for cdn.csp.com (or to return a CNAME for authoritative DNS server for cdn.csp.example (or to return a CNAME
cdn.csp.com for which operator A is the authoritative DNS server). for cdn.csp.example for which operator A is the authoritative DNS
server).
o Operator A is configured so that a DNS request for o Operator A is configured so that a DNS request for
op-b-acq.op-a.net returns a request router in Operator A. op-b-acq.op-a.example returns a request router in Operator A.
o Operator B is configured so that a DNS request for peer-a.op-b.net o Operator B is configured so that a DNS request for
/cdn.csp.com returns a request router in Operator B. peer-a.op-b.example/cdn.csp.example returns a request router in
Operator B.
Figure 3 illustrates how a client request for Figure 3 illustrates how a client request for
http://cdn.csp.com/...rest of url... http://cdn.csp.example/...rest of url...
is handled. is handled.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.example | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
|IPaddr of A's Request Router | |IPaddr of A's Request Router |
|<--------------------------------------------------| |<--------------------------------------------------|
|HTTP cdn.csp.com | | |HTTP cdn.csp.example | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(2) | | |(2)
|302 peer-a.op-b.net/cdn.csp.com | |302 peer-a.op-b.example/cdn.csp.example |
|<--------------------------------------------------| |<--------------------------------------------------|
|DNS peer-a.op-b.net | | |DNS peer-a.op-b.example | |
|------------------------>| | |------------------------>| |
| |(3) | | |(3) |
|IPaddr of B's Request Router | |IPaddr of B's Request Router |
|<------------------------| | |<------------------------| |
| | | | | |
|HTTP peer-a.op-b.net/cdn.csp.com | |HTTP peer-a.op-b.example/cdn.csp.example |
|------------------------>| | |------------------------>| |
| |(4) | | |(4) |
|302 node1.peer-a.op-b.net/cdn.csp.com | |302 node1.peer-a.op-b.example/cdn.csp.example |
|<------------------------| | |<------------------------| |
|DNS node1.peer-a.op-b.net| | |DNS node1.peer-a.op-b.example |
|------------------------>| | |------------------------>| |
| |(5) | | |(5) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
| | | | | |
|HTTP node1.peer-a.op-b.net/cdn.csp.com | |HTTP node1.peer-a.op-b.example/cdn.csp.example |
|------------------------>| | |------------------------>| |
| |(6) | | |(6) |
| |DNS op-b-acq.op-a.net | | |DNS op-b-acq.op-a.example|
| |------------------------>| | |------------------------>|
| | |(7) | | |(7)
| |IPaddr of A's Request Router | |IPaddr of A's Request Router
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.example
| |------------------------>| | |------------------------>|
| | |(8) | | |(8)
| |302 node2.op-b.acq.op-A.net | |302 node2.op-b.acq.op-A.example
| |<------------------------| | |<------------------------|
| |DNS node2.op-b-acq.op-a.net | |DNS node2.op-b-acq.op-a.example
| |------------------------>| | |------------------------>|
| | |(9) | | |(9)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| | | | | |
| |HTTP node2.op-b-acq.op-a.net | |HTTP node2.op-b-acq.op-a.example
| |------------------------>| | |------------------------>|
| | |(10) | | |(10)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 3: Message Flow for Iterative HTTP Redirection Figure 3: Message Flow for Iterative HTTP Redirection
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. A DNS resolver for Operator A processes the DNS request for its 1. A DNS resolver for Operator A processes the DNS request for its
customer based on CDN-Domain cdn.csp.com. It returns the IP customer based on CDN-Domain cdn.csp.example. It returns the IP
address of a request router in Operator A. address of a request router in Operator A.
2. A Request Router for Operator A processes the HTTP request and 2. A Request Router for Operator A processes the HTTP request and
recognizes that the end-user is best served by another CDN, recognizes that the end-user is best served by another CDN,
specifically one provided by Operator B, and so it returns a 302 specifically one provided by Operator B, and so it returns a 302
redirect message for a new URL constructed by "stacking" redirect message for a new URL constructed by "stacking"
Operator B's distinguished CDN-Domain (peer-a.op-b.net) on the Operator B's distinguished CDN-Domain (peer-a.op-b.example) on
front of the original URL. (Note that more complex URL the front of the original URL. (Note that more complex URL
manipulations are possible, such as replacing the initial CDN- manipulations are possible, such as replacing the initial CDN-
Domain by some opaque handle.) Domain by some opaque handle.)
3. The end-user does a DNS lookup using Operator B's distinguished 3. The end-user does a DNS lookup using Operator B's distinguished
CDN-Domain (peer-a.op-b.net). B's DNS resolver returns the IP CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the
address of a request router for Operator B. Note that if request IP address of a request router for Operator B. Note that if
routing within dCDN was performed using DNS instead of HTTP request routing within dCDN was performed using DNS instead of
redirection, B's DNS resolver would also behave as the request HTTP redirection, B's DNS resolver would also behave as the
router and directly return the IP address of a delivery node. request router and directly return the IP address of a delivery
node.
4. The request router for Operator B processes the HTTP request and 4. The request router for Operator B processes the HTTP request and
selects a suitable delivery node to serve the end-user request, selects a suitable delivery node to serve the end-user request,
and returns a 302 redirect message for a new URL constructed by and returns a 302 redirect message for a new URL constructed by
replacing the hostname with a subdomain of the Operator B's replacing the hostname with a subdomain of the Operator B's
distinguished CDN-Domain that points to the selected delivery distinguished CDN-Domain that points to the selected delivery
node. node.
5. The end-user does a DNS lookup using Operator B's delivery node 5. The end-user does a DNS lookup using Operator B's delivery node
subdomain (node1.peer-a.op-b.net). B's DNS resolver returns the subdomain (node1.peer-a.op-b.example). B's DNS resolver returns
IP address of the delivery node. the IP address of the delivery node.
6. The end-user requests the content from B's delivery node. In 6. The end-user requests the content from B's delivery node. In
the case of a cache hit, steps 6, 7, 8, 9 and 10 below do not the case of a cache hit, steps 6, 7, 8, 9 and 10 below do not
happen, and the content data is directly returned by the happen, and the content data is directly returned by the
delivery node to the end-user. In the case of a cache miss, the delivery node to the end-user. In the case of a cache miss, the
content needs to be acquired by dCDN from uCDN (not the CSP). content needs to be acquired by dCDN from uCDN (not the CSP).
The distinguished CDN-Domain peer-a.op-b.net indicates to dCDN The distinguished CDN-Domain peer-a.op-b.example indicates to
that this content is to be acquired from uCDN; stripping the dCDN that this content is to be acquired from uCDN; stripping
CDN-Domain reveals the original CDN-Domain cdn.csp.com and dCDN the CDN-Domain reveals the original CDN-Domain cdn.csp.example
may verify that this CDN-Domain belongs to a known peer (so as and dCDN may verify that this CDN-Domain belongs to a known peer
to avoid being tricked into serving as an open proxy). It then (so as to avoid being tricked into serving as an open proxy).
does a DNS request for an inter-CDN acquisition CDN-Domain as It then does a DNS request for an inter-CDN acquisition CDN-
agreed above (in this case, op-b-acq.op-a.net). Domain as agreed above (in this case, op-b-acq.op-a.example).
7. Operator A's DNS resolver processes the DNS request and returns 7. Operator A's DNS resolver processes the DNS request and returns
the IP address of a request router in operator A. the IP address of a request router in operator A.
8. The request router for Operator A processes the HTTP request 8. The request router for Operator A processes the HTTP request
from Operator B delivery node. Operator A request router from Operator B delivery node. Operator A request router
recognizes that the request is from a peer CDN rather than an recognizes that the request is from a peer CDN rather than an
end-user because of the dedicated inter-CDN acquisition domain end-user because of the dedicated inter-CDN acquisition domain
(op-b-acq.op-a.net). (Note that without this specially defined (op-b-acq.op-a.example). (Note that without this specially
inter-CDN acquisition domain, operator A would be at risk of defined inter-CDN acquisition domain, operator A would be at
redirecting the request back to operator B, resulting in an risk of redirecting the request back to operator B, resulting in
infinite loop). The request router for Operator A selects a an infinite loop). The request router for Operator A selects a
suitable delivery node in uCDN to serve the inter-CDN suitable delivery node in uCDN to serve the inter-CDN
acquisition request and returns a 302 redirect message for a new acquisition request and returns a 302 redirect message for a new
URL constructed by replacing the hostname with a subdomain of URL constructed by replacing the hostname with a subdomain of
the Operator A's distinguished inter-CDN acquisition domain that the Operator A's distinguished inter-CDN acquisition domain that
points to the selected delivery node. points to the selected delivery node.
9. Operator A DNS resolver processes the DNS request and returns 9. Operator A DNS resolver processes the DNS request and returns
the IP address of the delivery node in operator A. the IP address of the delivery node in operator A.
10. Operator B requests (acquires) the content from Operator A. 10. Operator B requests (acquires) the content from Operator A.
skipping to change at page 17, line 16 skipping to change at page 17, line 31
correctly process. Neither CDN needs to be aware of the internal correctly process. Neither CDN needs to be aware of the internal
structure of the other's URLs. Moreover, the inter-CDN redirection structure of the other's URLs. Moreover, the inter-CDN redirection
is entirely supported by a single HTTP redirect; neither CDN needs to is entirely supported by a single HTTP redirect; neither CDN needs to
be aware of the other's internal redirection mechanism (i.e., whether be aware of the other's internal redirection mechanism (i.e., whether
it is DNS or HTTP based). it is DNS or HTTP based).
One disadvantage is that the end-user's browser is redirected to a One disadvantage is that the end-user's browser is redirected to a
new URL that is not in the same domain of the original URL. This has new URL that is not in the same domain of the original URL. This has
implications on a number of security or validation mechanisms implications on a number of security or validation mechanisms
sometimes used on endpoints. For example, it is important that any sometimes used on endpoints. For example, it is important that any
redirected URL be in the same domain (e.g., csp.com) if the browser redirected URL be in the same domain (e.g., csp.example) if the
is expected to send any cookies associated with that domain. As browser is expected to send any cookies associated with that domain.
another example, some video players enforce validation of a cross As another example, some video players enforce validation of a cross
domain policy that needs to allow for the domains involved in the CDN domain policy that needs to allow for the domains involved in the CDN
redirection. These problems are generally soluble, but the solutions redirection. These problems are generally soluble, but the solutions
complicate the example, so we do not discuss them further in this complicate the example, so we do not discuss them further in this
version of the draft. version of the draft.
We note that this example begins to illustrate some of the interfaces We note that this example begins to illustrate some of the interfaces
that may be required for CDNI, but does not require all of them. For that may be required for CDNI, but does not require all of them. For
example, obtaining information from dCDN regarding the set of client example, obtaining information from dCDN regarding the set of client
IP addresses or geographic regions it might be able to serve is an IP addresses or geographic regions it might be able to serve is an
aspect of request routing (specifically of the CDNI Footprint & aspect of request routing (specifically of the CDNI Footprint &
skipping to change at page 18, line 33 skipping to change at page 18, line 46
routing. We build on the HTTP-based redirection approach because it routing. We build on the HTTP-based redirection approach because it
illustrates the principles and benefits clearly, but it is equally illustrates the principles and benefits clearly, but it is equally
possible to perform recursive redirection when DNS-based redirection possible to perform recursive redirection when DNS-based redirection
is employed. is employed.
In contrast to the prior example, the operators need not agree in In contrast to the prior example, the operators need not agree in
advance on a CDN-Domain to serve as the target of redirections from advance on a CDN-Domain to serve as the target of redirections from
uCDN to dCDN. We assume that the operators agree on some uCDN to dCDN. We assume that the operators agree on some
distinguished CDN-Domain that will be used for inter-CDN acquisition distinguished CDN-Domain that will be used for inter-CDN acquisition
of CSP's content by dCDN. In this example, we'll use of CSP's content by dCDN. In this example, we'll use
op-b-acq.op-a.net. op-b-acq.op-a.example.
We assume the operators also exchange information regarding which We assume the operators also exchange information regarding which
requests dCDN is prepared to serve. For example, dCDN may be requests dCDN is prepared to serve. For example, dCDN may be
prepared to serve requests from clients in a given geographical prepared to serve requests from clients in a given geographical
region or a set of IP address prefixes. This information may again region or a set of IP address prefixes. This information may again
be provided out of band or via a defined protocol. be provided out of band or via a defined protocol.
We assume DNS is configured in the following way: We assume DNS is configured in the following way:
o The content provider is configured to make operator A the o The content provider is configured to make operator A the
authoritative DNS server for cdn.csp.com (or to return a CNAME for authoritative DNS server for cdn.csp.example (or to return a CNAME
cdn.csp.com for which operator A is the authoritative DNS server). for cdn.csp.example for which operator A is the authoritative DNS
server).
o Operator A is configured so that a DNS request for o Operator A is configured so that a DNS request for
op-b-acq.op-a.net returns a request router in Operator A. op-b-acq.op-a.example returns a request router in Operator A.
o Operator B is configured so that a request for node1.op-b.net/ o Operator B is configured so that a request for node1.op-b.example/
cdn.csp.com returns the IP address of a delivery node. Note that cdn.csp.example returns the IP address of a delivery node. Note
there might be a number of such delivery nodes. that there might be a number of such delivery nodes.
Figure 3 illustrates how a client request for Figure 3 illustrates how a client request for
http://cdn.csp.com/...rest of url... http://cdn.csp.example/...rest of url...
is handled. is handled.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.example | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
|IPaddr of A's Request Router | |IPaddr of A's Request Router |
|<--------------------------------------------------| |<--------------------------------------------------|
|HTTP cdn.csp.com | | |HTTP cdn.csp.example | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(2) | | |(2)
| |RR/RI REQ cdn.csp.com | | |RR/RI REQ cdn.csp.example|
| |<------------------------| | |<------------------------|
| | | | | |
| |RR/RI RESP node1.op-b.net| | |RR/RI RESP node1.op-b.example
| |------------------------>| | |------------------------>|
| | |(3) | | |(3)
|302 node1.op-b.net/cdn.csp.com | |302 node1.op-b.example/cdn.csp.example |
|<--------------------------------------------------| |<--------------------------------------------------|
|DNS node1.op-b.net | | |DNS node1.op-b.example | |
|------------------------>| | |------------------------>| |
| |(4) | | |(4) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
|HTTP node1.op-b.net/cdn.csp.com | |HTTP node1.op-b.example/cdn.csp.example |
|------------------------>| | |------------------------>| |
| |(5) | | |(5) |
| |DNS op-b-acq.op-a.net | | |DNS op-b-acq.op-a.example|
| |------------------------>| | |------------------------>|
| | |(6) | | |(6)
| |IPaddr of A's Request Router | |IPaddr of A's Request Router
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.example
| |------------------------>| | |------------------------>|
| | |(7) | | |(7)
| |302 node2.op-b.acq.op-A.net | |302 node2.op-b.acq.op-A.example
| |<------------------------| | |<------------------------|
| |DNS node2.op-b-acq.op-a.net | |DNS node2.op-b-acq.op-a.example
| |------------------------>| | |------------------------>|
| | |(8) | | |(8)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| | | | | |
| |HTTP node2.op-b-acq.op-a.net | |HTTP node2.op-b-acq.op-a.example
| |------------------------>| | |------------------------>|
| | |(9) | | |(9)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 4: Message Flow for Recursive HTTP Redirection Figure 4: Message Flow for Recursive HTTP Redirection
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. A DNS resolver for Operator A processes the DNS request for its 1. A DNS resolver for Operator A processes the DNS request for its
customer based on CDN-Domain cdn.csp.com. It returns the IP customer based on CDN-Domain cdn.csp.example. It returns the IP
address of a Request Router in Operator A. address of a Request Router in Operator A.
2. A Request Router for Operator A processes the HTTP request and 2. A Request Router for Operator A processes the HTTP request and
recognizes that the end-user is best served by another recognizes that the end-user is best served by another CDN--
CDN-\u002Dspecifically one provided by Operator B-\u002Dand so it specifically one provided by Operator B--and so it queries the
queries the CDNI Request Routing Redirection interface of CDNI Request Routing Redirection interface of Operator B,
Operator B, providing a set of information about the request providing a set of information about the request including the
including the URL requested. Operator B replies with the DNS URL requested. Operator B replies with the DNS name of a
name of a delivery node. delivery node.
3. Operator A returns a 302 redirect message for a new URL obtained 3. Operator A returns a 302 redirect message for a new URL obtained
from the RI. from the RI.
4. The end-user does a DNS lookup using the host name of the URL 4. The end-user does a DNS lookup using the host name of the URL
just provided (node1.op-b.net). B's DNS resolver returns the IP just provided (node1.op-b.example). B's DNS resolver returns the
address of the corresponding delivery node. Note that, since the IP address of the corresponding delivery node. Note that, since
name of the delivery node was already obtained from B using the the name of the delivery node was already obtained from B using
RI, there should not be any further redirection here (in contrast the RI, there should not be any further redirection here (in
to the iterative method described above.) contrast to the iterative method described above.)
5. The end-user requests the content from B's delivery node, 5. The end-user requests the content from B's delivery node,
potentially resulting in a cache miss. In the case of a cache potentially resulting in a cache miss. In the case of a cache
miss, the content needs to be acquired from uCDN (not the CSP.) miss, the content needs to be acquired from uCDN (not the CSP.)
The distinguished CDN-Domain op-b.net indicates to dCDN that this The distinguished CDN-Domain op-b.example indicates to dCDN that
content is to be acquired from another CDN; stripping the CDN- this content is to be acquired from another CDN; stripping the
Domain reveals the original CDN-Domain cdn.csp.com, dCDN may CDN-Domain reveals the original CDN-Domain cdn.csp.example, dCDN
verify that this CDN-Domain belongs to a known peer (so as to may verify that this CDN-Domain belongs to a known peer (so as to
avoid being tricked into serving as an open proxy). It then does avoid being tricked into serving as an open proxy). It then does
a DNS request for the inter-CDN Acquisition "distinguished" CDN- a DNS request for the inter-CDN Acquisition "distinguished" CDN-
Domain as agreed above (in this case, op-b-acq.op-a.net). Domain as agreed above (in this case, op-b-acq.op-a.example).
6. Operator A DNS resolver processes the DNS request and returns the 6. Operator A DNS resolver processes the DNS request and returns the
IP address of a request router in operator A. IP address of a request router in operator A.
7. The request router for Operator A processes the HTTP request from 7. The request router for Operator A processes the HTTP request from
Operator B delivery node. Operator A request router recognizes Operator B delivery node. Operator A request router recognizes
that the request is from a peer CDN rather than an end-user that the request is from a peer CDN rather than an end-user
because of the dedicated inter-CDN acquisition domain because of the dedicated inter-CDN acquisition domain
(op-b-acq.op-a.net). (Note that without this specially defined (op-b-acq.op-a.example). (Note that without this specially
inter-CDN acquisition domain, operator A would be at risk of defined inter-CDN acquisition domain, operator A would be at risk
redirecting the request back to operator B, resulting in an of redirecting the request back to operator B, resulting in an
infinite loop). The request router for Operator A selects a infinite loop). The request router for Operator A selects a
suitable delivery node in uCDN to serve the inter-CDN acquisition suitable delivery node in uCDN to serve the inter-CDN acquisition
request and returns a 302 redirect message for a new URL request and returns a 302 redirect message for a new URL
constructed by replacing the hostname with a subdomain of the constructed by replacing the hostname with a subdomain of the
Operator A's distinguished inter-CDN acquisition domain that Operator A's distinguished inter-CDN acquisition domain that
points to the selected delivery node. points to the selected delivery node.
8. Operator A recognizes that the DNS request is from a peer CDN 8. Operator A recognizes that the DNS request is from a peer CDN
rather than an end-user (due to the internal CDN-Domain) and so rather than an end-user (due to the internal CDN-Domain) and so
returns the address of a delivery node. (Note that without this returns the address of a delivery node. (Note that without this
skipping to change at page 22, line 25 skipping to change at page 22, line 44
As before, Operator A has to learn the set of requests that dCDN is As before, Operator A has to learn the set of requests that dCDN is
willing or able to serve (e.g. which client IP address prefixes or willing or able to serve (e.g. which client IP address prefixes or
geographic regions are part of the dCDN footprint). We assume geographic regions are part of the dCDN footprint). We assume
Operator has and makes known to operator A some unique identifier Operator has and makes known to operator A some unique identifier
that can be used for the construction of a distinguished CDN-Domain, that can be used for the construction of a distinguished CDN-Domain,
as shown in more detail below. (This identifier strictly needs only as shown in more detail below. (This identifier strictly needs only
to be unique within the scope of Operator A, but a globally unique to be unique within the scope of Operator A, but a globally unique
identifier, such as an AS number assigned to B, is one easy way to identifier, such as an AS number assigned to B, is one easy way to
achieve that.) Also, Operator A obtains the NS records for Operator achieve that.) Also, Operator A obtains the NS records for Operator
B's externally visible redirection servers. Also, as before, a B's externally visible redirection servers. Also, as before, a
distinguished CDN-Domain, such as op-b-acq.op-a.net, must be assigned distinguished CDN-Domain, such as op-b-acq.op-a.example, must be
for inter-CDN acquisition. assigned for inter-CDN acquisition.
We assume DNS is configured in the following way: We assume DNS is configured in the following way:
o The CSP is configured to make Operator A the authoritative DNS o The CSP is configured to make Operator A the authoritative DNS
server for cdn.csp.com (or to return a CNAME for cdn.csp.com for server for cdn.csp.example (or to return a CNAME for
which operator A is the authoritative DNS server). cdn.csp.example for which operator A is the authoritative DNS
server).
o When uCDN sees a request best served by dCDN, it returns CNAME and o When uCDN sees a request best served by dCDN, it returns CNAME and
NS records for "b.cdn.csp.com", where "b" is the unique identifier NS records for "b.cdn.csp.example", where "b" is the unique
assigned to Operator B. (It may, for example, be an AS number identifier assigned to Operator B. (It may, for example, be an AS
assigned to Operator B.) number assigned to Operator B.)
o dCDN is configured so that a request for "b.cdn.csp.com" returns a o dCDN is configured so that a request for "b.cdn.csp.example"
delivery node in dCDN. returns a delivery node in dCDN.
o uCDN is configured so that a request for "op-b-acq.op-a.net" o uCDN is configured so that a request for "op-b-acq.op-a.example"
returns a delivery node in uCDN. returns a delivery node in uCDN.
Figure 5 depicts the exchange of DNS and HTTP requests. The main Figure 5 depicts the exchange of DNS and HTTP requests. The main
differences from Figure 3 are the lack of HTTP redirection and differences from Figure 3 are the lack of HTTP redirection and
transparency to the end-user. transparency to the end-user.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.example | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
|CNAME b.cdn.csp.com | | |CNAME b.cdn.csp.example | |
|NS records for b.cdn.csp.com | |NS records for b.cdn.csp.example |
|<--------------------------------------------------| |<--------------------------------------------------|
|DNS b.cdn.csp.com | | |DNS b.cdn.csp.example | |
|------------------------>| | |------------------------>| |
| |(2) | | |(2) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
|HTTP cdn.csp.com | | |HTTP cdn.csp.example | |
|------------------------>| | |------------------------>| |
| |(3) | | |(3) |
| |DNS op-b-acq.op-a.net | | |DNS op-b-acq.op-a.example|
| |------------------------>| | |------------------------>|
| | |(4) | | |(4)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.example
| |------------------------>| | |------------------------>|
| | |(5) | | |(5)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 5: Message Flow for DNS-based Redirection Figure 5: Message Flow for DNS-based Redirection
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. Request Router for Operator A processes the DNS request for CDN- 1. Request Router for Operator A processes the DNS request for CDN-
Domain cdn.csp.com and recognizes that the end-user is best Domain cdn.csp.example and recognizes that the end-user is best
served by another CDN. (This may depend on the IP address of the served by another CDN. (This may depend on the IP address of the
user's local DNS resolver, or other information discussed below.) user's local DNS resolver, or other information discussed below.)
The Request Router returns a DNS CNAME response by "stacking" the The Request Router returns a DNS CNAME response by "stacking" the
distinguished identifier for Operator B onto the original CDN- distinguished identifier for Operator B onto the original CDN-
Domain (e.g., b.cdn.csp.com), plus an NS record that maps Domain (e.g., b.cdn.csp.example), plus an NS record that maps
b.cdn.csp.com to B's Request Router. b.cdn.csp.example to B's Request Router.
2. The end-user does a DNS lookup using the modified CDN-Domain 2. The end-user does a DNS lookup using the modified CDN-Domain
(i.e., b.cdn.csp.com). This causes B's Request Router to respond (i.e., b.cdn.csp.example). This causes B's Request Router to
with a suitable delivery node. respond with a suitable delivery node.
3. The end-user requests the content from B's delivery node. The 3. The end-user requests the content from B's delivery node. The
requested URL contains the name cdn.csp.com. (Note that the requested URL contains the name cdn.csp.example. (Note that the
returned CNAME does not affect the URL.) At this point the returned CNAME does not affect the URL.) At this point the
delivery node has the correct IP address of the end-user and can delivery node has the correct IP address of the end-user and can
do an HTTP 302 redirect if the redirections in steps 2 and 3 were do an HTTP 302 redirect if the redirections in steps 2 and 3 were
incorrect. Otherwise B verifies that this CDN-Domain belongs to incorrect. Otherwise B verifies that this CDN-Domain belongs to
a known peer (so as to avoid being tricked into serving as an a known peer (so as to avoid being tricked into serving as an
open proxy). It then does a DNS request for an "internal" CDN- open proxy). It then does a DNS request for an "internal" CDN-
Domain as agreed above (op-b-acq.op-a.net). Domain as agreed above (op-b-acq.op-a.example).
4. Operator A recognizes that the DNS request is from a peer CDN 4. Operator A recognizes that the DNS request is from a peer CDN
rather than an end-user (due to the internal CDN-Domain) and so rather than an end-user (due to the internal CDN-Domain) and so
returns the address of a delivery node in uCDN. returns the address of a delivery node in uCDN.
5. Operator A serves content to dCDN. Although not shown, it is at 5. Operator A serves content to dCDN. Although not shown, it is at
this point that Operator A processes the rest of the URL: it this point that Operator A processes the rest of the URL: it
extracts information identifying the origin server, validates extracts information identifying the origin server, validates
that this server has been registered, and determines the content that this server has been registered, and determines the content
provider that owns the origin server. provider that owns the origin server.
The advantages of this approach are that it is more transparent to The advantages of this approach are that it is more transparent to
the end-user and requires fewer round trips than HTTP-based the end-user and requires fewer round trips than HTTP-based
redirection (in its worst case, i.e., when none of the needed DNS redirection (in its worst case, i.e., when none of the needed DNS
information is cached). A potential problem is that the upstream CDN information is cached). A potential problem is that the upstream CDN
depends on being able to learn the correct downstream CDN that serves depends on being able to learn the correct downstream CDN that serves
the end-user from the client address in the DNS request. In standard the end-user from the client address in the DNS request. In standard
DNS operation, uCDN will only obtain the address of the client's DNS operation, uCDN will only obtain the address of the client's
local DNS resolver (LDNS), which is not guaranteed to be in the same local DNS resolver (LDNS), which is not guaranteed to be in the same
network (or geographic region) as the client. If not-\u002De.g., the network (or geographic region) as the client. If not--e.g., the end-
end-user uses a global DNS service-\u002Dthen the upstream CDN cannot user uses a global DNS service--then the upstream CDN cannot
determine the appropriate downstream CDN to serve the end-user. In determine the appropriate downstream CDN to serve the end-user. In
this case, and assuming the uCDN is capable of detecting that this case, and assuming the uCDN is capable of detecting that
situation, one option is for the upstream CDN to treat the end-user situation, one option is for the upstream CDN to treat the end-user
as it would any user not connected to a peer CDN. Another option is as it would any user not connected to a peer CDN. Another option is
for the upstream CDN to "fall back" to a pure HTTP-based redirection for the upstream CDN to "fall back" to a pure HTTP-based redirection
strategy in this case (i.e., use the first method). Note that this strategy in this case (i.e., use the first method). Note that this
problem affects existing CDNs that rely on DNS to determine where to problem affects existing CDNs that rely on DNS to determine where to
redirect client requests, but the consequences are arguably less redirect client requests, but the consequences are arguably less
serious for CDNI since the LDNS is likely in the same network as the serious for CDNI since the LDNS is likely in the same network as the
dCDN serves. One approach to ensuring that the client's IP address dCDN serves. One approach to ensuring that the client's IP address
skipping to change at page 25, line 16 skipping to change at page 26, line 5
There could be situations where being able to dynamically discover There could be situations where being able to dynamically discover
the set of requests that a given dCDN is willing and able to serve is the set of requests that a given dCDN is willing and able to serve is
beneficial. For example, a CDN might at one time be able to serve a beneficial. For example, a CDN might at one time be able to serve a
certain set of client IP prefixes, but that set might change over certain set of client IP prefixes, but that set might change over
time due to changes in the topology and routing policies of the IP time due to changes in the topology and routing policies of the IP
network. The following example illustrates this capability. We have network. The following example illustrates this capability. We have
chosen the example of DNS-based redirection, but HTTP-based chosen the example of DNS-based redirection, but HTTP-based
redirection could equally well use this approach. redirection could equally well use this approach.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.example | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
| | RI REQ op-b.net | | | RI REQ op-b.example |
| |<------------------------| | |<------------------------|
| | |(2) | | |(2)
| | RI REPLY | | | RI REPLY |
| |------------------------>| | |------------------------>|
| | |(3) | | |(3)
|CNAME b.cdn.csp.com | | |CNAME b.cdn.csp.example | |
|NS records for b.cdn.csp.com | |NS records for b.cdn.csp.example |
|<--------------------------------------------------| |<--------------------------------------------------|
|DNS b.cdn.csp.com | | |DNS b.cdn.csp.example | |
|------------------------>| | |------------------------>| |
| |(2) | | |(2) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
|HTTP cdn.csp.com | | |HTTP cdn.csp.example | |
|------------------------>| | |------------------------>| |
| |(3) | | |(3) |
| |DNS op-b-acq.op-a.net | | |DNS op-b-acq.op-a.example|
| |------------------------>| | |------------------------>|
| | |(4) | | |(4)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.example
| |------------------------>| | |------------------------>|
| | |(5) | | |(5)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 6: Message Flow for Dynamic Footprint Discovery Figure 6: Message Flow for Dynamic Footprint Discovery
This example differs from the one in Figure 5 only in the addition of This example differs from the one in Figure 5 only in the addition of
a FCI request (step 2) and corresponding response (step 3). The RI a FCI request (step 2) and corresponding response (step 3). The RI
REQ could be a message such as "Can you serve clients from this IP REQ could be a message such as "Can you serve clients from this IP
Prefix?" or it could be "Provide the list of client IP prefixes you Prefix?" or it could be "Provide the list of client IP prefixes you
can currently serve". In either case the response might be cached by can currently serve". In either case the response might be cached by
operator A to avoid repeatedly asking the same question. operator A to avoid repeatedly asking the same question.
Alternatively, or in addition, Operator B may spontaneously advertise Alternatively, or in addition, Operator B may spontaneously advertise
skipping to change at page 26, line 38 skipping to change at page 27, line 26
The following example illustrates how the CDNI Control interface may The following example illustrates how the CDNI Control interface may
be used to achieve pre-positioning of an item of content in the dCDN. be used to achieve pre-positioning of an item of content in the dCDN.
In this example, user requests for a particular content, and In this example, user requests for a particular content, and
corresponding redirection of such requests from Operator A to corresponding redirection of such requests from Operator A to
Operator B CDN, may (or may not) have taken place earlier. Then, at Operator B CDN, may (or may not) have taken place earlier. Then, at
some point in time, the uCDN (for example, in response to a some point in time, the uCDN (for example, in response to a
corresponding Trigger from the Content Provider) uses the CI to corresponding Trigger from the Content Provider) uses the CI to
request that content identified by a particular URL be removed from request that content identified by a particular URL be removed from
dCDN. The following diagram illustrates the operation. dCDN. The following diagram illustrates the operation.
End-User Operator B Operator A End-User Operator B Operator A
| |CI purge cdn.csp.com/... | | |CI purge cdn.csp.example/...
| |<------------------------| | |<------------------------|
| | | | | |
| |CI OK | | |CI OK |
| |------------------------>| | |------------------------>|
| | | | | |
Figure 7: Message Flow for Content Removal Figure 7: Message Flow for Content Removal
The CI is used to convey the request from uCDN to dCDN that some The CI is used to convey the request from uCDN to dCDN that some
previously acquired content should be deleted. The URL in the previously acquired content should be deleted. The URL in the
request specifies which content to remove. This example corresponds request specifies which content to remove. This example corresponds
to a DNS-based redirection scenario such as Section 3.4. If HTTP- to a DNS-based redirection scenario such as Section 3.4. If HTTP-
based redirection had been used, the URL for removal would be of the based redirection had been used, the URL for removal would be of the
form peer-a.op-b.net/cdn.csp.com/... form peer-a.op-b.example/cdn.csp.example/...
The dCDN is expected to confirm to the uCDN, as illustrated by the CI The dCDN is expected to confirm to the uCDN, as illustrated by the CI
OK message, the completion of the removal of the targeted content OK message, the completion of the removal of the targeted content
from all the caches in dCDN. from all the caches in dCDN.
3.7. Pre-Positioned Content Acquisition Example 3.7. Pre-Positioned Content Acquisition Example
The following example illustrates how the CI may be used to pre- The following example illustrates how the CI may be used to pre-
position an item of content in the dCDN. In this example, Operator A position an item of content in the dCDN. In this example, Operator A
uses the CDNI Metadata interface to request that content identified uses the CDNI Metadata interface to request that content identified
by a particular URL be pre-positioned into Operator B CDN. by a particular URL be pre-positioned into Operator B CDN.
End-User Operator B Operator A End-User Operator B Operator A
| |CI pre-position cdn.csp.com/... | |CI pre-position cdn.csp.example/...
| |<------------------------| | |<------------------------|
| | |(1) | | |(1)
| |CI OK | | |CI OK |
| |------------------------>| | |------------------------>|
| | | | | |
| |DNS op-b-acq.op-a.net | | |DNS op-b-acq.op-a.example|
| |------------------------>| | |------------------------>|
| | |(2) | | |(2)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.example
| |------------------------>| | |------------------------>|
| | |(3) | | |(3)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|DNS cdn.csp.com | | |DNS cdn.csp.example | |
|-------------------------------------------------->| |--------------------------------------------->|
| | |(4) | | |(4)
|IPaddr of A's Request Router | |IPaddr of A's Request Router |
|<--------------------------------------------------| |<---------------------------------------------|
|HTTP cdn.csp.com | | |HTTP cdn.csp.example| |
|-------------------------------------------------->| |--------------------------------------------->|
| | |(5) | | |(5)
|302 peer-a.op-b.net/cdn.csp.com | |302 peer-a.op-b.example/cdn.csp.example |
|<--------------------------------------------------| |<---------------------------------------------|
|DNS peer-a.op-b.net | | |DNS peer-a.op-b.example |
|------------------------>| | |------------------->| |
| |(6) | | |(6) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<-------------------| |
|HTTP peer-a.op-b.net/cdn.csp.com | |HTTP peer-a.op-b.example/cdn.csp.example |
|------------------------>| | |------------------->| |
| |(7) | | |(7) |
|Data | | |Data | |
|<------------------------| | |<-------------------| |
Figure 8: Message Flow for Content Pre-Positioning Figure 8: Message Flow for Content Pre-Positioning
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. Operator A uses the CI to request that Operator B pre-positions a 1. Operator A uses the CI to request that Operator B pre-positions a
particular content item identified by its URL. Operator B particular content item identified by its URL. Operator B
responds by confirming that it is willing to perform this responds by confirming that it is willing to perform this
operation. operation.
Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only
this time those steps happen as the result of the Pre-positioning this time those steps happen as the result of the Pre-positioning
request instead of as the result of a cache miss. request instead of as the result of a cache miss.
Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of Figure Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of
3, only this time Operator B CDN can serve the end-user request Figure 3, only this time Operator B CDN can serve the end-user
without triggering dynamic content acquisition, since the content has request without triggering dynamic content acquisition, since the
been pre-positioned in dCDN. Note that, depending on dCDN operations content has been pre-positioned in dCDN. Note that, depending on
and policies, the content pre-positioned in the dCDN may be pre- dCDN operations and policies, the content pre-positioned in the dCDN
positioned to all, or a subset of, dCDN caches. In the latter case, may be pre-positioned to all, or a subset of, dCDN caches. In the
intra-CDN dynamic content acquisition may take place inside the dCDN latter case, intra-CDN dynamic content acquisition may take place
serving requests from caches on which the content has not been pre- inside the dCDN serving requests from caches on which the content has
positioning; however, such intra-CDN dynamic acquisition would not not been pre-positioning; however, such intra-CDN dynamic acquisition
involve the uCDN. would not involve the uCDN.
3.8. Asynchronous CDNI Metadata Example 3.8. Asynchronous CDNI Metadata Example
In this section we walk through a simple example illustrating a In this section we walk through a simple example illustrating a
scenario of asynchronously exchanging CDNI metadata, where the scenario of asynchronously exchanging CDNI metadata, where the
downstream CDN obtains CDNI metadata for content ahead of a downstream CDN obtains CDNI metadata for content ahead of a
corresponding content request. The example that follows assumes that corresponding content request. The example that follows assumes that
HTTP-based inter-CDN redirection and recursive CDNI request-routing HTTP-based inter-CDN redirection and recursive CDNI request-routing
are used, as in Section 3.3. However, Asynchronous exchange of CDNI are used, as in Section 3.3. However, Asynchronous exchange of CDNI
Metadata is similarly applicable to DNS-based inter-CDN redirection Metadata is similarly applicable to DNS-based inter-CDN redirection
skipping to change at page 29, line 22 skipping to change at page 30, line 29
| CONTENT REQUEST | | | CONTENT REQUEST | |
|-------------------------------------------------->|(5) |-------------------------------------------------->|(5)
| | | | | |
| | RI REQ | | | RI REQ |
| |<------------------------|(6) | |<------------------------|(6)
| | | | | |
| | RI RESP | | | RI RESP |
| |------------------------>|(7) | |------------------------>|(7)
| | | | | |
| CONTENT REDIRECTION | | | CONTENT REDIRECTION | |
|<--------------------------------------------------| (8) |<--------------------------------------------------|(8)
| | | | | |
| CONTENT REQUEST | | | CONTENT REQUEST | |
|------------------------>|(9) | |------------------------>|(9) |
| | | | | |
: : : : : :
| CONTENT DATA | | | CONTENT DATA | |
|<------------------------| |(10) |<------------------------| |(10)
Figure 9: Message Flow for Asynchronous CDNI Metadata Figure 9: Message Flow for Asynchronous CDNI Metadata
skipping to change at page 30, line 48 skipping to change at page 32, line 6
In this section we walk through a simple example illustrating a In this section we walk through a simple example illustrating a
scenario of Synchronous CDNI metadata acquisition, in which the scenario of Synchronous CDNI metadata acquisition, in which the
downstream CDN obtains CDNI metadata for content at the time of downstream CDN obtains CDNI metadata for content at the time of
handling a first request for the corresponding content. As in the handling a first request for the corresponding content. As in the
preceding section, this example assumes that HTTP-based inter-CDN preceding section, this example assumes that HTTP-based inter-CDN
redirection and recursive CDNI request-routing are used (as in redirection and recursive CDNI request-routing are used (as in
Section 3.3), but dynamic CDNI metadata acquisition is applicable to Section 3.3), but dynamic CDNI metadata acquisition is applicable to
other variations of request routing. other variations of request routing.
End-User Operator B Operator A End-User Operator B Operator A
| | | | | |
| CONTENT REQUEST | | | CONTENT REQUEST | |
|-------------------------------------------------->|(1) |-------------------------------------------------->|(1)
| | | | | |
| | RI REQ | | | RI REQ |
| (2)|<------------------------| | (2)|<------------------------|
| | | | | |
| | MI REQ | | | MI REQ |
| (3)|------------------------>| | (3)|------------------------>|
| | MI RESP | | | MI RESP |
| |<------------------------|(4) | |<------------------------|(4)
| | | | | |
| | RI RESP | | | RI RESP |
| |------------------------>|(5) | |------------------------>|(5)
| | | | | |
| | | | | |
| CONTENT REDIRECTION | | | CONTENT REDIRECTION | |
|<--------------------------------------------------|(6) |<--------------------------------------------------|(6)
| | | | | |
| CONTENT REQUEST | | | CONTENT REQUEST | |
|------------------------>| (7) | |------------------------>|(7) |
| | | | | |
| | MI REQ | | | MI REQ |
| (8)|------------------------>| | (8)|------------------------>|
| | MI RESP | | | MI RESP |
| |<------------------------|(9) | |<------------------------|(9)
| | | | | |
: : : : : :
| CONTENT DATA | | | CONTENT DATA | |
|<------------------------| | (10) |<------------------------| |(10)
Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. A Content Request arrives as normal. 1. A Content Request arrives as normal.
2. An RI request occurs as in the prior example. 2. An RI request occurs as in the prior example.
3. On receipt of the CDNI Request Routing Request, Operator B's CDN 3. On receipt of the CDNI Request Routing Request, Operator B's CDN
skipping to change at page 33, line 37 skipping to change at page 34, line 42
lookup. If the content metadata includes information for acquiring lookup. If the content metadata includes information for acquiring
the content, then the MI is also tightly coupled with the acquisition the content, then the MI is also tightly coupled with the acquisition
interface in that the result of the metadata lookup (an acquisition interface in that the result of the metadata lookup (an acquisition
URL likely hosted by the uCDN) should serve as input to the content URL likely hosted by the uCDN) should serve as input to the content
acquisition. acquisition.
4. Main Interfaces 4. Main Interfaces
Figure 1 illustrates the main interfaces that are in scope for the Figure 1 illustrates the main interfaces that are in scope for the
CDNI WG, along with several others. The detailed specifications of CDNI WG, along with several others. The detailed specifications of
these interfaces are left to other documents, but see RFC 6707 and these interfaces are left to other documents, but see [RFC6707] and
[I-D.ietf-cdni-requirements] for some discussion of the interfaces. [I-D.ietf-cdni-requirements] for some discussion of the interfaces.
One interface that is not shown in Figure 1 is the interface between One interface that is not shown in Figure 1 is the interface between
the user and the CSP. While for the purposes of CDNI that interface the user and the CSP. While for the purposes of CDNI that interface
is out of scope, it is worth noting that it does exist and can is out of scope, it is worth noting that it does exist and can
provide useful functions, such as end-to-end performance monitoring provide useful functions, such as end-to-end performance monitoring
and some forms of authentication and authorization. and some forms of authentication and authorization.
There is also an important interface between the user and the Request There is also an important interface between the user and the Request
Routing function of both uCDN and dCDN (shown as the "Request" Routing function of both uCDN and dCDN (shown as the "Request"
skipping to change at page 35, line 30 skipping to change at page 36, line 38
As illustrated in Section 3, the RI part of request routing may be As illustrated in Section 3, the RI part of request routing may be
implemented in part by DNS and HTTP. Naming conventions may be implemented in part by DNS and HTTP. Naming conventions may be
established by which CDN peers communicate whether a request should established by which CDN peers communicate whether a request should
be routed or content served. be routed or content served.
We also note that RI plays a key role in enabling recursive We also note that RI plays a key role in enabling recursive
redirection, as illustrated in Section 3.3. It enables the user to redirection, as illustrated in Section 3.3. It enables the user to
be redirected to the correct delivery node in dCDN with only a single be redirected to the correct delivery node in dCDN with only a single
redirection step (as seen by the user). This may be particularly redirection step (as seen by the user). This may be particularly
valuable as the chain of interconnected CDNs increases beyond two valuable as the chain of interconnected CDNs increases beyond two
CDNs. CDNs. For further discussion on the RI, see
[I-D.ietf-cdni-redirection].
In support of these redirection requests, it is necessary for CDN In support of these redirection requests, it is necessary for CDN
peers to exchange additional information with each other, and this is peers to exchange additional information with each other, and this is
the role of the FCI part of request routing. Depending on the the role of the FCI part of request routing. Depending on the
method(s) supported, this might includes method(s) supported, this might includes
o The operator's unique id (operator-id) or distinguished CDN-Domain o The operator's unique id (operator-id) or distinguished CDN-Domain
(operator-domain); (operator-domain);
o NS records for the operator's set of externally visible request o NS records for the operator's set of externally visible request
skipping to change at page 36, line 8 skipping to change at page 37, line 18
o Additional capabilities of the dCDN, such as its ability to o Additional capabilities of the dCDN, such as its ability to
support different CDNI Metadata requests. support different CDNI Metadata requests.
Note that the set of requests that dCDN is willing to serve could in Note that the set of requests that dCDN is willing to serve could in
some cases be relatively static (e.g., a set of IP prefixes) which some cases be relatively static (e.g., a set of IP prefixes) which
could be exchanged off-line, or might even be negotiated as part of a could be exchanged off-line, or might even be negotiated as part of a
peering agreement. However, it may also be more dynamic, in which peering agreement. However, it may also be more dynamic, in which
case the exchange supported by FCI would be be helpful. A further case the exchange supported by FCI would be be helpful. A further
discussion of the Footprint & Capability Advertisement interface can discussion of the Footprint & Capability Advertisement interface can
be found in [I-D.spp-cdni-rr-foot-cap-semantics]. be found in [I-D.ietf-cdni-footprint-capabilities-semantics].
4.4. CDNI Logging Interface 4.4. CDNI Logging Interface
It is necessary for the upstream CDN to have visibility into the It is necessary for the upstream CDN to have visibility into the
delivery of content that it redirected to a downstream CDN. This delivery of content that it redirected to a downstream CDN. This
allows the upstream CDN to properly bill its customers for multiple allows the upstream CDN to properly bill its customers for multiple
deliveries of content cached by the downstream CDN, as well as to deliveries of content cached by the downstream CDN, as well as to
report accurate traffic statistics to those content providers. This report accurate traffic statistics to those content providers. This
is one role of the LI. is one role of the LI.
skipping to change at page 36, line 43 skipping to change at page 38, line 4
o Time zone - any time zone modifier for the end time o Time zone - any time zone modifier for the end time
o Method - the transfer command itself (e.g., GET, POST, HEAD) o Method - the transfer command itself (e.g., GET, POST, HEAD)
o URL - the requested URL o URL - the requested URL
o Version - the protocol version, such as HTTP/1.0 o Version - the protocol version, such as HTTP/1.0
o Response - a numeric response code indicating transfer result o Response - a numeric response code indicating transfer result
o Bytes Sent - the number of bytes in the body sent to the client o Bytes Sent - the number of bytes in the body sent to the client
o Request ID - a unique identifier for this transfer o Request ID - a unique identifier for this transfer
o User agent - the user agent, if supplied o User agent - the user agent, if supplied
o Duration - the duration of the transfer in milliseconds o Duration - the duration of the transfer in milliseconds
o Cached Bytes - the number of body bytes served from the cache o Cached Bytes - the number of body bytes served from the cache
o Referrer - the referrer string from the client, if supplied o Referrer - the referrer string from the client, if supplied
Of these, only the Domain field is indirect in the downstream Of these, only the Domain field is indirect in the downstream CDN--it
CDN-\u002Dit is set to the CDN-Domain used by the upstream CDN rather is set to the CDN-Domain used by the upstream CDN rather than the
than the actual origin server. This field could then used to filter actual origin server. This field could then used to filter traffic
traffic log entries so only those entries matching the upstream CDN log entries so only those entries matching the upstream CDN are
are reported to the corresponding operator. Further discussion of reported to the corresponding operator. Further discussion of the LI
the LI can be found in [I-D.bertrand-cdni-logging]. can be found in [I-D.ietf-cdni-logging].
One open question is who does the filtering. One option is that the One open question is who does the filtering. One option is that the
downstream CDN filters its own logs, and passes the relevant records downstream CDN filters its own logs, and passes the relevant records
directly to each upstream peer. This requires that the downstream directly to each upstream peer. This requires that the downstream
CDN knows the set of CDN-Domains that belong to each upstream peer. CDN knows the set of CDN-Domains that belong to each upstream peer.
If this information is already exchanged between peers as part of If this information is already exchanged between peers as part of
another interface, then direct peer-to-peer reporting is another interface, then direct peer-to-peer reporting is
straightforward. If it is not available, and operators do not wish straightforward. If it is not available, and operators do not wish
to advertise the set of CDN-Domains they serve to their peers, then to advertise the set of CDN-Domains they serve to their peers, then
the second option is for each CDN to send both its non-local traffic the second option is for each CDN to send both its non-local traffic
skipping to change at page 38, line 20 skipping to change at page 39, line 28
The CDNI Control interface is initially used to bootstrap the other The CDNI Control interface is initially used to bootstrap the other
interfaces. As a simple example, it could be used to provide the interfaces. As a simple example, it could be used to provide the
address of the logging server in dCDN to uCDN in order to bootstrap address of the logging server in dCDN to uCDN in order to bootstrap
the CDNI Logging interface. It may also be used, for example, to the CDNI Logging interface. It may also be used, for example, to
establish security associations for the other interfaces. establish security associations for the other interfaces.
The other role the CI plays is to allow the uCDN to pre-position, The other role the CI plays is to allow the uCDN to pre-position,
revalidate, or purge metadata and content on a dCDN. These revalidate, or purge metadata and content on a dCDN. These
operations, sometimes collectively called the Trigger interface, are operations, sometimes collectively called the Trigger interface, are
discussed further in [I-D.murray-cdni-triggers]. discussed further in [I-D.ietf-cdni-control-triggers].
4.6. CDNI Metadata Interface 4.6. CDNI Metadata Interface
The role of the CDNI Metadata interface is to enable CDNI The role of the CDNI Metadata interface is to enable CDNI
distribution metadata to be conveyed to the downstream CDN by the distribution metadata to be conveyed to the downstream CDN by the
upstream CDN. For example, see [I-D.ietf-cdni-metadata]. Such upstream CDN. Such metadata includes geo-blocking restrictions,
metadata includes geo-blocking restrictions, availability windows, availability windows, access control policies, and so on. It may
access control policies, and so on. It may also include information also include information to facilitate acquisition of content by dCDN
to facilitate acquisition of content by dCDN (e.g., alternate sources (e.g., alternate sources for the content, authorization information
for the content, authorization information needed to acquire the needed to acquire the content from the source). For a full
content from the source). discussion of the CDNI Metadata Interface, see
[I-D.ietf-cdni-metadata]
Some distribution metadata may be partially emulated using in-band Some distribution metadata may be partially emulated using in-band
mechanisms. For example, in case of any geo-blocking restrictions or mechanisms. For example, in case of any geo-blocking restrictions or
availability windows, the upstream CDN can elect to redirect a availability windows, the upstream CDN can elect to redirect a
request to the downstream CDN only if that CDN's advertised delivery request to the downstream CDN only if that CDN's advertised delivery
footprint is acceptable for the requested URL. Similarly, the footprint is acceptable for the requested URL. Similarly, the
request could be forwarded only if the current time is within the request could be forwarded only if the current time is within the
availability window. However, such approaches typically come with availability window. However, such approaches typically come with
shortcomings such as inability to prevent from replay outside the shortcomings such as inability to prevent from replay outside the
time window or inability to make use of a downstream CDN that covers time window or inability to make use of a downstream CDN that covers
skipping to change at page 45, line 16 skipping to change at page 46, line 50
is the more general concept, involving two or more CDNs serving is the more general concept, involving two or more CDNs serving
content to each other's users, while federation implies a multi- content to each other's users, while federation implies a multi-
lateral interconnection arrangement, but other CDN interconnection lateral interconnection arrangement, but other CDN interconnection
agreements are also possible (e.g., symmetric bilateral, asymmetric agreements are also possible (e.g., symmetric bilateral, asymmetric
bilateral). An important conclusion is that CDNI technology should bilateral). An important conclusion is that CDNI technology should
not presume (or bake in) a particular interconnection agreement, but not presume (or bake in) a particular interconnection agreement, but
should instead be general enough to permit alternative should instead be general enough to permit alternative
interconnection arrangements to evolve. interconnection arrangements to evolve.
The second concept often used in the context of CDN Federation is CDN The second concept often used in the context of CDN Federation is CDN
Exchange-\u002Da third party broker or exchange that is used to Exchange--a third party broker or exchange that is used to facilitate
facilitate a CDN federation. Our view is that a CDN exchange offers a CDN federation. Our view is that a CDN exchange offers valuable
valuable machinery to scale the number of CDN operators involved in a machinery to scale the number of CDN operators involved in a multi-
multi-lateral (federated) agreement, but that this machinery is built lateral (federated) agreement, but that this machinery is built on
on top of the core CDNI interconnection mechanisms. For example, as top of the core CDNI interconnection mechanisms. For example, as
illustrated in Figure 14, the exchange might aggregate and illustrated in Figure 14, the exchange might aggregate and
redistribute information about each CDN footprint and capacity, as redistribute information about each CDN footprint and capacity, as
well as collect, filter, and redistribute traffic logs that each well as collect, filter, and redistribute traffic logs that each
participant needs for interconnection settlement, but inter-CDN participant needs for interconnection settlement, but inter-CDN
request routing, inter-CDN content distribution (including inter-CDN request routing, inter-CDN content distribution (including inter-CDN
acquisition) and inter-CDN control which fundamentally involve a acquisition) and inter-CDN control which fundamentally involve a
direct interaction between an upstream CDN and a downstream direct interaction between an upstream CDN and a downstream CDN--
CDN-\u002Doperate exactly as in a pair-wise peering arrangement. operate exactly as in a pair-wise peering arrangement. Turning to
Turning to Figure 14, we observe that in this example: Figure 14, we observe that in this example:
o each CDN supports a direct CDNI Control interface to every other o each CDN supports a direct CDNI Control interface to every other
CDN CDN
o each CDN supports a direct CDNI Metadata interface to every other o each CDN supports a direct CDNI Metadata interface to every other
CDN CDN
o each CDN supports a CDNI Logging interface with the CDN Exchange o each CDN supports a CDNI Logging interface with the CDN Exchange
o each CDN supports both a CDNI Request Routing interfaces with the o each CDN supports both a CDNI Request Routing interfaces with the
skipping to change at page 50, line 5 skipping to change at page 52, line 15
will be specified in the relevant interface documents. will be specified in the relevant interface documents.
8.2. Digital Rights Management 8.2. Digital Rights Management
Issues of digital rights management (DRM, also sometimes called Issues of digital rights management (DRM, also sometimes called
digital restrictions management) is often employed for content digital restrictions management) is often employed for content
distributed via CDNs. In general, DRM relies on the CDN to distributed via CDNs. In general, DRM relies on the CDN to
distribute encrypted content, with decryption keys distributed to distribute encrypted content, with decryption keys distributed to
users by some other means (e.g. directly from the CSP to the end users by some other means (e.g. directly from the CSP to the end
user.) For this reason, DRM is considered out of scope for the CDNI user.) For this reason, DRM is considered out of scope for the CDNI
WG RFC 6707 and does not introduce additional security issues for WG [RFC6707] and does not introduce additional security issues for
CDNI. CDNI.
9. Contributors 9. Contributors
The following individuals contributed to this document: The following individuals contributed to this document:
o Ray van Brandenburg o Ray van Brandenburg
o Matt Caulfield o Matt Caulfield
skipping to change at page 50, line 34 skipping to change at page 52, line 44
o Ben Niven-Jenkins o Ben Niven-Jenkins
o Kent Leung o Kent Leung
10. Acknowledgements 10. Acknowledgements
We thank Huw Jones for helpful input to the draft. We thank Huw Jones for helpful input to the draft.
11. Informative References 11. Informative References
[I-D.bertrand-cdni-logging]
Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F.,
and P. Grochocki, "CDNI Logging Interface", draft-
bertrand-cdni-logging-02 (work in progress), October 2012.
[I-D.ietf-appsawg-http-forwarded] [I-D.ietf-appsawg-http-forwarded]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-10 (work in progress), draft-ietf-appsawg-http-forwarded-10 (work in progress),
October 2012. October 2012.
[I-D.ietf-cdni-control-triggers]
Murray, R. and B. Niven-Jenkins, "CDNI Control Interface /
Triggers", draft-ietf-cdni-control-triggers-02 (work in
progress), December 2013.
[I-D.ietf-cdni-footprint-capabilities-semantics]
Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R.,
and K. Ma, "CDNI Request Routing: Footprint and
Capabilities Semantics", draft-ietf-cdni-footprint-
capabilities-semantics-01 (work in progress), October
2013.
[I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-08 (work in progress), October 2013.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
ietf-cdni-metadata-03 (work in progress), October 2013. ietf-cdni-metadata-04 (work in progress), December 2013.
[I-D.ietf-cdni-redirection]
Danhua, W., Niven-Jenkins, B., He, X., Chen, G., and W.
Ni, "Request Routing Redirection Interface for CDN
Interconnection", draft-ietf-cdni-redirection-01 (work in
progress), October 2013.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", draft-ietf-cdni- Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-12 (work in progress), November 2013. requirements-14 (work in progress), December 2013.
[I-D.lefaucheur-cdni-logging-delivery]
Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI
Logging Formats for HTTP and HTTP Adaptive Streaming
Deliveries", draft-lefaucheur-cdni-logging-delivery-01
(work in progress), July 2012.
[I-D.murray-cdni-triggers]
Murray, R. and B. Niven-Jenkins, "CDNI Control Interface /
Triggers", draft-murray-cdni-triggers-03 (work in
progress), April 2013.
[I-D.seedorf-alto-for-cdni]
Seedorf, J., "ALTO for CDNi Request Routing", draft-
seedorf-alto-for-cdni-00 (work in progress), October 2011.
[I-D.spp-cdni-rr-foot-cap-semantics]
Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R.,
and K. Ma, "CDNI Request Routing: Footprint and
Capabilities Semantics", draft-spp-cdni-rr-foot-cap-
semantics-04 (work in progress), February 2013.
[I-D.vandergaast-edns-client-subnet] [I-D.vandergaast-edns-client-subnet]
Contavalli, C., Gaast, W., Leach, S., and E. Lewis, Contavalli, C., Gaast, W., Leach, S., and E. Lewis,
"Client Subnet in DNS Requests", draft-vandergaast-edns- "Client Subnet in DNS Requests", draft-vandergaast-edns-
client-subnet-02 (work in progress), July 2013. client-subnet-02 (work in progress), July 2013.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466, February for Content Internetworking (CDI)", RFC 3466, February
2003. 2003.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, October
2009.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012. Interconnection", RFC 6770, November 2012.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
 End of changes. 81 change blocks. 
447 lines changed or deleted 449 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/