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/ |