draft-ietf-cdni-framework-04.txt   draft-ietf-cdni-framework-05.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: February 22, 2014 August 21, 2013 Expires: March 13, 2014 September 09, 2013
Framework for CDN Interconnection Framework for CDN Interconnection
draft-ietf-cdni-framework-04 draft-ietf-cdni-framework-05
Abstract Abstract
This document presents a framework for Content Distribution Network This document presents a framework for Content Distribution Network
Interconnection (CDNI). The purpose of the framework is to provide Interconnection (CDNI). The purpose of the framework is to provide
an overall picture of the problem space of CDNI and to describe the an overall picture of the problem space of CDNI and to describe the
relationships among the various components necessary to interconnect relationships among the various components necessary to interconnect
CDNs. CDN Interconnection requires the specification of several CDNs. CDN Interconnection requires the specification of several
interfaces and mechanisms to address issues such as request routing, interfaces and mechanisms to address issues such as request routing,
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 February 22, 2014. This Internet-Draft will expire on March 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . 26
3.7. Pre-Positioned Content Acquisition Example . . . . . . . 27 3.7. Pre-Positioned Content Acquisition Example . . . . . . . 27
3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 29 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 28
3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 31 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 30
3.10. Content and Metadata Acquisition with Multiple Upstream 3.10. Content and Metadata Acquisition with Multiple Upstream
CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34
4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 35 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 34
4.3. Request Routing Interface . . . . . . . . . . . . . . . . 35 4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 35
4.4. Logging Interface . . . . . . . . . . . . . . . . . . . . 36 4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 36
4.5. Control Interface . . . . . . . . . . . . . . . . . . . . 38 4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 38
4.6. Metadata Interface . . . . . . . . . . . . . . . . . . . 38 4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 38
4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39
4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 41 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 41
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 42 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 41
5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42
5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43
5.3. CSP using CDNI Request Routing Interface . . . . . . . . 44 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 44
5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 45 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 45
6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 47 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 46
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48
8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 50 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 49
8.2. Digital Rights Management . . . . . . . . . . . . . . . . 50 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 50
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
11. Informative References . . . . . . . . . . . . . . . . . . . 51 11. Informative References . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
The interconnection of Content Distribution Networks (CDNs) is The interconnection of Content Distribution Networks (CDNs) is
motivated by several use cases, such as those described in motivated by several use cases, such as those described in
[I-D.ietf-cdni-use-cases]. The overall problem space for CDN [I-D.ietf-cdni-use-cases]. The overall problem space for CDN
Interconnection is described in RFC 6707. The purpose of this Interconnection is described in RFC 6707. The purpose of this
document is to provide an overview of the various components document is to provide an overview of the various components
skipping to change at page 4, line 18 skipping to change at page 4, line 18
Recursive CDNI Request Redirection: When an Upstream CDN elects to Recursive CDNI Request Redirection: When an Upstream CDN elects to
redirect a request towards a Downstream CDN, the Upstream CDN can redirect a request towards a Downstream CDN, the Upstream CDN can
query the Downstream CDN Request Routing system via the CDNI Request query the Downstream CDN Request Routing system via the CDNI Request
Routing Redirection Interface (or use information cached from earlier Routing Redirection Interface (or use information cached from earlier
similar queries) to find out how the Downstream CDN wants the request similar queries) to find out how the Downstream CDN wants the request
to be redirected, which allows the Upstream CDN to factor in the to be redirected, which allows the Upstream CDN to factor in the
Downstream CDN response when redirecting the user agent. This Downstream CDN response when redirecting the user agent. This
approach is referred to as "Recursive" CDNI Request Redirection. approach is referred to as "Recursive" CDNI Request Redirection.
Note that the Downstream CDN may elect to have the request redirected Note that the Downstream CDN may elect to have the request redirected
directly to a Surrogate inside the Downstream CDN, to the Request- directly to a Surrogate inside the Downstream CDN, to the Request
Routing System of the Downstream CDN, to another CDN, or to any other Routing System of the Downstream CDN, to another CDN, or to any other
system that the Downstream CDN sees as fit for handling the system that the Downstream CDN sees as fit for handling the
redirected request. redirected request.
Iterative CDNI Request Redirection: When an Upstream CDN elects to Iterative CDNI Request Redirection: When an Upstream CDN elects to
redirect a request towards a Downstream CDN, the Upstream CDN can redirect a request towards a Downstream CDN, the Upstream CDN can
base its redirection purely on a local decision (and without base its redirection purely on a local decision (and without
attempting to take into account how the Downstream CDN may in turn attempting to take into account how the Downstream CDN may in turn
redirect the user agent). In that case, the Upstream CDN redirects redirect the user agent). In that case, the Upstream CDN redirects
the request to the request routing system in the Downstream CDN, the request to the request routing system in the Downstream CDN,
skipping to change at page 4, line 42 skipping to change at page 4, line 42
Synchronous CDNI operations: operations between CDNs that happen Synchronous CDNI operations: operations between CDNs that happen
during the process of servicing a user request, i.e. between the time during the process of servicing a user request, i.e. between the time
that the user agent begins its attempt to obtain content and the time that the user agent begins its attempt to obtain content and the time
at which that request is served. at which that request is served.
Asynchronous CDNI operations: operations between CDNs that happen Asynchronous CDNI operations: operations between CDNs that happen
independently of any given user request, such as advertisement of independently of any given user request, such as advertisement of
footprint information or pre-positioning of content for later footprint information or pre-positioning of content for later
delivery. delivery.
Trigger Interface: a sub-set of the Control Interface that includes Trigger Interface: a subset of the CDNI Control interface that
operations to pre-position, revalidate, and purge both metadata and includes operations to pre-position, revalidate, and purge both
content. These operations are typically called in response to some metadata and content. These operations are typically called in
action (trigger) by the CSP on the upstream CDN. response to some action (trigger) by the CSP on the upstream CDN.
1.2. Reference Model 1.2. Reference Model
This document uses the reference model in Figure 1, which extends the
This document uses the reference model in Figure 1, which expands the
reference model originally defined in RFC 6707. (The difference is reference model originally defined in RFC 6707. (The difference is
that the extended model splits the Request Routing Interface into two that the expanded model splits the Request Routing Interface into its
distinct parts: the Request Routing Redirection Interface and the two distinct parts: the Request Routing Redirection interface and the
Footprint and Capability Interface, as described below.) Footprint and Capabilities Advertisement interface, as described
below.)
-------- --------
/ \ / \
| CSP | | CSP |
\ / \ /
-------- --------
* *
* *
* /\ * /\
* / \ * / \
---------------------- |CDNI| ---------------------- ---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \ / Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control Interface| +-------------+ | | +-------------+ | | CI | | +-------------+ |
|******* Control |<======|====|========>| Control *******| |******* Control |<======|====|=======>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *| |* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *| |* * * | | | | * * *|
|* +------*------+ | Logging Interface| +------*------+ *| |* +------*------+ | | LI | | +------*------+ *|
|* ***** Logging |<======|====|========>| Logging ***** *| |* ***** Logging |<======|====|=======>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *| |* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | RR Redirection | * * * *| |* * * * | | | | * * * *|
.....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... .....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*...
. |* * | |<======|====|========>| | * *| . . |* * | |<======|====|=======>| | * *| .
. |* * | Req-Routing | | Foot & Cap Int | | Req-Routing | * *| . . |* * | Req-Routing | | |FCI | | | Req-Routing | * *| .
. |* * *** |<======|====|========>| |** * *| . . |* * *** |<======|====|=======>| |** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| . . |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . CDNI Metadata | * * *| . . |* * * . | | | * * *| .
. |* * * +-------------+ |. Interface | +-------------+ * * *| . . |* * * +-------------+ |. | MI | | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . . |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| . . |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| . . |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ....Request......+---------+ |*** * *| . . |* * ***| +---------+| | ...Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|************************|Surrogate|-+***** *| . . |* *****+-|Surrogate|***********************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| . . |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | . . | +-------------+ | | +-------*-----+ | .
. \ / \ * / . . \ / \ * / .
. ---------------------- ---------*------------ . . ---------------------- ---------*------------ .
. * . . * .
. * Delivery . . * Delivery .
. * . . * .
. +--*---+ . . +--*---+ .
...............Request.............................| User |..Request.. ...............Request............................| User |..Request..
| Agent| | Agent|
+------+ +------+
<==> interfaces inside the scope of CDNI <==> interfaces inside the scope of CDNI
**** interfaces outside the scope of CDNI **** interfaces outside the scope of CDNI
.... interfaces outside the scope of CDNI .... interfaces outside the scope of CDNI
Figure 1: CDNI Model and CDNI Interfaces Figure 1: CDNI Expanded Model and CDNI Interfaces
We note that while some interfaces in the reference model are "out of We note that while some interfaces in the reference model are "out of
scope" for the CDNI WG (in the sense that there is no need to define scope" for the CDNI WG (in the sense that there is no need to define
new protocols for those interfaces) we still need to refer to them in new protocols for those interfaces) we still need to refer to them in
this document to explain the overall operation of CDNI. this document to explain the overall operation of CDNI.
We also note that, while we generally show only one uCDN serving a We also note that, while we generally show only one uCDN serving a
given CSP, it is entirely possible that multiple uCDNs can serve a given CSP, it is entirely possible that multiple uCDNs can serve a
single CSP. In fact, this situation effectively exists today in the single CSP. In fact, this situation effectively exists today in the
sense that a single CSP can currently delegate its content delivery sense that a single CSP can currently delegate its content delivery
to more than one CDN. to more than one CDN.
The following briefly describes the five CDNI interfaces, The following briefly describes the five CDNI interfaces,
paraphrasing the definitions given in RFC 6707. We discuss these paraphrasing the definitions given in RFC 6707. We discuss these
interfaces in more detail in Section 4. interfaces in more detail in Section 4.
o CDNI Control Interface (CI): Operations to bootstrap and o CDNI Control interface (CI): Operations to bootstrap and
parameterize the other CDNI interfaces, as well as operations to parameterize the other CDNI interfaces, as well as operations to
pre-position, revalidate, and purge both metadata and content. pre-position, revalidate, and purge both metadata and content.
The latter sub-set of operations is sometimes collectively called The latter subset of operations is sometimes collectively called
the "trigger interface." the "trigger interface."
o CDNI Request Routing Interface: Operations to determine what CDN o CDNI Request Routing interface: Operations to determine what CDN
(and optionally what surrogate within a CDN) is to serve end- (and optionally what surrogate within a CDN) is to serve end-
user's requests. Is actually a logical bundling of two separate user's requests. Is actually a logical bundling of two separate
but related interfaces: but related interfaces:
* Footprint & Capability Interface (FCI): Asynchronous operations * CDNI Footprint & Capabilities Advertisement interface (FCI):
to exchange routing information (e.g., the network footprint Asynchronous operations to exchange routing information (e.g.,
and capabilities served by a given CDN) that enables CDN the network footprint and capabilities served by a given CDN)
selection for subsequent user requests; and that enables CDN selection for subsequent user requests; and
* Request Routing Redirection (RI): Synchronous operations to * CDNI Request Routing Redirection interface (RI): Synchronous
select a delivery CDN (surrogate) for a given user request. operations to select a delivery CDN (surrogate) for a given
user request.
o CDNI Metadata Interface (MI): Operations to communicate metadata o CDNI Metadata interface (MI): Operations to communicate metadata
that governs the how content is delivered by interconnected CDNs. that governs how the content is delivered by interconnected CDNs.
Examples of CDNI metadata include geo-blocking directives, Examples of CDNI metadata include geo-blocking directives,
availability windows, access control mechanisms, and purge availability windows, access control mechanisms, and purge
directives. May include a combination of: directives. May include a combination of:
* Asynchronous operations to exchange metadata that govern * Asynchronous operations to exchange metadata that govern
subsequent user requests for content; and subsequent user requests for content; and
* Synchronous operations that govern behavior for a given user * Synchronous operations that govern behavior for a given user
request for content. request for content.
o CDNI Logging Interface (LI): Operations that allow interconnected o CDNI Logging interface (LI): Operations that allow interconnected
CDNs to exchange relevant activity logs. May include a CDNs to exchange relevant activity logs. May include a
combination of: combination of:
* Real-time exchanges, suitable for runtime traffic monitoring; * Real-time exchanges, suitable for runtime traffic monitoring;
and and
* Off-line exchanges, suitable for analytics and billing. * Offline exchanges, suitable for analytics and billing.
There is some potential overlap between the set of trigger-based There is some potential overlap between the set of trigger-based
operations in the Control Interface and the Metadata Interface. For operations in the CDNI Control interface and the CDNI Metadata
both cases, the information passed from the upstream CDN to the interface. For both cases, the information passed from the upstream
downstream CDN can broadly be viewed as metadata that describes how CDN to the downstream CDN can broadly be viewed as metadata that
content is to be managed by the downstream CDN. For example, the describes how content is to be managed by the downstream CDN. For
information conveyed by Control operations to pre-position, example, the information conveyed by CI to pre-position, revalidate
revalidate or purge metadata is similar to the information conveyed or purge metadata is similar to the information conveyed by posting
by posting updated metadata via the Metadata Interface. Even the updated metadata via the MI. Even the CI operation to purge content
Control operation to purge content could be viewed as an metadata could be viewed as an metadata update for that content: purge simply
update for that content: purge simply says that the availability says that the availability window for the named content ends now.
window for the named content ends now. The two interfaces share much The two interfaces share much in common, so minimally, there will
in common, so minimally, there will need to be a consistent data need to be a consistent data model that spans both.
model that spans both.
The distinction we draw has to do with what the caller knows about The distinction we draw has to do with what the caller knows about
the successful application of the metadata by the callee. In the the successful application of the metadata by the callee. In the
case of the Control Interface, the downstream CDN returning a case of the CI, the downstream CDN returning a successful status
successful status message guarantees that the operation has been message guarantees that the operation has been successfully
successfully completed; e.g., the content has been purged or pre- completed; e.g., the content has been purged or pre-positioned. This
positioned. This implies that the downstream CDN accepts implies that the downstream CDN accepts responsibility for having
responsibility for having successfully completed the requested successfully completed the requested operation. In contrast,
operation. In contrast, metadata passed between CDNs via the metadata passed between CDNs via the MI carries no such completion
Metadata Interface carries no such completion guarantee. Returning guarantee. Returning success implies successful receipt of the
success implies successful receipt of the metadata, but nothing can metadata, but nothing can be inferred about precisely when the
be inferred about precisely when the metadata will take effect in the metadata will take effect in the downstream CDN, only that it will
downstream CDN, only that it will take effect eventually. This is take effect eventually. This is because of the challenge in globally
because of the challenge in globally synchronizing updates to synchronizing updates to metadata with end-user requests that are
metadata with end-user requests that are currently in progress (or currently in progress (or indistinguishable from currently being in
indistinguishable from currently being in progress). Clearly, a CDN progress). Clearly, a CDN will not be viewed as a trusted peer if
will not be viewed as a trusted peer if "eventually" often becomes an "eventually" often becomes an indefinite period of time, but the
indefinite period of time, but the acceptance of responsibility acceptance of responsibility cannot be as crisply defined for the MI.
cannot be as crisply defined for the Metadata Interface.
Finally, there is a practical issue that impacts all of the CNDI Finally, there is a practical issue that impacts all of the CNDI
interfaces, and that is whether or not to optimize CDNI for HTTP interfaces, and that is whether or not to optimize CDNI for HTTP
Adaptive Streaming (HAS). We highlight specific issues related to Adaptive Streaming (HAS). We highlight specific issues related to
delivering HAS content throughout this document, but for a more delivering HAS content throughout this document, but for a more
thorough treatment of the topic, see [I-D.brandenburg-cdni-has]. thorough treatment of the topic, see [I-D.brandenburg-cdni-has].
1.3. Structure Of This Document 1.3. Structure Of This Document
The remainder of this document is organized as follows: The remainder of this document is organized as follows:
skipping to change at page 10, line 9 skipping to change at page 9, line 44
HTTP redirection makes use of the redirection response of the HTTP HTTP redirection makes use of the redirection response of the HTTP
protocol (e.g.,"302" or "307"). This response contains a new URL protocol (e.g.,"302" or "307"). This response contains a new URL
that the application should fetch instead of the original URL. By that the application should fetch instead of the original URL. By
changing the URL appropriately, the server can cause the user to changing the URL appropriately, the server can cause the user to
redirect to a different server. The advantages of HTTP redirection redirect to a different server. The advantages of HTTP redirection
are that (1) the server can change the URL fetched by the client to are that (1) the server can change the URL fetched by the client to
include, for example, both the DNS name of the particular server to include, for example, both the DNS name of the particular server to
use, as well as the original HTTP server that was being accessed; (2) use, as well as the original HTTP server that was being accessed; (2)
the client sends the HTTP request to the server, so that its IP the client sends the HTTP request to the server, so that its IP
address is known and can be used in selecting the server; and (3) address is known and can be used in selecting the server; and (3)
other attributes (e.g., content type, user-agent type) are visible to other attributes (e.g., content type, user agent type) are visible to
the redirection mechanism. the redirection mechanism.
The disadvantages of HTTP redirection are (1) it is visible to the The disadvantages of HTTP redirection are (1) it is visible to the
application, so it requires application support and may affect the application, so it requires application support and may affect the
application behavior (e.g., web browsers will not send cookies if the application behavior (e.g., web browsers will not send cookies if the
URL changes to a different domain); (2) HTTP is a heavy-weight URL changes to a different domain); (2) HTTP is a heavyweight
protocol layered on TCP so it has relatively high overhead; and (3) protocol layered on TCP so it has relatively high overhead; and (3)
the results of HTTP redirection are not cached so that all the results of HTTP redirection are not cached so that all
redirections must go through to the server. redirections must go through to the server.
3. Overview of CDNI Operation 3. Overview of CDNI Operation
To provide a big-picture overview of the various components of CDN To provide a big picture overview of the various components of CDN
Interconnection, we walk through a "day in the life" of a content Interconnection, we walk through a "day in the life" of a content
item that is made available via a pair of interconnected CDNs. This item that is made available via a pair of interconnected CDNs. This
will serve to illustrate many of the functions that need to be will serve to illustrate many of the functions that need to be
supported in a complete CDNI solution. We give examples using both supported in a complete CDNI solution. We give examples using both
DNS-based and HTTP-based redirection. We begin with very simple DNS-based and HTTP-based redirection. We begin with very simple
examples and then how additional capabilities, such as recursive examples and then how additional capabilities, such as recursive
request redirection and content removal, might be added. request redirection and content removal, might be added.
Before walking through some specific examples, we present a high- Before walking through some specific examples, we present a high-
level view of the operations that may take place. This high-level level view of the operations that may take place. This high-level
skipping to change at page 17, line 35 skipping to change at page 17, line 28
another example, some video players enforce validation of a cross another example, some video players enforce validation of a cross
domain policy that needs to allow for the domains involved in the CDN domain policy that needs to allow for the domains involved in the CDN
redirection. These problems are generally soluble, but the solutions redirection. These problems are generally soluble, but the solutions
complicate the example, so we do not discuss them further in this complicate the example, so we do not discuss them further in this
version of the draft. version of the draft.
We note that this example begins to illustrate some of the interfaces We note that this example begins to illustrate some of the interfaces
that may be required for CDNI, but does not require all of them. For that may be required for CDNI, but does not require all of them. For
example, obtaining information from dCDN regarding the set of client example, obtaining information from dCDN regarding the set of client
IP addresses or geographic regions it might be able to serve is an IP addresses or geographic regions it might be able to serve is an
aspect of the CDNI request routing interface (specifically of the aspect of request routing (specifically of the CDNI Footprint &
CDNI Footprint and Capabilities Interface). Important configuration Capabilities Advertisement interface). Important configuration
information such as the distinguished names used for redirection and information such as the distinguished names used for redirection and
inter-CDN acquisition could also be conveyed via a CDNI interface inter-CDN acquisition could also be conveyed via a CDNI interface
(e.g., perhaps the Control Interface). The example also shows how (e.g., perhaps the CDNI Control interface). The example also shows
existing HTTP-based methods suffice for the acquisition interface. how existing HTTP-based methods suffice for the acquisition
Arguably, the absolute minimum metadata required for CDNI is the interface. Arguably, the absolute minimum metadata required for CDNI
information required to acquire the content, and this information was is the information required to acquire the content, and this
provided "in-band" in this example by means of the URI handed to the information was provided "in-band" in this example by means of the
client in the HTTP 302 response. The example also assumes that the URI handed to the client in the HTTP 302 response. The example also
CSP does not require any distribution policy (e.g. time window, geo- assumes that the CSP does not require any distribution policy (e.g.
blocking) or delivery processing to be applied by the interconnected time window, geo-blocking) or delivery processing to be applied by
CDNs. Hence, there is no explicit Metadata Interface invoked in this the interconnected CDNs. Hence, there is no explicit CDNI Metadata
example. There is also no explicit Logging Interface discussed in interface invoked in this example. There is also no explicit CDNI
this example. Logging interface discussed in this example.
We also note that the step of deciding when a request should be We also note that the step of deciding when a request should be
redirected to dCDN rather than served by uCDN has been somewhat redirected to dCDN rather than served by uCDN has been somewhat
glossed over. It may be as simple as checking the client IP address glossed over. It may be as simple as checking the client IP address
against a list of prefixes, or it may be considerably more complex, against a list of prefixes, or it may be considerably more complex,
involving a wide range of factors, such as the geographic location of involving a wide range of factors, such as the geographic location of
the client (perhaps determined from a third party service), CDN load, the client (perhaps determined from a third party service), CDN load,
or specific business rules. or specific business rules.
This example uses the "iterative" CDNI request redirection approach. This example uses the "iterative" CDNI request redirection approach.
skipping to change at page 18, line 29 skipping to change at page 18, line 21
two successive HTTP redirections. By contrast, the alternative two successive HTTP redirections. By contrast, the alternative
approach of "recursive" CDNI request redirection effectively approach of "recursive" CDNI request redirection effectively
coalesces these two successive HTTP redirections into a single one, coalesces these two successive HTTP redirections into a single one,
sending the end-user directly to the right delivery node in the dCDN. sending the end-user directly to the right delivery node in the dCDN.
This "recursive" CDNI request routing approach is discussed in the This "recursive" CDNI request routing approach is discussed in the
next section. next section.
3.3. Recursive HTTP Redirection Example 3.3. Recursive HTTP Redirection Example
The following example builds on the previous one to illustrate the The following example builds on the previous one to illustrate the
use of the Request Routing Interface (specifically the CDNI Request use of the request routing interface (specifically the CDNI Request
Routing Redirection Interface) to enable "recursive" CDNI request Routing Redirection interface) to enable "recursive" CDNI request
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
skipping to change at page 20, line 33 skipping to change at page 20, line 22
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. A DNS resolver for Operator A processes the DNS request for its 1. A DNS resolver for Operator A processes the DNS request for its
customer based on CDN-Domain cdn.csp.com. It returns the IP customer based on CDN-Domain cdn.csp.com. It returns the IP
address of a Request Router in Operator A. address of a Request Router in Operator A.
2. A Request Router for Operator A processes the HTTP request and 2. A Request Router for Operator A processes the HTTP request and
recognizes that the end-user is best served by another recognizes that the end-user is best served by another
CDN-\u002Dspecifically one provided by Operator B-\u002Dand so it CDN-\u002Dspecifically one provided by Operator B-\u002Dand so it
queries the CDNI Request Routing Redirection Interface of queries the CDNI Request Routing Redirection interface of
Operator B, providing a set of information about the request Operator B, providing a set of information about the request
including the URL requested. Operator B replies with the DNS including the URL requested. Operator B replies with the DNS
name of a delivery node. name of a delivery node.
3. Operator A returns a 302 redirect message for a new URL obtained 3. Operator A returns a 302 redirect message for a new URL obtained
from the Request Routing Interface. from the 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.net). B's DNS resolver returns the IP
address of the corresponding delivery node. Note that, since the address of the corresponding delivery node. Note that, since the
name of the delivery node was already obtained from B using the name of the delivery node was already obtained from B using the
CDNI Request Routing Interface, there should not be any further RI, there should not be any further redirection here (in contrast
redirection here (in contrast to the iterative method described to the iterative method described above.)
above.)
5. The end-user requests the content from B's delivery node, 5. The end-user requests the content from B's delivery node,
potentially resulting in a cache miss. In the case of a cache potentially resulting in a cache miss. In the case of a cache
miss, the content needs to be acquired from uCDN (not the CSP.) miss, the content needs to be acquired from uCDN (not the CSP.)
The distinguished CDN-Domain op-b.net indicates to dCDN that this The distinguished CDN-Domain op-b.net indicates to dCDN that this
content is to be acquired from another CDN; stripping the CDN- content is to be acquired from another CDN; stripping the CDN-
Domain reveals the original CDN-Domain cdn.csp.com, dCDN may Domain reveals the original CDN-Domain cdn.csp.com, dCDN may
verify that this CDN-Domain belongs to a known peer (so as to verify that this CDN-Domain belongs to a known peer (so as to
avoid being tricked into serving as an open proxy). It then does avoid being tricked into serving as an open proxy). It then does
a DNS request for the inter-CDN Acquisition "distinguished" CDN- a DNS request for the inter-CDN Acquisition "distinguished" CDN-
skipping to change at page 22, line 12 skipping to change at page 21, line 49
redirection does not require dCDN to expose the addresses of its edge redirection does not require dCDN to expose the addresses of its edge
caches to uCDN. caches to uCDN.
This example happens to use HTTP-based redirection in both CDN A and This example happens to use HTTP-based redirection in both CDN A and
CDN B, but a similar example could be constructed using DNS-based CDN B, but a similar example could be constructed using DNS-based
redirection in either CDN. Hence, the key point to take away here is redirection in either CDN. Hence, the key point to take away here is
simply that the end user only sees a single redirection of some type, simply that the end user only sees a single redirection of some type,
as opposed to the pair of redirections in the prior (iterative) as opposed to the pair of redirections in the prior (iterative)
example. example.
The use of the Request Routing Interface requires that interface to The use of the RI requires that the request routing mechanism be
be appropriately configured and bootstrapped, which is not shown appropriately configured and bootstrapped, which is not shown here.
here. More discussion on the bootstrapping of interfaces is provided More discussion on the bootstrapping of interfaces is provided in
in Section 4 Section 4
3.4. Iterative DNS-based Redirection Example 3.4. Iterative DNS-based Redirection Example
In this section we walk through a simple example using DNS-based In this section we walk through a simple example using DNS-based
redirection for request redirection from uCDN to dCDN (as well as for redirection for request redirection from uCDN to dCDN (as well as for
request routing inside dCDN and uCDN). As noted in Section 2.1, DNS- request routing inside dCDN and uCDN). As noted in Section 2.1, DNS-
based redirection has certain advantages over HTTP-based redirection based redirection has certain advantages over HTTP-based redirection
(notably, it is transparent to the end-user) as well as some (notably, it is transparent to the end-user) as well as some
drawbacks (notably the client IP address is not visible to the drawbacks (notably the client IP address is not visible to the
request router). request router).
skipping to change at page 25, line 8 skipping to change at page 24, line 43
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
prefix is correctly determined in such situations is described in prefix is correctly determined in such situations is described in
[I-D.vandergaast-edns-client-subnet]. [I-D.vandergaast-edns-client-subnet].
As with the prior example, this example partially illustrates the As with the prior example, this example partially illustrates the
various interfaces involved in CDNI. Operator A could learn various interfaces involved in CDNI. Operator A could learn
dynamically from Operator B the set of prefixes or regions that B is dynamically from Operator B the set of prefixes or regions that B is
willing and able to serve via the Footprint & Capabilities Interface. willing and able to serve via the CDNI Footprint & Capabilities
The distinguished name used for acquisition and the identifier for Advertisement interface. The distinguished name used for acquisition
Operator B that is prepended to the CDN-Domain on redirection are and the identifier for Operator B that is prepended to the CDN-Domain
examples of information elements that might also be conveyed by CDNI on redirection are examples of information elements that might also
interfaces (or, alternatively, statically configured). As before, be conveyed by CDNI interfaces (or, alternatively, statically
minimal metadata sufficient to obtain the content is carried "in- configured). As before, minimal metadata sufficient to obtain the
band" as part of the redirection process, and standard HTTP is used content is carried "in-band" as part of the redirection process, and
for inter-CDN acquisition. There is no explicit Logging Interface standard HTTP is used for inter-CDN acquisition. There is no
discussed in this example. explicit CDNI Logging interface discussed in this example.
3.5. Dynamic Footprint Discovery Example 3.5. Dynamic Footprint Discovery Example
There could be situations where being able to dynamically discover There could be situations where being able to dynamically discover
the set of requests that a given dCDN is willing and able to serve is the set of requests that a given dCDN is willing and able to serve is
beneficial. For example, a CDN might at one time be able to serve a beneficial. For example, a CDN might at one time be able to serve a
certain set of client IP prefixes, but that set might change over certain set of client IP prefixes, but that set might change over
time due to changes in the topology and routing policies of the IP time due to changes in the topology and routing policies of the IP
network. The following example illustrates this capability. We have network. The following example illustrates this capability. We have
chosen the example of DNS-based redirection, but HTTP-based chosen the example of DNS-based redirection, but HTTP-based
skipping to change at page 26, line 17 skipping to change at page 26, line 6
| |------------------------>| | |------------------------>|
| | |(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 CDNI Request Routing Interface Footprint request (step 2) and a FCI request (step 2) and corresponding response (step 3). The RI
corresponding response (step 3). The RI REQ could be a message such REQ could be a message such as "Can you serve clients from this IP
as "Can you serve clients from this IP Prefix?" or it could be Prefix?" or it could be "Provide the list of client IP prefixes you
"Provide the list of client IP prefixes you can currently serve". In can currently serve". In either case the response might be cached by
either case the response might be cached by operator A to avoid operator A to avoid repeatedly asking the same question.
repeatedly asking the same question. Alternatively, or in addition, Alternatively, or in addition, Operator B may spontaneously advertise
Operator B may spontaneously advertise to Operator A information (or to Operator A information (or changes) on the set of requests it is
changes) on the set of requests it is willing and able to serve on willing and able to serve on behalf of operator A; in that case,
behalf of operator A; in that case, Operator B may spontaneously Operator B may spontaneously issue RR/RI REPLY messages that are not
issue RR/RI REPLY messages that are not in direct response to a in direct response to a corresponding RR/RI REQ message. (Note that
corresponding RR/RI REQ message. (Note that the issues of the issues of determining the client's subnet from DNS requests, as
determining the client's subnet from DNS requests, as described described above, are exactly the same here as in Section 3.4.)
above, are exactly the same here as in Section 3.4.)
Once Operator A obtains the RI response, it is now able to determine Once Operator A obtains the RI response, it is now able to determine
that Operator B's CDN is an appropriate dCDN for this request and that Operator B's CDN is an appropriate dCDN for this request and
therefore a valid candidate dCDN to consider in its Redirection therefore a valid candidate dCDN to consider in its Redirection
decision. If that dCDN is selected, the redirection and serving of decision. If that dCDN is selected, the redirection and serving of
the request proceeds as before (i.e. in the absence of dynamic the request proceeds as before (i.e. in the absence of dynamic
footprint discovery). footprint discovery).
3.6. Content Removal Example 3.6. Content Removal Example
The following example illustrates how the Control Interface may be The following example illustrates how the CDNI Control interface may
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 Control corresponding trigger from the Content Provider) uses the CI to
Interface to request that content identified by a particular URL be request that content identified by a particular URL be removed from
removed from dCDN. The following diagram illustrates the operation. dCDN. The following diagram illustrates the operation.
End-User Operator B Operator A End-User Operator B Operator A
| |CI purge cdn.csp.com/... | | |CI purge cdn.csp.com/... |
| |<------------------------| | |<------------------------|
| | | | | |
| |CI OK | | |CI OK |
| |------------------------>| | |------------------------>|
| | | | | |
Figure 7: Message Flow for Content Removal Figure 7: Message Flow for Content Removal
The Control Interface is used to convey the request from uCDN to dCDN The CI is used to convey the request from uCDN to dCDN that some
that some previously acquired content should be deleted. The URL in previously acquired content should be deleted. The URL in the
the request specifies which content to remove. This example request specifies which content to remove. This example corresponds
corresponds to a DNS-based redirection scenario such as Section 3.4. to a DNS-based redirection scenario such as Section 3.4. If HTTP-
If HTTP-based redirection had been used, the URL for removal would be based redirection had been used, the URL for removal would be of the
of the form peer-a.op-b.net/cdn.csp.com/... form peer-a.op-b.net/cdn.csp.com/...
The dCDN is expected to confirm to the uCDN, as illustrated by the CI The dCDN is expected to confirm to the uCDN, as illustrated by the CI
OK message, the completion of the removal of the targeted content OK message, the completion of the removal of the targeted content
from all the caches in dCDN. from all the caches in dCDN.
3.7. Pre-Positioned Content Acquisition Example 3.7. Pre-Positioned Content Acquisition Example
The following example illustrates how the Control Interface may be The following example illustrates how the CI may be used to pre-
used to pre-position an item of content in the dCDN. In this position an item of content in the dCDN. In this example, Operator A
example, Operator A uses the Metadata Interface to request that uses the CDNI Metadata interface to request that content identified
content identified by a particular URL be pre-positioned into by a particular URL be pre-positioned into Operator B CDN.
Operator B CDN.
End-User Operator B Operator A End-User Operator B Operator A
| |CI pre-position cdn.csp.com/... | |CI pre-position cdn.csp.com/...
| |<------------------------| | |<------------------------|
| | |(1) | | |(1)
| |CI OK | | |CI OK |
| |------------------------>| | |------------------------>|
| | | | | |
| |DNS op-b-acq.op-a.net | | |DNS op-b-acq.op-a.net |
skipping to change at page 28, line 27 skipping to change at page 28, line 13
|HTTP peer-a.op-b.net/cdn.csp.com | |HTTP peer-a.op-b.net/cdn.csp.com |
|------------------------>| | |------------------------>| |
| |(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 Control Interface to request that Operator B 1. Operator A uses the CI to request that Operator B pre-positions a
pre-positions a particular content item identified by its URL. particular content item identified by its URL. Operator B
Operator B responds by confirming that it is willing to perform responds by confirming that it is willing to perform this
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 Figure
3, only this time Operator B CDN can serve the end-user request 3, only this time Operator B CDN can serve the end-user request
without triggering dynamic content acquisition, since the content has without triggering dynamic content acquisition, since the content has
been pre-positioned in dCDN. Note that, depending on dCDN operations been pre-positioned in dCDN. Note that, depending on dCDN operations
and policies, the content pre-positioned in the dCDN may be pre- and policies, the content pre-positioned in the dCDN may be pre-
skipping to change at page 30, line 7 skipping to change at page 29, line 35
|------------------------>|(9) | |------------------------>|(9) |
| | | | | |
: : : : : :
| CONTENT DATA | | | CONTENT DATA | |
|<------------------------| |(10) |<------------------------| |(10)
Figure 9: Message Flow for Asynchronous CDNI Metadata Figure 9: Message Flow for Asynchronous CDNI Metadata
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. Operator A uses the Control Interface to trigger to signal the 1. Operator A uses the CI to trigger to signal the availability of
availability of CDNI metadata to Operator B. CDNI metadata to Operator B.
2. Operator B acknowledges the receipt of this trigger. 2. Operator B acknowledges the receipt of this trigger.
3. Operator B requests the latest metadata from Operator A using 3. Operator B requests the latest metadata from Operator A using
the Metadata Interface. the MI.
4. Operator A replies with the requested metadata. This document 4. Operator A replies with the requested metadata. This document
does not constrain how the CDNI metadata information is actually does not constrain how the CDNI metadata information is actually
represented. For the purposes of this example, we assume that represented. For the purposes of this example, we assume that
Operator A provides CDNI metadata to Operator B indicating that: Operator A provides CDNI metadata to Operator B indicating that:
* this CDNI Metadata is applicable to any content referenced by * this CDNI Metadata is applicable to any content referenced by
some CDN-Domain. some CDN-Domain.
* this CDNI metadata consists of a distribution policy * this CDNI metadata consists of a distribution policy
skipping to change at page 32, line 7 skipping to change at page 31, line 36
: : : : : :
| 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. A Request Routing Interface request occurs as in the prior 2. An RI request occurs as in the prior example.
example.
3. On receipt of the CDNI Request Routing Request, Operator B's CDN 3. On receipt of the CDNI Request Routing Request, Operator B's CDN
initiates synchronous acquisition of CDNI Metadata that are initiates synchronous acquisition of CDNI Metadata that are
needed for routing of the end-user request. We assume the URI needed for routing of the end-user request. We assume the URI
for the a Metadata server is known ahead of time through some for the a Metadata server is known ahead of time through some
out-of-band means. out-of-band means.
4. On receipt of a CDNI Metadata Request, Operator A's CDN 4. On receipt of a CDNI Metadata Request, Operator A's CDN
responds, making the corresponding CDNI metadata information responds, making the corresponding CDNI metadata information
available to Operator B's CDN. This metadata is considered by available to Operator B's CDN. This metadata is considered by
skipping to change at page 33, line 40 skipping to change at page 33, line 24
trust any of these uCDNs to acquire the content (provided the uCDN is trust any of these uCDNs to acquire the content (provided the uCDN is
in a position to serve it). If the dCDN is not ready to trust any of in a position to serve it). If the dCDN is not ready to trust any of
these uCDNs, it needs to ensure via out of band arrangements that, these uCDNs, it needs to ensure via out of band arrangements that,
for a given content, only a single uCDN will ever redirect requests for a given content, only a single uCDN will ever redirect requests
to the dCDN. to the dCDN.
Content acquisition may be preceded by content metadata acquisition. Content acquisition may be preceded by content metadata acquisition.
If possible, the acquisition path for metadata should also follow the If possible, the acquisition path for metadata should also follow the
redirection path. Additionally, we assume metadata is indexed based redirection path. Additionally, we assume metadata is indexed based
on rewritten URIs in the case of HTTP-redirection and is indexed on rewritten URIs in the case of HTTP-redirection and is indexed
based on published URIs in the case of DNS-redirection. Thus, the based on published URIs in the case of DNS-redirection. Thus, the RI
Request Routing Interface and the Metadata Interface are tightly and the MI are tightly coupled in that the result of request routing
coupled in that the result of request routing (a rewritten URI (a rewritten URI pointing to the dCDN) serves as an input to metadata
pointing to the dCDN) serves as an input to metadata lookup. If the lookup. If the content metadata includes information for acquiring
content metadata includes information for acquiring the content, then the content, then the MI is also tightly coupled with the acquisition
the Metadata Interface 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 RFC 6707 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.
skipping to change at page 35, line 12 skipping to change at page 34, line 43
it conditional: if the requested object has not been modified since it conditional: if the requested object has not been modified since
the time specified in this field, a copy of the object will not be the time specified in this field, a copy of the object will not be
returned, and instead, a 304 (not modified) response will be returned, and instead, a 304 (not modified) response will be
returned. returned.
4.2. Cross Interface Concerns 4.2. Cross Interface Concerns
Although the CDNI interfaces are largely independent, there are a set Although the CDNI interfaces are largely independent, there are a set
of conventions practiced consistently across all interfaces. Most of conventions practiced consistently across all interfaces. Most
important among these is how resources are named, for exampmle, how important among these is how resources are named, for exampmle, how
the Metadata and Control Interfaces identify the set of resources to the CDNI Metadata and Control interfaces identify the set of
which a given directive applies, or the Logging Interface identifies resources to which a given directive applies, or the CDNI Logging
the set of resources for which a summary record applies. interface identifies the set of resources for which a summary record
applies.
While in the limit the CDNI interfaces could explicitly identify While in the limit the CDNI interfaces could explicitly identify
every individual resource, in practice, they name resource aggregates every individual resource, in practice, they name resource aggregates
(sets of URIs) that are to be treated in a similar way. For example, (sets of URIs) that are to be treated in a similar way. For example,
URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at
the beginning of a URI) or by a URI-Filter (i.e., a regular the beginning of a URI) or by a URI-Filter (i.e., a regular
expression that matches a subset of URIs contained in some CDN- expression that matches a subset of URIs contained in some CDN-
Doman). In other words, CDN-Domains and URI-Filters provide a Doman). In other words, CDN-Domains and URI-Filters provide a
uniform means to aggregate sets (and subsets) of URIs for the purpose uniform means to aggregate sets (and subsets) of URIs for the purpose
of defining the scope for some operation in one of the CDNI of defining the scope for some operation in one of the CDNI
interfaces. interfaces.
4.3. Request Routing Interface 4.3. Request Routing Interfaces
The Request Routing Interface comprises two parts: the asynchronous The Request Routing interface comprises two parts: the asynchronous
interface used by a dCDN to advertize footprint and capabilities interface used by a dCDN to advertize footprint and capabilities
(denoted FCI) to a uCDN, allowing the uCDN to decide whether to (denoted FCI) to a uCDN, allowing the uCDN to decide whether to
redirect particular user requests to that dCDN; and the synchronous redirect particular user requests to that dCDN; and the synchronous
interface used by the uCDN to redirect a user request to the dCDN interface used by the uCDN to redirect a user request to the dCDN
(denoted RI). (These are somewhat analogous to the operations of (denoted RI). (These are somewhat analogous to the operations of
routing and forwarding in IP.) routing and forwarding in IP.)
As illustrated in Section 3, the RI part of request routing may be As illustrated in Section 3, the RI part of request routing may be
implemented in part by DNS and HTTP. Naming conventions may be implemented in part by DNS and HTTP. Naming conventions may be
established by which CDN peers communicate whether a request should established by which CDN peers communicate whether a request should
skipping to change at page 36, line 28 skipping to change at page 36, line 7
by dCDN). by dCDN).
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.spp-cdni-rr-foot-cap-semantics].
4.4. 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 Logging Interface. is one role of the LI.
Other operational data that may be relevant to CDNI can also be Other operational data that may be relevant to CDNI can also be
exchanged by the Logging Interface. For example, dCDN may report the exchanged by the LI. For example, dCDN may report the amount of
amount of content it has acquired from uCDN, and how much cache content it has acquired from uCDN, and how much cache storage has
storage has been consumed by content cached on behalf of uCDN. been consumed by content cached on behalf of uCDN.
Traffic logs are easily exchanged off-line. For example, the Traffic logs are easily exchanged off-line. For example, the
following traffic log is a small deviation from the Apache log file following traffic log is a small deviation from the Apache log file
format, where entries include the following fields: format, where entries include the following fields:
o Domain - the full domain name of the origin server o Domain - the full domain name of the origin server
o IP address - the IP address of the client making the request o IP address - the IP address of the client making the request
o End time - the ending time of the transfer o End time - the ending time of the transfer
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
skipping to change at page 37, line 23 skipping to change at page 37, line 4
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-\u002Dit is set to the CDN-Domain used by the upstream CDN rather CDN-\u002Dit is set to the CDN-Domain used by the upstream CDN rather
than the actual origin server. This field could then used to filter than the actual origin server. This field could then used to filter
traffic log entries so only those entries matching the upstream CDN traffic log entries so only those entries matching the upstream CDN
are reported to the corresponding operator. Further discussion of are reported to the corresponding operator. Further discussion of
the Logging Interface can be found in [I-D.bertrand-cdni-logging]. the LI can be found in [I-D.bertrand-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
records and the set of CDN-Domains it serves to an independent third- records and the set of CDN-Domains it serves to an independent third-
party (i.e., a CDN Exchange), which subsequently filters, merges, and party (i.e., a CDN Exchange), which subsequently filters, merges, and
distributes traffic records on behalf of each participating CDN distributes traffic records on behalf of each participating CDN
operator. operator.
A second open question is how timely traffic information should be. A second open question is how timely traffic information should be.
For example, in addition to off-line traffic logs, accurate real-time For example, in addition to offline traffic logs, accurate real-time
traffic monitoring might also be useful, but such information traffic monitoring might also be useful, but such information
requires that the downstream CDN inform the upstream CDN each time it requires that the downstream CDN inform the upstream CDN each time it
serves upstream content from its cache. The downstream CDN can do serves upstream content from its cache. The downstream CDN can do
this, for example, by sending a conditional HTTP GET request (If- this, for example, by sending a conditional HTTP GET request (If-
Modified-Since) to the upstream CDN each time it receives an HTTP GET Modified-Since) to the upstream CDN each time it receives an HTTP GET
request from one of its end-users. This allows the upstream CDN to request from one of its end-users. This allows the upstream CDN to
record that a request has been issued for the purpose of real-time record that a request has been issued for the purpose of real-time
traffic monitoring. The upstream CDN can also use this information traffic monitoring. The upstream CDN can also use this information
to validate the traffic logs received later from the downstream CDN. to validate the traffic logs received later from the downstream CDN.
There is obviously a tradeoff between accuracy of such monitoring and There is obviously a tradeoff between accuracy of such monitoring and
the overhead of the downstream CDN having to go back to the upstream the overhead of the downstream CDN having to go back to the upstream
CDN for every request. CDN for every request.
Another design tradeoff in the Logging Interface is the degree of Another design tradeoff in the LI is the degree of aggregation or
aggregation or summarization of data. One situation that lends summarization of data. One situation that lends itself to
itself to summarization is the delivery of HTTP adaptive streaming summarization is the delivery of HTTP adaptive streaming (HAS), since
(HAS), since the large number of individual chunk requests the large number of individual chunk requests potentially results in
potentially results in large volumes of logging information. This large volumes of logging information. This case is discussed below,
case is discussed below, but other forms of aggregation may also be but other forms of aggregation may also be useful. For example,
useful. For example, there may be situations where bulk metrics such there may be situations where bulk metrics such as bytes delivered
as bytes delivered per hour may suffice rather than the detailed per- per hour may suffice rather than the detailed per-request logs
request logs outlined above. It seems likely that a range of outlined above. It seems likely that a range of granularities of
granularities of logging will be needed along with ways to specify logging will be needed along with ways to specify the type and degree
the type and degree of aggregation required. of aggregation required.
4.5. Control Interface 4.5. CDNI Control Interface
The 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 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 Control Interface plays is to allow the uCDN to The other role the CI plays is to allow the uCDN to pre-position,
pre-position, revalidate, or purge metadata and content on a dCDN. revalidate, or purge metadata and content on a dCDN. These
These operations, sometimes collectively called the trigger operations, sometimes collectively called the trigger interface, are
interface, are discussed further in [I-D.murray-cdni-triggers]. discussed further in [I-D.murray-cdni-triggers].
4.6. Metadata Interface 4.6. CDNI Metadata Interface
The role of the CDNI Metadata Interface is to enable CDNI The role of the CDNI Metadata interface is to enable CDNI
distribution metadata to be conveyed to the downstream CDN by the distribution metadata to be conveyed to the downstream CDN by the
upstream CDN. For example, see [I-D.ietf-cdni-metadata]. Such upstream CDN. For example, see [I-D.ietf-cdni-metadata]. Such
metadata includes geo-blocking restrictions, availability windows, metadata includes geo-blocking restrictions, availability windows,
access control policies, and so on. It may also include information access control policies, and so on. It may also include information
to facilitate acquisition of content by dCDN (e.g., alternate sources to facilitate acquisition of content by dCDN (e.g., alternate sources
for the content, authorization information needed to acquire the for the content, authorization information needed to acquire the
content from the source). content from the source).
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
skipping to change at page 39, line 39 skipping to change at page 39, line 21
this particular end-user. The upstream CDN would communicate its this particular end-user. The upstream CDN would communicate its
directive through its response to the conditional GET. The directive through its response to the conditional GET. The
downstream CDN can cache information for a period of time specified downstream CDN can cache information for a period of time specified
by the upstream CDN, thereby reducing control overhead, but then by the upstream CDN, thereby reducing control overhead, but then
preventing per-request control during the corresponding caching preventing per-request control during the corresponding caching
period. period.
All of these in-band techniques serve to illustrate that uCDNs have All of these in-band techniques serve to illustrate that uCDNs have
the option of enforcing some of their access control policies the option of enforcing some of their access control policies
themselves (at the expense of increased inter-CDN signaling load), themselves (at the expense of increased inter-CDN signaling load),
rather than delegating enforcement to dCDNs using the Metadata rather than delegating enforcement to dCDNs using the MI. As a
Interface. As a consequence, the Metadata Interface could provide a consequence, the MI could provide a means for the uCDN to express its
means for the uCDN to express its desire to retain enforcement for desire to retain enforcement for itself. For example, this might be
itself. For example, this might be done by including a "check with done by including a "check with me" flag in the metadata associated
me" flag in the metadata associated with certain content. The with certain content. The realization of such in-band techniques
realization of such in-band techniques over the various inter-CDN over the various inter-CDN acquisition protocols (e.g., HTTP)
acquisition protocols (e.g., HTTP) requires further investigation and requires further investigation and may require small extensions or
may require small extensions or semantic changes to the acquisition semantic changes to the acquisition protocol.
protocol.
4.7. HTTP Adaptive Streaming Concerns 4.7. HTTP Adaptive Streaming Concerns
We consider HTTP Adaptive Streaming (HAS) and the impact it has on We consider HTTP Adaptive Streaming (HAS) and the impact it has on
the CDNI interfaces because large objects (e.g., videos) are broken the CDNI interfaces because large objects (e.g., videos) are broken
into a sequence of small, independent chunks. For each of the into a sequence of small, independent chunks. For each of the
following, a more thorough discussion, including an overview of the following, a more thorough discussion, including an overview of the
tradeoffs involved in alternative designs, can be found in tradeoffs involved in alternative designs, can be found in
[I-D.brandenburg-cdni-has]. [I-D.brandenburg-cdni-has].
skipping to change at page 40, line 31 skipping to change at page 40, line 12
Second, with respect to Request Routing, we note that HAS manifest Second, with respect to Request Routing, we note that HAS manifest
files have the potential to interfere with request routing since files have the potential to interfere with request routing since
manifest files contain URLs pointing to the location of content manifest files contain URLs pointing to the location of content
chunks. To make sure that a manifest file does not hinder CDNI chunks. To make sure that a manifest file does not hinder CDNI
request routing and does not place excessive load on CDNI resources, request routing and does not place excessive load on CDNI resources,
the use of manifest files could either be limited to those containing the use of manifest files could either be limited to those containing
relative URLs or the uCDN could modify the URLs in the manifest. Our relative URLs or the uCDN could modify the URLs in the manifest. Our
approach for dealing with these issues is twofold. As a mandatory approach for dealing with these issues is twofold. As a mandatory
requirement, CDNs should be able to handle unmodified manifest files requirement, CDNs should be able to handle unmodified manifest files
containing either relative or absolute URLs. To limit the number of containing either relative or absolute URLs. To limit the number of
redirects, and thus the load placed on the CDNI Interfaces, as an redirects, and thus the load placed on the CDNI interfaces, as an
optional feature uCDNs can use the information obtained through the optional feature uCDNs can use the information obtained through the
CNDI Request Routing Redirection Interface to modify the URLs in the CNDI Request Routing Redirection interface to modify the URLs in the
manifest file. Since the modification of the manifest file is an manifest file. Since the modification of the manifest file is an
optional uCDN-internal process, this does not require any optional uCDN-internal process, this does not require any
standardization effort beyond being able to communicate chunk standardization effort beyond being able to communicate chunk
locations in the CDNI Request Routing Redirection Interface. locations in the CDNI Request Routing Redirection interface.
Third, with respect to the Logging Interface, there are several Third, with respect to the CDNI Logging interface, there are several
potential issues, including the large number of individual chunk potential issues, including the large number of individual chunk
requests potentially resulting in large volumes of logging requests potentially resulting in large volumes of logging
information, and the desire to correlate logging information for information, and the desire to correlate logging information for
chunk requests that correspond to the same HAS session. For the chunk requests that correspond to the same HAS session. For the
initial CDNI specification, our approach is to expect participating initial CDNI specification, our approach is to expect participating
CDNs to support per-chunk logging (e.g. logging each chunk request as CDNs to support per-chunk logging (e.g. logging each chunk request as
if it were an independent content request) over the CDNI Logging if it were an independent content request) over the CDNI Logging
Interface. Optionally, the Logging Interface may include a Content interface. Optionally, the LI may include a Content Collection
Collection IDentifier (CCID) and/or a Session IDentifier (SID) as IDentifier (CCID) and/or a Session IDentifier (SID) as part of the
part of the logging fields, thereby facilitating correlation of per- logging fields, thereby facilitating correlation of per-chunk logs
chunk logs into per-session logs for applications benefiting from into per-session logs for applications benefiting from such session
such session level information (e.g. session-based analytics). This level information (e.g. session-based analytics). This approach is
approach is in line with the recommendations made in in line with the recommendations made in [I-D.brandenburg-cdni-has],
[I-D.brandenburg-cdni-has], which also identifies potential which also identifies potential improvements in this area that might
improvements in this area that might be considered in the future. be considered in the future.
Fourth, with respect to the Control Interface, and in particular Fourth, with respect to the CDNI Control interface, and in particular
purging HAS chunks from a given CDN, our approach is to expect each purging HAS chunks from a given CDN, our approach is to expect each
CDN supports per-chunk content purge (e.g. purging of chunks as if CDN supports per-chunk content purge (e.g. purging of chunks as if
they were individual content items). Optionally, a CDN may support they were individual content items). Optionally, a CDN may support
content purge on the basis of a "Purge IDentifier (Purge-ID)" content purge on the basis of a "Purge IDentifier (Purge-ID)"
allowing the removal of all chunks related to a given Content allowing the removal of all chunks related to a given Content
Collection with a single reference. It is possible that this Purge- Collection with a single reference. It is possible that this Purge-
ID could be merged with the CCID discussed above for HAS Logging, or ID could be merged with the CCID discussed above for HAS Logging, or
alternatively, they may remain distinct. alternatively, they may remain distinct.
4.8. URI Rewriting 4.8. URI Rewriting
skipping to change at page 42, line 5 skipping to change at page 41, line 39
"d-URI" represents a content URI in a request made within the "d-URI" represents a content URI in a request made within the
delegate dCDN. delegate dCDN.
In our simple pair-wise example, the "ud-URI" effectively becomes the In our simple pair-wise example, the "ud-URI" effectively becomes the
handle that the uCDN/dCDN pair use to correlate all CDNI information. handle that the uCDN/dCDN pair use to correlate all CDNI information.
In particular, for a given pair of CDNs executing the HTTP In particular, for a given pair of CDNs executing the HTTP
redirection, the uCDN needs to map the u-URI to the ud-URI handle for redirection, the uCDN needs to map the u-URI to the ud-URI handle for
all MI message exchanges, while the dCDN needs to map the d-URI to all MI message exchanges, while the dCDN needs to map the d-URI to
the ud-URI handle for all LI message exchanges. the ud-URI handle for all LI message exchanges.
In the case of a cascaded CDNs, the transit CDN will re-write the In the case of a cascaded CDNs, the transit CDN will rewrite the
content URI when redirecting to the dCDN, thereby establishing a new content URI when redirecting to the dCDN, thereby establishing a new
handle between the transit CDN and the dCDN, that is different from handle between the transit CDN and the dCDN, that is different from
the handle between the uCDN and transit CDN. It is the the handle between the uCDN and transit CDN. It is the
responsibility of the transit CDN to manage its mapping across responsibility of the transit CDN to manage its mapping across
handles so the right handle for all pairs of CDNs is always used in handles so the right handle for all pairs of CDNs is always used in
its CDNI communication. its CDNI communication.
In summary, all CDNI interfaces between a given pair of CDNs need to In summary, all CDNI interfaces between a given pair of CDNs need to
always use the "ud-URI" handle for that specific CDN pair as their always use the "ud-URI" handle for that specific CDN pair as their
content URI reference. content URI reference.
skipping to change at page 43, line 34 skipping to change at page 43, line 19
<==> CDNI interfaces, with right-hand side CDN acting as dCDN <==> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN and with left-hand side CDN acting to left-hand side CDN and with left-hand side CDN acting
as dCDN to right-hand side CDN as dCDN to right-hand side CDN
Figure 11: CDNI Deployment Model: CDN Meshing Example Figure 11: CDNI Deployment Model: CDN Meshing Example
5.2. CSP combined with CDN 5.2. CSP combined with CDN
Note that our terminology refers to functional roles and not economic Note that our terminology refers to functional roles and not economic
or business roles. That is, a given organization may be operating as or business roles. That is, a given organization may be operating as
both a CSP and a fully-fledged uCDN when we consider the functions both a CSP and a fully fledged uCDN when we consider the functions
performed, as illustrated in Figure 12. performed, as illustrated in Figure 12.
##################################### ################## ##################################### ##################
# # # # # # # #
# Organization A # # Organization B # # Organization A # # Organization B #
# # # # # # # #
# -------- ------------- # # ----------- # # -------- ------------- # # ----------- #
# / CSP \ / uCDN \ # # / dCDN \ # # / CSP \ / uCDN \ # # / dCDN \ #
# | | | +----+ | # # | +----+ | # # | | | +----+ | # # | +----+ | #
# | | | | C | | # # | | C | | # # | | | | C | | # # | | C | | #
skipping to change at page 44, line 18 skipping to change at page 44, line 4
# # # # # # # #
##################################### ################## ##################################### ##################
===> CDNI interfaces, with right-hand side CDN acting as dCDN ===> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN to left-hand side CDN
**** interfaces outside the scope of CDNI **** interfaces outside the scope of CDNI
C Control component of the CDN C Control component of the CDN
L Logging component of the CDN L Logging component of the CDN
RR Request Routing component of the CDN RR Request Routing component of the CDN
D Distribution component of the CDN D Distribution component of the CDN
Figure 12: CDNI Deployment Model: Organization combining CSP & uCDN Figure 12: CDNI Deployment Model: Organization combining CSP & uCDN
5.3. CSP using CDNI Request Routing Interface 5.3. CSP using CDNI Request Routing Interface
As another example, a content provider organization may choose to run As another example, a content provider organization may choose to run
its own request routing function as a way to select among multiple its own request routing function as a way to select among multiple
candidate CDN providers; In this case the content provider may be candidate CDN providers; In this case the content provider may be
modeled as the combination of a CSP and of a special, restricted case modeled as the combination of a CSP and of a special, restricted case
of a CDN. In that case, as illustrated in Figure 13, the CDNI of a CDN. In that case, as illustrated in Figure 13, the CDNI
Request Routing Interfaces can be used between the restricted CDN Request Routing interfaces can be used between the restricted CDN
operated by the content provider Organization and the CDN operated by operated by the content provider Organization and the CDN operated by
the full-CDN organization acting as a dCDN in the request routing the full CDN organization acting as a dCDN in the request routing
control plane. Interfaces outside the scope of the CDNI work can be control plane. Interfaces outside the scope of the CDNI work can be
used between the CSP functional entities of the content provider used between the CSP functional entities of the content provider
organization and the CDN operated by the full-CDN organization acting organization and the CDN operated by the full CDN organization acting
as a uCDN) in the CDNI control planes other than the request routing as a uCDN) in the CDNI control planes other than the request routing
plane (i.e. Control, Distribution, Logging). plane (i.e. Control, Distribution, Logging).
##################################### ################## ##################################### ##################
# # # # # # # #
# Organization A # # Organization B # # Organization A # # Organization B #
# # # # # # # #
# -------- ------------- # # ----------- # # -------- ------------- # # ----------- #
# / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ # # / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ #
# | | | +----+ | # # | +----+ | # # | | | +----+ | # # | +----+ | #
skipping to change at page 45, line 41 skipping to change at page 45, line 26
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-\u002Da third party broker or exchange that is used to
facilitate a CDN federation. Our view is that a CDN exchange offers facilitate a CDN federation. Our view is that a CDN exchange offers
valuable machinery to scale the number of CDN operators involved in a valuable machinery to scale the number of CDN operators involved in a
multi-lateral (federated) agreement, but that this machinery is built multi-lateral (federated) agreement, but that this machinery is built
on top of the core CDNI interconnection mechanisms. For example, as on 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 re-distribute 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-\u002Doperate exactly as in a pair-wise peering arrangement. CDN-\u002Doperate exactly as in a pair-wise peering arrangement.
Turning to Figure 14, we observe that in this example: Turning to Figure 14, we observe that in this example:
o each CDN supports a direct CDNI Control Interface to every other o each CDN supports a direct CDNI Control interface to every other
CDN CDN
o each CDN supports a direct CDNI Metadata Interface to every other o each CDN supports a direct CDNI Metadata interface to every other
CDN CDN
o each CDN supports a CDNI Logging Interface with the CDN Exchange o each CDN supports a CDNI Logging interface with the CDN Exchange
o each CDN supports both a CDNI Request Routing Interface with the o each CDN supports both a CDNI Request Routing interfaces with the
CDN Exchange (for aggregation and redistribution of dynamic CDN CDN Exchange (for aggregation and redistribution of dynamic CDN
footprint discovery information) and a direct CDNI Request Routing footprint discovery information) and a direct RI to every other
Interface to every other CDN (for actual request redirection). CDN (for actual request redirection).
---------- --------- ---------- ---------
/ CDN A \ / CDN B \ / CDN A \ / CDN B \
| +----+ | | +----+ | | +----+ | | +----+ |
//========>| C |<==============CDNI============>| C |<==========\\ //========>| C |<==============CDNI============>| C |<==========\\
|| | +----+ | C | +----+ | || || | +----+ | C | +----+ | ||
|| | +----+ | | +----+ | || || | +----+ | | +----+ | ||
|| //=====>| D |<==============CDNI============>| D |<=======\\ || || //=====>| D |<==============CDNI============>| D |<=======\\ ||
|| || | +----+ | M | +----+ | || || || || | +----+ | M | +----+ | || ||
|| || | | /------------\ | | || || || || | | /------------\ | | || ||
 End of changes. 84 change blocks. 
250 lines changed or deleted 245 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/