< draft-bertrand-cdni-experiments-01.txt   draft-bertrand-cdni-experiments-02.txt >
Internet Engineering Task Force G. Bertrand, Ed. Internet Engineering Task Force G. Bertrand, Ed.
Internet-Draft France Telecom - Orange Internet-Draft France Telecom - Orange
Intended status: Informational F. Le Faucheur Intended status: Informational F. Le Faucheur
Expires: February 20, 2012 Cisco Systems Expires: August 18, 2012 Cisco Systems
L. Peterson L. Peterson
Verivue, Inc. Verivue, Inc.
August 19, 2011 February 15, 2012
Content Distribution Network Interconnection (CDNI) Experiments Content Distribution Network Interconnection (CDNI) Experiments
draft-bertrand-cdni-experiments-01 draft-bertrand-cdni-experiments-02
Abstract Abstract
This document reports studies and related experiments on CDN This document reports studies and related experiments on CDN
interconnection performed by France Telecom-Orange Labs. The interconnection performed by France Telecom-Orange Labs. The
document summarizes implications of CDN interconnection to CDN document summarizes implications of CDN interconnection to CDN
service providers and lessons learned through CDNI experiments. service providers and lessons learned through CDNI experiments.
The main purpose of the experiments was to test the interconnection The main purpose of the experiments was to test the interconnection
of CDN solutions from two vendors (namely, Cisco and Verivue) and to of CDN solutions from two vendors (namely, Cisco and Verivue) and to
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 February 20, 2012. This Internet-Draft will expire on August 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 3, line 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. CDN Interconnection Experiments . . . . . . . . . . . . . . . 5 2. CDN Interconnection Experiments . . . . . . . . . . . . . . . 4
2.1. Experiment Configuration . . . . . . . . . . . . . . . . . 5 2.1. Experiment Configuration . . . . . . . . . . . . . . . . . 4
2.2. Control . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Control . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Request Routing and Content Delivery . . . . . . . . . . . 7 2.4. Request Routing and Content Delivery . . . . . . . . . . . 6
2.4.1. HTTP Redirection by CDN A and Delivery by CDN B . . . 8 2.4.1. HTTP Redirection by CDN A and Delivery by CDN B . . . 7
2.4.2. HTTP Redirection by CDN B and Delivery by CDN A . . . 10 2.4.2. HTTP Redirection by CDN B and Delivery by CDN A . . . 9
2.4.3. Test Result . . . . . . . . . . . . . . . . . . . . . 12 2.4.3. Test Result . . . . . . . . . . . . . . . . . . . . . 11
2.5. Content Delivery Metadata . . . . . . . . . . . . . . . . 13 2.5. Content Delivery Metadata . . . . . . . . . . . . . . . . 12
2.6. Content Acquisition . . . . . . . . . . . . . . . . . . . 13 2.6. Content Acquisition . . . . . . . . . . . . . . . . . . . 12
2.6.1. Content Acquisition by CDN B through CDN A . . . . . . 13 2.6.1. Content Acquisition by CDN B through CDN A . . . . . . 12
2.6.2. Content Acquisition by CDN A Directly from CP B . . . 14 2.6.2. Content Acquisition by CDN A Directly from CP B . . . 13
3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 15 3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Request Routing . . . . . . . . . . . . . . . . . . . . . 16 3.1. Request Routing . . . . . . . . . . . . . . . . . . . . . 15
3.1.1. Request-Routing Information and Policies . . . . . . . 16 3.1.1. Request-Routing Information and Policies . . . . . . . 15
3.1.2. Iterative and Recursive Redirection . . . . . . . . . 16 3.1.2. Iterative and Recursive Redirection . . . . . . . . . 15
3.1.3. Request Looping Avoidance . . . . . . . . . . . . . . 17 3.1.3. Request Looping Avoidance . . . . . . . . . . . . . . 16
3.2. Content Delivery Metadata . . . . . . . . . . . . . . . . 17 3.2. Content Delivery Metadata . . . . . . . . . . . . . . . . 16
3.3. Content Acquisition and Deletion . . . . . . . . . . . . . 18 3.3. Content Acquisition and Deletion . . . . . . . . . . . . . 17
3.3.1. Content Pre-Positioning in Downstream CDN . . . . . . 18 3.3.1. Content Pre-Positioning in Downstream CDN . . . . . . 17
3.3.2. Content Purge . . . . . . . . . . . . . . . . . . . . 18 3.3.2. Content Purge . . . . . . . . . . . . . . . . . . . . 17
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document reports studies and related experiments on CDN This document reports studies and related experiments on CDN
interconnection performed by France Telecom-Orange Labs. The interconnection performed by France Telecom-Orange Labs. The
document summarizes implications of CDN interconnection to CDN document summarizes implications of CDN interconnection to CDN
service providers and lessons learned through CDNI experiments. service providers and lessons learned through CDNI experiments.
The main purpose of the experiments was to test the interconnection The main purpose of the experiments was to test the interconnection
of CDN solutions from two vendors (namely, Cisco and Verivue) and to of CDN solutions from two vendors (namely, Cisco and Verivue) and to
skipping to change at page 4, line 26 skipping to change at page 4, line 26
This study is not intended to explore the entire scope of CDNI, and This study is not intended to explore the entire scope of CDNI, and
in fact, it purposely takes a minimalist approach. That is, we focus in fact, it purposely takes a minimalist approach. That is, we focus
on what's minimally required to interconnect two cooperating CDNs in on what's minimally required to interconnect two cooperating CDNs in
a "best effort" way. This provides a constructive foundation for a "best effort" way. This provides a constructive foundation for
adding requirements and mechanisms only after they prove essential in adding requirements and mechanisms only after they prove essential in
practice. practice.
1.1. Terminology 1.1. Terminology
Except for the terms defined below, we adopt the terminology We adopt the terminology described in [RFC3466], [RFC3568],
described in [RFC3466], [RFC3568], [RFC3570], the problem statement [RFC3570], CDNI problem statement draft
draft [I-D.jenkins-cdni-problem-statement] and the use cases draft [I-D.ietf-cdni-problem-statement], CDNI framework draft
[I-D.bertrand-cdni-use-cases]. [I-D.davie-cdni-framework] and CDNI use cases draft
[I-D.ietf-cdni-use-cases].
Content Distribution Network (CDN) / Content Delivery Network (CDN):
A type of network in which the components are arranged for more
effective delivery of content to User Agents.
Content Delivery Service Content Delivery Service
Set of services offered to content providers (CPs) for delivering Set of services offered to content service providers (CSPs) for
their content through a single Content Delivery Network or delivering their content through a single Content Delivery Network or
interconnections of Content Delivery Networks. interconnections of Content Delivery Networks.
CDN Service Provider (CDSP):
An administrative entity who operates a CDN over a Network Service
Provider (NSP) or over the Internet.
Authoritative CDN (aCDN):
The CDSP contracted by the CP for delivery of content by this CDN or
by its downstream CDNs.
Downstream CDN (dCDN):
A CDSP which is contracted by an upstream CDN to achieve the delivery
of content to users.
CDN Interconnection (CDNI):
Relationship between two CDNs that enables a CDN to provide content
delivery services on behalf of another CDN. It relies on a set of
interfaces over which two CDNs communicate in order to achieve the
delivery of content to end-users by one CDN (the downstream CDN) on
behalf of another CDN (the upstream CDN).
Recursive Request Routing:
Recursive: Where a process is repeated, but embedded within the
original process. In the case of Request Routing, this means that
the initial request received by the Authoritative CDN is processed
downstream from one CDN to another and that the responses are send
back upstream to the Authoritative CDN which then replies to the
initial request.
Iterative Request Routing:
Iterative: Where a process is repeated multiple times to make
progress towards a goal. In the case of Request Routing, this means
that the initial request is received by the Authoritative CDN, which
replies it with a redirection directive to a dowstream CDN. When the
end-user sends its request to the downstream CDN, the same process is
repeated, until the request arrives to the delivering CDN.
User-Agent (UA):
A client application acting as the end point of a communication
session.
2. CDN Interconnection Experiments 2. CDN Interconnection Experiments
2.1. Experiment Configuration 2.1. Experiment Configuration
The interconnection of two CDN solutions from different vendors has The interconnection of two CDN solutions from different vendors has
been tested. These tests have been run with CDN solutions from Cisco been tested. These tests have been run with CDN solutions from Cisco
(hereafter referred to as Vendor A) and from Verivue/CoBlitz (hereafter referred to as Vendor A) and from Verivue/CoBlitz
(hereafter referred to as Vendor B). (hereafter referred to as Vendor B).
As depicted in Figure 1, we have interconnected two experimental CDNs As depicted in Figure 1, we have interconnected two experimental CDNs
skipping to change at page 7, line 26 skipping to change at page 6, line 23
2.2. Control 2.2. Control
The tested CDN solutions support control APIs but those are The tested CDN solutions support control APIs but those are
proprietary, so that the tested CDN solutions do not support a common proprietary, so that the tested CDN solutions do not support a common
inter-operable CDNI control interface. Therefore, we have not tested inter-operable CDNI control interface. Therefore, we have not tested
CDNI control operations and we had to perform manually most CDNI control operations and we had to perform manually most
operations related to the configuration of the CDNI. operations related to the configuration of the CDNI.
2.3. Logging 2.3. Logging
Proprietary mechanisms to export transaction logs were available in Proprietary mechanisms to export transaction logs
the tested CDN solutions, but have not been covered by our tests. [I-D.bertrand-cdni-logging] were available in the tested CDN
solutions, but have not been covered by our tests.
2.4. Request Routing and Content Delivery 2.4. Request Routing and Content Delivery
As defined in [I-D.bertrand-cdni-use-cases], two main types of As defined in [I-D.davie-cdni-framework], two main types of request-
request-routing call flows can be used for CDNI: routing call flows can be used for CDNI:
1. iterative request-routing, 1. iterative request-routing,
2. recursive request-routing. 2. recursive request-routing.
Moreover, two main methods can be used for redirecting an end-user Moreover, two main methods can be used for redirecting an end-user
from the authoritative CDN to the downstream CDN: from the authoritative CDN to the downstream CDN:
1. DNS-based redirection, 1. DNS-based redirection,
skipping to change at page 16, line 8 skipping to change at page 15, line 8
In the present section, we highlight some of the limitations induced In the present section, we highlight some of the limitations induced
by the lack of standard CDNI interfaces that we have faced in our by the lack of standard CDNI interfaces that we have faced in our
tests. tests.
One of the insights from this work is that by encoding information One of the insights from this work is that by encoding information
inside the redirection URI, it is possible to communicate some inside the redirection URI, it is possible to communicate some
essential CDNI-related information across CDNs "in-band" (i.e., as essential CDNI-related information across CDNs "in-band" (i.e., as
part of HTTP), rather than communicating it through an out-of-band part of HTTP), rather than communicating it through an out-of-band
interface. In these tests, the information communicated in-band was interface. In these tests, the information communicated in-band was
restricted to the most fundamental information, that is, a handle restricted to the most fundamental information; that is, a handle
allowing the Downstream CDN to determine where to acquire the allowing the Downstream CDN to determine where to acquire the
content. This was key to achieving multi-CDN operations without any content. This was key to achieving multi-CDN operations without any
common CDNI "out-of-band" interface supported by existing CDN common CDNI "out-of-band" interface supported by existing CDN
technologies. This raises an interesting general question: what technologies. This raises an interesting general question: what
subset of inter-CDN information is to be communicated between subset of inter-CDN information is to be communicated between
interconnected CDNs in-band (possibly using existing methods) as interconnected CDNs in-band (possibly using existing methods) as
opposed to communicated via out-of-band interfaces? opposed to communicated via out-of-band interfaces?
3.1. Request Routing 3.1. Request Routing
skipping to change at page 19, line 25 skipping to change at page 18, line 25
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References 7.2. Informative References
[I-D.bertrand-cdni-use-cases] [I-D.bertrand-cdni-logging]
Bertrand, G., Stephan, E., Watson, G., Burbridge, T., Gilles, B. and S. Emile, "CDNI Logging Interface",
Eardley, P., and K. Ma, "Use Cases for Content Delivery draft-bertrand-cdni-logging-00 (work in progress),
Network Interconnection", draft-bertrand-cdni-use-cases-02 February 2012.
(work in progress), July 2011.
[I-D.jenkins-cdni-problem-statement] [I-D.davie-cdni-framework]
Davie, B. and L. Peterson, "Framework for CDN
Interconnection", draft-davie-cdni-framework-01 (work in
progress), October 2011.
[I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", draft-jenkins-cdni-problem-statement-02 (work Statement", draft-ietf-cdni-problem-statement-03 (work in
in progress), March 2011. progress), January 2012.
[I-D.lefaucheur-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K., Lee, Y., Faucheur, F., Viveganandhan, M., and Leung, K. and Y. Lee, "Content Distribution Network
G. Watson, "Content Distribution Network Interconnection Interconnection (CDNI) Requirements",
(CDNI) Requirements", draft-ietf-cdni-requirements-02 (work in progress),
draft-lefaucheur-cdni-requirements-02 (work in progress), December 2011.
July 2011.
[I-D.ietf-cdni-use-cases]
Gilles, B., Emile, S., Watson, G., Burbridge, T., Eardley,
P., and K. Ma, "Use Cases for Content Delivery Network
Interconnection", draft-ietf-cdni-use-cases-03 (work in
progress), January 2012.
[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, for Content Internetworking (CDI)", RFC 3466,
February 2003. February 2003.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms", Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003. RFC 3568, July 2003.
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
skipping to change at page 20, line 17 skipping to change at page 19, line 26
Authors' Addresses Authors' Addresses
Gilles Bertrand (editor) Gilles Bertrand (editor)
France Telecom - Orange France Telecom - Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy les Moulineaux 92130 Issy les Moulineaux 92130
FR FR
Phone: +33 1 45 29 89 46 Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange-ftgroup.com Email: gilles.bertrand@orange.com
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
FR FR
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com Email: flefauch@cisco.com
 End of changes. 17 change blocks. 
110 lines changed or deleted 70 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/
X-Generator: pyht 0.35