CDNI J. Seedorf
Internet-Draft NEC
Intended status: Informational J. Peterson
Expires: September 6, 2012 Neustar
S. Previdi
Cisco
March 5, 2012
CDNI Request Routing: Footprint and Capabilities Semantics
draft-spp-cdni-rr-foot-cap-semantics-00
Abstract
This document tries to capture the semantics of the "Footprint and
Capabilities Advertisment" part of the CDNI Request Routing
interface, i.e. the desired meaning and what "Footprint and
Capabilities Advertisment" is expected to offer within CDNI. The
discussion in this document has the goal to facilitate the choosing
of one or more suitable protocols for "Footprint and Capabilities
Advertisment" within CDNI Request Routing.
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 September 6, 2012.
Copyright Notice
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
Seedorf, et al. Expires September 6, 2012 [Page 1]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
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. Apparent Understanding of CDNI Footprint and Capabilities
Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Description of footpring and capabilities
advertisement in existing CDNI documents . . . . . . . . . 4
2.2. Summary of understanding of footprint and capabilities
advertisement in existing CDNI documents . . . . . . . . . 5
3. Design Decisions for Footprint and Capabilities . . . . . . . 6
3.1. Advertising Limited Coverage . . . . . . . . . . . . . . . 6
3.2. Capabilities and Dynamic Datae . . . . . . . . . . . . . . 7
3.3. Advertisement versus Queries . . . . . . . . . . . . . . . 8
4. Semantics for Footprint Advertisement . . . . . . . . . . . . 9
5. Semantics for Capabilities Advertisement . . . . . . . . . . . 10
6. Open Issues and Questions . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Seedorf, et al. Expires September 6, 2012 [Page 2]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
1. Introduction
The CDNI working group is working on a set of protocols to enable the
interconnection of multiple CDNs to a CDN federation. This CDN-
federation should serve multiple purposes, as discussed in
[I-D.ietf-cdni-use-cases], for instance, to extend the reach of a
given CDN to areas in the network which are not covered by this
particular CDN.
The goal of this document is to achieve a clear understanding in the
CDNI WG about the semantics associated with the CDNI request routing
interface, in particular regarding the "footprint and capabilities
advertisement" of a downstream CDN. To narrow down undecided aspects
of these semantics, this document first tries to capture the common
understanding of what the "footprint and capabilities advertisement"
should offer and accomplish, i.e. what seems to be agreed. Then, the
document will discuss open questions. It is the goal of this
document to capture the outcome of dicussions and answers to open
questions in future versions of this draft.
General assumptions in this document:
o The CDNs participating in the CDN federation have already
performed a boot strap process, i.e., they have connected to each
other, either directly or indirectly, and can exchange information
amongst each other.
o The uCDN has received footprint and/or capability advertisements
from a set of dCDNs. Footprint advertisement and capability
advertisement need not use the same underlying protocol.
o The upstream CDN (uCDN) receives the initial request-routing
request from the endpoint requesting the resource.
This document is organized as follows. We first recap the
descriptions regarding "footprint and capabilities advertisement" in
existing documents and try to distill the apparent common
understanding of the terms "footprint" and "capabilties" in the CDNI
request routing context. We then separately discuss the semantics of
the footprint advertisement mechanism, and the capability
advertisement mechanism. Finally, we list open issues and questions
to be discussed in the CDNI WG.
Comments and discussions about this memo should be directed to the
CDNI WG: cdni@ietf.org.
Seedorf, et al. Expires September 6, 2012 [Page 3]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
2. Apparent Understanding of CDNI Footprint and Capabilities
Advertisement
In the following, we will summarize the descriptions of the CDNI
"footprint and capabilities advertisement" as part of the "request
routing" interface in existing documents. We will then carve out the
apparent common understanding of what this interface is intended to
offer and accomplish.
2.1. Description of footpring and capabilities advertisement in
existing CDNI documents
The CDNI problem statement draft [I-D.ietf-cdni-problem-statement]
describes footprint and capabilities advertisement as: "enabling an
upstream CDN to determine if a downstream CDN is able (and willing)
to accept the delegated content request". In addition, the draft
says "the CDNI Request Routing interface is also expected to enable a
downstream CDN to provide to the upstream CDN (static or dynamic)
information (e.g. resources, footprint, load) to facilitate selection
of the downstream CDN by the upstream CDN request routing system when
processing subsequent content requests from User Agents". It thus
considers "resources" and "load" as capabilities to be advertised by
the downstream CDN.
The CDNI use cases draft [I-D.ietf-cdni-use-cases] describes
capabilities as "... supported range of devices and User Agents or
the supported range of delivery technologies". Examples for such
capabilities given are specific delivery protocols, technology
migration, and meeting a certain QoS.
The CDNI requirements draft [I-D.ietf-cdni-requirements] lists
several requirements relevant for the "footprint and capabilities
advertisement" part of the CDNI request routing interface. In
summary, the following requirements are relevant for the
understanding of the semantics of the "footprint and capabilities
advertisement":
o REQ-1, allowing the downstream CDN to communicate "excessive load
or failure condition".
o REQ-2, allowing the downstream CDN to communicate capabilities
such as supported content types and delivery protocols, a set of
metrics/attributes (e.g. Streaming bandwidth, storage resources,
distribution and delivery priority), a set of affinities (e.g.
Preferences, indication of distribution/delivery fees),
information to facilitate request redirection, as well as
footprint information (e.g. "layer-3 coverage").
Seedorf, et al. Expires September 6, 2012 [Page 4]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
o REQ-4, allowing the downstream CDN to communicate "aggregate
information on CDNI administrative limits and policy" (e.g. the
maximum number of requests redirected by the Upstream CDN to be
served simultaneously by the Downstream CDN or maximum aggregate
volume of content (e.g. in Terabytes) to be delivered by the
Downstream CDN over a time period).
"Layer-3 coverage" is hence given as an example of what "footprint"
information might convey in the CDNI requirements draft
[I-D.ietf-cdni-requirements].
The CDNI framework draft [I-D.davie-cdni-framework] describes a
"footprint" as in [I-D.previdi-cdni-footprint-advertisement],
consisting of two parts: 1) "a class of end user requests
(represented, for example, by a set of IP prefixes, or a geographic
region) that the dCDN is willing and able to serve directly, without
use of another dCDN", and 2) "the connectivity of the dCDN to other
CDNs that may be able to serve content to users on behalf of dCDN".
The term "connectivity" has recently been replaced with
"reachability" in [I-D.previdi-cdni-footprint-advertisement].
Further, examples for capabilities are "the ability to handle certain
types of content (e.g. specific streaming formats) or quality of
service (QoS)."
2.2. Summary of understanding of footprint and capabilities
advertisement in existing CDNI documents
Im summary, neither the term "footprint" nor "capabilties" are
clearly defined. Also, a very broad range of potential capabilities
is listed in the existing documents.
Seedorf, et al. Expires September 6, 2012 [Page 5]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
3. Design Decisions for Footprint and Capabilities
A large part of the difficulty lies in understanding what we mean
when try to define footprint to terms of "coverage" or
"reachability." While the operators of CDNs pick strategic locations
to situate caches, a cache with a public IPv4 address is reachable by
any endpoint on the Internet unless some policy enforcement precludes
the use of the cache.
Some CDNs aspire to cover the entire world, henceforth global CDNs;
which we will henceforth call global CDNs. The footprint advertised
by such a CDN in the CDNi environment would, from a coverage or
reachability perspective, presumably cover all prefixes. More
interesting for CDNi use cases, however, are CDNs that claim a more
limited covergage, but seek to federate with other CDNs in order to
create a single CDN fabric which shares resources fairly.
The key to understanding the semantics of footprint and capability
advertisement lies in understand why a dCDN would advertise a limited
coverage area, and how a uCDN would use such advertisements to decide
among one of several dCDNs.
3.1. Advertising Limited Coverage
The basic use case that would motivate a dCDN to advertise a limited
coverage is that the CDN was built to cover only a particular portion
of the Internet. For example, an ISP could purpose-build a CDN to
serve only their own customers by situating caches in close
topological proximity to high concentrations of their subscribers.
The ISP knows the prefixes it has allocated to end users and thus can
easily construct a list of prefixes that its caches were positioned
to serve.
When such a purpose-built CDN joined a federation, however, and
advertises its footprint to a uCDN, the original intended coverage of
the CDN might not represent its actual value to the federation of
CDNs. Consider an ISP-A and ISP-B that both field their own CDNs,
which they federate through CDNi. A given user E, who is customer of
ISP-B, might happen to be topologically closest to a cache fielded by
ISP-A, if E happens to live in a region where ISP-B has few customers
and ISP-A has many. In this case, should ISP-A's CDN "cover" E? If
ISP-B's CDN has a failure condition, should the uCDN understand that
ISP-A's caches are potentially available back-ups - and if so, how
does ISP-A advertise itself as a "standby" for E? What about the
case where CDNs advertising to the same uCDN express overlapping
coverage (for example, a federation mixing global and limited CDNs)?
The answers to these questions greatly depend on how much information
Seedorf, et al. Expires September 6, 2012 [Page 6]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
we want the uCDN to use to make a selection of a dCDN. If a uCDN has
three dCDNs to choose from that "cover" the IP address of user E,
obviously the uCDN might be interested to know how optimal the
coverage is from each of the dCDNs - coverage need not be binary,
either provided or not provided. dCDNs could advertise a coverage
"score," for example, and provided that they all reported scores
fairly on the same scale, uCDNs could use that to make their
topological optimality decision. Alternatively, dCDNs could for
their footprint advertise the IP addresses of their caches rather
than prefix "coverage," and let the uCDN decide for itself (based on
its own topological intelligence) which dCDN has better resources to
serve a given user.
3.2. Capabilities and Dynamic Datae
In cases where the apparent footprint of dCDNs overlaps, uCDNs might
also want to rely on a host of other factors to evaluate the
respective merits of dCDNs. These include facts related to the
caches themselves, to the network where the cache is deployed, to the
nature of the resource sought and to the administrative policies of
the respective networks.
In the absence of network-layer impediments to reaching caches, the
choice to limit coverage is necessarily an administrative policy.
Much policy must be agreed upon before CDNs can merge into
federations, including questions of membership, compensation, volumes
and so on. A uCDN certainly will factor these sorts of
considerations into its decision to select a dCDN, but there is
probably little need for dCDNs to actually advertise them through an
interface - they will be settled out of band as a precondition for
federating.
Other facts about the dCDN would be expressed through the interface
to the uCDN. Some capabilities of a dCDN are static, and some are
highly dynamic. Expressing the total storage built into its caches,
for example, changes relatively rarely, whereas the amount storage in
use at any given moment is highly volatile. Network bandwidth
similarly could be expressed as either total bandwidth available to a
cache, or based on the current state of the network. A cache may at
one moment lack a particular resource in storage, but have it the
next.
The semantics of the capabilities interface will depend on how much
of the dCDN state needs to be pushed to the uCDN in order for it to
make a decision.
Seedorf, et al. Expires September 6, 2012 [Page 7]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
3.3. Advertisement versus Queries
In a federated CDN environment, each dCDN shares some of its state
with the uCDN, which the uCDN uses to built a unified picture of all
of the dCDNs available to it. In architectures that share detailed
capability information, the uCDN could basically perform the entire
request-routing intelligence down to selecting a particular cache
before sending the request to the dCDN. However, when the uCDN must
deal with many potential dCDNs, this approach does not scale.
Especially as CDNs scale up from dozens or hundred of caches to
thousands or tens of thousands, the volume of updates to footprint
and capability may become onerous.
Were the volume of updates to exceed the volumes of requests to the
uCDN, it might make more sense for the uCDN to query dCDNs upon
receiving requests, instead of receiving advertisements and tracking
the state of dCDNs itself. The advantage of querying dCDNs would be
that much of the dynamic data that dCDNs cannot share with the uCDN
would now be factored into the uCDN's decision. dCDNs need not
replicate any state to the uCDN - uCDNs could effectively operate in
a stateless mode.
The semantics of both footprint and capability advertisement depend
on the service model here: are there cases where a synchronous query/
response model would work better for the uCDN decision than a state
replication model?
Seedorf, et al. Expires September 6, 2012 [Page 8]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
4. Semantics for Footprint Advertisement
Based on the characterizations in existing documents (see Section 2),
we can distill the following "rough" candidates for definitions of a
footprint:
o Footprint could be defined by "layer-3 coverage", where coverage
refers to a set of prefixes, a geographic region, or similar
boundary.
o Footprint could be defined as the set of the IP addresses of the
caches deployed by a CDN.
o Potentially, a footprint may include "the connectivity of the dCDN
to other CDNs that may be able to serve content to users on behalf
of dCDN".
o Footprint could altenatively be defined as "a class of end user
requests a dCDN is willing to serve".
The downstream CDN must be able to express its footprint to an
interested upstream CDN (uCDN) in a comprehensive form, e.g., as a
complete data set containing the complete footprint. Making
incremental updates, however, to express dynamic changes in state is
also desirable.
The footprint information must be able to contain full IP addresses
(i.e., a /32 for IPv4 and a /128 for IPv6) and also IP prefixes with
an arbitrary prefix length. There must be support for multiple IP
address version, i.e., IPv4 and IPv6 in the footprint.
Seedorf, et al. Expires September 6, 2012 [Page 9]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
5. Semantics for Capabilities Advertisement
The dCDN must be able to express its general capabilities to the
uCDN. These general capabilites could express if the dCDN supports a
given service, for instance, WWW delivery, Video on Demand (VoD)
delivery based on flash or apple technologies, or live streaming
based on RTSP.
The dCDN must be able to express particular capabilities for the
delivery in a particular footprint area. For example, the dCDN might
in general offer VoD but not in some areas, either for maintenance
reasons or because this particular area cannot deliver this type of
service.
High-level and very rough semantics for (and characteristics of)
capabilities are thus:
o Capabilities are types of information that allow a uCDN to
determine if if a downstream CDN is able (and willing) to accept
the delegated content request.
o Some capabilities may change dynamically based on the state of the
network or a cache.
Capabilities seem to fall into several broad categories. Some are
capabilities associated with a resource iteslf, like the codecs or
streaming technologies in which a particular resource is available.
Some capabilities are associated with the cache: these include the
load state, available storage resources, and so on. Some
capabilities are associated with the network where the cache is
deployed, including available bandwidth for streaming, availability
of QoS mechanisms, and so on.
Some capabilities reflect administrative restrictions or policies
that may affect the decisions made up a uCDN. It seems unlikely
these factors will be shared through the interface, however.
Cache Capabilites are:
o load, or "excessive load"
o available resources, storage resources
o failure conditions
Resource Capabilities:
Seedorf, et al. Expires September 6, 2012 [Page 10]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
o supported range of playback devices
o supported range of delivery technologies
o specific delivery protocols
o supported content types (MIME)
Network Capabilities:
o meeting a certain QoS
o distribution and delivery priority
o streaming bandwidth
Outside the scope of capability advertisements are administrative
capabilities, such as:
o policy (membership in the federation, etc)
o administrative limits, e.g. maximum aggregate volume of content
delivered monthly
o indication of distribution/delivery fees
Seedorf, et al. Expires September 6, 2012 [Page 11]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
6. Open Issues and Questions
The following open issues deserve discussion in the CDNI WG:
o What is the service model of this interface: Does the uCDN always
query the dCDNs? Or does the dCDN always push information to the
uCDNs?
o Should footprint advertisement be based on prefixes, on cache
addresses, or on other facts?
o Should capability advertisement include only static attributes of
the CDN, or should it factor in dynamic attributes as well?
o How can the dCDN express the associated costs of delivery, either
monetary or virtual costs, to the uCDN for the actual delivery?
Is this in scope of this interface?
o Are monetary delivery costs explictly in scope of capabilities
advertisement?
o Does a footprint need to include the "reachability" of the dCDN to
other CDNs that may be able to serve content to users on behalf of
dCDN?
o What is the assumed business relationship between the uCDN and the
dCDN? Is the uCDN always the "authoritative" CDN provider which
transitively has itself contracted several downstream CDN
providers?
Seedorf, et al. Expires September 6, 2012 [Page 12]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
7. Security Considerations
Security considerations will be discussed in a future version of this
document.
Seedorf, et al. Expires September 6, 2012 [Page 13]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
8. Conclusion
This document tried to capture the semantics of the "Footprint and
Capabilities Advertisment" part of the CDNI Request Routing
interface, i.e. the desired meaning and what "Footprint and
Capabilities Advertisment" is expected to offer within CDNI. Several
key design decisions and open questions have been discussed.
The discussion in this document has the onjective to facilitate the
choosing of one or more suitable protocols for "Footprint and
Capabilities Advertisment" within CDNI Request Routing. It is the
goal of this document to capture the outcome of dicussions and
answers to open questions in future versions of this draft.
Seedorf, et al. Expires September 6, 2012 [Page 14]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.davie-cdni-framework]
Davie, B. and L. Peterson, "Framework for CDN
Interconnection", draft-davie-cdni-framework-01 (work in
progress), October 2011.
[I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", draft-ietf-cdni-problem-statement-03 (work in
progress), January 2012.
[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements",
draft-ietf-cdni-requirements-02 (work in progress),
December 2011.
[I-D.ietf-cdni-use-cases]
Gilles, B., Watson, G., Ma, K., Eardley, P., Emile, S.,
and T. Burbridge, "Use Cases for Content Delivery Network
Interconnection", draft-ietf-cdni-use-cases-03 (work in
progress), January 2012.
[I-D.peterson-cdni-strawman]
Peterson, L. and J. Hartman, "A Simple Approach to CDN
Interconnection", draft-peterson-cdni-strawman-01 (work in
progress), May 2011.
[]
Previdi, S., Faucheur, F., Faucheur, F., and J. Medved,
"CDNI Footprint Advertisement",
draft-previdi-cdni-footprint-advertisement-00 (work in
progress), October 2011.
[I-D.xiaoyan-cdni-requestrouting]
He, X., Li, J., Dawkins, S., and G. Chen, "Request Routing
for CDN Interconnection",
draft-xiaoyan-cdni-requestrouting-01 (work in progress),
June 2011.
Seedorf, et al. Expires September 6, 2012 [Page 15]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
Appendix A. Acknowledgment
Jan Seedorf is 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.
Martin Stiemerling provided initial input to this document and
valuable comments to the ongoing discussions among the authors of
this document.
Seedorf, et al. Expires September 6, 2012 [Page 16]
Internet-Draft RR Footprint/Capabilities Semantics March 2012
Authors' Addresses
Jan Seedorf
NEC
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 221
Fax: +49 6221 4342 155
Email: seedorf@neclab.eu
Jon Peterson
NeuStar
1800 Sutter St Suite 570
Concord CA 94520
USA
Phone:
Fax:
Email: jon.peterson@neustar.biz
Stefano Previdi
Cisco Systems
Via Del Serafico 200
Rome 0144
Italy
Phone:
Fax:
Email: sprevidi@cisco.com
Seedorf, et al. Expires September 6, 2012 [Page 17]