CDNI J. Seedorf
Internet-Draft NEC
Intended status: Informational J. Peterson
Expires: April 25, 2013 Neustar
S. Previdi
Cisco
October 22, 2012
CDNI Request Routing: Footprint and Capabilities Semantics
draft-spp-cdni-rr-foot-cap-semantics-02
Abstract
This document tries to capture the semantics of the "Footprint and
Capabilities Advertisement" part of the CDNI Request Routing
interface, i.e. the desired meaning and what "Footprint and
Capabilities Advertisement" 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
Advertisement" 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 April 25, 2013.
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 April 25, 2013 [Page 1]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 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 footprint and capabilities
advertisement in existing CDNI documents . . . . . . . . . 4
2.2. Summary of understanding of footprint and capabilities
advertisement in existing CDNI documents . . . . . . . . . 6
3. Design Decisions for Footprint and Capabilities . . . . . . . 7
3.1. Advertising Limited Coverage . . . . . . . . . . . . . . . 7
3.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 8
3.3. Advertisement versus Queries . . . . . . . . . . . . . . . 9
3.4. Avoiding or Handling 'cheating' Downstream CDNs . . . . . 9
3.5. Focus on Main Use Cases may Simplify Things . . . . . . . 10
4. Towards Semantics for Footprint Advertisement . . . . . . . . 11
5. Towards Semantics for Capabilities Advertisement . . . . . . . 13
6. Open Issues and Questions . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Seedorf, et al. Expires April 25, 2013 [Page 2]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 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 discussions and answers to open
questions in future versions of this draft. In particular, this
document summarizes the progress of the recently formed CDNI design
team on "footprint and capabilities advertisement".
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 "capabilities" 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 April 25, 2013 [Page 3]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 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 footprint 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 for the CDNI Request Routing
Interface and general requirements are relevant for the understanding
of the semantics of the "footprint and capabilities advertisement":
o GEN-4 [HIGH], "The CDNI solution shall not require intra-CDN
information to be exposed to other CDNs for effective and
efficient delivery of the content. Examples of intra-CDN
information include surrogate topology, surrogate status, cached
content, etc."
o GEN-9 [MED], "The CDNI solution should support cascaded CDN
redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an
arbitrary number of levels beyond the first level."
Seedorf, et al. Expires April 25, 2013 [Page 4]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
o GEN-10 [MED], "The CDNI solution should support an arbitrary
topology of interconnected CDNs (i.e. the CDN topology cannot be
restricted to a tree, a loop-free topology, etc.)."
o GEN-11 [HIGH], "The CDNI solution shall prevent looping of any
CDNI information exchange."
o REQ-1 [HIGH], allowing the downstream CDN "to communicate to the
Upstream CDN coarse information about the Downstream CDN ability
and/or willingness to handle requests from the Upstream CDN. For
example, this could potentially include a binary signal
("Downstream CDN ready/not-ready to take additional requests from
Upstream CDN") to be used in case of excessive load or failure
condition in the Downstream CDN."
o REQ-2 [MED], 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").
o REQ-3 [MED], "In the case of cascaded redirection, the CDNI
Request-Routing interface shall allow the Downstream CDN to also
include in the information communicated to the Upstream CDN,
information on the capabilities, resources and affinities of CDNs
to which the Downstream CDN may (in turn) redirect requests
received by the Upstream CDN. In that case, the CDNI Request-
Routing interface shall prevent looping of such information
exchange."
o REQ-4 [LOW], 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).
o REQ-11 [LOW], "The CDNI Request-Routing protocol may support a
mechanism allowing an Upstream CDN to avoid redirecting a request
to a Downstream CDN if that is likely to result in the total
redirection time exceeding some limit."
Note that in REQ-2 [MED] "Layer-3 coverage" is given as an example of
what "footprint" information might convey in the CDNI requirements
draft [I-D.ietf-cdni-requirements]. Also, note that REQ-3 [MED]
addresses cascaded (transitive) downstream CDNs. In such a case, a
Seedorf, et al. Expires April 25, 2013 [Page 5]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
downstream CDN needs to include (in its advertisement information
that it conveys to an upstream CDN) also information the footprint
and capabilities of any further transitive downstream CDN. Such
information may be included implicitly (i.e. the cascaded dCDN is
oblivious to the uCDN), or explicitly (i.e. the cascaded dCDN of the
fact that there is a cascaded dCDN is visible to the uCDN). In any
case, a logic is needed to process incoming footprint information
from a cascaded dCDN and decide if/how it is to be re-advertised/
aggregated when advertising footprint to an upstream CDN.
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
In summary, neither the term "footprint" nor "capabilities" are
clearly defined. Also, a very broad range of potential capabilities
is listed in the existing documents.
Seedorf, et al. Expires April 25, 2013 [Page 6]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 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 coverage, 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 April 25, 2013 [Page 7]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 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 Data
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 April 25, 2013 [Page 8]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 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 build 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 (note that within the current
CDNI WG scope, such direct selection of specific caches by the uCDN
is out of scope). However, when the uCDN must deal with many
potential dCDNs, this approach does not scale. Especially as CDNs
scale up from dozens or hundreds 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?
3.4. Avoiding or Handling 'cheating' Downstream CDNs
In a situation where more than one dCDN is willing to serve a given
end user request, it might be attractive for a dCDN to "cheat" in the
sense that the dCDN provides inaccurate information to the uDCDN in
order to convince the uCDN to select it opposed to "competing" other
dCDNs. It is therefore desirable to take away the incentive for
dCDNs to cheat (in information advertised) as much as possible. One
option here is to make the information the dCDN advertises somehow
verifiable for the uCDN. One the other hand, a cheating dCDN might
be avoided or handled by the fact that there will be strong
contractual agreements between a uCDN and a dCDN, so that a dCDN
would risk severe penalties or legal consequences when caught
cheating.
Overall, it seems that information a dCDN advertises should (in the
long run) be somehow verifiable by the uCDN. However, it is probably
an overly strict requirement to demand that such verification must be
possible "immediately", i.e. during the request routing process
Seedorf, et al. Expires April 25, 2013 [Page 9]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
itself. If the uCDN can detect a cheating dCDN at a later stage, it
should suffice for the dCDN to "de-incentivize" cheating because it
would negatively affect long-term business relationsships with uCDNs.
3.5. Focus on Main Use Cases may Simplify Things
To narrow down semantics for "footprint" and "capabilities" in the
CDNI context, it can be useful to initially focus on key use cases to
be addressed by the CDNI WG that are to be envisioned the main
deployments in the foreseeable future. In this regard, a main
realistic use case is the existence of ISP-owned CDNs, which
essentially cover a certain operator's network. At the same time,
however, the possibility of overlapping footprints should not be
excluded, i.e. the scenario where more than one dCDN claims it can
serve a given end user request. Further, it seems reasonable to
assume that in most use cases it is the uCDN that makes the decision
on selecting a certain dCDN for request routing based on information
the uCDN has received from this particular dCDN.
Seedorf, et al. Expires April 25, 2013 [Page 10]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
4. Towards Semantics for Footprint Advertisement
Based on the characterizations in existing documents (see Section 2),
we can distill some "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 alternatively be defined as "a class of end user
requests a dCDN is willing to serve".
Independent of the exact definition of footprint, a footprint likely
needs to be able to include the connectivity of a given dCDN to other
CDNs that may be able to serve content to users on behalf of that
dCDN, to cover cases where there is a transitive CDN interconnection.
Further, 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.
Different concrete candidates for a footprint are imaginable (set of
prefixes, a geographic region, ...). Among these, "set of IP-
prefixes" may potentially be a useful footprint in the CDDNI context.
Such 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.
Roughly speaking, footprint can be defined as "willingness to serve"
by a downstream CDN. However, in addition to simply "willingness to
serve", the uCDN needs to have some additional information to make a
dCDN selection decision. The uCDN needs additional information so
that it can assess "how well" a given dCDN can actually serve a given
end user request; otherwise, any dCDN can claim it can deliver
content to the whole world. One can imagine that such additonal
information is implicitly associated with a given footprint, e.g. due
to (from the request routing interface's perspective out-of-band)
contractual agreements (e.g. SLAs), business relationships, or
perceived dCDN quality in the past. As an alternative, such
additional information could also be explicitly be tagged along with
the footprint.
It is reasonable to assume that a significant part of the actual
footprint advertisement will happen in contractual agreements between
participating CDNs, i.e. prior to the advertisement phase of the CDNI
Seedorf, et al. Expires April 25, 2013 [Page 11]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
request routing protocol. The reason for this assumption is that any
contractual agreement is likely to contain specifics about the dCDN
coverage (i.e. the dCDN footprint) the contractual agreement applies
to. In particular, additional information to judge the delivery
quality associated with a given dCDN footprint might be defined in
contractual agreements (i.e. outside of the CDNI RR interface).
Further, one can assume that dCDN contractual agreements about the
delivery quality associated with a given footprint will probably be
based on high-level aggregated statistics (i.e. not too detailed).
Given that a large part of footprint advertisement will actually
happen in contractual agreements, the semantics of CDNI footprint
advertisement refer to answering the following question: what exactly
still needs to be advertised by the CDNI request routing interface?
For instance, updates about temporal failures of part of a footprint
can be useful information to convey via the CDNI request routing
interface. Such information would provide updates on information
previously agreed in contracts between the participating CDNs. In
other words, the CDNI request routing footprint advertisement is a
means for a dCDN to provide changes/updates regarding a footprint it
has prior agreed to serve in a contract with a uCDN.
Seedorf, et al. Expires April 25, 2013 [Page 12]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
5. Towards Semantics for Capabilities Advertisement
The dCDN must be able to express its general capabilities to the
uCDN. These general capabilities 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. Hence, in certain cases footprint and capabilities are tied
together and cannot be interpreted independently from each other. In
such cases, i.e. where capabilities must be expressed on a per
footprint basis, it may be beneficial to combine footprint and
capabilities advertisement.
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 a downstream CDN is able (and willing) to accept the
delegated content request.
o Capabilities are types of information that possibly may change
over time based on the state of the network or caches.
Candidates for capabilities seem to fall into several broad
categories. Some are capabilities associated with a resource itself,
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.
Potential Cache capabilities are:
o aggregate information (i.e. not for individual caches, but still
helpful for dCDN selection) about load, or "excessive load"
o aggregate information (i.e. not for individual caches, but still
helpful for dCDN selection) about available resources, storage
Seedorf, et al. Expires April 25, 2013 [Page 13]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
resources
o aggregate information (i.e. not for individual caches, but still
helpful for dCDN selection) regarding failure conditions
Potential Resource Capabilities are:
o supported range of playback devices
o supported range of delivery technologies
o specific delivery protocols
o supported content types (MIME)
Potential Network Capabilities are:
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
At a first glance, the above list of candidates contains useful
capabilities to convey via an advertisement interface (and indeed the
candidate capabilities listed above have been suggested in CDNI
drafts, see Section 2). However, advertising capabilities that
change highly dynamically (e.g. real-time delivery performance
metrics, CDN resource load, or other highly dynamically changing QoS
information) is probably not a good idea. First, out of the
multitude of possible metrics and capabilities, it is hard to agree
on a subset and the precise metrics to be used. Second, and perhaps
more importantly, it seems not feasible to specify such highly
dynamically changing capabilities and the corresponding metrics
within the CDNI charter time-frame.
Useful capabilities to convey are resource capabilities: Such
information does not change highly dynamically and in many cases such
Seedorf, et al. Expires April 25, 2013 [Page 14]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
information is absolutely necessary to decide on a dCDN for a given
end user request. For instance, if an end user request concerns the
delivery of a movie with a certain protocol (e.g. RTMP), the uCDN
needs to knwo if a given dCDN has the capabiltity of supporting this
delivery protocol.
Similar to footprint advertisement, it is reasonable to assume that a
significant part of the actual (resource) capabilities advertisement
will happen in contractual agreements between participating CDNs,
i.e. prior to the advertisement phase of the CDNI request routing
protocol. The role of capabilities advertisement is hence rather to
enable the dCDN to update a uCDN on changes since a contract has been
set up (e.g. in case a new delivery protocol is suddenly being added
to the list of supported delivery protocols of a given dCDN, or in
case a certain delivery protocol is suddenly not being supported
anymore due to failures).
Under the above considerations, the semantics of capabilities
advertisement are roughly the following:
o The main category of useful capabilities to convey is resource
capabilities.
o Advertisement refers to conveying information to a uCDN about
changes/updates of certain capabilities with respect to a given
contract.
Given these semantics, it needs to be decided what capabilities
exactly are useful and how these can be expressed. Since the details
of CDNI contracts are not known at the time of this writing (i.e. at
this point in time there are only very preliminary trials ongoing and
no real deployments with actual contracts between CDNs yet), it
remains to be seen what capabilities will be used to define
agreements between CDNs in practise. One implication for
standardization may be to initially only specify very fey mandatory
capabilities for advertisement and have on top of that a flexible
protocol that allows to exchange additional capabilities when needed.
Still, agreement needs to be found on what core capabilities are
really needed to convey among CDNs. As discussed in Section 3.5,
finding the concrete answers to these questions can benefit from
focusing on a small number of key use cases that are highly relevant
and contain enough complexity to help in understanding what concrete
capabilities are needed to facilitate CDN Interconnection.
Seedorf, et al. Expires April 25, 2013 [Page 15]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
6. Open Issues and Questions
The following open issues deserve further 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 What exactly is a footprint based on? (e.g. prefix, geographic
area, ASN, or location of surrogates/resources)
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?
o How exactly can a given dCDN derive its footprint?
o To what extent should capability advertisement include or factor
in dynamic attributes?
Seedorf, et al. Expires April 25, 2013 [Page 16]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
7. Security Considerations
Security considerations will be discussed in a future version of this
document.
Seedorf, et al. Expires April 25, 2013 [Page 17]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
8. Conclusion
This document tries to capture the semantics of the "Footprint and
Capabilities Advertisement" part of the CDNI Request Routing
interface, i.e. the desired meaning and what "Footprint and
Capabilities Advertisement" is expected to offer within CDNI, also
reflecting ongoing discussions in the CDNI design team on "Footprint
and Capabilities Advertisement". Several key design decisions and
open questions have been discussed.
The discussion in this document has the objective to facilitate the
choosing of one or more suitable protocols for "Footprint and
Capabilities Advertisement" within CDNI Request Routing. It is the
goal of this document to capture the outcome of further progress of
the CDNI WG and the design team on "Footprint and Capabilities
Advertisement" including answers to currently open questions in
future versions of this draft.
Seedorf, et al. Expires April 25, 2013 [Page 18]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 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-08 (work in
progress), June 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.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., Medved, J., and
L. Faucheur, "CDNI Footprint Advertisement",
draft-previdi-cdni-footprint-advertisement-02 (work in
progress), September 2012.
[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 April 25, 2013 [Page 19]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012
Appendix A. Acknowledgment
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.
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 April 25, 2013 [Page 20]
Internet-Draft CDNI RR Footprint/Capabilities Semantics October 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 April 25, 2013 [Page 21]