draft-ietf-cdni-framework-03.txt   draft-ietf-cdni-framework-04.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: August 22, 2013 February 18, 2013 Expires: February 22, 2014 August 21, 2013
Framework for CDN Interconnection Framework for CDN Interconnection
draft-ietf-cdni-framework-03 draft-ietf-cdni-framework-04
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
across CDNs. The intent of this document is to outline what each across CDNs. The intent of this document is to outline what each
interface needs to accomplish, and to describe how these interfaces interface needs to accomplish, and to describe how these interfaces
and mechanisms fit together, while leaving their detailed and mechanisms fit together, while leaving their detailed
specification to other documents. It obsoletes RFC 3466. specification to other documents. It obsoletes RFC 3466.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 22, 2013. This Internet-Draft will expire on February 22, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 5 1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4
1.3. Structure Of This Document . . . . . . . . . . . . . . . . 9 1.3. Structure Of This Document . . . . . . . . . . . . . . . 8
2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 9 2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8
2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 9 2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8
2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . 10 2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9
3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . . 11 3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10
3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 14 3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13
3.3. Recursive HTTP Redirection Example . . . . . . . . . . . . 19 3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18
3.4. Iterative DNS-based Redirection Example . . . . . . . . . 23 3.4. Iterative DNS-based Redirection Example . . . . . . 22
3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 27 3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25
3.6. Content Removal Example . . . . . . . . . . . . . . . . . 29 3.6. Content Removal Example . . . . . . . . . . . . . . . . . 26
3.7. Pre-Positioned Content Acquisition Example . . . . . . . . 29 3.7. Pre-Positioned Content Acquisition Example . . . . . . . 27
3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . . 31 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 29
3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 33 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 31
3.10. Content and Metadata Acquisition with Multiple 3.10. Content and Metadata Acquisition with Multiple Upstream
Upstream CDNs . . . . . . . . . . . . . . . . . . . . . . 35 CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 36 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 37 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34
4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . . 37 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 35
4.3. Request Routing Interface . . . . . . . . . . . . . . . . 38 4.3. Request Routing Interface . . . . . . . . . . . . . . . . 35
4.4. Logging Interface . . . . . . . . . . . . . . . . . . . . 39 4.4. Logging Interface . . . . . . . . . . . . . . . . . . . . 36
4.5. Control Interface . . . . . . . . . . . . . . . . . . . . 41 4.5. Control Interface . . . . . . . . . . . . . . . . . . . . 38
4.6. Metadata Interface . . . . . . . . . . . . . . . . . . . . 41 4.6. Metadata Interface . . . . . . . . . . . . . . . . . . . 38
4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . . 42 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 43 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 41
5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 44 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 42
5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 45 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42
5.3. CSP using CDNI Request Routing Interface . . . . . . . . . 46 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43
5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 47 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 44
6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 45
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 47
8. Security Considerations . . . . . . . . . . . . . . . . . . . 51 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 52 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
8.2. Digital Rights Management . . . . . . . . . . . . . . . . 53 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 50
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 50
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50
11. Informative References . . . . . . . . . . . . . . . . . . . . 53 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 11. Informative References . . . . . . . . . . . . . . . . . . . 51
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
necessary to interconnect CDNs. CDN Interconnection requires the necessary to interconnect CDNs. CDN Interconnection requires the
specification of several interfaces and mechanisms to address issues specification of several interfaces and mechanisms to address issues
skipping to change at page 5, line 40 skipping to change at page 5, line 4
independently of any given user request, such as advertisement of independently of any given user request, such as advertisement of
footprint information or pre-positioning of content for later footprint information or pre-positioning of content for later
delivery. delivery.
Trigger Interface: a sub-set of the Control Interface that includes Trigger Interface: a sub-set of the Control Interface that includes
operations to pre-position, revalidate, and purge both metadata and operations to pre-position, revalidate, and purge both metadata and
content. These operations are typically called in response to some content. These operations are typically called in response to some
action (trigger) by the CSP on the upstream CDN. action (trigger) by the CSP on the upstream CDN.
1.2. Reference Model 1.2. Reference Model
This document uses the reference model in Figure 1, which extends the
reference model originally defined in RFC 6707. (The difference is
that the extended model splits the Request Routing Interface into two
distinct parts: the Request Routing Redirection Interface and the
Footprint and Capability Interface, as described below.)
This document uses the reference model in Figure 1 as originally --------
created in RFC 6707. / \
| CSP |
-------- \ /
/ \ --------
| CSP | *
\ / *
-------- * /\
* * / \
* ---------------------- |CDNI| ----------------------
* /\ / Upstream CDN \ | | / Downstream CDN \
* / \ | +-------------+ | Control Interface| +-------------+ |
---------------------- |CDNI| ---------------------- |******* Control |<======|====|========>| Control *******|
/ Upstream CDN \ | | / Downstream CDN \ |* +------*----*-+ | | | | +-*----*------+ *|
| +-------------+ | Control Interface| +-------------+ | |* * * | | | | * * *|
|******* Control |<======|====|========>| Control *******| |* +------*------+ | Logging Interface| +------*------+ *|
|* +------*----*-+ | | | | +-*----*------+ *| |* ***** Logging |<======|====|========>| Logging ***** *|
|* * * | | | | * * *| |* * +-*-----------+ | | | | +-----------*-+ * *|
|* +------*------+ | Logging Interface| +------*------+ *| |* * * * | RR Redirection | * * * *|
|* ***** Logging |<======|====|========>| Logging ***** *| .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*...
|* * +-*-----------+ | | | | +-----------*-+ * *| . |* * | |<======|====|========>| | * *| .
|* * * * | Request Routing | * * * *| . |* * | Req-Routing | | Foot & Cap Int | | Req-Routing | * *| .
.....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... . |* * *** |<======|====|========>| |** * *| .
. |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . . |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| . . |* * * . CDNI Metadata | * * *| .
. |* * * . CDNI Metadata | * * *| . . |* * * +-------------+ |. Interface | +-------------+ * * *| .
. |* * * +-------------+ |. Interface | +-------------+ * * *| . . |* * * | 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 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 four 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 sub-set 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
skipping to change at page 9, line 16 skipping to change at page 8, line 22
The remainder of this document is organized as follows: The remainder of this document is organized as follows:
o Section 2 describes some essential building blocks for CDNI, o Section 2 describes some essential building blocks for CDNI,
notably the various options for redirecting user requests to a notably the various options for redirecting user requests to a
given CDN. given CDN.
o Section 3 provides a number of illustrative examples of various o Section 3 provides a number of illustrative examples of various
CDNI operations. CDNI operations.
o Section 4 describes the functionality of the four main CDNI o Section 4 describes the functionality of the main CDNI interfaces.
interfaces.
o Section 5 shows how various deployment models of CDNI may be o Section 5 shows how various deployment models of CDNI may be
achieved using the defined interfaces. achieved using the defined interfaces.
o Section 6 describes the trust model of CDNI and the issues of o Section 6 describes the trust model of CDNI and the issues of
transitive trust in particular that CDNI raises. transitive trust in particular that CDNI raises.
2. Building Blocks 2. Building Blocks
2.1. Request Redirection 2.1. Request Redirection
skipping to change at page 9, line 51 skipping to change at page 9, line 14
DNS redirection is based on returning different IP addresses for the DNS redirection is based on returning different IP addresses for the
same DNS name, for example, to balance server load or to account for same DNS name, for example, to balance server load or to account for
the client's location in the network. A DNS server, sometimes called the client's location in the network. A DNS server, sometimes called
the Local DNS (LDNS), resolves DNS names on behalf of an end-user. the Local DNS (LDNS), resolves DNS names on behalf of an end-user.
The LDNS server in turn queries other DNS servers until it reaches The LDNS server in turn queries other DNS servers until it reaches
the authoritative DNS server for the CDN-Domain. The network the authoritative DNS server for the CDN-Domain. The network
operator typically provides the LDNS server, although the user is operator typically provides the LDNS server, although the user is
free to choose other DNS servers (e.g., OpenDNS, Google Public DNS). free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).
The advantage of DNS redirection is that it is completely transparent The advantage of DNS redirection is that it is completely transparent
to the end user--the user sends a DNS name to the LDNS server and to the end user-\u002Dthe user sends a DNS name to the LDNS server
gets back an IP address. On the other hand, DNS redirection is and gets back an IP address. On the other hand, DNS redirection is
problematic because the DNS request comes from the LDNS server, not problematic because the DNS request comes from the LDNS server, not
the end-user. This may affect the accuracy of server selection that the end-user. This may affect the accuracy of server selection that
is based on the user's location. The transparency of DNS redirection is based on the user's location. The transparency of DNS redirection
is also a problem in that there is no opportunity to take the is also a problem in that there is no opportunity to take the
attributes of the user agent or the URI path component into account. attributes of the user agent or the URI path component into account.
We consider two main forms of DNS redirection: simple and CNAME- We consider two main forms of DNS redirection: simple and CNAME-
based. based.
In simple DNS redirection, the authoritative DNS server for the name In simple DNS redirection, the authoritative DNS server for the name
simply returns an IP address from a set of possible IP addresses. simply returns an IP address from a set of possible IP addresses.
skipping to change at page 10, line 28 skipping to change at page 9, line 39
Simple redirection is straightforward. The only caveats are (1) Simple redirection is straightforward. The only caveats are (1)
there is a limit to the number alternate IP addresses a single DNS there is a limit to the number alternate IP addresses a single DNS
server can manage; and (2) DNS responses are cached by downstream server can manage; and (2) DNS responses are cached by downstream
servers so the TTL on the response must be set to an appropriate servers so the TTL on the response must be set to an appropriate
value so as to preserve the fresheness of the redirection. value so as to preserve the fresheness of the redirection.
In CNAME-based DNS redirection, the authoritative server returns a In CNAME-based DNS redirection, the authoritative server returns a
CNAME response to the DNS request, telling the LDNS server to restart CNAME response to the DNS request, telling the LDNS server to restart
the name lookup using a new name. A CNAME is essentially a symbolic the name lookup using a new name. A CNAME is essentially a symbolic
link in the DNS namespace, and like a symbolic link, redirection is link in the DNS namespace, and like a symbolic link, redirection is
transparent to the client--the LDNS server gets the CNAME response transparent to the client-\u002Dthe LDNS server gets the CNAME
and re-executes the lookup. Only when the name has been resolved to response and re-executes the lookup. Only when the name has been
an IP address does it return the result to the user. Note that DNAME resolved to an IP address does it return the result to the user.
would be preferable to CNAME if it becomes widely supported. Note that DNAME would be preferable to CNAME if it becomes widely
supported.
2.1.2. HTTP Redirection 2.1.2. HTTP Redirection
HTTP redirection makes use of the redirection response of the HTTP HTTP redirection makes use of the redirection response of the HTTP
protocol (e.g.,"302" or "307"). This response contains a new URL protocol (e.g.,"302" or "307"). This response contains a new URL
that the application should fetch instead of the original URL. By that the application should fetch instead of the original URL. By
changing the URL appropriately, the server can cause the user to changing the URL appropriately, the server can cause the user to
redirect to a different server. The advantages of HTTP redirection redirect to a different server. The advantages of HTTP redirection
are that (1) the server can change the URL fetched by the client to are that (1) the server can change the URL fetched by the client to
include, for example, both the DNS name of the particular server to include, for example, both the DNS name of the particular server to
skipping to change at page 12, line 36 skipping to change at page 11, line 32
| | ACQUISITION REQUEST | | | ACQUISITION REQUEST |
| X------------------------>| (8) | X------------------------>| (8)
| X | | X |
| X CONTENT DATA | | X CONTENT DATA |
| X<------------------------| (9) | X<------------------------| (9)
| | | | | |
| CONTENT DATA | | | CONTENT DATA | |
|<------------------------| | (10) |<------------------------| | (10)
| | | | | |
: : : : : :
: [Other content requests] : : [Other content requests] :
: : : : : :
| | [CI: Content Purge] | (11) | | [CI: Content Purge] | (11)
: : : : : :
| | [LI: Log exchange] | (12) | | [LI: Log exchange] | (12)
| | | | | |
Figure 2: Overview of Operation Figure 2: Overview of Operation
The operations shown in the Figure are as follows: The operations shown in the Figure are as follows:
skipping to change at page 15, line 11 skipping to change at page 14, line 9
prepared to serve requests from clients in a given geographical prepared to serve requests from clients in a given geographical
region or a set of IP address prefixes. This information may again region or a set of IP address prefixes. This information may again
be provided out of band or via a defined CDNI interface. be provided out of band or via a defined CDNI interface.
We assume DNS is configured in the following way: We assume DNS is configured in the following way:
o The content provider is configured to make operator A the o The content provider is configured to make operator A the
authoritative DNS server for cdn.csp.com (or to return a CNAME for authoritative DNS server for cdn.csp.com (or to return a CNAME for
cdn.csp.com for which operator A is the authoritative DNS server). cdn.csp.com for which operator A is the authoritative DNS server).
o Operator A is configured so that a DNS request for op-b-acq.op- o Operator A is configured so that a DNS request for
a.net returns a request router in Operator A. op-b-acq.op-a.net returns a request router in Operator A.
o Operator B is configured so that a DNS request for peer-a.op- o Operator B is configured so that a DNS request for peer-a.op-b.net
b.net/cdn.csp.com returns a request router in Operator B. /cdn.csp.com returns a request router in Operator B.
Figure 3 illustrates how a client request for Figure 3 illustrates how a client request for
http://cdn.csp.com/...rest of url... http://cdn.csp.com/...rest of url...
is handled. is handled.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.com | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
|IPaddr of A's Request Router | |IPaddr of A's Request Router |
|<--------------------------------------------------| |<--------------------------------------------------|
|HTTP cdn.csp.com | | |HTTP cdn.csp.com | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(2) | | |(2)
|302 peer-a.op-b.net/cdn.csp.com | |302 peer-a.op-b.net/cdn.csp.com |
|<--------------------------------------------------| |<--------------------------------------------------|
|DNS peer-a.op-b.net | | |DNS peer-a.op-b.net | |
|------------------------>| | |------------------------>| |
| |(3) | | |(3) |
|IPaddr of B's Request Router | |IPaddr of B's Request Router |
|<------------------------| | |<------------------------| |
| | | | | |
|HTTP peer-a.op-b.net/cdn.csp.com | |HTTP peer-a.op-b.net/cdn.csp.com |
|------------------------>| | |------------------------>| |
| |(4) | | |(4) |
|302 node1.peer-a.op-b.net/cdn.csp.com | |302 node1.peer-a.op-b.net/cdn.csp.com |
|<------------------------| | |<------------------------| |
|DNS node1.peer-a.op-b.net| | |DNS node1.peer-a.op-b.net| |
|------------------------>| | |------------------------>| |
| |(5) | | |(5) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
| | | | | |
|HTTP node1.peer-a.op-b.net/cdn.csp.com | |HTTP node1.peer-a.op-b.net/cdn.csp.com |
|------------------------>| | |------------------------>| |
| |(6) | | |(6) |
| |DNS op-b-acq.op-a.net | | |DNS op-b-acq.op-a.net |
| |------------------------>| | |------------------------>|
| | |(7) | | |(7)
| |IPaddr of A's Request Router | |IPaddr of A's Request Router
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.net |
| |------------------------>| | |------------------------>|
| | |(8) | | |(8)
| |302 node2.op-b.acq.op-A.net | |302 node2.op-b.acq.op-A.net
| |<------------------------| | |<------------------------|
| |DNS node2.op-b-acq.op-a.net | |DNS node2.op-b-acq.op-a.net
| |------------------------>| | |------------------------>|
| | |(9) | | |(9)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| | | | | |
| |HTTP node2.op-b-acq.op-a.net | |HTTP node2.op-b-acq.op-a.net
| |------------------------>| | |------------------------>|
| | |(10) | | |(10)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 3: Message Flow for Iterative HTTP Redirection Figure 3: Message Flow for Iterative HTTP Redirection
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. A DNS resolver for Operator A processes the DNS request for its 1. A DNS resolver for Operator A processes the DNS request for its
customer based on CDN-Domain cdn.csp.com. It returns the IP customer based on CDN-Domain cdn.csp.com. It returns the IP
address of a request router in Operator A. address of a request router in Operator A.
2. A Request Router for Operator A processes the HTTP request and 2. A Request Router for Operator A processes the HTTP request and
recognizes that the end-user is best served by another CDN-- recognizes that the end-user is best served by another
specifically one provided by Operator B--and so it returns a 302 CDN-\u002Dspecifically one provided by Operator B-\u002Dand so
redirect message for a new URL constructed by "stacking" it returns a 302 redirect message for a new URL constructed by
Operator B's distinguished CDN-Domain (peer-a.op-b.net) on the "stacking" Operator B's distinguished CDN-Domain
front of the original URL. (Note that more complex URL (peer-a.op-b.net) on the front of the original URL. (Note that
manipulations are possible, such as replacing the initial CDN- more complex URL manipulations are possible, such as replacing
Domain by some opaque handle.) the initial CDN-Domain by some opaque handle.)
3. The end-user does a DNS lookup using Operator B's distinguished 3. The end-user does a DNS lookup using Operator B's distinguished
CDN-Domain (peer-a.op-b.net). B's DNS resolver returns the IP CDN-Domain (peer-a.op-b.net). B's DNS resolver returns the IP
address of a request router for Operator B. Note that if request address of a request router for Operator B. Note that if request
routing within dCDN was performed using DNS instead of HTTP routing within dCDN was performed using DNS instead of HTTP
redirection, B's DNS resolver would also behave as the request redirection, B's DNS resolver would also behave as the request
router and directly return the IP address of a delivery node. router and directly return the IP address of a delivery node.
4. The request router for Operator B processes the HTTP request and 4. The request router for Operator B processes the HTTP request and
selects a suitable delivery node to serve the end-user request, selects a suitable delivery node to serve the end-user request,
skipping to change at page 19, line 38 skipping to change at page 18, line 40
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 op-b-acq.op- of CSP's content by dCDN. In this example, we'll use
a.net. op-b-acq.op-a.net.
We assume the operators also exchange information regarding which We assume the operators also exchange information regarding which
requests dCDN is prepared to serve. For example, dCDN may be requests dCDN is prepared to serve. For example, dCDN may be
prepared to serve requests from clients in a given geographical prepared to serve requests from clients in a given geographical
region or a set of IP address prefixes. This information may again region or a set of IP address prefixes. This information may again
be provided out of band or via a defined protocol. be provided out of band or via a defined protocol.
We assume DNS is configured in the following way: We assume DNS is configured in the following way:
o The content provider is configured to make operator A the o The content provider is configured to make operator A the
authoritative DNS server for cdn.csp.com (or to return a CNAME for authoritative DNS server for cdn.csp.com (or to return a CNAME for
cdn.csp.com for which operator A is the authoritative DNS server). cdn.csp.com for which operator A is the authoritative DNS server).
o Operator A is configured so that a DNS request for op-b-acq.op- o Operator A is configured so that a DNS request for
a.net returns a request router in Operator A. op-b-acq.op-a.net returns a request router in Operator A.
o Operator B is configured so that a request for node1.op-b.net/ o Operator B is configured so that a request for node1.op-b.net/
cdn.csp.com returns the IP address of a delivery node. Note that cdn.csp.com returns the IP address of a delivery node. Note that
there might be a number of such delivery nodes. there might be a number of such delivery nodes.
Figure 3 illustrates how a client request for Figure 3 illustrates how a client request for
http://cdn.csp.com/...rest of url... http://cdn.csp.com/...rest of url...
is handled. is handled.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.com | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
|IPaddr of A's Request Router | |IPaddr of A's Request Router |
|<--------------------------------------------------| |<--------------------------------------------------|
|HTTP cdn.csp.com | | |HTTP cdn.csp.com | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(2) | | |(2)
| |RR/RI REQ cdn.csp.com | | |RR/RI REQ cdn.csp.com |
| |<------------------------| | |<------------------------|
| | | | | |
| |RR/RI RESP node1.op-b.net| | |RR/RI RESP node1.op-b.net|
| |------------------------>| | |------------------------>|
| | |(3) | | |(3)
|302 node1.op-b.net/cdn.csp.com | |302 node1.op-b.net/cdn.csp.com |
|<--------------------------------------------------| |<--------------------------------------------------|
|DNS node1.op-b.net | | |DNS node1.op-b.net | |
|------------------------>| | |------------------------>| |
| |(4) | | |(4) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
|HTTP node1.op-b.net/cdn.csp.com | |HTTP node1.op-b.net/cdn.csp.com |
|------------------------>| | |------------------------>| |
| |(5) | | |(5) |
| |DNS op-b-acq.op-a.net | | |DNS op-b-acq.op-a.net |
| |------------------------>| | |------------------------>|
| | |(6) | | |(6)
| |IPaddr of A's Request Router | |IPaddr of A's Request Router
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.net |
| |------------------------>| | |------------------------>|
| | |(7) | | |(7)
| |302 node2.op-b.acq.op-A.net | |302 node2.op-b.acq.op-A.net
| |<------------------------| | |<------------------------|
| |DNS node2.op-b-acq.op-a.net | |DNS node2.op-b-acq.op-a.net
| |------------------------>| | |------------------------>|
| | |(8) | | |(8)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| | | | | |
| |HTTP node2.op-b-acq.op-a.net | |HTTP node2.op-b-acq.op-a.net
| |------------------------>| | |------------------------>|
| | |(9) | | |(9)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 4: Message Flow for Recursive HTTP Redirection Figure 4: Message Flow for Recursive HTTP Redirection
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. A DNS resolver for Operator A processes the DNS request for its 1. A DNS resolver for Operator A processes the DNS request for its
customer based on CDN-Domain cdn.csp.com. It returns the IP customer based on CDN-Domain cdn.csp.com. It returns the IP
address of a Request Router in Operator A. address of a Request Router in Operator A.
2. A Request Router for Operator A processes the HTTP request and 2. A Request Router for Operator A processes the HTTP request and
recognizes that the end-user is best served by another CDN-- recognizes that the end-user is best served by another
specifically one provided by Operator B--and so it queries the CDN-\u002Dspecifically one provided by Operator B-\u002Dand so it
CDNI Request Routing Redirection Interface of Operator B, queries the CDNI Request Routing Redirection Interface of
providing a set of information about the request including the Operator B, providing a set of information about the request
URL requested. Operator B replies with the DNS name of a including the URL requested. Operator B replies with the DNS
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 Request Routing Interface.
4. The end-user does a DNS lookup using the host name of the URL 4. The end-user does a DNS lookup using the host name of the URL
just provided (node1.op-b.net). B's DNS resolver returns the IP just provided (node1.op-b.net). B's DNS resolver returns the IP
address of the corresponding delivery node. Note that, since the address of the corresponding delivery node. Note that, since the
name of the delivery node was already obtained from B using the name of the delivery node was already obtained from B using the
CDNI Request Routing Interface, there should not be any further CDNI Request Routing Interface, there should not be any further
redirection here (in contrast to the iterative method described redirection here (in contrast to the iterative method described
skipping to change at page 22, line 49 skipping to change at page 21, line 18
avoid being tricked into serving as an open proxy). It then does avoid being tricked into serving as an open proxy). It then does
a DNS request for the inter-CDN Acquisition "distinguished" CDN- a DNS request for the inter-CDN Acquisition "distinguished" CDN-
Domain as agreed above (in this case, op-b-acq.op-a.net). Domain as agreed above (in this case, op-b-acq.op-a.net).
6. Operator A DNS resolver processes the DNS request and returns the 6. Operator A DNS resolver processes the DNS request and returns the
IP address of a request router in operator A. IP address of a request router in operator A.
7. The request router for Operator A processes the HTTP request from 7. The request router for Operator A processes the HTTP request from
Operator B delivery node. Operator A request router recognizes Operator B delivery node. Operator A request router recognizes
that the request is from a peer CDN rather than an end-user that the request is from a peer CDN rather than an end-user
because of the dedicated inter-CDN acquisition domain (op-b- because of the dedicated inter-CDN acquisition domain
acq.op-a.net). (Note that without this specially defined inter- (op-b-acq.op-a.net). (Note that without this specially defined
CDN acquisition domain, operator A would be at risk of inter-CDN acquisition domain, operator A would be at risk of
redirecting the request back to operator B, resulting in an redirecting the request back to operator B, resulting in an
infinite loop). The request router for Operator A selects a infinite loop). The request router for Operator A selects a
suitable delivery node in uCDN to serve the inter-CDN acquisition suitable delivery node in uCDN to serve the inter-CDN acquisition
request and returns a 302 redirect message for a new URL request and returns a 302 redirect message for a new URL
constructed by replacing the hostname by a subdomain of the constructed by replacing the hostname by a subdomain of the
Operator A's distinguished inter-CDN acquisition domain that Operator A's distinguished inter-CDN acquisition domain that
points to the selected delivery node. points to the selected delivery node.
8. Operator A recognizes that the DNS request is from a peer CDN 8. Operator A recognizes that the DNS request is from a peer CDN
rather than an end-user (due to the internal CDN-Domain) and so rather than an end-user (due to the internal CDN-Domain) and so
skipping to change at page 25, line 5 skipping to change at page 23, line 12
o dCDN is configured so that a request for "b.cdn.csp.com" returns a o dCDN is configured so that a request for "b.cdn.csp.com" returns a
delivery node in dCDN. delivery node in dCDN.
o uCDN is configured so that a request for "op-b-acq.op-a.net" o uCDN is configured so that a request for "op-b-acq.op-a.net"
returns a delivery node in uCDN. returns a delivery node in uCDN.
Figure 5 depicts the exchange of DNS and HTTP requests. The main Figure 5 depicts the exchange of DNS and HTTP requests. The main
differences from Figure 3 are the lack of HTTP redirection and differences from Figure 3 are the lack of HTTP redirection and
transparency to the end-user. transparency to the end-user.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.com | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
|CNAME b.cdn.csp.com | | |CNAME b.cdn.csp.com | |
|NS records for b.cdn.csp.com | |NS records for b.cdn.csp.com |
|<--------------------------------------------------| |<--------------------------------------------------|
|DNS b.cdn.csp.com | | |DNS b.cdn.csp.com | |
|------------------------>| | |------------------------>| |
| |(2) | | |(2) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
|HTTP cdn.csp.com | | |HTTP cdn.csp.com | |
|------------------------>| | |------------------------>| |
| |(3) | | |(3) |
| |DNS op-b-acq.op-a.net | | |DNS op-b-acq.op-a.net |
| |------------------------>| | |------------------------>|
| | |(4) | | |(4)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.net |
| |------------------------>| | |------------------------>|
| | |(5) | | |(5)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 5: Message Flow for DNS-based Redirection Figure 5: Message Flow for DNS-based Redirection
The steps illustrated in the figure are as follows: The steps illustrated in the figure are as follows:
1. Request Router for Operator A processes the DNS request for CDN- 1. Request Router for Operator A processes the DNS request for CDN-
Domain cdn.csp.com and recognizes that the end-user is best Domain cdn.csp.com and recognizes that the end-user is best
served by another CDN. (This may depend on the IP address of the served by another CDN. (This may depend on the IP address of the
user's local DNS resolver, or other information discussed below.) user's local DNS resolver, or other information discussed below.)
The Request Router returns a DNS CNAME response by "stacking" the The Request Router returns a DNS CNAME response by "stacking" the
skipping to change at page 26, line 29 skipping to change at page 24, line 37
provider that owns the origin server. provider that owns the origin server.
The advantages of this approach are that it is more transparent to The advantages of this approach are that it is more transparent to
the end-user and requires fewer round trips than HTTP-based the end-user and requires fewer round trips than HTTP-based
redirection (in its worst case, i.e., when none of the needed DNS redirection (in its worst case, i.e., when none of the needed DNS
information is cached). A potential problem is that the upstream CDN information is cached). A potential problem is that the upstream CDN
depends on being able to learn the correct downstream CDN that serves depends on being able to learn the correct downstream CDN that serves
the end-user from the client address in the DNS request. In standard the end-user from the client address in the DNS request. In standard
DNS operation, uCDN will only obtain the address of the client's DNS operation, uCDN will only obtain the address of the client's
local DNS resolver (LDNS), which is not guaranteed to be in the same local DNS resolver (LDNS), which is not guaranteed to be in the same
network (or geographic region) as the client. If not--e.g., the end- network (or geographic region) as the client. If not-\u002De.g., the
user uses a global DNS service--then the upstream CDN cannot end-user uses a global DNS service-\u002Dthen the upstream CDN cannot
determine the appropriate downstream CDN to serve the end-user. In determine the appropriate downstream CDN to serve the end-user. In
this case, and assuming the uCDN is capable of detecting that this case, and assuming the uCDN is capable of detecting that
situation, one option is for the upstream CDN to treat the end-user situation, one option is for the upstream CDN to treat the end-user
as it would any user not connected to a peer CDN. Another option is as it would any user not connected to a peer CDN. Another option is
for the upstream CDN to "fall back" to a pure HTTP-based redirection for the upstream CDN to "fall back" to a pure HTTP-based redirection
strategy in this case (i.e., use the first method). Note that this strategy in this case (i.e., use the first method). Note that this
problem affects existing CDNs that rely on DNS to determine where to problem affects existing CDNs that rely on DNS to determine where to
redirect client requests, but the consequences are arguably less redirect client requests, but the consequences are arguably less
serious for CDNI since the LDNS is likely in the same network as the serious for CDNI since the LDNS is likely in the same network as the
dCDN serves. One approach to ensuring that the client's IP address dCDN serves. One approach to ensuring that the client's IP address
skipping to change at page 28, line 5 skipping to change at page 25, line 29
There could be situations where being able to dynamically discover There could be situations where being able to dynamically discover
the set of requests that a given dCDN is willing and able to serve is the set of requests that a given dCDN is willing and able to serve is
beneficial. For example, a CDN might at one time be able to serve a beneficial. For example, a CDN might at one time be able to serve a
certain set of client IP prefixes, but that set might change over certain set of client IP prefixes, but that set might change over
time due to changes in the topology and routing policies of the IP time due to changes in the topology and routing policies of the IP
network. The following example illustrates this capability. We have network. The following example illustrates this capability. We have
chosen the example of DNS-based redirection, but HTTP-based chosen the example of DNS-based redirection, but HTTP-based
redirection could equally well use this approach. redirection could equally well use this approach.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.com | | |DNS cdn.csp.com | |
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(1) | | |(1)
| | RI REQ op-b.net | | | RI REQ op-b.net |
| |<------------------------| | |<------------------------|
| | |(2) | | |(2)
| | RI REPLY | | | RI REPLY |
| |------------------------>| | |------------------------>|
| | |(3) | | |(3)
|CNAME b.cdn.csp.com | | |CNAME b.cdn.csp.com | |
|NS records for b.cdn.csp.com | |NS records for b.cdn.csp.com |
|<--------------------------------------------------| |<--------------------------------------------------|
|DNS b.cdn.csp.com | | |DNS b.cdn.csp.com | |
|------------------------>| | |------------------------>| |
| |(2) | | |(2) |
|IPaddr of B's Delivery Node | |IPaddr of B's Delivery Node |
|<------------------------| | |<------------------------| |
|HTTP cdn.csp.com | | |HTTP cdn.csp.com | |
|------------------------>| | |------------------------>| |
| |(3) | | |(3) |
| |DNS op-b-acq.op-a.net | | |DNS op-b-acq.op-a.net |
| |------------------------>| | |------------------------>|
| | |(4) | | |(4)
| |IPaddr of A's Delivery Node | |IPaddr of A's Delivery Node
| |<------------------------| | |<------------------------|
| |HTTP op-b-acq.op-a.net | | |HTTP op-b-acq.op-a.net |
| |------------------------>| | |------------------------>|
| | |(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 CDNI Request Routing Interface Footprint request (step 2) and
corresponding response (step 3). The RI REQ could be a message such corresponding response (step 3). The RI REQ could be a message such
as "Can you serve clients from this IP Prefix?" or it could be as "Can you serve clients from this IP Prefix?" or it could be
"Provide the list of client IP prefixes you can currently serve". In "Provide the list of client IP prefixes you can currently serve". In
either case the response might be cached by operator A to avoid either case the response might be cached by operator A to avoid
repeatedly asking the same question. Alternatively, or in addition, repeatedly asking the same question. Alternatively, or in addition,
skipping to change at page 31, line 4 skipping to change at page 28, line 29
| |(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 Control Interface to request that Operator B
pre-positions a particular content item identified by its URL. pre-positions a particular content item identified by its URL.
Operator B responds by confirming that it is willing to perform Operator B responds by confirming that it is willing to perform
this operation. this operation.
Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only
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 Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of Figure
Figure 3, only this time Operator B CDN can serve the end-user 3, only this time Operator B CDN can serve the end-user request
request without triggering dynamic content acquisition, since the without triggering dynamic content acquisition, since the content has
content has been pre-positioned in dCDN. Note that, depending on been pre-positioned in dCDN. Note that, depending on dCDN operations
dCDN operations and policies, the content pre-positioned in the dCDN and policies, the content pre-positioned in the dCDN may be pre-
may be pre-positioned to all, or a subset of, dCDN caches. In the positioned to all, or a subset of, dCDN caches. In the latter case,
latter case, intra-CDN dynamic content acquisition may take place intra-CDN dynamic content acquisition may take place inside the dCDN
inside the dCDN serving requests from caches on which the content has serving requests from caches on which the content has not been pre-
not been pre-positioning; however, such intra-CDN dynamic acquisition positioning; however, such intra-CDN dynamic acquisition would not
would not involve the uCDN. involve the uCDN.
3.8. Asynchronous CDNI Metadata Example 3.8. Asynchronous CDNI Metadata Example
In this section we walk through a simple example illustrating a In this section we walk through a simple example illustrating a
scenario of asynchronously exchanging CDNI metadata, where the scenario of asynchronously exchanging CDNI metadata, where the
downstream CDN obtains CDNI metadata for content ahead of a downstream CDN obtains CDNI metadata for content ahead of a
corresponding content request. The example that follows assumes that corresponding content request. The example that follows assumes that
HTTP-based inter-CDN redirection and recursive CDNI request-routing HTTP-based inter-CDN redirection and recursive CDNI request-routing
are used, as in Section 3.3. However, asynchronous exchange of CDNI are used, as in Section 3.3. However, asynchronous exchange of CDNI
Metadata is similarly applicable to DNS-based inter-CDN redirection Metadata is similarly applicable to DNS-based inter-CDN redirection
skipping to change at page 33, line 12 skipping to change at page 30, line 25
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
requiring enforcement by the delivery node of a specific per- requiring enforcement by the delivery node of a specific per-
request authorization mechanism (e.g. URI signature or token request authorization mechanism (e.g. URI signature or token
validation). validation).
5. A Content Request occurs as usual. 5. A Content Request occurs as usual.
6. A CDNI Request Routing Redirection request (RI REQ) is issued by 6. A CDNI Request Routing Redirection request (RI REQ) is issued by
operator A CDN, as discussed in Section 3.3. Operator B's operator A CDN, as discussed in Section 3.3. Operator B's
request router can access the CDNI Metadata that are relevant to request router can access the CDNI Metadata that are relevant to
the requested content and that have been pre-positioned as per the requested content and that have been pre-positioned as per
Steps 1-4, which may or may not affect the response. Steps 1-4, which may or may not affect the response.
skipping to change at page 35, line 25 skipping to change at page 32, line 36
7. A delivery node of Operator B receives the end user request. 7. A delivery node of Operator B receives the end user request.
8. The delivery node triggers dynamic acquisition of additional 8. The delivery node triggers dynamic acquisition of additional
CDNI metadata that are needed to process the end-user content CDNI metadata that are needed to process the end-user content
request. Note that there may exist cases where this step need request. Note that there may exist cases where this step need
not happen, for example because the metadata were already not happen, for example because the metadata were already
acquired previously. acquired previously.
9. Operator A's CDN responds to the CDNI Metadata Request and makes 9. Operator A's CDN responds to the CDNI Metadata Request and makes
the corresponding CDNI metadata available to Operator B. This the corresponding CDNI metadata available to Operator B. This
metadata influence how Operator B's CDN processes the end-user metadata influence how Operator B's CDN processes the end-user
request. request.
10. Content is served (possibly preceded by inter-CDN acquisition) 10. Content is served (possibly preceded by inter-CDN acquisition)
as in Section 3.3. as in Section 3.3.
3.10. Content and Metadata Acquisition with Multiple Upstream CDNs 3.10. Content and Metadata Acquisition with Multiple Upstream CDNs
A single dCDN may receive end-user requests from multiple uCDNs. A single dCDN may receive end-user requests from multiple uCDNs.
When a dCDN receives an end-user request, it must determine the When a dCDN receives an end-user request, it must determine the
skipping to change at page 36, line 40 skipping to change at page 34, line 4
Request Routing Interface and the Metadata Interface are tightly Request Routing Interface and the Metadata Interface are tightly
coupled in that the result of request routing (a rewritten URI coupled in that the result of request routing (a rewritten URI
pointing to the dCDN) serves as an input to metadata lookup. If the pointing to the dCDN) serves as an input to metadata lookup. If the
content metadata includes information for acquiring the content, then content metadata includes information for acquiring the content, then
the Metadata Interface 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 four main interfaces that are in scope for CDNI WG, along with several others. The detailed specifications of
the CDNI WG, along with several others. The detailed specifications these interfaces are left to other documents, but see RFC 6707 and
of 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.
There is also an important interface between the user and the Request There is also an important interface between the user and the Request
Routing function of both uCDN and dCDN (shown as the "Request" Routing function of both uCDN and dCDN (shown as the "Request"
Interface in Figure 1). As we saw in some of the preceding examples, Interface in Figure 1). As we saw in some of the preceding examples,
that interface can be used as a way of passing information a subset that interface can be used as a way of passing information a subset
of metadata such as the minimum information that is required for dCDN of metadata such as the minimum information that is required for dCDN
to obtain the content from uCDN. to obtain the content from uCDN.
In this section we will provide an overview of the functions In this section we will provide an overview of the functions
performed by each of the CDNI interfaces and discuss how they fit performed by each of the CDNI interfaces and discuss how they fit
into the overall solution. We also examine some of the design into the overall solution. We also examine some of the design
tradeoffs. We begin with an examination of one such tradeoff that tradeoffs, and explore several cross-interface concerns. We begin
affects all the interfaces - the use of in-band or out-of-band with an examination of one such tradeoff that affects all the
communication. interfaces - the use of in-band or out-of-band communication.
4.1. In-Band versus Out-of-Band Interfaces 4.1. In-Band versus Out-of-Band Interfaces
Before getting to the individual interfaces, we observe that there is Before getting to the individual interfaces, we observe that there is
a high-level design choice for each, involving the use of existing a high-level design choice for each, involving the use of existing
in-band communication channels versus defining new out-of-band in-band communication channels versus defining new out-of-band
interfaces. interfaces.
It is possible that the information needed to carry out various It is possible that the information needed to carry out various
interconnection functions can be communicated between peer CDNs using interconnection functions can be communicated between peer CDNs using
skipping to change at page 40, line 14 skipping to change at page 37, line 28
o Request ID - a unique identifier for this transfer o Request ID - a unique identifier for this transfer
o User agent - the user agent, if supplied o User agent - the user agent, if supplied
o Duration - the duration of the transfer in milliseconds o Duration - the duration of the transfer in milliseconds
o Cached Bytes - the number of body bytes served from the cache o Cached Bytes - the number of body bytes served from the cache
o Referrer - the referrer string from the client, if supplied o Referrer - the referrer string from the client, if supplied
Of these, only the Domain field is indirect in the downstream CDN--it Of these, only the Domain field is indirect in the downstream
is set to the CDN-Domain used by the upstream CDN rather than the CDN-\u002Dit is set to the CDN-Domain used by the upstream CDN rather
actual origin server. This field could then used to filter traffic than the actual origin server. This field could then used to filter
log entries so only those entries matching the upstream CDN are traffic log entries so only those entries matching the upstream CDN
reported to the corresponding operator. Further discussion of the are reported to the corresponding operator. Further discussion of
Logging Interface can be found in [I-D.bertrand-cdni-logging]. the Logging Interface 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
skipping to change at page 42, line 11 skipping to change at page 39, line 25
Similarly, some forms of access control may also be performed on a Similarly, some forms of access control may also be performed on a
per-request basis using HTTP directives. For example, being able to per-request basis using HTTP directives. For example, being able to
respond to a conditional GET request gives the upstream CDN an respond to a conditional GET request gives the upstream CDN an
opportunity to influence how the downstream CDN delivers its content. opportunity to influence how the downstream CDN delivers its content.
Minimally, the upstream CDN can invalidate (purge) content previously Minimally, the upstream CDN can invalidate (purge) content previously
cached by the downstream CDN. cached by the downstream CDN.
Fine-grain control over how the downstream CDN delivers content on Fine-grain control over how the downstream CDN delivers content on
behalf of the upstream CDN is also possible. For example, by behalf of the upstream CDN is also possible. For example, by
including the X-Forwarded-For HTTP header with the conditional GET including the Forwarded HTTP header [I-D.ietf-appsawg-http-forwarded]
request, the downstream CDN can report the end-user's IP address to with the conditional GET request, the downstream CDN can report the
the upstream CDN, giving it an opportunity to control whether the end-user's IP address to the upstream CDN, giving it an opportunity
downstream CDN should serve the content to this particular end-user. to control whether the downstream CDN should serve the content to
The upstream CDN would communicate its directive through its response this particular end-user. The upstream CDN would communicate its
to the conditional GET. The downstream CDN can cache information for directive through its response to the conditional GET. The
a period of time specified by the upstream CDN, thereby reducing downstream CDN can cache information for a period of time specified
control overhead. by the upstream CDN, thereby reducing control overhead, but then
preventing per-request control during the corresponding caching
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 Metadata
Interface. As a consequence, the Metadata Interface should provide a Interface. As a consequence, the Metadata Interface could provide a
means for the uCDN to express its desire to retain enforcement for means for the uCDN to express its desire to retain enforcement for
itself. For example, this might be done by including a "check with itself. For example, this might be done by including a "check with
me" flag in the metadata associated with certain content. me" flag in the metadata associated with certain content. The
realization of such in-band techniques over the various inter-CDN
acquisition protocols (e.g., HTTP) requires further investigation and
may require small extensions or semantic changes to the acquisition
protocol.
4.7. HTTP Adaptive Streaming Concerns 4.7. HTTP Adaptive Streaming Concerns
We consider HTTP Adaptive Streaming (HAS) and the impact it has on We consider HTTP Adaptive Streaming (HAS) and the impact it has on
the CDNI interfaces because large objects (e.g., videos) are broken the CDNI interfaces because large objects (e.g., videos) are broken
into a sequence of small, independent chunks. For each of the into a sequence of small, independent chunks. For each of the
following, a more thorough discussion, including an overview of the following, a more thorough discussion, including an overview of the
tradeoffs involved in alternative designs, can be found in tradeoffs involved in alternative designs, can be found in
[I-D.brandenburg-cdni-has]. [I-D.brandenburg-cdni-has].
skipping to change at page 43, line 43 skipping to change at page 41, line 14
approach is in line with the recommendations made in approach is in line with the recommendations made in
[I-D.brandenburg-cdni-has], which also identifies potential [I-D.brandenburg-cdni-has], which also identifies potential
improvements in this area that might be considered in the future. improvements in this area that might be considered in the future.
Fourth, with respect to the Control Interface, and in particular Fourth, with respect to the 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 Collection with a single reference. It is possible that this Purge-
Purge-ID could be merged with the CCID discussed above for HAS ID could be merged with the CCID discussed above for HAS Logging, or
Logging, or alternatively, they may remain distinct. alternatively, they may remain distinct.
4.8. URI Rewriting
When using HTTP redirection, content URIs may be rewritten when
redirection takes place within an uCDN, from an uCDN to a dCDN, and
within the dCDN. In the case of cascaded CDNs, content URIs may be
rewritten at every CDN hop (e.g., between the uCDN and the dCDN
acting as the transit CDN, and between the transit CDN and the dCDN
serving the request. The content URI used between any uCDN/dCDN pair
becomes a common handle that can be referred without ambiguity by
both CDNs in all their inter-CDN communications. This handle allows
the uCDN and dCDN to correlate information exchanged using other CDNI
interfaces in both the downstream direction (e.g., when using the MI)
and the upstream direction (e.g., when using the LI).
Consider the simple case of a single uCDN/dCDN pair using HTTP
redirection. We introduce the following terminology for content URIs
to simplify the discussion:
"u-URI" represents a content URI in a request presented to the
uCDN;
"ud-URI" is a content URI acting as the common handle across uCDN
and dCDN for requests redirected by the uCDN to a specific dCDN;
"d-URI" represents a content URI in a request made within the
delegate dCDN.
In our simple pair-wise example, the "ud-URI" effectively becomes the
handle that the uCDN/dCDN pair use to correlate all CDNI information.
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
all MI message exchanges, while the dCDN needs to map the d-URI to
the ud-URI handle for all LI message exchanges.
In the case of a cascaded CDNs, the transit CDN will re-write the
content URI when redirecting to the dCDN, thereby establishing a new
handle between the transit CDN and the dCDN, that is different from
the handle between the uCDN and transit CDN. It is the
responsibility of the transit CDN to manage its mapping across
handles so the right handle for all pairs of CDNs is always used in
its CDNI communication.
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
content URI reference.
5. Deployment Models 5. Deployment Models
In this section we describe a number of possible deployment models In this section we describe a number of possible deployment models
that may be achieved using the CDNI interfaces described above. We that may be achieved using the CDNI interfaces described above. We
note that these models are by no means exhaustive, and that many note that these models are by no means exhaustive, and that many
other models may be possible. other models may be possible.
Although the reference model of Figure 1 shows all CDN functions on Although the reference model of Figure 1 shows all CDN functions on
each side of the CDNI interface, deployments can rely on entities each side of the CDNI interface, deployments can rely on entities
that are involved in any subset of these functions, and therefore that are involved in any subset of these functions, and therefore
only support the relevant subset of CDNI interfaces. As already only support the relevant subset of CDNI interfaces. As already
noted in Section 3, effective CDNI deployments can be built without noted in Section 3, effective CDNI deployments can be built without
necessarily implementing all four interfaces. Some examples of such necessarily implementing all the interfaces. Some examples of such
deployments are shown below. deployments are shown below.
Note that, while we refer to upstream and downstream CDNs, this Note that, while we refer to upstream and downstream CDNs, this
distinction applies to specific content items and transactions. That distinction applies to specific content items and transactions. That
is, a given CDN may be upstream for some transactions and downstream is, a given CDN may be upstream for some transactions and downstream
for others, depending on many factors such as location of the for others, depending on many factors such as location of the
requesting client and the particular piece of content requested. requesting client and the particular piece of content requested.
5.1. Meshed CDNs 5.1. Meshed CDNs
skipping to change at page 46, line 52 skipping to change at page 44, line 35
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) \ #
# | | | +----+ | # # | +----+ | # # | | | +----+ | # # | +----+ | #
# | |*****| | RR |==========CDNI=====>| RR | | # # | |*****| | RR |==========CDNI=====>| RR | | #
# | | | +----+ | # RR # | +----+ | # # | | | +----+ | # RR # | +----+ | #
skipping to change at page 47, line 50 skipping to change at page 45, line 34
is the more general concept, involving two or more CDNs serving is the more general concept, involving two or more CDNs serving
content to each other's users, while federation implies a multi- content to each other's users, while federation implies a multi-
lateral interconnection arrangement, but other CDN interconnection lateral interconnection arrangement, but other CDN interconnection
agreements are also possible (e.g., symmetric bilateral, asymmetric agreements are also possible (e.g., symmetric bilateral, asymmetric
bilateral). An important conclusion is that CDNI technology should bilateral). An important conclusion is that CDNI technology should
not presume (or bake in) a particular interconnection agreement, but not presume (or bake in) a particular interconnection agreement, but
should instead be general enough to permit alternative should instead be general enough to permit alternative
interconnection arrangements to evolve. interconnection arrangements to evolve.
The second concept often used in the context of CDN Federation is CDN The second concept often used in the context of CDN Federation is CDN
Exchange--a third party broker or exchange that is used to facilitate Exchange-\u002Da third party broker or exchange that is used to
a CDN federation. Our view is that a CDN exchange offers valuable facilitate a CDN federation. Our view is that a CDN exchange offers
machinery to scale the number of CDN operators involved in a multi- valuable machinery to scale the number of CDN operators involved in a
lateral (federated) agreement, but that this machinery is built on multi-lateral (federated) agreement, but that this machinery is built
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 re-distribute traffic logs that each
participant needs for interconnection settlement, but inter-CDN participant needs for interconnection settlement, but inter-CDN
request routing, inter-CDN content distribution (including inter-CDN request routing, inter-CDN content distribution (including inter-CDN
acquisition) and inter-CDN control which fundamentally involve a acquisition) and inter-CDN control which fundamentally involve a
direct interaction between an upstream CDN and a downstream CDN-- direct interaction between an upstream CDN and a downstream
operate exactly as in a pair-wise peering arrangement. Turning to CDN-\u002Doperate exactly as in a pair-wise peering arrangement.
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 Interface with the
skipping to change at page 49, line 52 skipping to change at page 47, line 13
-------------- --------------
<=CDNI RR=> CDNI Request Routing Interface <=CDNI RR=> CDNI Request Routing Interface
<=CDNI M==> CDNI Metadata Interface <=CDNI M==> CDNI Metadata Interface
<=CDNI C==> CDNI Control Interface <=CDNI C==> CDNI Control Interface
<=CDNI L==> CDNI Logging Interface <=CDNI L==> CDNI Logging Interface
Figure 14: CDNI Deployment Model: CDN Exchange Figure 14: CDNI Deployment Model: CDN Exchange
Note that a CDN exchange may alternatively support a different set of Note that a CDN exchange may alternatively support a different set of
functionality (e.g. Logging only, or Logging and full request functionality (e.g. Logging only, or Logging and full request
routing, or all the functionality of a CDN including content routing, or all the functionality of a CDN including content
distribution). All these options are expected to be allowed by the distribution). All these options are expected to be allowed by the
IETF CDNI specifications. IETF CDNI specifications.
6. Trust Model 6. Trust Model
There are a number of trust issues that need to be addressed by a There are a number of trust issues that need to be addressed by a
CDNI solution. Many of them are in fact similar or identical to CDNI solution. Many of them are in fact similar or identical to
those in a simple CDN without interconnection. In a standard CDN those in a simple CDN without interconnection. In a standard CDN
environment (without CDNI), the CSP places a degree of trust in a environment (without CDNI), the CSP places a degree of trust in a
skipping to change at page 53, line 47 skipping to change at page 51, line 18
o Kent Leung o Kent Leung
10. Acknowledgements 10. Acknowledgements
We thank Huw Jones for helpful input to the draft. We thank Huw Jones for helpful input to the draft.
11. Informative References 11. Informative References
[I-D.bertrand-cdni-logging] [I-D.bertrand-cdni-logging]
Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F., Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F.,
and P. Grochocki, "CDNI Logging Interface", and P. Grochocki, "CDNI Logging Interface", draft-
draft-bertrand-cdni-logging-02 (work in progress), bertrand-cdni-logging-02 (work in progress), October 2012.
October 2012.
[I-D.brandenburg-cdni-has] [I-D.brandenburg-cdni-has]
Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung, Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung,
"Models for adaptive-streaming-aware CDN Interconnection", "Models for adaptive-streaming-aware CDN Interconnection",
draft-brandenburg-cdni-has-04 (work in progress), draft-brandenburg-cdni-has-05 (work in progress), April
January 2013. 2013.
[I-D.ietf-appsawg-http-forwarded]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-10 (work in progress),
October 2012.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
Leung, K., and K. Ma, "CDN Interconnect Metadata", Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
draft-ietf-cdni-metadata-00 (work in progress), ietf-cdni-metadata-02 (work in progress), July 2013.
October 2012.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", Interconnection (CDNI) Requirements", draft-ietf-cdni-
draft-ietf-cdni-requirements-04 (work in progress), requirements-09 (work in progress), July 2013.
December 2012.
[I-D.ietf-cdni-use-cases] [I-D.ietf-cdni-use-cases]
Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", draft-ietf-cdni-use-cases-10 (work in Interconnection", draft-ietf-cdni-use-cases-10 (work in
progress), August 2012. progress), August 2012.
[I-D.lefaucheur-cdni-logging-delivery] [I-D.lefaucheur-cdni-logging-delivery]
Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI
Logging Formats for HTTP and HTTP Adaptive Streaming Logging Formats for HTTP and HTTP Adaptive Streaming
Deliveries", draft-lefaucheur-cdni-logging-delivery-01 Deliveries", draft-lefaucheur-cdni-logging-delivery-01
(work in progress), July 2012. (work in progress), July 2012.
[I-D.murray-cdni-triggers] [I-D.murray-cdni-triggers]
Murray, R. and B. Niven-Jenkins, "CDN Interconnect Murray, R. and B. Niven-Jenkins, "CDNI Control Interface /
Triggers", draft-murray-cdni-triggers-01 (work in Triggers", draft-murray-cdni-triggers-03 (work in
progress), August 2012. progress), April 2013.
[I-D.seedorf-alto-for-cdni] [I-D.seedorf-alto-for-cdni]
Seedorf, J., "ALTO for CDNi Request Routing", Seedorf, J., "ALTO for CDNi Request Routing", draft-
draft-seedorf-alto-for-cdni-00 (work in progress), seedorf-alto-for-cdni-00 (work in progress), October 2011.
October 2011.
[I-D.spp-cdni-rr-foot-cap-semantics] [I-D.spp-cdni-rr-foot-cap-semantics]
Seedorf, J., Peterson, J., and S. Previdi, "CDNI Request Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R.,
Routing: Footprint and Capabilities Semantics", and K. Ma, "CDNI Request Routing: Footprint and
draft-spp-cdni-rr-foot-cap-semantics-02 (work in Capabilities Semantics", draft-spp-cdni-rr-foot-cap-
progress), October 2012. semantics-04 (work in progress), February 2013.
[I-D.vandergaast-edns-client-subnet] [I-D.vandergaast-edns-client-subnet]
Contavalli, C., Gaast, W., Leach, S., and E. Lewis, Contavalli, C., Gaast, W., Leach, S., and E. Lewis,
"Client subnet in DNS requests", "Client Subnet in DNS Requests", draft-vandergaast-edns-
draft-vandergaast-edns-client-subnet-01 (work in client-subnet-02 (work in progress), July 2013.
progress), April 2012.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466, for Content Internetworking (CDI)", RFC 3466, February
February 2003. 2003.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, Optimization (ALTO) Problem Statement", RFC 5693, October
October 2009. 2009.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
Authors' Addresses Authors' Addresses
Larry Peterson (editor) Larry Peterson (editor)
Akamai Technologies, Inc. Akamai Technologies, Inc.
8 Cambridge Center 8 Cambridge Center
 End of changes. 52 change blocks. 
368 lines changed or deleted 423 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/