draft-ietf-cdni-framework-13.txt | draft-ietf-cdni-framework-14.txt | |||
---|---|---|---|---|
Network Working Group L. Peterson | Network Working Group L. Peterson | |||
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: December 1, 2014 R. van Brandenburg, Ed. | Expires: December 8, 2014 R. van Brandenburg, Ed. | |||
TNO | TNO | |||
May 30, 2014 | June 6, 2014 | |||
Framework for CDN Interconnection | Framework for CDN Interconnection | |||
draft-ietf-cdni-framework-13 | draft-ietf-cdni-framework-14 | |||
Abstract | Abstract | |||
This document presents a framework for Content Distribution Network | This document presents a framework for Content Distribution Network | |||
Interconnection (CDNI). The purpose of the framework is to provide | Interconnection (CDNI). The purpose of the framework is to provide | |||
an overall picture of the problem space of CDNI and to describe the | an overall picture of the problem space of CDNI and to describe the | |||
relationships among the various components necessary to interconnect | relationships among the various components necessary to interconnect | |||
CDNs. CDN Interconnection requires the specification of interfaces | CDNs. CDN Interconnection requires the specification of interfaces | |||
and mechanisms to address issues such as request routing, | and mechanisms to address issues such as request routing, | |||
distribution metadata exchange, and logging information exchange | distribution metadata exchange, and logging information exchange | |||
skipping to change at page 1, line 44 | skipping to change at page 1, line 44 | |||
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 December 1, 2014. | This Internet-Draft will expire on December 8, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 12, line 17 | skipping to change at page 12, line 17 | |||
| | | | | | | | |||
| | [Async FCI Push] | (1) | | | [Async FCI Push] | (1) | |||
| | | | | | | | |||
| | [MI pre-positioning] | (2) | | | [MI pre-positioning] | (2) | |||
| | | | | | | | |||
| CONTENT REQUEST | | | | CONTENT REQUEST | | | |||
|-------------------------------------------------->| (3) | |-------------------------------------------------->| (3) | |||
| | | | | | | | |||
| | [Sync RI Pull] | (4) | | | [Sync RI Pull] | (4) | |||
| | | | | | | | |||
| RI REPLY | | | | CONTENT REQUEST REDIRECTION | | |||
|<--------------------------------------------------| (5) | |<--------------------------------------------------| (5) | |||
| | | | | | | | |||
| | | | | | | | |||
| CONTENT REQUEST | | | | CONTENT REQUEST | | | |||
|------------------------>| | (6) | |------------------------>| | (6) | |||
| | | | | | | | |||
| | [Sync MI Pull] | (7) | | | [Sync MI Pull] | (7) | |||
| | | | | | | | |||
| | ACQUISITION REQUEST | | | | ACQUISITION REQUEST | | |||
| X------------------------>| (8) | | X------------------------>| (8) | |||
skipping to change at page 15, line 14 | skipping to change at page 15, line 14 | |||
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.example (or to return a CNAME | authoritative DNS server for cdn.csp.example (or to return a CNAME | |||
for cdn.csp.example for which operator A is the authoritative DNS | for cdn.csp.example for which operator A is the authoritative DNS | |||
server). | server). | |||
o Operator A is configured so that a DNS request for | o Operator A is configured so that a DNS request for op-b-acq.op- | |||
op-b-acq.op-a.example returns a request router in Operator A. | a.example returns a request router in Operator A. | |||
o Operator B is configured so that a DNS request for peer-a.op-b | o Operator B is configured so that a DNS request for peer-a.op- | |||
.example/cdn.csp.example returns a request router in Operator B. | b.example/cdn.csp.example returns a request router in Operator B. | |||
Figure 3 illustrates how a client request for | Figure 3 illustrates how a client request for | |||
http://cdn.csp.example/...rest of url... | http://cdn.csp.example/...rest of url... | |||
is handled. | is handled. | |||
End-User Operator B Operator A | End-User Operator B Operator A | |||
|DNS cdn.csp.example | | | |DNS cdn.csp.example | | | |||
|-------------------------------------------------->| | |-------------------------------------------------->| | |||
skipping to change at page 20, line 11 | skipping to change at page 20, line 11 | |||
Routing Redirection interface) to enable "recursive" CDNI request | Routing Redirection interface) to enable "recursive" CDNI request | |||
routing. We build on the HTTP-based redirection approach because it | routing. We build on the HTTP-based redirection approach because it | |||
illustrates the principles and benefits clearly, but it is equally | illustrates the principles and benefits clearly, but it is equally | |||
possible to perform recursive redirection when DNS-based redirection | possible to perform recursive redirection when DNS-based redirection | |||
is employed. | is employed. | |||
In contrast to the prior example, the operators need not agree in | In contrast to the prior example, the operators need not agree in | |||
advance on a CDN-Domain to serve as the target of redirections from | advance on a CDN-Domain to serve as the target of redirections from | |||
uCDN to dCDN. We assume that the operators agree on some | uCDN to dCDN. We assume that the operators agree on some | |||
distinguished CDN-Domain that will be used for inter-CDN acquisition | distinguished CDN-Domain that will be used for inter-CDN acquisition | |||
of CSP's content by dCDN. In this example, we'll use | of CSP's content by dCDN. In this example, we'll use op-b-acq.op- | |||
op-b-acq.op-a.example. | a.example. | |||
We assume the operators also exchange information regarding which | We assume the operators also exchange information regarding which | |||
requests dCDN is prepared to serve. For example, dCDN may be | requests dCDN is prepared to serve. For example, dCDN may be | |||
prepared to serve requests from clients in a given geographical | prepared to serve requests from clients in a given geographical | |||
region or a set of IP address prefixes. This information may again | region or a set of IP address prefixes. This information may again | |||
be provided out of band or via a defined protocol. | be provided out of band or via a defined protocol. | |||
We assume DNS is configured in the following way: | We assume DNS is configured in the following way: | |||
o The content provider is configured to make operator A the | o The content provider is configured to make operator A the | |||
authoritative DNS server for cdn.csp.example (or to return a CNAME | authoritative DNS server for cdn.csp.example (or to return a CNAME | |||
for cdn.csp.example for which operator A is the authoritative DNS | for cdn.csp.example for which operator A is the authoritative DNS | |||
server). | server). | |||
o Operator A is configured so that a DNS request for | o Operator A is configured so that a DNS request for op-b-acq.op- | |||
op-b-acq.op-a.example returns a request router in Operator A. | a.example returns a request router in Operator A. | |||
o Operator B is configured so that a request for node1.op-b.example/ | o Operator B is configured so that a request for node1.op-b.example/ | |||
cdn.csp.example returns the IP address of a delivery node. Note | cdn.csp.example returns the IP address of a delivery node. Note | |||
that there might be a number of such delivery nodes. | that there might be a number of such delivery nodes. | |||
Figure 3 illustrates how a client request for | Figure 3 illustrates how a client request for | |||
http://cdn.csp.example/...rest of url... | http://cdn.csp.example/...rest of url... | |||
is handled. | is handled. | |||
skipping to change at page 22, line 36 | skipping to change at page 22, line 36 | |||
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.example). | Domain as agreed above (in this case, op-b-acq.op-a.example). | |||
6. Operator A DNS resolver processes the DNS request and returns the | 6. Operator A DNS resolver processes the DNS request and returns the | |||
IP address of a request router in operator A. | IP address of a request router in operator A. | |||
7. The request router for Operator A processes the HTTP request from | 7. The request router for Operator A processes the HTTP request from | |||
Operator B delivery node. Operator A request router recognizes | Operator B delivery node. Operator A request router recognizes | |||
that the request is from a peer CDN rather than an end-user | that the request is from a peer CDN rather than an end-user | |||
because of the dedicated inter-CDN acquisition domain | because of the dedicated inter-CDN acquisition domain (op-b- | |||
(op-b-acq.op-a.example). (Note that without this specially | acq.op-a.example). (Note that without this specially defined | |||
defined inter-CDN acquisition domain, operator A would be at risk | inter-CDN acquisition domain, operator A would be at risk of | |||
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 with a subdomain of the | constructed by replacing the hostname with a subdomain of the | |||
Operator A's distinguished inter-CDN acquisition domain that | Operator A's distinguished inter-CDN acquisition domain that | |||
points to the selected delivery node. | points to the selected delivery node. | |||
8. Operator A recognizes that the DNS request is from a peer CDN | 8. Operator A recognizes that the DNS request is from a peer CDN | |||
rather than an end-user (due to the internal CDN-Domain) and so | rather than an end-user (due to the internal CDN-Domain) and so | |||
returns the address of a delivery node. (Note that without this | returns the address of a delivery node. (Note that without this | |||
End of changes. 10 change blocks. | ||||
17 lines changed or deleted | 17 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/ |