CDNI J. Seedorf
Internet-Draft NEC
Intended status: Informational J. Peterson
Expires: September 4, 2015 Neustar
S. Previdi
Cisco
R. van Brandenburg
TNO
K. Ma
Ericsson
March 3, 2015
CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-05
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 of "Footprint" and
"Capabilities" in the CDNI context, and what the "Footprint and
Capabilities Advertisement Interface (FCI)" is expected to offer
within CDNI. The document also provides guidelines for a CDNI FCI
protocol. It further defines a Base Advertisement Object, the
necessary registries for capabilities and footprints, and guidelines
how these registries may be extended in the future.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Seedorf, et al. Expires September 4, 2015 [Page 1]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
This Internet-Draft will expire on September 4, 2015.
Copyright Notice
Copyright (c) 2015 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 and Scope . . . . . . . . . . . . . . . . . . . 3
2. Design Decisions for Footprint and Capabilities . . . . . . . 4
2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4
2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6
2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7
2.5. Focusing on Main Use Cases . . . . . . . . . . . . . . . 7
3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8
4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8
5. Semantics for Capabilities Advertisement . . . . . . . . . . 11
6. Negotiation of Support for Optional Types of
Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 14
7. Capability Advertisement Object . . . . . . . . . . . . . . . 14
7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14
7.2. Redirection Mode Advertisement Object . . . . . . . . . . 15
7.3. Example of Advertisement Object Serialization . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. Capabilities Registry . . . . . . . . . . . . . . . . . . 16
8.2. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 16
8.3. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 17
8.4. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 17
8.5. Logging Record Type Sub-Registry . . . . . . . . . . . . 17
8.6. Logging Field Name Sub-Registry . . . . . . . . . . . . . 17
8.7. Metadata Type Sub-Registry . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 19
Seedorf, et al. Expires September 4, 2015 [Page 2]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction and Scope
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 [RFC6770],
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 about
the semantics associated with the CDNI Request Routing Footprint &
Capabilities Advertisement Interface (from now on referred to as
FCI), in particular the type of information a downstream CDN
'advertises' regarding its footprint and capabilities. To narrow
down undecided aspects of these semantics, this document tries to
establish a common understanding of what the FCI should offer and
accomplish in the context of CDN Interconnection.
It is explicitly outside the scope of this document to decide on
specific protocols to use for the FCI. However, guidelines for such
FCI protocols are provided.
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.
The CDNI Problem Statement [RFC6707] describes footprint and
capabilities advertisement as: "[enabling] 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". In addition, the
RFC 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".
Seedorf, et al. Expires September 4, 2015 [Page 3]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
It thus considers "resources" and "load" as capabilities to be
advertised by the downstream CDN.
The range of different footprint definitions and possible
capabilities is very broad. Attempting to define a comprehensive
advertisement solution quickly becomes intractable. The CDNI
requirements draft [RFC7337] lists the specific requirements for the
CDNI Footprint & Capabilities Advertisement Interface in order to
disambiguate footprints and capabilities with respect to CDNI. This
document attempts to distill the apparent common understanding of
what the terms 'footprint' and 'capabilities' mean in the context of
CDNI, and detail the semantics of the footprint advertisement
mechanism and the capability advertisement mechanism.
2. Design Decisions for Footprint and Capabilities
A large part of the difficulty in discussing the FCI lies in
understanding what exactly is meant when trying to define footprint
in 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, 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. Potentially 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.
Futhermore, not all capabilities need be footprint restricted.
Depending upon the use case, the optimal semantics of "footprints
with capability attributes" vs. "capabilities with footprint
restrictions" are not clear.
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. The following section will discuss some
of the trade-offs and design decisions that need to be decided upon
for the CDNI FCI.
2.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
Seedorf, et al. Expires September 4, 2015 [Page 4]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
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 joins 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
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.
In summary, the semantics of advertising footprint depend on whether
such qualitative metrics for expressing footprint (such as the
coverage 'score' mentioned above) should be part of the CDNI FCI, or
if it should focus just on 'binary' footprint.
2.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.
Seedorf, et al. Expires September 4, 2015 [Page 5]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
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 of 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 and qualitatively
how often that information should be updated.
2.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 (as is the case in the recursive redirection mode
described in [RFC7336]), 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.
Seedorf, et al. Expires September 4, 2015 [Page 6]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
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?
2.4. Avoiding or Handling 'cheating' dCDNs
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 uCDN in
order to convince the uCDN to select it opposed to 'competing' dCDNs.
It could therefore be 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 qualitatively verifiable by the uCDN, though
possibly through non-real-time out-of-band audits. It is probably an
overly strict requirement to mandate that such verification be
possible "immediately", i.e., during the request routing process
itself. If the uCDN can detect a cheating dCDN at a later stage, it
should suffice for the uCDN to "de-incentivize" cheating because it
would negatively affect the long-term business relationship with a
particular dCDN.
2.5. Focusing on Main Use Cases
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. The ISPs may also choose to federate
with a fallback global CDN.
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. It may be assumed that 'cheating' CDNs will be
dealt with via means outside the scope of CDNI and that the
Seedorf, et al. Expires September 4, 2015 [Page 7]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
information advertised between CDNs is accurate. In addition,
excluding the use of qualitative information (e.g., cache proximity,
delivery latency, cache load) to predict the quality of delivery
would further simplify the use case allowing it to better focus on
the basic functionality of the FCI.
3. Main Use Case to Consider
Focusing on a main use case that contains a simple (yet somewhat
challenging), realistic, and generally imaginable scenario can help
in narrowing down the requirements for the CDNI FCI. To this end,
the following (simplified) use case can help in clarifying the
semantics of footprint and capabilities for CDNI. In particular, the
intention of the use case is to clarify what information needs to be
exchanged on the CDNI FCI, what types of information need to be
supported in a mandatory fashion (and which should be considered
optional), and what types of information need to be updated with
respect to a priori established CDNI contracts.
In short, one can imagine the following use case: A given uCDN has
several dCDNs. It selects one dCDN for delivery protocol A and
footprint 1 and another dCDN for delivery protocol B and footprint 1.
The dCDN that serves delivery protocol B has a further, transitive
(level-2) dCDN, that serves delivery protocol B in a subset of
footprint 1 where the first-level dCDN cannot serve delivery protocol
B itself. What happens if capabilities change in the transitive
level-2 dCDN that might affect how the uCDN selects a level-1 dCDN
(e.g., in case the level-2 dCDN cannot serve delivery protocol B
anymore)? How will these changes be conveyed to the uCDN? In
particular, what information does the uCDN need to be able to select
a new first-level dCDN, either for all of footprint 1 or only for the
subset of footprint 1 that the transitive level-2 dCDN served on
behalf of the first-level dCDN?
4. Semantics for Footprint Advertisement
Roughly speaking, "footprint" can be defined as "ability and
willingness to serve" by a downstream CDN. However, in addition to
simple "ability and willingness to serve", the uCDN may wish to have
additional information to make a dCDN selection decision, e.g., "how
well" a given dCDN can actually serve a given end user request. The
"ability and willingness" to serve should be distinguished from the
subjective qualitative measurement of "how well" it was served. One
can imagine that such additional information is implicitly associated
with a given footprint, e.g., due to contractual agreements (e.g.,
SLAs), business relationships, or perceived dCDN quality in the past.
As an alternative, such additional information could also be
explicitly tagged along with the footprint.
Seedorf, et al. Expires September 4, 2015 [Page 8]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
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 using the
CDNI FCI. The reason for this assumption is that any contractual
agreement is likely to contain specifics about the dCDN coverage
(i.e., the dCDN footprint) to which the contractual agreement
applies. 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 FCI). 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 FCI? 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
FCI 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.
Generally speaking, one can imagine two categories of footprint to be
advertised by a dCDN:
o Footprint could be defined based on "coverage/reachability", where
coverage/reachability refers to a set of prefixes, a geographic
region, or similar boundary. The dCDN claims that it can cover/
reach 'end user requests coming from this footprint'.
o Footprint could be defined based on "resources", where resources
refers to surrogates/caches a dCDN claims to have (e.g., the
location of surrogates/resources). The dCDN claims that 'from
this footprint' it can serve incoming end user requests.
For each of these footprint types, there are capabilities associated
with a given footprint, i.e., the capabilities (e.g., delivery
protocol, redirection mode, metadata) supported in the coverage area
for a "coverage/reachability" defined footprint, or the capabilities
of resources (e.g., delivery protocol, redirection mode, metadata
support) for a "resources" defined footprint.
It seems clear that "coverage/reachability" types of footprint must
be supported within CDNI. The following such types of footprint are
mandatory and must be supported by the CDNI FCI:
Seedorf, et al. Expires September 4, 2015 [Page 9]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
o List of ISO Country Codes
o List of AS numbers
o Set of IP-prefixes
A 'set of IP-prefixes' 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 also be support for multiple
IP address versions, i.e., IPv4 and IPv6, in such a footprint.
"Resource" types of footprints are more specific than "coverage/
reachability" types of footprints, where the actual coverage/
reachability are extrapolated from the resource location (e.g.,
netmask applied to resource IP address to derive IP-prefix). The
specific methods for extrapolating coverage/reachability from
resource location are beyond the scope of this document. In the
degenerate case, the resource address could be specified as a
coverage/reachability type of footprint, in which case no
extrapolation is necessary. Resource types of footprints may expose
the internal structure of a CDN network which may be undesirable. As
such, the resource types of footprints are not considered mandatory
to support for CDNI.
For all of these mandatory-to-implement footprint types, footprints
can be viewed as constraints for delegating requests to a dCDN: A
dCDN footprint advertisement tells the uCDN the limitations for
delegating a request to the dCDN. For IP prefixes or ASN(s), the
footprint signals to the uCDN that it should consider the dCDN a
candidate only if the IP address of the request routing source falls
within the prefix set (or ASN, respectively). The CDNI
specifications do not define how a given uCDN determines what address
ranges are in a particular ASN. Similarly, for country codes a uCDN
should only consider the dCDN a candidate if it covers the country of
the request routing source. The CDNI specifications do not define
how a given uCDN determines the country of the request routing
source. Multiple footprint constraints are additive, i.e., the
advertisement of different types of footprint narrows the dCDN
candidacy cumulatively.
In addition to these mandatory "coverage/reachability" types of
footprint, other optional "coverage/reachability" types of footprint
or "resource" types of footprint may defined by future
specifications. To facilitate this, a clear process for specifying
optional footprint types in a IANA registry is specified in
Section 8. This includes the specification of the level of oversight
necessary (e.g., WG decision or expert review) for adding new
optional footprints to a IANA registry as well as the specification
Seedorf, et al. Expires September 4, 2015 [Page 10]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
of a template regarding design choices that must be captured by new
optional types of footprints.
Independent of the exact type of a footprint, a footprint might also
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 data set
containing the complete footprint. Making incremental updates,
however, to express dynamic changes in state is also desirable.
5. Semantics for Capabilities Advertisement
In general, 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, HTTP delivery, RTP/RTSP
delivery or RTMP. Furthermore, 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 RTMP but not in
some specific areas, either for maintenance reasons or because the
caches covering 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.
A high-level and very rough semantic for capabilities is thus the
following: Capabilities are types of information that allow a uCDN to
determine if a downstream CDN is able (and willing) to accept (and
properly handle) a delegated content request. In addition,
Capabilities are characterized by the fact that this information may
possibly change over time based on the state of the network or
caches.
At a first glance, several broad categories of capabilities seem
useful to convey via an advertisement interface, however, advertising
capabilities that change highly dynamically (e.g., real-time delivery
performance metrics, CDN resource load, or other highly dynamically
changing QoS information) should probably not be in scope for the
CDNI FCI. 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.
Seedorf, et al. Expires September 4, 2015 [Page 11]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
Useful capabilities refer to information that does not change highly
dynamically and which in many cases is absolutely necessary to decide
on a particular dCDN for a given end user request. For instance, if
an end user request concerns the delivery of a video file with a
certain protocol (e.g., RTMP), the uCDN needs to know if a given dCDN
has the capabilitity 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 using the CDNI FCI. The role
of capability 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). Capabilities advertisement thus 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 exact capabilities
are useful and how these can be expressed. Since the details of CDNI
contracts are not known at the time of this writing (and the CDNI
interface should probably be agnostic to these contracts anyway), it
remains to be seen what capabilities will be used to define
agreements between CDNs in practice. One implication for
standardization may be to initially only specify a very limited set
of mandatory capabilities for advertisement and have on top of that a
flexible data model that allows exchanging additional capabilities
when needed. Still, agreement needs to be found on which
capabilities (if any) should be mandatory among CDNs. As discussed
in Section 2.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.
Under the above considerations, the following capabilities seem
useful as 'base' capabilities, i.e., ones that are needed in any case
and therefore constitute mandatory capabilities to be supported by
the CDNI FCI:
o Delivery Protocol (e.g., HTTP vs. RTMP)
o Acquisition Protocol (for aquiring content from a uCDN)
o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
discussed in [RFC7336])
Seedorf, et al. Expires September 4, 2015 [Page 12]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
o CDNI Logging (i.e., supported logging fields)
o CDNI Metadata (i.e., supported Generic Metadata types)
It is not feasable to enumerate all the possible options for the
mandatory capabilities listed above (e.g., all the potential delivery
protocols or metadata options) or anticipate all the future needs for
additional capabilities. It would be unreasonable to burden the CDNI
FCI specification with defining each supported capability. Instead,
the CDNI FCI specification should define a generic protocol for
conveying any capability information (e.g. with common encoding,
error handling, and security mechanism; further requirements for the
CDNI FCI Advertisement Interface are listed in [RFC7337]). In this
respect, it seems reasonable to define a registry which initially
contains the mandatory capabilities listed above, but may be extended
as needs dictate. This document defines the registry (and the rules
for adding new entries to the registry) for the different capability
types (see Section 8). Each capability type MAY have a list of valid
values. Future specifications which define a given capability SHOULD
define any necessary registries (and the rules for adding new entries
to the registry) for the values advertised for a given capability
type.
The "CDNI Logging Fields Names" registry defines all supported
logging fields, including mandatory-to-implement logging fields.
Advertisement of support for mandatory-to-implement logging fields
SHOULD be supported but would be redundant. CDNs SHOULD NOT
advertise support for mandatory-to-implement logging fields. The
following logging fields are defined as optional in the CDNI Logging
Interface document [I-D.ietf-cdni-logging]:
o c-ip-anonimizing
o s-ccid
o s-sid
The "CDNI GenericMetadata Types" registry defines all supported
GenericMetadats types, including mandatory-to-implement
GenericMetadata types. Advertisement of support for mandatory-to-
implement GenericMetadata types SHOULD be supported but would be
redundant. CDNs SHOULD NOT advertise support for mandatory-to-
implement GenericMetadata types. The CDNI Metadata Interface
document [I-D.ietf-cdni-metadata] does not define any optional
GenericMetadata types.
Seedorf, et al. Expires September 4, 2015 [Page 13]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
6. Negotiation of Support for Optional Types of Footprint/Capabilities
The notion of optional types of footprint and capabilities implies
that certain implementations may not support all kinds of footprint
and capabilities. Therefore, any FCI solution protocol must define
how the support for optional types of footprint/capabilities will be
negotiated between a uCDN and a dCDN that use the particular FCI
protocol. In particular, any FCI solution protocol needs to specify
how to handle failure cases or non-supported types of footprint/
capabilities.
In general, a uCDN may ignore capabilities or types of footprint it
does not understand; in this case it only selects a suitable
downstream CDN based on the types of capabilities and footprint it
understands. Similarly, if a dCDN does not use an optional
capability or footprint which is, however, supported by a uCDN, this
causes no problem for the FCI functionality because the uCDN decides
on the remaining capabilities/footprint information that is being
conveyed by the dCDN.
7. Capability Advertisement Object
To support extensibility, the FCI defines a generic base object
(similar to the CDNI Metadata interface GenericMetadata object)
[I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory
parsing requirements for all future FCI objects.
Future object definitions (e.g. regarding CDNI Metadata or Logging)
will build off the base object defined here, but will be specified in
separate documents.
7.1. Base Advertisement Object
The FCIBase object is an abstraction for managing individual CDNI
capabilities (see Section 8.1) in an opaque manner.
Property: capability-type
Description: CDNI Capability object type.
Type: MIME Type String (from Section 8)
Mandatory-to-Specify: Yes.
Property: capability-value
Description: CDNI Capability object.
Seedorf, et al. Expires September 4, 2015 [Page 14]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
Type: Format/Type is defined by the value of capability-type
property above.
Mandatory-to-Specify: Yes.
7.2. Redirection Mode Advertisement Object
The Redirection Mode advertisement object is used to indicate support
for one or more of the modes listed in the CDNI Capabilities
Redirection Modes registry (see Section 8.4).
Property: redirection-modes
Description: List of supported CDNI Redirection Modes.
Type: List of Redirection Modes (from Section 8.4)
Mandatory-to-Specify: Yes.
Redirection Mode is not contained in the CDNI Metadata or Logging
specifications; it is FCI specific. It is defined here as an example
for future specifications that define further CDNI FCI objects.
7.3. Example of Advertisement Object Serialization
The following shows an example of CDNI FCI Advertisement Object
Serialization for two supported redirection modes and one supported
logging capability.
{
"capabilities": [
{
"capability-type": "application/cdni.FCI.RedirectionMode.v1"
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
},
{
"capability-type": "application/cdni.FCI.LI.s-ccid.v1"
"capability-value": {
"s-ccid-support": true
}
}
]
}
Seedorf, et al. Expires September 4, 2015 [Page 15]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
8. IANA Considerations
This document requests the registration of the following MIME Media
Type under the IANA MIME Media Type registry
(http://www.iana.org/assignments/media-types/index.html).
application/cdni.FCI.RedirectionMode.v1
8.1. Capabilities Registry
IANA registries are to be used for mandatory and optional types of
footprint and capabilities. Therefore, the mandatory types of
capabilities listed in this document (see Section 5) are to be
registered with IANA. In order to prevent namespace collisions for
capabilities a new IANA registry is requested for the "CDNI
Capabilities" namespace. The namespace shall be split into two
partitions: standard and optional.
The "standard" namespace partition is intended to contain mandatory
to implement capabilities and conforms to the "IETF Review" policy as
defined in [RFC5226]. The registry contains the name of the standard
capability, the RFC number of the specification defining the
capability (including the capability advertisement object format and
serialization).
The following table defines the initial capabilities for the standard
partition:
+-----------------------------------------+---------+
| Capability | RFC |
+-----------------------------------------+---------+
| application/cdni.FCI.RedirectionMode.v1 | RFCthis |
+-----------------------------------------+---------+
The "optional" namespace partition conforms to the "Expert Review"
policy as defined in [RFC5226]. The expert review is intended to
prevent namespace hoarding and to prevent the definition of redundant
capabilities. Vendors defining new capabilities which conflict with
existing capabilities follow the guidelines for the "Specification
Required" policy as defined in [RFC5226].
8.2. Footprint Sub-Registry
The "CDNI Metadata Footprint Types" namespace defined in the CDNI
Metadata Interface document [I-D.ietf-cdni-metadata] contains the
supported footprint formats for use in footprint advertisement. No
further IANA action is required here.
Seedorf, et al. Expires September 4, 2015 [Page 16]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
8.3. Protocol Sub-Registry
The "CDNI Metadata Protocols" namespace defined in the CDNI Metadata
Interface document [I-D.ietf-cdni-metadata] contains the supported
protocol values for the Delivery Protocol and Acquisition Protocol
capabilities. No further IANA action is required here.
8.4. Redirection Mode Sub-Registry
The "CDNI Capabilities Redirection Modes" namespace defines the valid
redirection modes that may be advertised as supported by a CDN.
Additions to the Redirection Mode namespace conform to the "IETF
Review" policy as defined in [RFC5226].
The following table defines the initial Redirection Modes:
+------------------+----------------------------------+---------+
| Redirection Mode | Description | RFC |
+------------------+----------------------------------+---------+
| DNS-I | Iterative DNS-based Redirection | RFCthis |
| | | |
| DNS-R | Recursive DNS-based Redirection | RFCthis |
| | | |
| HTTP-I | Iterative HTTP-based Redirection | RFCthis |
| | | |
| HTTP-R | Recursive HTTP-based Redirection | RFCthis |
+------------------+----------------------------------+---------+
8.5. Logging Record Type Sub-Registry
The "CDNI Logging Record-Types" namespace defined in the CDNI Logging
Interface document [I-D.ietf-cdni-logging] contains the types of all
supported logging record-types. No further IANA action is required
here.
8.6. Logging Field Name Sub-Registry
The "CDNI Logging Fields Names" namespace defined in the CDNI Logging
Interface document [I-D.ietf-cdni-logging] contains the names of all
supported logging fields. No further IANA action is required here.
8.7. Metadata Type Sub-Registry
The "CDNI GenericMetadata Types" namespace defined in the CDNI
Metadata Interface document [I-D.ietf-cdni-metadata] contains the
names of the supported GenericMetadata objects. No further IANA
action is required here.
Seedorf, et al. Expires September 4, 2015 [Page 17]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
9. Security Considerations
This specification describes the semantics for capabilities and
footprint advertisement objects in content distribution networks. It
does not, however, specify a concrete protocol for transporting those
objects, or even a specific object syntax. Specific security
mechanisms can only be selected for concrete protocols that
instantiate these semantics. This document does, however, place some
high-level security constraints on such protocols.
All protocols that implement these semantics are REQUIRED to provide
integrity and authentication services. Without authentication and
integrity, an attacker could trivially deny service by forging a
footprint advertisement from a dCDN which claims the network has no
footprint or capability. This would prevent the uCDN from delegating
any requests to the dCDN. Since a pre-existing relationship between
all dCDNs and uCDNs is assumed by CDNi, the exchange of any necessary
credentials could be conducted before the FCI interface is brought
online. The authorization decision to accept advertisements would
also follow this pre-existing relationship and any contractual
obligations that it stipulates.
It is not believed that there are any serious privacy risks in
sharing footprint or capability information: it will represent highly
aggregated data about networks and at best policy-related information
about media, rather than any personally identifying information.
However, particular dCDNs may wish to share information about their
footprint with a uCDN but not with other, competing dCDNs. For
example, if a dCDN incurs an outage that reduces footprint coverage
temporarily, that may be information the dCDN would want to share
confidentially with the uCDN. Protocols implementing these semantics
SHOULD provide confidentiality services.
As specified in this document, the security requirements of the FCI
could be met by hop-by-hop transport-layer security mechanisms
coupled with domain certificates as credentials. There is no
apparent need for further object-level security in this framework, as
the trust relationships it defines are bilateral relationships
between uCDNs and dCDNs rather than transitive relationships.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Seedorf, et al. Expires September 4, 2015 [Page 18]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg,
"Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, August 2014.
[RFC7337] Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", RFC 7337, August
2014.
10.2. Informative References
[I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-15 (work in progress), February 2015.
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-08 (work in progress), October 2014.
Appendix A. Acknowledgment
Jan Seedorf is partially supported by the GreenICN project (GreenICN:
Architecture and Applications of Green Information Centric
Networking), a research project supported jointly by the European
Commission under its 7th Framework Program (contract no. 608518) and
the National Institute of Information and Communications Technology
(NICT) in Japan (contract no. 167). 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 GreenICN project,
the European Commission, or NICT.
Martin Stiemerling provided initial input to this document and
valuable comments to the ongoing discussions among the authors of
Seedorf, et al. Expires September 4, 2015 [Page 19]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
this document. Thanks to Francois Le Faucheur and Scott Wainner for
providing valuable comments and suggestions to the text.
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
Email: jon.peterson@neustar.biz
Stefano Previdi
Cisco Systems
Via Del Serafico 200
Rome 0144
Italy
Email: sprevidi@cisco.com
Ray van Brandenburg
TNO
Brassersplein 2
Delft 2612CT
The Netherlands
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl
Seedorf, et al. Expires September 4, 2015 [Page 20]
Internet-Draft CDNI RR Footprint/Capabilities Semantics March 2015
Kevin J. Ma
Ericsson
43 Nagog Park
Acton, MA 01720
USA
Phone: +1 978-844-5100
Email: kevin.j.ma@ericsson.com
Seedorf, et al. Expires September 4, 2015 [Page 21]
