| < 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||