draft-ietf-cdni-framework-02.txt   draft-ietf-cdni-framework-03.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: June 20, 2013 December 17, 2012 Expires: August 22, 2013 February 18, 2013
Framework for CDN Interconnection Framework for CDN Interconnection
draft-ietf-cdni-framework-02 draft-ietf-cdni-framework-03
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 June 20, 2013. This Internet-Draft will expire on August 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 16, line 20 skipping to change at page 16, line 20
| |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
| |------------------------>|
| | |(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:
skipping to change at page 17, line 46 skipping to change at page 17, line 49
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 suitable delivery node in uCDN to serve the inter-CDN
acquisition request and returns a 302 redirect message for a new acquisition request and returns a 302 redirect message for a new
URL constructed by replacing the hostname by a subdomain of the URL 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.
9. Operator A DNS resolver processes the DNS request and returns 9. Operator A DNS resolver processes the DNS request and returns
the IP address of the delivery node in operator A. the IP address of the delivery node in operator A.
10. Operator A serves content for the requested CDN-Domain to dCDN. 10. Operator B requests (acquires) the content from Operator A.
Although not shown, Operator A processes the rest of the URL: it Although not shown, Operator A processes the rest of the URL: it
extracts information identifying the origin server, validates extracts information identifying the origin server, validates
that this server has been registered, and determines the content that this server has been registered, and determines the content
provider that owns the origin server. It may also perform its provider that owns the origin server. It may also perform its
own content acquisition steps if needed before returning the own content acquisition steps if needed before returning the
content to dCDN. content to dCDN.
The main advantage of this design is that it is simple: each CDN need The main advantage of this design is that it is simple: each CDN need
only know the distinguished CDN-Domain for each peer, with the only know the distinguished CDN-Domain for each peer, with the
upstream CDN "pushing" the downstream CDN-Domain onto the URL as part upstream CDN "pushing" the downstream CDN-Domain onto the URL as part
skipping to change at page 21, line 22 skipping to change at page 21, line 22
|-------------------------------------------------->| |-------------------------------------------------->|
| | |(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 mode1.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)
skipping to change at page 21, line 45 skipping to change at page 21, line 45
| |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
| |------------------------>|
| | |(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:
skipping to change at page 23, line 16 skipping to change at page 23, line 18
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
specially defined internal domain, Operator A would be at risk of specially defined internal 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.) infinite loop.)
9. Operator A serves content for the requested CDN-Domain to dCDN. 9. Operator B requests (acquires) the content from Operator A.
Operator A serves content for the requested CDN-Domain to dCDN.
Although not shown, it is at this point that Operator A processes Although not shown, it is at this point that Operator A processes
the rest of the URL: it extracts information identifying the the rest of the URL: it extracts information identifying the
origin server, validates that this server has been registered, origin server, validates that this server has been registered,
and determines the content provider that owns the origin server. and determines the content provider that owns the origin server.
It may also perform its own content acquisition steps if needed It may also perform its own content acquisition steps if needed
before returning the content to dCDN. before returning the content to dCDN.
Recursive redirection has the advantage over iterative of being more Recursive redirection has the advantage over iterative of being more
transparent from the end-user's perspective, but the disadvantage of transparent from the end-user's perspective, but the disadvantage of
each CDN exposing more of its internal structure (in particular, the each CDN exposing more of its internal structure (in particular, the
skipping to change at page 54, line 9 skipping to change at page 54, line 9
[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-bertrand-cdni-logging-02 (work in progress), draft-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-03 (work in progress), draft-brandenburg-cdni-has-04 (work in progress),
July 2012. January 2013.
[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-ietf-cdni-metadata-00 (work in progress), draft-ietf-cdni-metadata-00 (work in progress),
October 2012. 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",
 End of changes. 10 change blocks. 
9 lines changed or deleted 16 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/