Internet Engineering Task Force G. Bertrand
Internet-Draft E. Stephan
Intended status: Informational France Telecom - Orange
Expires: August 1, 2011 G. Watson
T. Burbridge
P. Eardley
BT
January 28, 2011
Use Cases for Content Distribution Network Interconnection
draft-bertrand-cdni-use-cases-01
Abstract
Content Delivery Networks (CDNs) are commonly used for improving the
footprint and the end-user experience of a content delivery service,
at a reasonable cost. This document outlines real world use-cases
(not technical solutions) for interconnecting CDNs. The intention is
to motivate CDN Interconnection and to support the case for formation
of a Working Group, which would work on the definition of
standardized, inter-operable method(s) for interconnecting CDNs.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 1, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Bertrand, et al. Expires August 1, 2011 [Page 1]
Internet-Draft CDNI Use Cases January 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Bertrand, et al. Expires August 1, 2011 [Page 2]
Internet-Draft CDNI Use Cases January 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
2. High Level Use Cases for Multi-CDN Systems . . . . . . . . . . 7
2.1. Footprint Extension Use Cases . . . . . . . . . . . . . . 8
2.1.1. Geographic Extension . . . . . . . . . . . . . . . . . 8
2.1.2. Country to Country Interconnection . . . . . . . . . . 8
2.1.3. Nomadic Users . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Geo-blocking . . . . . . . . . . . . . . . . . . . . . 9
2.1.5. Device and Network Technology Extension . . . . . . . 9
2.2. Offload Use Cases . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Overload Handling and Dimensioning . . . . . . . . . . 10
2.2.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Technology and Vendor Interoperability . . . . . . . . . . 12
2.4. QoE and QoS improvement . . . . . . . . . . . . . . . . . 12
2.4.1. NSP CDSP Use Case . . . . . . . . . . . . . . . . . . 12
3. Experiments with Existing CDN Solutions and Lessons Learned . 12
3.1. France Telecom-Orange Experiments . . . . . . . . . . . . 12
3.2. Gaps in Existing Solutions and Need for Specifications . . 14
4. Discussion on Priorities for the Proposed Charter . . . . . . 14
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. CDN Interconnection Patterns . . . . . . . . . . . . 16
A.1. Single CDN . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2. Dual CDN with Direct Content Delivery . . . . . . . . . . 17
A.3. Intermediary CDN . . . . . . . . . . . . . . . . . . . . . 19
A.3.1. Option A - Recursive . . . . . . . . . . . . . . . . . 19
A.3.2. Option B - Iterative . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Bertrand, et al. Expires August 1, 2011 [Page 3]
Internet-Draft CDNI Use Cases January 2011
1. Introduction
This document now merges input from [I-D.watson-cdni-use-cases].
Content Delivery Networks (CDNs) are commonly used for improving the
footprint and the end-user experience of a content delivery service,
at a reasonable cost. This document outlines real world use-cases
(not technical solutions) for interconnecting CDNs. The intention is
to motivate CDN Interconnection and to support the case for formation
of a Working Group, which would work on the definition of
standardized, inter-operable method(s) for interconnecting CDNs.
There are many possible combinations for the relationships between
the different parties (Network Service Provider (NSP), Content
Delivery Service Provider (CDSP), Content Service Provider (CSP),
etc.) involved in end-to-end content delivery. However, in the
context of interconnecting CDNs the key relationships are listed
below.
o How the CSP interacts with the CDN to publish and deliver content.
o How the End User interacts with the interconnected CDNs to request
and receive content.
o How the different CDSPs, operating their CDNs, interact with one
another to deliver the CSP's content to the End User.
Section 2 describes a number of use cases that motivate CDN
Interconnection. We also briefly describe some experiments with
existing CDN solutions (Section 4).
1.1. Terminology
Except for the terms defined below, we adopt the terminology
described in [RFC3466], [RFC3568], and [RFC3570].
Problem statement draft [I-D.jenkins-cdni-problem-statement]defines a
set of terms. Below we recall only the terms used in the memo.
Content Service Provider (CSP):
Provides Content Services to Users. A CSP may own the content made
available as part of the Content Service, or may license content
rights from another party.
Content Service:
The service offered by a CSP. The Content Service encompasses the
Bertrand, et al. Expires August 1, 2011 [Page 4]
Internet-Draft CDNI Use Cases January 2011
complete service which may be wider than just the delivery of items
of Content, e.g. the Content Service also includes any middle-ware,
key distribution, program guide, etc. which may not require any
direct interaction with the CDN.
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
Set of services offered to CSPs for delivering their contents through
a single Content Delivery Network or interconnections of Content
Delivery Networks.
CDN Service Provider (CDSP):
An administrative entity who operates a CDN over a NSP or over the
Internet.
Authoritative CDN (aCDN):
The CDSP contracted by the CSP for delivery of content by this CDN or
by its downstream CDNs.
Downstream CDN (dCDN):
A CDSP which is contracted by an aCDN to achieve the delivery of
content to users.
Access CDN
A CDN that is connected to the end-user's access and has information
about the end-user's profile and access capabilities.
Delivering CDN
The CDN that delivers the requested content asset to the end-user.
In particular, the delivering CDN can be an access CDN.
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).
Bertrand, et al. Expires August 1, 2011 [Page 5]
Internet-Draft CDNI Use Cases January 2011
CDN peering: A business relation between two CDSPs based on one or
more CDN interconnections.
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.
1.2. Abbreviations
[Ed. Note: List of abbreviations to be updated later and sorted
alphabetically]
o ISP
o NSP
o STB
o PC
o QoS
o QoE
o SLA
o VoD
o WiFi
o 3G
Bertrand, et al. Expires August 1, 2011 [Page 6]
Internet-Draft CDNI Use Cases January 2011
2. High Level Use Cases for Multi-CDN Systems
The prevalent use cases for CDNI are presented according to a CDSP's
main motivation for interconnecting its CDN. They are classified
according to their level of priority for the CDSP:
o CDN Footprint Extension Use Cases
o CDN Offload Use Cases
o Technology and vendor interoperability
o QoE and QoS improvement
"CSPs have a desire to be able to get (some of their) content to very
large number of users and/or over many/all geographies and/or with a
high quality of experience, all without having to maintain direct
business relationships with many different CDN providers"
[draft-jenkins-cdni-problem-statement].
In order to minimize the number of direct business relationships
between a CSP and a set of interconnected CDNs, it is assumed that a
CSP will only be required/ desire to have a direct relationship with
a single CDN, although relationships with more than one CDN are not
precluded. A CDN selected by the CSP is referred to as an
"Authoritative CDN" in this document. When receiving requests from
User Agents, the Authoritative CDN will select an appropriate
Surrogate in its own CDN or will decide to delegate the delivery to
another CDN, to which a CDN interconnection can be established.
The CDNI model enables Content Delivery Networks to collaborate,
allowing Content Delivery Service Providers to offer consistent
delivery services throughout the CDN Interconnection
The CDNI model helps enables Content Delivery Networks that
collaborate to provide Content Service Providers with delivery
services throughout CDN Interconnections.
Let's take an example. CDSP-A and CDSP-B respectively operate CDN-A
and CDN-B. They establish a CDN peering for building the CDN
interconnections from CDN-A to CDN-B and from CDN-B to CDN-A. The
content service provider CSP-A reaches an agreement with CDSP-A.
CDSP-A services rely on the CDN-A and on the interconnection from
CDN-A to CDN-B. Meanwhile, the content service provider CSP-B
reaches an agreement with CDSP-B. These services rely on the CDN-A
and on the interconnection from CDN-A to CDN-B.
[Ed. Note: Figure to be added to help the reader understand the
Bertrand, et al. Expires August 1, 2011 [Page 7]
Internet-Draft CDNI Use Cases January 2011
example]
2.1. Footprint Extension Use Cases
Footprint extension is a major use case for CDN interconnection.
2.1.1. Geographic Extension
In this use case, the CDSP is concerned with extending the geographic
distribution that it can offer to the CSP without overly compromising
the quality of delivery and without attracting transit and other
network costs by serving from geographically or topologically remote
surrogates. For example, several CDSPs have a geographically limited
footprint (e.g., a country), or do not serve all end-users in a
geographic area. Interconnecting CDNs enables CDSPs to provide their
services beyond their own footprint by relying on other CDNs.
As an example, a French CSP that distributes TV series wants to
distribute them to end-users located in various countries in Europe
and North Africa. It asks a French CDSP to deliver the series to
several countries. The French CDSP makes an agreement with an
external CDSP that covers North Africa , so that overall the French
CDSP provides a CDN service for both France and North Africa.
This use case applies to other types of contents such as automatic
software updates (browser updates, operating system patches, or virus
database update, etc).
2.1.2. Country to Country Interconnection
There is a specific scenario where a large content delivery service
provider (CDSP) operates the CDNs of a set of subsidiaries from
different countries. These CDNs can rely on different CDN solutions.
Such a situation may occur due to independent regional operations, or
through mergers and acquisitions. In certain circumstances, the CDSP
needs to make its CDNs interoperate to provide a consistent service
to its customers on its whole footprint.
[Ed. Note: FIGURE TO BE INCLUDED
Figure 1
2.1.3. Nomadic Users
Another scenario is nomadic situation. In this scenario a CSP wishes
to allow users who move to other geographic regions to continue to
access their content. The motivation in this case is to allow
Bertrand, et al. Expires August 1, 2011 [Page 8]
Internet-Draft CDNI Use Cases January 2011
nomadic users to maintain access, rather than to allow all residents
within a region access to the content.
2.1.4. Geo-blocking
Currently, the distribution of some content is restricted. For
instance, distribution rights for audiovisual content are often
negotiated per country.
The selection of the Authoritative CDN is influenced by policies
which may include "geo-blocking" rules that specify
o the geographic regions where content can be delivered from (i.e.
the location of the Surrogates),
o geographic locations where content can be delivered to (i.e. the
location of the End Users),
o or quality of service policies specifying how the content is to be
delivered.
Hence, the exchange through the CDN interconnection of information
for controlling the footprint of the delivery is an important use
case.
2.1.5. Device and Network Technology Extension
In this use case the CDSP may have the geographic and end-user
coverage that it requires, but wishes to support the delivery of
content to alternative end devices. These devices may sit on remote
networks (such as smartphones connected to a mobile network) and may
also require unique delivery capabilities in the CDN. In this case
the CDSP may federate with another CDSP that offers service to these
devices.
As depicted in Figure 2, an end-user can use its tablet to download a
VoD through WiFi (1) from CDN1 and then switch to 3G network (2),
which is served by CDN2. The end user should be able to reach the
selected VoD content through any access network technology.
Consequently, every considered CDN must have access to this VoD
content. One way to proceed consists in having an ingestion
interface among the CDNs to access the content. Replication of the
requested VoD content in the CDN serving the terminal (a) enables
controlling the QoS (e.g. screen size, bitrate) of the VoD
distribution to the terminal used by the end-user. In another
situation, the serving of the VoD without replication (b) will save
storage resources. The end-user's experience improves thanks to an
increase of the number of situations where the end-user can access
Bertrand, et al. Expires August 1, 2011 [Page 9]
Internet-Draft CDNI Use Cases January 2011
the service.
-------------- --------------
/ CDN1 \ / CDN2 \
| Fixed | | Mobile |
| ,---. | | ,---. |
+---+ | . ) | (a) | . ) |
|CSP|****| |`---'| |''''`---------.....>|`---'| |
+---+ | | | -.. Acquisition | | | |
| ( ) | `-.._ | ( ) |
| `---' | `-.. | `---' |
|,------------.| (b) ``-._ |,------------.|
||Delivery || `->. Delivery ||
\`------------'/ \`------------'/
----------+--- -----*--+-----
: * |
: * |
+........+ +--------+
: Tablet : (1) | Tablet |(2)
+........+ +--------+
Figure 2: Fixed-Mobile CDN Inter-connection
.: This use case is similar to use case in Section 2.3.
2.2. Offload Use Cases
Offload is a major use case of CDN interconnection.
2.2.1. Overload Handling and Dimensioning
The support of prime-time traffic load requires over-dimensioning the
CDN capacity. In addition unexpected spikes in content popularity
may drive load beyond the expected peak. As prime time and peaks of
content distribution may differ between two CDNs, a CDN may
interconnect with another CDN to increase its effective peak
capacity. Similarly, two CDNs may benefit from dimensioning savings
by using the resources of each other during their peaks of activity.
The profile of activity peaks (time, duration ...) differ not only
from a country to another but also according to the kind of CDNs.
Therefore, CDN interconnect will be required since the additional
capacity is likely to be provided by alternative technology.
Offload also applies to planned situation where a CDSP needs CDN
capacities in a particular region during a short period of time. For
Bertrand, et al. Expires August 1, 2011 [Page 10]
Internet-Draft CDNI Use Cases January 2011
example, during a specific maintenance operation or for covering the
distribution of a special event, such as an international sport
competition.
2.2.2. Resiliency
It is important for CDNs to be able to guarantee service continuity
during partial failures (e.g., failure of a set of surrogates). In
partial failure scenarios, a CDSP could redirect some requests toward
another CDN. This downstream CDN must be able to serve the
redirected requests or, depending on traffic management policies, to
forward these requests to the CSP origin server.
Resiliency may also be required against failure to ingest content
from the CSP. In these cases the content may be available from
another CDSP.
-------------- --------------
/ CDN1 \ / CDN2 \
| ,---. | | ,---. |
+---+ | . ) | | . ) |
|CSP|*******| |`---'| |__________________| |`---'| |
+---+ | | | | Acquisition | | | |
| ( ) | | ( ) |
| `---' | | `---' |
|+-----------+ | |,------------.|
||Req-Routing| | .|Delivery ||
\+-----------+ / \`------------'/
------------ .-'-----------
| .-'
| --------------- > .-'
| Redirect .-'
| .-'
| .-'
| .-'
| .-'
| .-'
+-----+
| User|
+-----+
Figure 3: Example of CDN Interconnection for failure resiliency
Bertrand, et al. Expires August 1, 2011 [Page 11]
Internet-Draft CDNI Use Cases January 2011
2.3. Technology and Vendor Interoperability
ISPs have deployed platforms per service or per network technology.
They are deploying CDNs or enhancing existing platforms to CDN. It
is desirable in certain circumstances to share the content or the
resources among these internal CDNs. A CDSP may wish to operate a
multi-vendor strategy for its CDN. Currently, operating a single
controller for such multi-vendor CDNs is problematic. This problem
can be alleviated by a CDN interconnection that allows the automation
of some operations among these CDNs.
2.4. QoE and QoS improvement
Some existing CDNs make the decision to work with ISPs to deploy
surrogates closer to the end users. Compared to alternatives such as
adding capacity at major peering points, this method offers better
experience to the end users. Some CSPs are willing to pay a premium
for such enhanced service rather than just using the CDSP to mitigate
their server and network access costs. Improved experience may be
provided by closer proximity to the end users. It could also involve
network characteristics, such as provisioning or QoS, and specific
delivery techniques such as encoding for constant Quality of
Experience.
2.4.1. NSP CDSP Use Case
In a interconnection use case, CDSP-A is likely to offer an SLA to
the CSP including performance or other quality metrics. If it cannot
meet the SLA it will push content via the interconnection to a CDSP-B
with CDN capabilities that are in a position to guaranty the SLA, and
redirect users appropriately to CDSP-B. CDSP-A may not be able to,
or may not wish to deploy its own CDN capabilities to meet the SLA
requirements for only a subset of its CSP customers. The ability to
offer stringent delivery quality SLAs is a differentiator against
other CDSPs and can be sold as a premium service.
Although this use case has similarities to extending geographic
reach, in this case it is expected that the CDSP does have a CDN
deployed which could effectively serve content to the end-users, but
wishes to increase experience for specific CSPs.
3. Experiments with Existing CDN Solutions and Lessons Learned
3.1. France Telecom-Orange Experiments
As depicted in Figure 1, we have interconnected two CDNs (CDN A and
CDN B) operated by different subsidiaries of a large CDSP. The CDNs
Bertrand, et al. Expires August 1, 2011 [Page 12]
Internet-Draft CDNI Use Cases January 2011
cover two different countries, henceforth referred to as Country A
and Country B and they rely on CDN solutions from two different
equipment vendors (Vendor A and Vendor B). The CDNI experiment
supported the services of two CSPs (CSP A and CSP B).
+-------+ : +-------+
| CSP A | : | CSP B |
+------- : +-------
| : |
,--,--,--. : ,--,--,--.
,-' CDN A `-. : ,-' CDN B `-.
( (Vendor A) )==:==( (Vendor B) )
`-. ,-' : `-. ,-'
`--'--'--' : `--'--'--'
:
COUNTRY A : COUNTRY B
=== CDN Interconnect
Experiment configuration
Figure 1
We have run several experiments in the configuration represented in
Figure 2. In these experiments, CSP A has an agreement with CDSP A
for content delivery to end-users located in Country A and Country B.
However, CDSP A operates a CDN (CDN A), whose footprint does not
include country B. Therefore, CDSP A has an agreement with CDSP B, so
that CDN A can delegate to CDN B the delivery of some content. More
specifically, CDN A is allowed to delegate to CDN B the handling of
requests sent by end-users located in Country B for CSP A's content.
When CDN A receives a content request related to CSP A and from an
end-user in Country B, it redirects the end-user to the appropriate
content on CDN B. If CDN B does not have a local copy of the
requested content yet (cache miss), CDN B ingests the content from
CDN A (or from the CSP's origin servers, depending on the test
scenario); if CDN A also does not have a local copy of the requested
content, it requests this asset from the CSP's origin servers before
sending the asset to CDN B.
Bertrand, et al. Expires August 1, 2011 [Page 13]
Internet-Draft CDNI Use Cases January 2011
+-------+ :
| CSP A | :
+-------+ :
| :
,--,--,--. : ,--,--,--.
,-' CDN A `-. : ,-' CDN B `-.
( (Vendor A) )==:==( (Vendor B) )
`-. CDSP A ,-' : `-. CDSP B ,-'
`--'--'--' : `--'--'--'
: |
: +------+
: | EU B |
: +------+
:
COUNTRY A : COUNTRY B
=== CDN Interconnect
Test scenario with heterogeneous solutions
Figure 2
3.2. Gaps in Existing Solutions and Need for Specifications
Our experiments have shown that the current CDN technologies suffer
from the following limitations.
o The content management policies must be defined manually, so that
the end-user's request triggers content delivery from the most
appropriate CDN (e.g., a CDN in the country of the end-user, or a
CDN that serves the type of files requested by the end-user).
o The target URLs for the request redirection must also be defined
manually, so that the authoritative CDN provides to the end-user a
valid URI on the downstream CDN.
o The content ingestion from an upstream CDN worked only in pull
mode.
To address more sophisticated scenarios, we consider that common
interfaces are required for request routing among interconnected CDNs
and for the exchange of content distribution metadata.
4. Discussion on Priorities for the Proposed Charter
This section will be worked out later according to the discussions on
Bertrand, et al. Expires August 1, 2011 [Page 14]
Internet-Draft CDNI Use Cases January 2011
the mailing list.
5. Acknowledgments
The authors would like to thank Francois Le Faucheur and Ben Niven-
Jenkins for lively discussions.
They also thank the contributors of the EU FP7 OCEAN and ETICS
projects for valuable inputs.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
CDN interconnect, as described in this document, has a wide variety
of security issues that should be considered. For example, every
interconnected CDN should be able to assess if it must serve a
delegated request or if this request is delegated by a non-allowed
CDN. The CDNs should also be protected so as to avoid being
overwhelmed by delegated requests. This document focuses on the
motivational use cases for CDN interconnect, and therefore, does not
analyze the threats in detail.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.jenkins-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", draft-jenkins-cdni-problem-statement-01 (work
in progress), January 2011.
[I-D.lefaucheur-cdni-requirements]
Faucheur, F., Viveganandhan, M., Watson, G., and Y. Lee,
"Content Distribution Network Interconnection (CDNI)
Requirements", draft-lefaucheur-cdni-requirements-00 (work
Bertrand, et al. Expires August 1, 2011 [Page 15]
Internet-Draft CDNI Use Cases January 2011
in progress), January 2011.
[I-D.watson-cdni-use-cases]
Watson, G., "CDN Interconnect Use Cases",
draft-watson-cdni-use-cases-00 (work in progress),
January 2011.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466,
February 2003.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003.
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
Internetworking (CDI) Scenarios", RFC 3570, July 2003.
Appendix A. CDN Interconnection Patterns
In this section we attempt to pull out the generic CDN
interconnection patterns that may result from the use cases detailed
previously. We find little difference between the use cases in the
generic interconnection patterns that occur, and these are presented
below. However, differences do occur due to the the business
concerns of the different parties operating the components in each
use case. This will result in different technical requirements at a
more detailed level (for example in reporting and accounting
mechanisms).
A.1. Single CDN
This section outlines an illustrative model for content delivery via
a single CDN where there is no interconnection with other CDNs. It
does not describe all the details and variations but rather the high
level interactions between the different Actors (CSP, CDN, End User)
which can be used as a point of comparison with the CDN
Interconnection patterns described in subsequent sections.
Bertrand, et al. Expires August 1, 2011 [Page 16]
Internet-Draft CDNI Use Cases January 2011
+-------+
| CSP-1 |
+-------+
|
,---------.
,-' `-.
( CDN-A )
`-. ,-'
`---------'
|
,---------.
,-' 0 or `-.
( more other )
`-. networks ,-'
/ `---------' \
/ \
,---------. ,---------.
,-' `-. ,-' `-.
( NSP-X ) ( NSP-Y )
`-. ,-' `-. ,-'
`---------' `---------'
| |
+-------+ +-------+
| UA-X | | UA-Y |
+-------+ +-------+
A.2. Dual CDN with Direct Content Delivery
Taking the above use cases into account the base pattern for CDN
Interconnection is shown in the diagram below. To simplify the
diagram the cloud showing "zero or more other networks" has been
excluded and NSPs are shown as though they are directly attached to
CDNs. This is not intended to imply any direct relationships or to
exclude the case where one or more networks may exist between the NSP
illustrated and the CDN.
Bertrand, et al. Expires August 1, 2011 [Page 17]
Internet-Draft CDNI Use Cases January 2011
+-------+
| CSP-1 |
+-------+
|
,---------. ,---------.
,-' `-. ,-' `-.
( CDN-A )==I==( CDN-B )
`-. ,-' /`-. ,-'
`---------' / `---------'
| ___/ |
| / |
,---------. / ,---------.
,-' `-. ,-' `-.
( NSP-X ) ( NSP-Y )
`-. ,-' `-. ,-'
`---------' `---------'
| |
+-------+ +-------+
| UA-X | | UA-Y |
+-------+ +-------+
==I== CDN Intercon
As shown in the diagram CSP-1 maintains a direct relationship with
CDN-A and so CDN-A is the Authoritative CDN for CSP-1. CDN-A
maintains a CDN Interconnect with CDN-B. CDN-A may decide to
delegate to CDN-B the delivery of contentto a UA/NSP. How CDN-A
makes such a decision is out of scope for this document, although the
motivations for doing so are captured in the above use cases. Let us
assume that an End User, at User Agent Y, wishes to use CSP-1's
service and that CDN-A decides to delegate the delivery of the
content to CDN-B and that CDN-B is willing to perform the delegated
delivery. In order for EU-Y to receive content the following
illustrative interactions occur:
1. UA-Y selects a piece of content (as directed by EU-Y) from
CSP-1's service.
2. CSP-1 returns a URL, URL-A, for the selected content which
resolve to the Request Router in CDN-A, the Authoritative CDN for
CSP-1.
3. CDN-A's Request Router makes a decision to delegate the delivery
to CDN-B.
4. CDN-A makes a request to CDN-B to deliver the content on behalf
of CDN-A and CDN-B responds with details of how CDN-A's Request
Router should respond to the request.
Bertrand, et al. Expires August 1, 2011 [Page 18]
Internet-Draft CDNI Use Cases January 2011
5. CDN-A's Request Router returns the appropriate response to UA-Y
or another device acting on its behalf (such as a DNS resolver).
6. UA-Y will connect to CDN-B and request the content. At this
point there are several possible variations:
a. The content request is directed to the Request Router of CDN-B.
In this manner the UA can be iteratively passed between CDNs. The
Request Router of CDN-B may identify a surrogate in CDN-B, or may
identify another CDN (as elaborated in the Intermediary Pattern
below).
b. The content request is directed to a surrogate in CDN-B.
7. UA-Y receives the content from the surrogate in CDN-B. Again
there are a couple of options:
a. The content already exists in the chosen surrogate and is
delivered to the UA.
b. The content is not stored within the chosen surrogate and is
dynamically transferred to the surrogate and sequentially delivered
to the UA.
8. CDN-B may link the content to URL-B. In this manner another
service may use URL-B to preferentially serve the content from CDN-B
directly rather than being directed through CDN-A.
A.3. Intermediary CDN
This use case extends the dual CDN pattern by allowing CDN-B to
accept a delegated content delivery from CDN-A and then delegate the
delivery to CDN-C. There are a couple of options for this pattern.
A.3.1. Option A - Recursive
Steps 1 to 3 proceed as for the dual CDN pattern.
4. CDN-A makes a request to CDN-B to deliver the content on behalf
of CDN-A. CDN-B instead decides to delegate this request to CDN-C,
as permiited by its CDN peering agreement with CDN-A. Thus, the
Request Router of CDN-B refers the request to the Request Router of
CDN-C. CDN-C responds to CDN-B and in turn CDN-A's Request Router
with details of how to respond to UA-Y
Steps 5 to 8 proceed as for the dual CDN pattern with the exception
that CDN-B is replaced by CDN-C.
Bertrand, et al. Expires August 1, 2011 [Page 19]
Internet-Draft CDNI Use Cases January 2011
A.3.2. Option B - Iterative
Steps 1 to 5 proceed as for the dual CDN pattern.
6. UA-Y will connect to CDN-B and request the content. The content
request is directed to the Request Router of CDN-B. The Request
Router of CDN-B identifies that the request should be serviced by
CDN-C.
The pattern then proceeds from step 4 of the dual CDN pattern with
CDN-A replaced by CDN-B and CDN-B replaced by CDN-C.
+-------+
| CSP-1 |
+-------+
|
,---------. ,---------. ,---------.
,-' `-. ,-' `-. ,-' `-.
( CDN-A )====( CDN-B )====( CDN-C )
`-. ,-' `-. ,-' `-. ,-'
`---------' `---------' `---------'
|
|
,---------.
,-' `-.
( NSP-Z )
`-. ,-'
`---------'
|
+-------+
| UA-Z |
+-------+
==== CDN Interconnect
Bertrand, et al. Expires August 1, 2011 [Page 20]
Internet-Draft CDNI Use Cases January 2011
Authors' Addresses
Gilles Bertrand
France Telecom - Orange
38-40 rue du General Leclerc
Issy les moulineaux, 92130
FR
Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange-ftgroup.com
Stephan Emile
France Telecom - Orange
2 avenue Pierre Marzin
Lannion F-22307
France
Email: emile.stephan@orange-ftgroup.com
Grant Watson
BT
pp GDC 1 PP14, Orion Building, Adastral Park, Martlesham
Ipswich, IP5 3RE
UK
Email: grant.watson@bt.com
Trevor Burbridge
BT
B54 Room 70, Adastral Park, Martlesham
Ipswich, IP5 3RE
UK
Email: trevor.burbridge@bt.com
Philip Eardley
BT
B54 Room 77, Adastral Park, Martlesham
Ipswich, IP5 3RE
UK
Email: philip.eardley@bt.com
Bertrand, et al. Expires August 1, 2011 [Page 21]