draft-ietf-cdni-framework-09.txt   draft-ietf-cdni-framework-10.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: August 3, 2014 R. van Brandenburg, Ed. Expires: September 4, 2014 R. van Brandenburg, Ed.
TNO TNO
January 30, 2014 March 3, 2014
Framework for CDN Interconnection Framework for CDN Interconnection
draft-ietf-cdni-framework-09 draft-ietf-cdni-framework-10
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 43 skipping to change at page 1, line 43
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 3, 2014. This Internet-Draft will expire on September 4, 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 7, line 14 skipping to change at page 7, line 14
o CDNI Logging interface (LI): Operations that allow interconnected o CDNI Logging interface (LI): Operations that allow interconnected
CDNs to exchange relevant activity logs. It may include a CDNs to exchange relevant activity logs. It may include a
combination of: combination of:
* Real-time exchanges, suitable for runtime traffic monitoring; * Real-time exchanges, suitable for runtime traffic monitoring;
and and
* Offline exchanges, suitable for analytics and billing. * Offline exchanges, suitable for analytics and billing.
There is some potential overlap between the set of Trigger-based The division between the sets of Trigger-based operations in the CDNI
operations in the CDNI Control interface and the CDNI Metadata Control interface and the CDNI Metadata interface is somewhat
interface. For both cases, the information passed from the upstream arbitrary. For both cases, the information passed from the upstream
CDN to the downstream CDN can broadly be viewed as metadata that CDN to the downstream CDN can broadly be viewed as metadata that
describes how content is to be managed by the downstream CDN. For describes how content is to be managed by the downstream CDN. For
example, the information conveyed by CI to pre-position, revalidate example, the information conveyed by CI to pre-position, revalidate
or purge metadata is similar to the information conveyed by posting or purge metadata is similar to the information conveyed by posting
updated metadata via the MI. Even the CI operation to purge content updated metadata via the MI. Even the CI operation to purge content
could be viewed as an metadata update for that content: purge simply could be viewed as an metadata update for that content: purge simply
says that the availability window for the named content ends now. says that the availability window for the named content ends now.
The two interfaces share much in common, so minimally, there will The two interfaces share much in common, so minimally, there will
need to be a consistent data model that spans both. need to be a consistent data model that spans both.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
| | | | | |
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:
1. dCDN uses the FCI to advertise information relevant to its 1. dCDN uses the FCI to advertise information relevant to its
delivery footprint and capabilities prior to any content delivery footprint and capabilities prior to any content
requests being redirected. requests being redirected.
2. Prior to any content request, the uCDN uses the MI to 2. Prior to any content request, the uCDN uses the MI to pre-
pre=position CDNI metadata to the dCDN, thereby making that position CDNI metadata to the dCDN, thereby making that metadata
metadata available in readiness for later content requests. available in readiness for later content requests.
3. A content request from a user agent arrives at uCDN. 3. A content request from a user agent arrives at uCDN.
4. uCDN may use the RI to synchronously request information from 4. uCDN may use the RI to synchronously request information from
dCDN regarding its delivery capabilities to decide if dCDN is a dCDN regarding its delivery capabilities to decide if dCDN is a
suitable target for redirection of this request. suitable target for redirection of this request.
5. uCDN redirects the request to dCDN by sending some response 5. uCDN redirects the request to dCDN by sending some response
(DNS, HTTP) to the user agent. (DNS, HTTP) to the user agent.
skipping to change at page 17, line 34 skipping to change at page 17, line 34
be aware of the other's internal redirection mechanism (i.e., whether be aware of the other's internal redirection mechanism (i.e., whether
it is DNS or HTTP based). it is DNS or HTTP based).
One disadvantage is that the end-user's browser is redirected to a One disadvantage is that the end-user's browser is redirected to a
new URL that is not in the same domain of the original URL. This has new URL that is not in the same domain of the original URL. This has
implications on a number of security or validation mechanisms implications on a number of security or validation mechanisms
sometimes used on endpoints. For example, it is important that any sometimes used on endpoints. For example, it is important that any
redirected URL be in the same domain (e.g., csp.example) if the redirected URL be in the same domain (e.g., csp.example) if the
browser is expected to send any cookies associated with that domain. browser is expected to send any cookies associated with that domain.
As another example, some video players enforce validation of a cross As another example, some video players enforce validation of a cross
domain policy that needs to allow for the domains involved in the CDN domain policy that needs to accommodate the domains involved in the
redirection. These problems are generally soluble, but the solutions CDN redirection. These problems are generally soluble, but the
complicate the example, so we do not discuss them further in this solutions complicate the example, so we do not discuss them further
version of the draft. in this version of the draft.
We note that this example begins to illustrate some of the interfaces We note that this example begins to illustrate some of the interfaces
that may be required for CDNI, but does not require all of them. For that may be required for CDNI, but does not require all of them. For
example, obtaining information from dCDN regarding the set of client example, obtaining information from dCDN regarding the set of client
IP addresses or geographic regions it might be able to serve is an IP addresses or geographic regions it might be able to serve is an
aspect of request routing (specifically of the CDNI Footprint & aspect of request routing (specifically of the CDNI Footprint &
Capabilities Advertisement interface). Important configuration Capabilities Advertisement interface). Important configuration
information such as the distinguished names used for redirection and information such as the distinguished names used for redirection and
inter-CDN acquisition could also be conveyed via a CDNI interface inter-CDN acquisition could also be conveyed via a CDNI interface
(e.g., perhaps the CDNI Control interface). The example also shows (e.g., perhaps the CDNI Control interface). The example also shows
skipping to change at page 36, line 44 skipping to change at page 36, line 44
redirection, as illustrated in Section 3.3. It enables the user to redirection, as illustrated in Section 3.3. It enables the user to
be redirected to the correct delivery node in dCDN with only a single be redirected to the correct delivery node in dCDN with only a single
redirection step (as seen by the user). This may be particularly redirection step (as seen by the user). This may be particularly
valuable as the chain of interconnected CDNs increases beyond two valuable as the chain of interconnected CDNs increases beyond two
CDNs. For further discussion on the RI, see CDNs. For further discussion on the RI, see
[I-D.ietf-cdni-redirection]. [I-D.ietf-cdni-redirection].
In support of these redirection requests, it is necessary for CDN In support of these redirection requests, it is necessary for CDN
peers to exchange additional information with each other, and this is peers to exchange additional information with each other, and this is
the role of the FCI part of request routing. Depending on the the role of the FCI part of request routing. Depending on the
method(s) supported, this might includes method(s) supported, this might include:
o The operator's unique id (operator-id) or distinguished CDN-Domain o The operator's unique id (operator-id) or distinguished CDN-Domain
(operator-domain); (operator-domain);
o NS records for the operator's set of externally visible request o NS records for the operator's set of externally visible request
routers; routers;
o The set of requests the dCDN operator is prepared to serve (e.g. a o The set of requests the dCDN operator is prepared to serve (e.g. a
set of client IP prefixes or geographic regions that may be served set of client IP prefixes or geographic regions that may be served
by dCDN). by dCDN).
skipping to change at page 53, line 9 skipping to change at page 53, line 9
[I-D.ietf-cdni-control-triggers] [I-D.ietf-cdni-control-triggers]
Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / Murray, R. and B. Niven-Jenkins, "CDNI Control Interface /
Triggers", draft-ietf-cdni-control-triggers-02 (work in Triggers", draft-ietf-cdni-control-triggers-02 (work in
progress), December 2013. progress), December 2013.
[I-D.ietf-cdni-footprint-capabilities-semantics] [I-D.ietf-cdni-footprint-capabilities-semantics]
Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R.,
and K. Ma, "CDNI Request Routing: Footprint and and K. Ma, "CDNI Request Routing: Footprint and
Capabilities Semantics", draft-ietf-cdni-footprint- Capabilities Semantics", draft-ietf-cdni-footprint-
capabilities-semantics-01 (work in progress), October capabilities-semantics-02 (work in progress), February
2013. 2014.
[I-D.ietf-cdni-logging] [I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R. Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-08 (work in progress), October 2013. logging-09 (work in progress), February 2014.
[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", draft- Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
ietf-cdni-metadata-04 (work in progress), December 2013. ietf-cdni-metadata-06 (work in progress), February 2014.
[I-D.ietf-cdni-redirection] [I-D.ietf-cdni-redirection]
Danhua, W., Niven-Jenkins, B., He, X., Chen, G., and W. Danhua, W., Niven-Jenkins, B., He, X., Chen, G., and W.
Ni, "Request Routing Redirection Interface for CDN Ni, "Request Routing Redirection Interface for CDN
Interconnection", draft-ietf-cdni-redirection-01 (work in Interconnection", draft-ietf-cdni-redirection-01 (work in
progress), October 2013. progress), October 2013.
[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", draft-ietf-cdni- Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-16 (work in progress), January 2014. requirements-17 (work in progress), January 2014.
[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", draft-vandergaast-edns- "Client Subnet in DNS Requests", draft-vandergaast-edns-
client-subnet-02 (work in progress), July 2013. client-subnet-02 (work in progress), July 2013.
[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, February for Content Internetworking (CDI)", RFC 3466, February
2003. 2003.
 End of changes. 12 change blocks. 
20 lines changed or deleted 20 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/