Content Delivery Networks J. Seedorf
Interconnection NEC
Internet-Draft October 19, 2012
Intended status: Informational
Expires: April 22, 2013
CDNI Request Routing with ALTO
draft-seedorf-cdni-request-routing-alto-03
Abstract
Network Service Providers (NSPs) are currently considering to deploy
Content Delivery Networks (CDNs) within their networks. As a
consequence of this development, there is a need for interconnecting
these local CDNs. The necessary interfaces for inter-connecting CDNs
are currently being defined in the Content Delivery Networks
Interconnection (CDNI) WG. This document focusses on the Request
Routing Interface of CDNI, and more specifically on how the solutions
currently being defined in the Application Layer Traffic Optimization
(ALTO) WG can improve CDNI request routing. The overall intention
behind this document is to foster discussions (in the CDNI as well as
in the ALTO WG) regarding if, how, and under what conditions ALTO can
be useful to optimize CDNI request routing. As basis for this
discussion, this document provides concrete examples of how ALTO can
be integrated within CDNI request routing and in particular in the
process of selecting a downstream CDN. The examples in this document
are based on the use cases and examples currently being discussed in
the CDNI WG.
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 April 22, 2013.
Copyright Notice
Seedorf Expires April 22, 2013 [Page 1]
Internet-Draft CDNI Request Routing with ALTO October 2012
Copyright (c) 2012 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. ALTO within CDNI Request Routing . . . . . . . . . . . . . . . 4
3. Assumptions and High-Level Design Considerations . . . . . . . 6
4. Selection of a Downstream CDN with ALTO . . . . . . . . . . . 8
4.1. Footprint Advertisement with ALTO Network Map . . . . . . 8
4.2. Resource Capabilities Advertisement with ALTO Network
Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Using ALTO maps to convey Additional Information for
Downstream CDN Selection . . . . . . . . . . . . . . . . . 9
4.4. Example of Selecting a Downstream CDN based on ALTO
Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Advantages of using ALTO . . . . . . . . . . . . . . . . . 11
5. Useful ALTO extensions for CDNI Request Routing . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Summary and Outlook . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. Informative References . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Seedorf Expires April 22, 2013 [Page 2]
Internet-Draft CDNI Request Routing with ALTO October 2012
1. Introduction
Many Network Service Providers (NSPs) are currently considering or
have already started to deploy Content Delivery Networks (CDNs)
within their networks. As a consequence of this development, there
is a need for interconnecting these local CDNs. Content Delivery
Networks Interconnection (CDNI) has the goal of standardizing
protocols to enable such interconnection of CDNs
[I-D.ietf-cdni-problem-statement].
The CDNI problem statement envisions four interfaces to be
standardized within the IETF for CDN interconnection
[I-D.ietf-cdni-problem-statement]:
o CDNI Request Routing Interface
o CDNI Metadata Interface
o CDNI Logging Interface
o CDNI Control Interface
This document focusses solely on the CDNI Request Routing Interface.
In particular, this document shows concrete examples of how ALTO
[RFC5693] can be integrated in CDNI request routing. The goal of
this document is to show in what cases ALTO can benefit CDNI request
routing, giving concrete examples and explaining how ALTO improves
CDNI request routing in each of these examples. The examples used in
this document are based on the use cases and request routing
proposals currently being discussed in the CDNI WG
[I-D.ietf-cdni-use-cases] [I-D.peterson-CDNI-strawman] and in the
ALTO WG [I-D.jenkins-alto-cdn-use-cases]. The overall rationale of
this document is to foster discussions (in the CDNI as well as in the
ALTO WG) regarding if, how, and under what conditions ALTO can be
useful to optimize CDNI request routing. Most importantly, the
document has the goal of finding consensus regarding which part of
the CDNI request routing interface can use ALTO.
A previous version of this document [I-D.seedorf-alto-for-cdni]
contained detailed examples of actual request routing and surrogate
selection with ALTO. This version solely focuses on selection of a
downstream CDN and how ALTO can support such downstream CDN
selection.
Throughout this document, we use the terminology for CDNI defined in
[I-D.ietf-cdni-problem-statement].
Seedorf Expires April 22, 2013 [Page 3]
Internet-Draft CDNI Request Routing with ALTO October 2012
2. ALTO within CDNI Request Routing
The main purpose of the CDNI Request Routing Interface is described
in [I-D.ietf-cdni-problem-statement] as follows: "The CDNI Request
Routing interface enables a Request Routing function in an upstream
CDN to query a Request Routing function in a downstream CDN to
determine if the downstream CDN is able (and willing) to accept the
delegated content request and to allow the downstream CDN to control
what the upstream Request Routing function should return to the User
Agent in the redirection message". On a high level, the scope of the
CDNI Request Routing Interface therefore contains two main tasks:
o A) Determining if the downstream CDN is willing to accept a
delegated content request
o B) Redirecting the content request coming from an upstream CDN to
the proper entry point or entity in the downstream CDN
More precisely, in [I-D.ietf-cdni-framework] the request routing
interface is broadly divided into two functionalities:
o 1) the asynchronous advertisement of footprint and capabilities by
a dCDN that allows a uCDN to decide whether to redirect particular
user requests to that dCDN;
o 2) the synchronous operation of actually redirecting a user
request.
Accorduing to consensus found at the CDNI working group session at
IETF-82, we refer to 1) as "Request Routing Interface - Footprint and
Capabilities Advertisement" and 2) as "Request Routing Interface -
Redirection" in this document. A previous version of this document
[I-D.seedorf-alto-for-cdni] provided some concrete examples how ALTO
could be used for the actual "redirection" part of the request
routing interface. Based on feedback received from the CDNI working
group (mostly at the IETF-82 meeting), this document solely focuses
on the "Footprint and Capabilities Advertisement" part of the request
routing interface. In particular, the scope of the current version
of this document is to show how ALTO [RFC5693] can be used for
selecting a downstream CDN. Thus, the scope of the current document
is to provide examples and discuss how a downstream CDN can advertise
its footprint and other information by means of ALTO.
Application Layer Traffic Optimization (ALTO) is an approach for
guiding the resource provider selection process in distributed
applications that can choose among several candidate resources
providers to retrieve a given resource. By conveying network layer
(topology) information, an ALTO server can provide important
Seedorf Expires April 22, 2013 [Page 4]
Internet-Draft CDNI Request Routing with ALTO October 2012
information to "guide" the resource provider selection process in
distributed applications. Usually, it is assumed that an ALTO server
conveys information these applications cannot measure themselves
[RFC5693].
Originally, ALTO was motivated by the huge amount of cross-ISP
traffic generated by P2P applications [RFC5693]. Recently, however,
ALTO is also being considered for improving the request routing in
CDNs [I-D.jenkins-alto-cdn-use-cases]. In this context, it has also
been proposed to use ALTO for selecting an entry-point in a
downstream NSP's network (see section 3.4 "CDN delivering Over-The-
Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]). Also,
the CDNI problem statement explicitly mentions ALTO as a candidate
protocol for "algorithms for selection of CDN or Surrogate by
Request-Routing systems" [I-D.ietf-cdni-problem-statement]. Yet,
there have not been concrete proposals so far on how to use ALTO in
the context of CDN interconnection. This document tries to close
this gap by giving some examples on how ALTO could be used within
CDNI request routing.
Seedorf Expires April 22, 2013 [Page 5]
Internet-Draft CDNI Request Routing with ALTO October 2012
3. Assumptions and High-Level Design Considerations
In this section we list some assumptions and design issues to be
considered when using ALTO for CDNI "footprint and capabilities
advertisement":
o As explicitly being out-of-scope for CDNI
[I-D.ietf-cdni-problem-statement], the examples used in this
document assume that ingestion of content or acquiring content
across CDNs is not part of request routing as considered within
CDNI standardization work. The focus of using ALTO (as considered
in this document) is hence on request routing only, assuming that
the content (desired by the end user) is available in the
downstream CDN (or can be aquired by the downstream CDN by some
means).
o Federation Model: "footprint and capabilities advertisement" and
in general CDN request routing depends on the federation model
among the CDN providers. Designing a suitable solution thus
depends on whether a solution is needed for different settings,
where CDNs consist of both NSP CDNs (serving individual ASes) and
general, traditional CDNs (such as Akamai). We assume that CDNI
is not designed for a setting where only NSP CDNs each serve a
single AS only.
o Many CDNs can claim that they can serve any host on the Internet
due to Internet connectivity. For example, even if an NSP CDN A
does not have surrogate servers inside network C, A can
legitimately claim that it can serve customers inside network C.
Hence, what a downstream CDN should inform an upstream CDN is
performance and capability, and not (only) reachability or
coverage. Although one may turn performance into (binary)
reachability by defining a threshold, the metric can be content-
dependent (image, video, files) or artificial. The requirement of
conveying performance and capability is consistent with the
context: after all, the foundation of the CDN business is to
improve user QoE.
o In this document, we assume that the upstream CDN (uCDN) makes the
decision on selecting a downstream CDN, based on information that
each downstream CDN has made available to the upstream CDN.
Further, we assume that in principle more than one dCDN may be
suitable for a given end-user request (i.e. different dCDNs may
claim "overlapping" footprints). The uCDN hence potentially has
to select among several candidate downstream CDNs for a given end
user request.
Seedorf Expires April 22, 2013 [Page 6]
Internet-Draft CDNI Request Routing with ALTO October 2012
o The term "footprint" has not been precisely defined by the CDNI
working group yet [I-D.spp-cdni-rr-foot-cap-semantics]. In this
document we assume that some notion of IP prefix-range is suitable
to define a footprint of a downstream CDN. Thus, a dCDN footprint
may be expressed as an IP-prefix range that a given dCDN claims it
can cover. However, in principle any host can reach any other
host on the Internet. Thus, simple "coverage" of IP-prefix ranges
seems insufficient for a uCDN to make a choice of a dCDN (see
[I-D.spp-cdni-rr-foot-cap-semantics] for a discussion of this
issue). The uCDN needs additional information that is "tagged
along" (either implicitly or explicitly) with such a coverage
footprint. Such additonal information has the prupose of
conveying to the uCDN more information about a footprint, so that
the uCDN can judge/assess the delivery quality that is associated
with a given dCDN footprint (or part of that footprint, in the
likely case that the delivery quality is not the same for a whole
dCDN footprint).
o It is not clear what kind(s) of business, contract, and
operational relationships two peering CDNs may form. For the
Internet, we see provider-customer and peering as two main
relations; providers may use different charging models (e.g., 95-
percentile, total volume) and may provide different SLAs. Given
such unknown characteristics of CDN peering business agreements,
we should design the protocol to support as much diverse potential
business and operational models as possible.
Seedorf Expires April 22, 2013 [Page 7]
Internet-Draft CDNI Request Routing with ALTO October 2012
4. Selection of a Downstream CDN with ALTO
Under the considerations stated in Section 3, ALTO can help the
upstream CDN provider to select a proper downstream CDN provider for
a given end user request as follows: Each downstream CDN provider
hosts an ALTO server which provides ALTO information (i.e. ALTO
network maps and ALTO cost maps [I-D.ietf-alto-protocol]) to an ALTO
client at the upstream CDN provider. A network map provided by each
of several candidate downstream CDNs can provide information to the
upstream CDN provider about each dCDN's "coverage" footprint, e.g.
regarding geopgraphical coverage, the (exact or rough) location of
"surrogates", the IP-prefix ranges the dCDN claims it can "cover"
with "good" delivery quality, or similar. Additional ALTO network
maps or cost maps can provide an upstream CDN provider additional
information about the footprint each individual dCDN offers, e.g. the
"cost" or quality associated with delivering certain content via the
downstream CDN which provided such a map. "Cost" in this context is
a generic term; many types of costs are possible and can be useful in
the context of CDNI request routing (see Section 4.3 for a detailed
discussion), e.g. average link load, expected delay, or monetary
costs.
4.1. Footprint Advertisement with ALTO Network Map
An ALTO network map contains a "set of Network Location groupings"
[I-D.ietf-alto-protocol]. The groupings are defined in the form of
so-called "PIDs". A PID is an identifier to group network location
endpoints, e.g. IP-addresses in the form of prefixes (see section 4
in [I-D.ietf-alto-protocol] for details).
The concept of an ALTO network map (and the PIDs contained therein)
is a natural and straightforward candidate for CDNI fooprint
advertisement: The downstream CDN provider groups the IP-addresses in
its footprint into PIDs and makes these groupings available to an
upstream CDN via an ALTO network map. With such a network map, the
upstream CDN provider can easily match a given end user request with
the footprint of the downstream CDN provider to see if a given
downstream CDN can in principle provide "coverage" for the IP-address
of the end user. Whenever the footprint changes, the downstream CDN
creates an updated network map and makes it available via its ALTO
server.
4.2. Resource Capabilities Advertisement with ALTO Network Maps
Out of many potentially useful capabilities, it seems mandatory to
support resource capabilities (see further the discussion in
[I-D.spp-cdni-rr-foot-cap-semantics]). For instance, the delivery
protocols supported by a downstream CDN are important to know for an
Seedorf Expires April 22, 2013 [Page 8]
Internet-Draft CDNI Request Routing with ALTO October 2012
upstreamn CDN to make a selection decision. Further, certain
resource capabilities may only be supported in a partial footprint of
a given downstream CDN (e.g. a certain delivery protocol may only be
available at a subset of a given overall dCDN footprint). ALTO
network maps can convey such resource capabilities via PID names.
For instance, an additional network map provided by a dCDN can group
the dCDN's coverage footprint into several PIDs, where each PID name
has a certain "resource capability" semantic.
4.3. Using ALTO maps to convey Additional Information for Downstream
CDN Selection
Additonal information (so that the uCDN can judge/assess the delivery
quality that is associated with a given dCDN footprint it received in
a network map from the dCDN) can be conveyed to a uCDN with
additional ALTO network maps or ALTO cost maps that the dCDN will
provide via its ALTO server. An ALTO cost map contains costs between
defined groupings of a corresponding network map (i.e. costs between
PIDs): "An ALTO Cost Map defines Path Costs pairwise amongst sets of
source and destination Network Locations" [I-D.ietf-alto-protocol].
This concept enables the provider of a cost map to express (and
quantify) preferences of a destination network location with respect
to a given source network location.
In the context of CDNI, the ALTO cost map concept is an extensive
tool to facilitate selection of the "best" downstream CDN because it
enables the upstream CDN provider to assess a candidate downstream
CDN based on other factors besides simply network coverage (coverage
footprint). Most importantly, the cost map concept provides a means
for a downstream CDN provider to convey a multitude of dynamically
changing information which the upstream CDN provider cannot measure
itself (or only roughly estimate) otherwise.
For instance, the following types of "delivery cost" can be conveyed
by a downstream CDN provider via ALTO for each combination of source
PID and destination PID:
o Latency: the expected/average RTT
o Bandwidth: the maximum bandwidth (e.g. due too bottlenecks)
o Monetary Costs: The amount of actual monetary costs the downstream
CDN provider would charge for the delivery of content to a given
destination (see also [I-D.liu-cdni-cost])
Normally, an ALTO cost map defines "costs" pairwise among two PIDs
[I-D.ietf-alto-protocol]. In the current scope of the CDNI working
group, however, the destination of a request routing redirection will
Seedorf Expires April 22, 2013 [Page 9]
Internet-Draft CDNI Request Routing with ALTO October 2012
always be the request router of the selected downstream CDN (as
direct redirection to dCDN surrogates is currently out of scope of
the CDNI work). The destination PID in an ALTO cost map offered by a
dCDN is thus always (i.e. in all entries) the same. Moreover, this
destination PID semantically refers to the whole dCDN (or to its
request router, as the decision where to route within the dCDN is
outside the scope of the CDNI request routing interface). Therefore,
a corresponding ALTO network map for footprint coverage offered by a
dCDN should always contain a special PID that covers the whole
footprint of the dCDN, i.e. the overall, whole prefix range the dCDN
claims it can cover (obviously, it can additonally contain smaller
prefix ranges in other PIDs, so that a cost map can have pairwise
costs entries of these smaller-scale source PIDs to the overall dCDN
coverage PID).
Note that such ALTO cost maps are always of the type N-to-1, i.e.
"costs" are expressed for each of N end user source PIDs to 1 single
dCDN request router PID. Semantically, the source PID in a CDNI ALTO
cost map is thus the end user location, whereas the destination is
the request router to which the uCDN redirects the end user request.
Note that this perspective is driven by the CDNI request routing. An
alternative way - seen from the perspective of content retrieval -
would be to have a 1-to-N cost map where the source is always the
dCDN and the destination is the end user (with the semantic "if the
source dCDN would deliver content to an end user in the destination
PID, the costs would be the following).
Alternatively to using cost maps for expressing delivery quality for
a given coverage footprint, ALTO networks map could be used. In this
case, an additional network map provided by the dCDN groups the
dCDN's coverage footprint into several PIDs, where each PID name has
a certain "quality" semantic. In other words, all IP-prefixes in a
certain PID have the same "quality", and the meaning of this quality
is expressed by the PID name.
4.4. Example of Selecting a Downstream CDN based on ALTO Maps
In the following, we will outline an example of dCDN selection by a
uCDN based on ALTO maps provided by each dCDN. In the example, an
ALTO network map "NM_cov" is used to express the overall "coverage"
footprint of each dCDN. In addition (as outlined in Section 4.3),
each dCDN provides one or more ALTO cost maps "CM_1", "CM_2", ...,
"CM_n" to express the delivery "costs"/quality associated with each
PID in the corresponding "NM_cov" coverage footprint network map.
Consider the following example: An upstream CDN (uCDN) has agreed on
CDN interconnection with several downstream CDNs (dCDN-a, dCDN-b, and
dCDN-c). Each of these downstream CDNs runs an ALTO server to
Seedorf Expires April 22, 2013 [Page 10]
Internet-Draft CDNI Request Routing with ALTO October 2012
provide information about what locations it can deliver content to
(coverage footprint) by means of a network map "NM_cov" and at which
"cost" (additional delivery quality information) by means of one or
more cost maps "CM_1", "CM_2", ..., "CM_n". uCDN has downloaded from
each candidate downstream CDN "NM_cov" and one or more ALTO cost maps
(e.g. by using the "Filtered Cost Map" option and different "cost-
types" as specified in 7.7.3.2. of [I-D.ietf-alto-protocol]). The
ALTO network map provides "coverage" (footprint) for each downstream
CDN as aggregated network locations in the form of ALTO PIDs. The
cost maps provide the upstream CDN information regarding the delivery
quality the selection of each individual downstream CDN would imply
depending on the given location of an end user request.
Whenever the upstream CDN receives a request from an end user and has
determined that this request is best served by an interconnected
dCDN, the uCDN uses ALTO maps to make a redirection decision. For a
given request, assume that only the ALTO network maps provided by
dCDN-a and dCDN-c, "NM_cov(dCDN-a)" and "NM_cov(dCDN-c)", indicate
that these downstream CDNs can deliver content to the location of the
request. In this case, the ALTO costs maps received from dCDN-a and
dCDN-c provide useful additional information to the upstream CDN in
order to make a selection decision regarding either dCDN-a or dCDN-c.
For instance, if both downstream CDNs have provided two ALTO cost
maps "CM_monetary" and "CM_latency" - one regarding monetary costs
and one regarding expected latency for delivery - uCDN can make a
downstream CDN selection based on its preferences: If one downstream
CDN can deliver cheaper, but the other faster, ALTO cost maps provide
such information in detail to the upstream CDN. This enables the
upstream CDN to make a well-considered downstream CDN selection. In
particular, the uCDN decision may take into account different
delivery quality indicators or other factors (which can be weighted
by the upstream CDN to make a decision).
4.5. Advantages of using ALTO
The following reasons make ALTO a suitable candidate protocol for
downstream CDN selection as part of CDNI request routing:
o CDN request routing is done at the application layer. ALTO is a
protocol specifically designed to improve application layer
traffic (and application layer connections among hosts on the
Internet) by providing additonal information to applications that
these applications could not easily retrieve themselves. For
CDNI, this is exactly the case: a uCDN wants to improve
application layer CDN request routing by using dedicated
information (provided by a dCDN) that the uCDN could not easily
obtain otherwise.
Seedorf Expires April 22, 2013 [Page 11]
Internet-Draft CDNI Request Routing with ALTO October 2012
o The semantics of an ALTO network are an exact match for the needed
information to convey a footprint by a downstream CDN, in
particular if such a footprint is being expressed by IP-prefix
ranges.
o ALTO cost maps are suitable to express various types of delivery
"cost" and can hence be used by an upstream to judge the delivery
quality associated with a given dCDN for a given end user request.
Further, an ALTO cost map can convey relevant network topology
information other than simply routing hops or reachability. This
facilitiates advanced and more sophisticated selection of a
downstream CDN based on various metrics by the upstream CDN and
increases flexibility to cover different use cases and business
models for CDN interconnection.
o Flexible granularity: The concept of the PID and ALTO network/cost
maps allows for different degrees of granularity. This enables a
dCDN to differentiate the delivery quality for serving an end user
request on a fine granularity depending on the end user location
(and not only express delivery quality e.g. on an AS-level). It
remains at the discretion of each dCDN how fine-granular the ALTO
network and cost maps are that it publishes.
o ALTO maps can be signed and hence provide inherent integrity
protection (see Section 6)
Seedorf Expires April 22, 2013 [Page 12]
Internet-Draft CDNI Request Routing with ALTO October 2012
5. Useful ALTO extensions for CDNI Request Routing
It is envisioned that yet-to-be-defined ALTO extensions will be
standardized that make the ALTO protocol more suitable and useful for
applications other than the originally considered P2P use case
[I-D.marocco-alto-next]. Some of these extensions to the ALTO
protocol would be useful for ALTO to be used as a protocol within
CDNI request routing, and in particular within the "Footprint and
Capabilities Advertisment" part of the CDNI request routing
interface.
The following proposed extensions to ALTO would be beneficial to
facilitate CDNI request routing with ALTO as outlined in Section 4:
o Server-initiated Notifications and Incremental Updates: In case
the footprint or the capabilities of a downstream CDN change
abruptly (i.e. unexpectedly from the perspective of an upstream
CDN), server initiated notifications would enable a dCDN to
directly inform an upstream CDN about such changes. Consider the
case where - due to failure - part of the footprint of the dCDN is
not functioning, i.e. the CDN cannot serve content to such clients
with reasonable QoS. Without server-initiated notifications, the
uCDN might still use a very recent network and cost map from dCDN,
and therefore redirect request to dCDN which it cannot serve.
Similarly, the possibility for incremental updates would enable
efficient conveyance of the aforementioned (or similar) status
changes by the dCDN to the uCDN. A proposal for server-initiated
ALTO updates can be found in [I-D.marocco-alto-ws]. A discussion
of incremental ALTO updates can be found in
[I-D.schwan-alto-incr-updates].
o Content Availability on Hosts: A dCDN might want to express CDN
capabilties in terms of certain content types (e.g. codecs/
formats, or content from certain content providers). A new
endpoint property for ALTO that would be able to express such
"content availability" would enable a dCDN to make available such
information to an upstream CDN. This would enable a uCDN to
determine if a given dCDN actually has the capabilities for a
given request with respect to the type of content requested.
o Resource Availability on Hosts or Links: The capabilities on links
(e.g. maximum bandwidth) or caches (e.g. average load) might be
useful information for an upstream CDN for optimized dowmstream
CDN selection. For instance, if a uCDN receives a streaming
request for content with a certain bitrate, it needs to know if it
is likely that a dCDN can fulfill such stringent application-level
requirements (i.e. can be expected to have enough consistent
bandwidth) before it redirects the request. In general, if ALTO
Seedorf Expires April 22, 2013 [Page 13]
Internet-Draft CDNI Request Routing with ALTO October 2012
could convey such information via new endpoint properties, it
would enable more sophisticated means for downstream CDN selection
with ALTO.
Seedorf Expires April 22, 2013 [Page 14]
Internet-Draft CDNI Request Routing with ALTO October 2012
6. Security Considerations
One important security consideration is the proper authentication of
advertisement information provided by a downstream CDN. The ALTO
protocol provides a specification for a signature of ALTO maps (see
8.2.2. of [I-D.ietf-alto-protocol]. ALTO thus provides a proper
means for protecting the integrity of footprint advertisment
information.
More Security Considerations will be discussed in a future version of
this document.
Seedorf Expires April 22, 2013 [Page 15]
Internet-Draft CDNI Request Routing with ALTO October 2012
7. Summary and Outlook
This document presented conrete examples of how ALTO can be used
within the downstream CDN selection of CDNI Request Routing.
Further, the document provides arguments why ALTO is a meaningful
protocol in this context. Essentially, ALTO network and cost maps
are a means to provide detailed and various types of information to
an upstream CDN, in order to facilitate well-considered downstream
CDN selection.
The intention of this document is to find consensus in the CDNI WG
that ALTO is a useful protocol for CDNI request routing, and that
ALTO has many benefits for proper selection of a downstream CDN. The
overall objective is to form agreement on how ALTO should be used
within the CDNI request routing protocol. It is the intention to
capture the outcome of such continuing discussions in future versions
of this document.
Seedorf Expires April 22, 2013 [Page 16]
Internet-Draft CDNI Request Routing with ALTO October 2012
8. Acknowledgements
Jan Seedorf is partially supported by the CHANGE project (CHANGE:
Enabling Innovation in the Internet Architecture through Flexible
Flow-Processing Extensions, http://www.change-project.eu/), a
research project supported by the European Commission under its 7th
Framework Program (contract no. 257422). The views and conclusions
contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the CHANGE project or
the European Commission.
Jan Seedorf has been partially supported by the COAST project
(COntent Aware Searching, retrieval and sTreaming,
http://www.coast-fp7.eu), a research project supported by the
European Commission under its 7th Framework Program (contract no.
248036). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the COAST project or the European Commission.
Thanks to Richard Yang for providing valuable comments, and for
contributiong some design considerations and assumptions.
Seedorf Expires April 22, 2013 [Page 17]
Internet-Draft CDNI Request Routing with ALTO October 2012
9. Informative References
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
[I-D.peterson-CDNI-strawman]
Peterson, L. and J. Hartman, "Content Distribution Network
Interconnection (CDNI) Problem Statement",
draft-peterson-CDNI-strawman-01 (work in progress),
May 2011.
[I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", draft-ietf-cdni-problem-statement-08 (work in
progress), June 2012.
[I-D.marocco-alto-next]
Marocco, E. and V. Gurbani, "Extending the Application-
Layer Traffic Optimization (ALTO) Protocol",
draft-marocco-alto-next-00 (work in progress),
January 2012.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-13 (work in progress),
September 2012.
[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements",
draft-ietf-cdni-requirements-03 (work in progress),
June 2012.
[I-D.ietf-cdni-use-cases]
Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", draft-ietf-cdni-use-cases-10 (work in
progress), August 2012.
[I-D.marocco-alto-ws]
Marocco, E. and J. Seedorf, "WebSocket-based server-to-
client notifications for the Application-Layer Traffic
Optimization (ALTO) Protocol", draft-marocco-alto-ws-01
(work in progress), July 2012.
[I-D.schwan-alto-incr-updates]
Seedorf Expires April 22, 2013 [Page 18]
Internet-Draft CDNI Request Routing with ALTO October 2012
Schwan, N. and B. Roome, "ALTO Incremental Updates",
draft-schwan-alto-incr-updates-02 (work in progress),
July 2012.
[I-D.jenkins-alto-cdn-use-cases]
Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
S. Previdi, "Use Cases for ALTO within CDNs",
draft-jenkins-alto-cdn-use-cases-03 (work in progress),
June 2012.
[I-D.seedorf-alto-for-cdni]
Seedorf, J., "ALTO for CDNi Request Routing",
draft-seedorf-alto-for-cdni-00 (work in progress),
October 2011.
[I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-01 (work in
progress), July 2012.
[I-D.liu-cdni-cost]
Liu, H., "A Cost Perspective on Using Multiple CDNs",
draft-liu-cdni-cost-00 (work in progress), October 2011.
[]
Seedorf, J., Peterson, J., and S. Previdi, "CDNI Request
Routing: Footprint and Capabilities Semantics",
draft-spp-cdni-rr-foot-cap-semantics-01 (work in
progress), July 2012.
Seedorf Expires April 22, 2013 [Page 19]
Internet-Draft CDNI Request Routing with ALTO October 2012
Author's Address
Jan Seedorf
NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 4342 221
Email: jan.seedorf@neclab.eu
URI: http://www.neclab.eu
Seedorf Expires April 22, 2013 [Page 20]
