Network Working Group B. Niven-Jenkins
Internet-Draft Velocix (Alcatel-Lucent)
Intended status: Informational G. Watson
Expires: October 29, 2011 BT
N. Bitar
Verizon
April 27, 2011
Use Cases for ALTO within CDNs
draft-jenkins-alto-cdn-use-cases-00
Abstract
For some time, Content Distribution Networks (CDNs) have been used in
the delivery of some Internet services (e.g. delivery of websites,
software updates and video delivery) as they provide numerous
benefits including reduced delivery cost for cacheable content,
improved quality of experience for end users and increased robustness
of delivery.
In order to derive the optimal benefit from a CDN it is preferable to
deliver content from the servers (caches) that are "closest" to the
End User requesting the content, where "closest" may be as simple as
"geographical or network distance" combined with CDN server load
within a location, but may also consider other more complex
combinations of metrics and CDN or Network Service Provider (NSP)
policies.
There are a number of different ways in which a CDN may obtain the
necessary network topology and/or cost information to allow it to
serve End Users from the most optimal servers/locations, such as
static configuration, passively listening to routing protocols
directly, or obtaining topology and cost by querying an information
service such as the ALTO map & cost services.
This document describes the use cases for a CDN to be able to obtain
network topology and cost information from an ALTO server(s) and
details additional requirements on the ALTO protocol that result from
such use cases.
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
Niven-Jenkins, et al. Expires October 29, 2011 [Page 1]
Internet-Draft Use Cases for ALTO within CDNs April 2011
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 October 29, 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.
Niven-Jenkins, et al. Expires October 29, 2011 [Page 2]
Internet-Draft Use Cases for ALTO within CDNs April 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. CDN overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. CDN & ALTO Use Cases . . . . . . . . . . . . . . . . . . . . . 7
3.1. CDN deployed within a Broadband network . . . . . . . . . 8
3.2. CDN delivering Over-The-Top of a NSP's network . . . . . . 9
3.3. Additional Use Cases . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Niven-Jenkins, et al. Expires October 29, 2011 [Page 3]
Internet-Draft Use Cases for ALTO within CDNs April 2011
1. Introduction
For some time, Content Distribution Networks (CDNs) have been used in
the delivery of some Internet services (e.g. delivery of websites,
software updates and video delivery) as they provide numerous
benefits including reduced delivery cost for cacheable content,
improved quality of experience for end users and increased robustness
of delivery.
A CDN typically consists of a network of servers often attached to
Network Service Provider (NSP) networks. The point of attachment is
often as close to content consumers and peering points as
economically or operationally feasible in order to decrease traffic
load on the NSP backbone and to provide better user experience
measured by reduced latency and higher throughput.
As the volume of video and multimedia content delivered over the
Internet is rapidly increasing and expected to continue doing so in
the future, existing CDN providers are scaling up their
infrastructure and many NSPs are deploying their own CDNs. The
result of such deployments is typically that more CDN servers are
being deployed within NSP networks and those CDN servers are being
deployed in locations that are "deeper" (i.e. geographically closer
to the NSP's End Users) than was previously the case.
In order to derive the optimal benefit from a CDN it is preferable to
deliver content from the servers (caches) that are "closest" to the
End User requesting the content, where "closest" may be as simple as
"geographical or network distance" combined with CDN server load
within a location, but may also consider other more complex
combinations of metrics and CDN or NSP policies.
When CDN servers are deployed outside of an NSP's network or in a
small number of central locations within an NSP's network a
simplified view of the NSP's topology or an approximation of
proximity is typically sufficient to enable the CDN to serve End
Users from the optimal server/location. As CDN servers are deployed
deeper within NSP networks it becomes necessary for the CDN to have
more detailed knowledge of the underlying network topology and costs
between network locations in order to enable the CDN to serve End
Users from the most optimal servers for the NSP.
There are a number of different ways in which a CDN may obtain the
necessary network topology and/or cost information to allow it to
serve End Users from the most optimal servers/locations, such as
static configuration, passively listening to routing protocols
directly, or obtaining topology and cost by querying an information
service such as the ALTO map & cost services.
Niven-Jenkins, et al. Expires October 29, 2011 [Page 4]
Internet-Draft Use Cases for ALTO within CDNs April 2011
The rest of this document describes the use cases for a CDN to be
able to obtain network topology and cost information from an ALTO
server(s) and details additional requirements on the ALTO protocol
that result from such use cases.
1.1. Terminology
The following terms are taken from
[I-D.jenkins-cdni-problem-statement] and repeated here for
completeness.
Content Distribution Network (CDN) / Content Delivery Network (CDN):
Network infrastructure in which the network elements cooperate at
layers 4 through layer 7 for more effective delivery of Content to
User Agents. Typically a CDN consists of a Request Routing system, a
Distribution System (that includes a set of Surrogates), a Logging
System and a CDN control system.
Content Service Provider (CSP): Provides a Content Service to End
Users (which the End Users access via a User Agent). A CSP may own
the Content made available as part of the Content Service, or may
license content rights from another party.
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.)
Network Service Provider (NSP): Provides network-based connectivity/
services to Users.
User Agent (UA): Software (or a combination of hardware and software)
through which the End 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.
2. CDN overview
This section provides a high level and simplified overview of the
operation of a CDN to help put the ALTO & CDN use cases into context.
A typical CDN consists of a number of functional components, however
in the context of ALTO three functional components are of interest:
The Request Routing function, the Caching (Surrogate) function and
Niven-Jenkins, et al. Expires October 29, 2011 [Page 5]
Internet-Draft Use Cases for ALTO within CDNs April 2011
the Origin function.
The Request Routing function within a CDN responsible for receiving a
content request from a user agent, obtaining and maintaining
necessary information about a set of candidate surrogates, and for
selecting and redirecting the user to the appropriate surrogate.
The Surrogate (Cache) function 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.
The figure below shows a high level call flow showing the interaction
between a User Agent, Request Router and Surrogate for the delivery
of content in a single CDN.
User Agent Request Router Surrogate
| | |
| (1) Initial Request | |
+------------------------------>| |
| +--+ |
| | | (2) Surrogate Selection |
| |<-+ |
| (3) Redirection Response | |
|<------------------------------+ |
| | |
| (4) Content Request | |
+------------------------------------------------------------>|
| | |
| | (5) Content |
|<------------------------------------------------------------+
| | |
1. The User Agent makes an initial request to the CDN. Depending on
the type of content being delivered and the configuration of the
CDN this request may be an application (e.g. HTTP, RTMP, etc.)
level request directly from the User Agent or may be a DNS
request via the User Agent's assigned DNS proxy.
2. The Request Router selects an appropriate Surrogate based on the
User Agent's (or its proxy's) IP address, the Request Router's
knowledge of the network topology and reachability cost between
CDN caches and end users, and any additional CDN policies.
3. The Request Router responds to the UA's initial request with an
appropriate response containing a redirection to the selected
cache, for example by returning an appropriate DNS A/AAAA record,
a HTTP 302 redirect, etc.
Niven-Jenkins, et al. Expires October 29, 2011 [Page 6]
Internet-Draft Use Cases for ALTO within CDNs April 2011
4. The User Agent uses the information provided in the Redirection
Response to connect directly to the Surrogate and request the
desired content.
5. If CDN policy allows the User Agent to receive the requested
content, the Surrogate delivers the content to the User Agent.
A. [Not Shown] If the Surrogate does not have a copy of the
requested content then it obtains it from the appropriate
Origin Server (possibly via ).
Note: A Surrogate may not communicate with the Origin server
directly and instead obtain the requested content from other
surrogates or caching layers in the CDN hierarchy. The
details of how content requests filter through the CDN
hierarchy to the Origin server are internal to a specific CDN
and are out of scope of this document.
3. CDN & ALTO Use Cases
The primary use case for ALTO in a CDN context is to improve the
selection of a CDN surrogate or Origin server. The CDN Request
Routing system makes use of an ALTO server to choose a better CDN
surrogate or Origin than would otherwise be the case. In its
simplest form an ALTO server would provide an NSP with the capability
to offer a service to a CDN which provides network map and cost
information that the CDN can use to enhance its surrogate and/or
Origin selection.
Although it is possible to obtain raw network map and cost
information in other ways, for example passively listening to the
NSP's routing protocols, the use of an ALTO service to expose that
information may provide additional control to the NSP over how their
network map/cost is exposed. Additionally it may enable the NSP to
maintain a functional separation between their routing plane and
network map computation functions. This may be attractive for a
number of reasons, for example:
o The ALTO service could provide a filtered view of the network
and/or cost map that relates to CDN locations and their proximity
to end users, for example to allow the NSP to control the level of
topology detail they are willing to share with the CDN.
o The ALTO service could apply additional policies to the network
map and cost information to provide a CDN-specific view of the
network map/cost, for example to allow the NSP to encourage the
CDN to use network links that would not ordinarily be preferred by
a Shortest Path First routing calculation.
o The routing plane may be operated and controlled by a different
operational entity (even within a single NSP) to the CDN and the
ALTO service could provide a layer of separation because:
Niven-Jenkins, et al. Expires October 29, 2011 [Page 7]
Internet-Draft Use Cases for ALTO within CDNs April 2011
* The CDN is not able to passively listen to routing protocols.
* The NSP is not willing to allow the CDN to passively listen to
routing protocols, e.g. because the NSP is concerned the CDN
may inadvertently interfere with the routing plane or because
the routing plane and the CDN are operated by different
operational entities/groups (including different entities
within the same NSP).
o Etc.
The use cases in this document are not necessarily specific as to the
relationship between the commercial/operational entity that "owns"
the ALTO service and the commercial/operational entity that "owns"
the CDN service as it is assumed that such relationships will be
deployment specific. Although the ownership of each service may
affect the level of topology detail that the ALTO service will be
permitted to expose, it is assumed that the general requirements a
CDN places on the ALTO service should not change provided that the
ALTO server is able to expose sufficient topology for CDN to make
appropriate surrogate selection decisions.
For the rest of this document it is assumed that the ALTO service
will be operated by the entity that operates the underlying network.
The following sections outline some specific, non-exhaustive, example
use cases, which are subsets of the primary use case outlined above
but applied to specific usage examples to demonstrate how a CDN could
make use of ALTO services.
3.1. CDN deployed within a Broadband network
In this use case an NSP is providing Broadband services to its
customers and has deployed a CDN within its Broadband network to
alleviate the cost and/or improve the User Experience of content
services for its Broadband customers.
The topology of Broadband access/backhaul networks is often much more
constrained than metro/core networks. If CDN surrogates are deployed
within the access/backhaul network, for a given set of End Users, the
NSP is likely to want to utilise the surrogates deployed in the same
access/backhaul region as the End Users in preference to surrogates
deployed within the metro/core or within other access/backhaul
regions. It is common for Broadband subscribers to obtain their IP
addresses dynamically and in many deployments the IP subnets
allocated to a particular access/backhaul region can change
relatively frequently. For example new IP subnets are added as the
subscriber base grows, IP subnets are moved from one Broadband
product in the NSP's portfolio to another as customers migrate in
order to optimise the NSP's IP address utilisation, or they are
Niven-Jenkins, et al. Expires October 29, 2011 [Page 8]
Internet-Draft Use Cases for ALTO within CDNs April 2011
simply moved as part of IP address management, etc. Additionally, in
certain cases, CDN surrogates allocated in a regional network may
become overloaded, leading to the selection of other CDN caches for
content delivery. If this occurs, an NSP would typically prefer a
surrogate to be selected that is deployed in the the next best (cost-
wise) location.
In order to meet the NSP's objective of utilising their CDN to
constrain access/backhaul costs and/or improve User Experience it is
important that the CDN is able to select the most appropriate
surrogate for a given set of End User IP subnets. Although the
network topology is often reasonably static, in networks where the IP
subnets allocated to a Broadband region are changing relatively
frequently, static configuration of End User IP Subnets to CDN
surrogates is possible but some NSPs may consider the operational
burden of having to update such static configuration too high and
would prefer the CDN to be able to dynamically obtain network map and
cost information.
The NSP could make use of an ALTO service to expose a cost mapping
between End User IP subnets and CDN surrogate IP subnets/locations to
meet its requirements while avoiding static configuration or direct
integration of the CDN into its IP routing plane and to avoid the CDN
being required to implement network layer routing computations.
3.2. CDN delivering Over-The-Top of a NSP's network
In this use case a CDN is deployed within one or more NSPs' networks
but is delivering content "Over-The-Top" into another NSP's network
(which we will call NSP Z) where the CDN is not deployed.
The CDN is unlikely to have direct visibility of NSP Z's network
topology and may have a choice of entry points into NSP Z's network
from which it could serve content to NSP Z's End Users. For example
because NSP Z has direct peering links with the CDN in a number of
locations or NSP Z has transit and/or peering relationships with
several other NSPs where the CDN is deployed. NSP Z may wish to
influence the locations from which the CDN serves content based on
some factor(s) that it does not wish to expose directly or that might
change over time. For example the available transit/peering capacity
in different locations, the cost of connectivity to different
locations, etc.
For example, a CSP is using NSP A's CDN and another NSP (NSP Z) has
peering with NSP A in LA and NYC. NSP Z would like to influence
which peering location NSP A's CDN delivers content out of for NSP
Z's end users by using their knowledge of the capacity they have
deployed between those peering locations and groups of end users
Niven-Jenkins, et al. Expires October 29, 2011 [Page 9]
Internet-Draft Use Cases for ALTO within CDNs April 2011
without directly exposing their internal topology to NSP A.
3.3. Additional Use Cases
The following additional use case are relevant to ALTO and will be
described in more detail in a future version of this document:
o Inter-provider CDN.
o Use of ALTO to aid a CDN select from multiple Origins.
4. IANA Considerations
This document makes no specific request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
TBD.
6. Acknowledgements
The authors would like to thank Vijay Gurbani for his review comments
and contributions to the text.
7. Normative 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-02 (work
in progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Niven-Jenkins, et al. Expires October 29, 2011 [Page 10]
Internet-Draft Use Cases for ALTO within CDNs April 2011
Authors' Addresses
Ben Niven-Jenkins
Velocix (Alcatel-Lucent)
326 Cambridge Science Park
Milton Road, Cambridge CB4 0WG
UK
Email: ben@velocix.com
Grant Watson
BT
Email: grant.watson@bt.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
USA
Email: nabil.bitar@verizon.com
Niven-Jenkins, et al. Expires October 29, 2011 [Page 11]