Network Working Group G. Watson
Internet-Draft BT
Intended status: Experimental January 6, 2011
Expires: July 10, 2011
CDN Interconnect Use Cases
draft-watson-cdni-use-cases-00
Abstract
[draft-jenkins-cdni-problem-statement] outlines the problem space for
CDN Interconnection within the IETF. This documents provides a
complimentary set of technical use cases for how CDNs may be
interconnected. The goal of this document is to outline real world
use-cases for CDN Interconnect, for the IETF, with the intention of
supporting the case for formation of a Working Group which would work
on the definition of standardised, interoperable methods of
Interconnecting CDNs. The goal of this document is NOT to define the
technical solutions to be used.
The intent of this document is to outline a set of technical use
cases. While the technical use cases may be influenced by business-
related and other non-technical factors, this document does not
attempt to detail any non-technical aspects of CDN Interconnect.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]
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 July 10, 2011.
Watson Expires July 10, 2011 [Page 1]
Internet-Draft CDN Interconnect Use Cases January 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
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Single CDN . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Base Use Case for CDN Interconnection . . . . . . . . . . . . 6
5. Intermediate CDNs . . . . . . . . . . . . . . . . . . . . . . 8
6. Other user cases . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Watson Expires July 10, 2011 [Page 2]
Internet-Draft CDN Interconnect Use Cases January 2011
1. Introduction
There are many possible combinations for the relationships between
the different parties (Network Service Provider (NSP), CDN Provider,
Content Service Provider (CSP), etc.) involved in end to end content
delivery. However, in the context of interconnecting CDNs the key
relationships are:
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 CDNs interact with one another to deliver the
CSP's content to the End User.
The role of the NSP in the end to end content delivery is excluded
above because although some NSPs may also have their own CDN which
may be interconnected with other CDNs (that may or may not have
direct relationships with an ISP or ISPs), the existence of such
NSP<->CDN relationships does not affect the information that needs to
be exchanged across a CDN Interconnect and therefore these NSP<->CDN
relationships do not need to be specifically called out within the
use cases. In other words no NSP-specific information needs to be
exchanged across a CDN Interconnect.
Therefore this document will use NSPs to highlight that sets of End
Users may be attached to different ISP networks but it does not imply
or exclude any further relationship between the NSP and the CDN.
Equally, the type of CDNs (e.g. NSP operated, Over The Top, global
footprint, regional footprint, etc.) that interact over a CDN
Interconnect do not need to be explicitly called out within the use
cases. Again this is because the type of CDN that exists on either
side on a CDN Interconnect does not place an specific "CDN type"
related requirements on the information that needs to be exchanged
across the interconnect.
Therefore this document will refer to CDNs in a generic fashion where
it is meant that any reference to a CDN could refer to any type of
deployment and operational model for a CDN including both NSP
operated and Over-the-top CDNs, CDNs that partner with NSPs and those
that do not, etc.
In the sections that follow a number of CDN Interconnection use cases
are described along with an set of interactions between the main
Actors. The interactions described are illustrative in order to
highlight the main touchpoints and interactions, in a number of
Watson Expires July 10, 2011 [Page 3]
Internet-Draft CDN Interconnect Use Cases January 2011
places various details may be glossed over or omitted in order to
avoid complicating the use case description with layers of detail
that is not directly relevant to the use case. For example the use
cases do not go into detail of how a User Agent is redirected to a
Surrogate to avoid detailing the details and nuances of DNS versus
application level redirection.
2. Terminology
This document uses terms defined in
[draft-jenkins-cdni-problem-statement]
The following additional terms are used:
Authoritative CDN: A CDN that maintains a direct business
relationship with a CSP for the delivery of the CSP's Content.
Request Router: The function responsible for steering or directing a
Content Request received directly from a User Agent (or received from
another CDN via a CDNI) to a suitable Surrogate (or alternative CDN).
Surrogate: A device/function that interacts with other elements of
the CDN for the control and distribution of Content within the CDN
and interacts with User Agents for the delivery of the Content.
End User (EU): The 'real' user of the system, typically a human but
maybe some combination of hardware and/or software emulating a human
(e.g. for automated quality monitoring etc.).
User Agent (UA): Software (or a combination of hardware and software)
through which the User interacts with the Content Service. The User
Agent will communicate with the CSP's Service for the selection of
content and one or more CDNs for the delivery of the Content. Such
communication is not restricted to HTTP and may be via a variety of
protocols. Examples of User Agents (non-exhaustive) are: Browsers,
Set Top Boxes (STB), Dedicated content applications (e.g. media
players), etc.
3. 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 use cases described in subsequent sections.
Watson Expires July 10, 2011 [Page 4]
Internet-Draft CDN Interconnect Use Cases January 2011
+-------+
| CSP-1 |
+-------+
|
,---------.
,-' `-.
( CDN-A )
`-. ,-'
`---------'
|
,---------.
,-' 0 or `-.
( more other )
`-. networks ,-'
/ `---------' \
/ \
,---------. ,---------.
,-' `-. ,-' `-.
( NSP-X ) ( NSP-Y )
`-. ,-' `-. ,-'
`---------' `---------'
| |
+-------+ +-------+
| UA-X | | UA-Y |
+-------+ +-------+
Single CDN Use Case
As shown in the diagram CSP-1 maintains a direct relationship with
CDN-A and CDN-A delivers content to User Agents attached to NSP-X and
NSP-Y. NSP-X and NSP-Y may or may not have a relationship with CDN-A
and traffic from CDN-A may traverse one or more other networks before
reaching NSP-X or NSP-Y.
In order for UA-X to receive content the following illustrative
interactions occur:
1. UA-X selects a piece of Content (as directed by an End User) from
CSP-1's service (e.g. through a portal or EPG).
2. CSP-1 returns a URL for the selected content which resolve to the
Request Router in CDN-A.
3. CDN-A's Request Router will select an appropriate Surrogate
(Cache) and redirect UA-X to the selected Surrogate in CDN-A.
Watson Expires July 10, 2011 [Page 5]
Internet-Draft CDN Interconnect Use Cases January 2011
4. UA-X will connect to the selected Surrogate and request the
Content.
4. Base Use Case for CDN Interconnection
This section describes the base use case for CDN Interconnection on
which the other use cases described in subsequent sections are built
upon.
"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 minimise 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. The single
CDN selected by the CSP is referred to as "The 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 that the
Authoritative CDN is interconnected with.
Although the Authoritative CDN makes the decision, that decision may
be influenced by policies configured by the CDN Operator(s) or the
CSP, e.g. "geo-blocking" rules that specify the geographic regions
where content can be delivered from (i.e. the location of the
Surrogates) and geographic locations where content can be delivered
to (i.e. the location of the End Users) or based on prior
notification of CDN capacity/availability from its own CDN surrogates
or interconnected CDN surrogates.
There is a large and diverse range of client software and devices
(referred to as User Agents in this document) used to access CSP
content via a CDN. It is assumed that content delivery through a set
of interconnected CDNs should not require any changes to existing
User Agents.
Taking the above two assumptions into account the base use case 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.
Watson Expires July 10, 2011 [Page 6]
Internet-Draft CDN Interconnect Use Cases January 2011
+-------+
| CSP-1 |
+-------+
|
,---------. ,---------.
,-' `-. ,-' `-.
( CDN-A )==I==( CDN-B )
`-. ,-' /`-. ,-'
`---------' / `---------'
| ___/ |
| / |
,---------. / ,---------.
,-' `-. ,-' `-.
( NSP-X ) ( NSP-Y )
`-. ,-' `-. ,-'
`---------' `---------'
| |
+-------+ +-------+
| UA-X | | UA-Y |
+-------+ +-------+
==I== CDN Interconnect
Base Use Case for CDN Interconnection
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 the delivery of contentto a UA/NSP to
CDN-B. How CDN-A makes such a decision is out of scope for this
document but some example scenarios include:
a. CDN-A has run out of capacity and so decides to use CDN-B to
handle the overspill rather than deny UA content requests from
NSP-X.
b. CDN-A may not have good coverage of the geographical region NSP-Y
resides in and so prefers to CDN-B to deliver content to that
region.
Let us assume that EU-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:
Watson Expires July 10, 2011 [Page 7]
Internet-Draft CDN Interconnect Use Cases January 2011
1. UA-Y selects a piece of content (as directed by EU-Y) from
CSP-1's service (e.g. through a portal or EPG).
2. CSP-1 returns a URL 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.
5. CDN-A's Request Router returns the appropriate response to UA-Y.
6. UA-Y will connect to CDN-B and request the content. Depending on
what CDN-B has returned to CDN-A earlier UA-Y may have connected
directly to a cache in CDN-B or may have connected to CDN-B's
Request Router where CDN-B's Request Router will select an
appropriate Surrogate (or possibly another CDN) and redirect UA-Y
to the selected Surrogate in CDN-B.
[Ed: There are a potentially couple of options, the above and the
option to hand off to CDN-B without making a request first. Consider
describing that as an option also? For example in the case of
intermediate CDN you might want to hand-off immediately to CDN-C
rather than relying on various requests flowing from A to B to C and
back.]
5. Intermediate CDNs
This use case extends the base use case by allowing CDN-B to accept a
delegated content delivery from CDN-A and then delegate the delivery
to CDN-C.
Watson Expires July 10, 2011 [Page 8]
Internet-Draft CDN Interconnect Use Cases January 2011
+-------+
| CSP-1 |
+-------+
|
,---------. ,---------. ,---------.
,-' `-. ,-' `-. ,-' `-.
( CDN-A )====( CDN-B )====( CDN-B )
`-. ,-' `-. ,-' `-. ,-'
`---------' `---------' `---------'
|
|
,---------.
,-' `-.
( NSP-Z )
`-. ,-'
`---------'
|
+-------+
| UA-Z |
+-------+
==== CDN Interconnect
Intermediate CDNs use case
6. Other user cases
[Ed: Needs expansion, currently just a placeholer for ideas]
Acquisition flow (via upstream CDNs and direct to CSP Origin)
Accounting flow.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations
[Ed: TBD]
Watson Expires July 10, 2011 [Page 9]
Internet-Draft CDN Interconnect Use Cases January 2011
9. Acknowledgements
Thanks to Ben Niven-Jenkins for some valuable discussions and
suggestions.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[draft-jenkins-cdni-problem-statement]
Niven-Jenkins, B., "Content Distribution Network
Interconnection (CDNI) Problem Statement", 2010.
Author's Address
Grant Watson
BT
Email: grant.watson@bt.com
Watson Expires July 10, 2011 [Page 10]