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/