draft-ietf-cdni-footprint-capabilities-semantics-06.txt   draft-ietf-cdni-footprint-capabilities-semantics-07.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: September 10, 2015 Neustar Expires: February 19, 2016 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
March 9, 2015 August 18, 2015
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-06 draft-ietf-cdni-footprint-capabilities-semantics-07
Abstract Abstract
This document tries to capture the semantics of the "Footprint and This document captures the semantics of the "Footprint and
Capabilities Advertisement" part of the CDNI Request Routing Capabilities Advertisement" part of the CDNI Request Routing
interface, i.e., the desired meaning of "Footprint" and interface, i.e., the desired meaning of "Footprint" and
"Capabilities" in the CDNI context, and what the "Footprint and "Capabilities" in the CDNI context, and what the "Footprint and
Capabilities Advertisement Interface (FCI)" is expected to offer Capabilities Advertisement Interface (FCI)" offers within CDNI. The
within CDNI. The document also provides guidelines for a CDNI FCI document also provides guidelines for the CDNI FCI protocol. It
protocol. It further defines a Base Advertisement Object, the further defines a Base Advertisement Object, the necessary registries
necessary registries for capabilities and footprints, and guidelines for capabilities and footprints, and guidelines how these registries
how these registries may be extended in the future. may be extended in the future.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015. This Internet-Draft will expire on February 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6
2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7
2.5. Focusing on Main Use Cases . . . . . . . . . . . . . . . 7 2.5. Focusing on Main Use Cases . . . . . . . . . . . . . . . 7
3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8 3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8
4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8 4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8
5. Semantics for Capabilities Advertisement . . . . . . . . . . 11 5. Semantics for Capabilities Advertisement . . . . . . . . . . 11
6. Negotiation of Support for Optional Types of 6. Negotiation of Support for Optional Types of
Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13
7. Capability Advertisement Object . . . . . . . . . . . . . . . 14 7. Capability Advertisement Object . . . . . . . . . . . . . . . 14
7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14 7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14
7.2. Delivery Protocol Capability Object . . . . . . . . . . . 15 7.2. Delivery Protocol Capability Object . . . . . . . . . . . 14
7.3. Acquisition Protocol Capability Object . . . . . . . . . 15 7.3. Acquisition Protocol Capability Object . . . . . . . . . 15
7.4. Redirection Mode Capability Object . . . . . . . . . . . 15 7.4. Redirection Mode Capability Object . . . . . . . . . . . 15
7.5. Capability Advertisement Object Serialization . . . . . . 16 7.5. Capability Advertisement Object Serialization . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. Redirection Mode Registry . . . . . . . . . . . . . . . . 17 8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1.2. CDNI FCI AcuiqisitionProtocol Payload Type . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18 8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Normative References . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction and Scope 1. Introduction and Scope
The CDNI working group is working on a set of protocols to enable the The CDNI working group is working on a set of protocols to enable the
interconnection of multiple CDNs to a CDN federation. This CDN- interconnection of multiple CDNs to a CDN federation. This CDN-
federation should serve multiple purposes, as discussed in [RFC6770], federation should serve multiple purposes, as discussed in [RFC6770],
for instance, to extend the reach of a given CDN to areas in the for instance, to extend the reach of a given CDN to areas in the
network which are not covered by this particular CDN. network which are not covered by this particular CDN.
The goal of this document is to achieve a clear understanding about The goal of this document is to achieve a clear understanding about
skipping to change at page 4, line 11 skipping to change at page 4, line 11
system when processing subsequent content requests from User Agents". system when processing subsequent content requests from User Agents".
It thus considers "resources" and "load" as capabilities to be It thus considers "resources" and "load" as capabilities to be
advertised by the downstream CDN. advertised by the downstream CDN.
The range of different footprint definitions and possible The range of different footprint definitions and possible
capabilities is very broad. Attempting to define a comprehensive capabilities is very broad. Attempting to define a comprehensive
advertisement solution quickly becomes intractable. The CDNI advertisement solution quickly becomes intractable. The CDNI
requirements draft [RFC7337] lists the specific requirements for the requirements draft [RFC7337] lists the specific requirements for the
CDNI Footprint & Capabilities Advertisement Interface in order to CDNI Footprint & Capabilities Advertisement Interface in order to
disambiguate footprints and capabilities with respect to CDNI. This disambiguate footprints and capabilities with respect to CDNI. This
document attempts to distill the apparent common understanding of document defines a common understanding of what the terms 'footprint'
what the terms 'footprint' and 'capabilities' mean in the context of and 'capabilities' mean in the context of CDNI, and detail the
CDNI, and detail the semantics of the footprint advertisement semantics of the footprint advertisement mechanism and the capability
mechanism and the capability advertisement mechanism. advertisement mechanism.
2. Design Decisions for Footprint and Capabilities 2. Design Decisions for Footprint and Capabilities
A large part of the difficulty in discussing the FCI lies in A large part of the difficulty in discussing the FCI lies in
understanding what exactly is meant when trying to define footprint understanding what exactly is meant when trying to define footprint
in terms of "coverage" or "reachability." While the operators of in terms of "coverage" or "reachability." While the operators of
CDNs pick strategic locations to situate caches, a cache with a CDNs pick strategic locations to situate caches, a cache with a
public IPv4 address is reachable by any endpoint on the Internet public IPv4 address is reachable by any endpoint on the Internet
unless some policy enforcement precludes the use of the cache. unless some policy enforcement precludes the use of the cache.
skipping to change at page 5, line 7 skipping to change at page 5, line 7
The basic use case that would motivate a dCDN to advertise a limited 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 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 of the Internet. For example, an ISP could purpose-build a CDN to
serve only their own customers by situating caches in close serve only their own customers by situating caches in close
topological proximity to high concentrations of their subscribers. topological proximity to high concentrations of their subscribers.
The ISP knows the prefixes it has allocated to end users and thus can 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 easily construct a list of prefixes that its caches were positioned
to serve. to serve.
When such a purpose-built CDN joins a federation, however, and When such a purpose-built CDN joins a federation, and advertises its
advertises its footprint to a uCDN, the original intended coverage of footprint to a uCDN, however, the original intended coverage of the
the CDN might not represent its actual value to the federation of CDN might not represent its actual value to the federation of CDNs.
CDNs. Consider an ISP-A and ISP-B that both field their own CDNs, Consider an ISP-A and ISP-B that both field their own CDNs, which
which they federate through CDNI. A given user E, who is customer of they federate through CDNI. A given user E, who is customer of ISP-
ISP-B, might happen to be topologically closest to a cache fielded by 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 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 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-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 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 does ISP-A advertise itself as a "standby" for E? What about the
case where CDNs advertising to the same uCDN express overlapping case where CDNs advertising to the same uCDN express overlapping
coverage (for example, a federation mixing global and limited CDNs)? coverage (for example, a federation mixing global and limited CDNs)?
The answers to these questions greatly depend on how much information 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 the uCDN wants 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, three dCDNs to choose from that "cover" the IP address of user E,
obviously the uCDN might be interested to know how optimal the obviously the uCDN might be interested to know how optimal the
coverage is from each of the dCDNs - coverage need not be binary, coverage is from each of the dCDNs - coverage need not be binary,
either provided or not provided. dCDNs could advertise a coverage either provided or not provided. dCDNs could advertise a coverage
"score," for example, and provided that they all reported scores "score," for example, and provided that they all reported scores
fairly on the same scale, uCDNs could use that to make their fairly on the same scale, uCDNs could use that to make their
topological optimality decision. Alternatively, dCDNs could for topological optimality decision. Alternately, dCDNs could advertise
their footprint advertise the IP addresses of their caches rather the IP addresses of their caches rather than prefix "coverage," and
than prefix "coverage," and let the uCDN decide for itself (based on let the uCDN decide for itself (based on its own topological
its own topological intelligence) which dCDN has better resources to intelligence) which dCDN has better resources to serve a given user.
serve a given user.
In summary, the semantics of advertising footprint depend on whether In summary, the semantics of advertising footprint depend on whether
such qualitative metrics for expressing footprint (such as the such qualitative metrics for expressing footprint (such as the
coverage 'score' mentioned above) should be part of the CDNI FCI, or coverage 'score' mentioned above) should be part of the CDNI FCI, or
if it should focus just on 'binary' footprint. if it should focus just on 'binary' footprint.
2.2. Capabilities and Dynamic Data 2.2. Capabilities and Dynamic Data
In cases where the apparent footprint of dCDNs overlaps, uCDNs might In cases where the apparent footprints of dCDNs overlap, uCDNs might
also want to rely on a host of other factors to evaluate the also want to rely on other factors to evaluate the respective merits
respective merits of dCDNs. These include facts related to the of dCDNs. These include facts related to the caches themselves, to
caches themselves, to the network where the cache is deployed, to the the network where the cache is deployed, to the nature of the
nature of the resource sought and to the administrative policies of resource sought, and to the administrative policies of the respective
the respective networks. networks.
In the absence of network-layer impediments to reaching caches, the In the absence of network-layer impediments to reaching caches, the
choice to limit coverage is necessarily an administrative policy. choice to limit coverage is necessarily an administrative policy.
Much policy must be agreed upon before CDNs can merge into Much policy must be agreed upon before CDNs can merge into
federations, including questions of membership, compensation, volumes federations, including questions of membership, compensation,
and so on. A uCDN certainly will factor these sorts of volumes, and so on. A uCDN certainly will factor these sorts of
considerations into its decision to select a dCDN, but there is considerations into its decision to select a dCDN, but there is
probably little need for dCDNs to actually advertise them through an probably little need for dCDNs to actually advertise them through an
interface - they will be settled out of band as a precondition for interface - they will be settled out-of-band as a precondition for
federating. federating.
Other facts about the dCDN would be expressed through the interface Other facts about the dCDN would be expressed through the interface
to the uCDN. Some capabilities of a dCDN are static, and some are to the uCDN. Some capabilities of a dCDN are static, and some are
highly dynamic. Expressing the total storage built into its caches, highly dynamic. Expressing the total storage built into its caches,
for example, changes relatively rarely, whereas the amount of storage for example, changes relatively rarely, whereas the amount of storage
in use at any given moment is highly volatile. Network bandwidth in use at any given moment is highly volatile. Network bandwidth
similarly could be expressed as either total bandwidth available to a 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 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 one moment lack a particular resource in storage, but have it the
next. next.
The semantics of the capabilities interface will depend on how much The semantics of the capabilities interface will depend on how much
of the dCDN state needs to be pushed to the uCDN and qualitatively of the dCDN state needs to be pushed to the uCDN and qualitatively
how often that information should be updated. how often that information should be updated.
2.3. Advertisement versus Queries 2.3. Advertisement versus Queries
In a federated CDN environment, each dCDN shares some of its state 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 with the uCDN. The uCDN uses this information to build a unified
of the dCDNs available to it. In architectures that share detailed picture of all of the dCDNs available to it. In architectures that
capability information, the uCDN could basically perform the entire share detailed capability information, the uCDN could perform the
request-routing intelligence down to selecting a particular cache entire request-routing operation down to selecting a particular cache
before sending the request to the dCDN (note that within the current in the dCDN (note: within the current CDNI WG charter, such direct
CDNI WG scope, such direct selection of specific caches by the uCDN selection of specific caches by the uCDN is out-of-scope). However,
is out of scope). However, when the uCDN must deal with many when the uCDN must deal with many potential dCDNs, this approach does
potential dCDNs, this approach does not scale. Especially as CDNs not scale, especially for dCDNs with thousands or tens of thousands
scale up from dozens or hundreds of caches to thousands or tens of of caches; the volume of updates to footprint and capability becomes
thousands, the volume of updates to footprint and capability may onerous.
become onerous.
Were the volume of updates to exceed the volumes of requests to the Were the volume of FCI updates from dCDNs to exceed the volume of
uCDN, it might make more sense for the uCDN to query dCDNs upon requests to the uCDN, it might make more sense for the uCDN to query
receiving requests (as is the case in the recursive redirection mode dCDNs upon receiving requests (as is the case in the recursive
described in [RFC7336]), instead of receiving advertisements and redirection mode described in [RFC7336]), instead of receiving
tracking the state of dCDNs itself. The advantage of querying dCDNs advertisements and tracking the state of dCDNs. The advantage of
would be that much of the dynamic data that dCDNs cannot share with querying dCDNs would be that much of the dynamic data that dCDNs
the uCDN would now be factored into the uCDN's decision. dCDNs need cannot share with the uCDN would now be factored into the uCDN's
not replicate any state to the uCDN - uCDNs could effectively operate decision. dCDNs need not replicate any state to the uCDN - uCDNs
in a stateless mode. could effectively operate in a stateless mode.
The semantics of both footprint and capability advertisement depend The semantics of both footprint and capability advertisement depend
on the service model here: are there cases where a synchronous query/ on the service model here: are there cases where a synchronous query/
response model would work better for the uCDN decision than a state response model would work better for the uCDN decision than a state
replication model? replication model?
2.4. Avoiding or Handling 'cheating' dCDNs 2.4. Avoiding or Handling 'cheating' dCDNs
In a situation where more than one dCDN is willing to serve a given 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 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 sense that the dCDN provides inaccurate information to the uCDN in
order to convince the uCDN to select it opposed to 'competing' dCDNs. order to convince the uCDN to select it over 'competing' dCDNs. It
It could therefore be desirable to take away the incentive for dCDNs could therefore be desirable to take away the incentive for dCDNs to
to cheat (in information advertised) as much as possible. One option cheat (in information advertised) as much as possible. One option is
here is to make the information the dCDN advertises somehow to make the information the dCDN advertises somehow verifiable for
verifiable for the uCDN. One the other hand, a cheating dCDN might the uCDN. One the other hand, a cheating dCDN might be avoided or
be avoided or handled by the fact that there will be strong handled by the fact that there will be strong contractual agreements
contractual agreements between a uCDN and a dCDN, so that a dCDN between a uCDN and a dCDN, so that a dCDN would risk severe penalties
would risk severe penalties or legal consequences when caught or legal consequences when caught cheating.
cheating.
Overall, it seems that information a dCDN advertises should (in the Overall, the information a dCDN advertises should (in the long run)
long run) be somehow qualitatively verifiable by the uCDN, though be somehow qualitatively verifiable by the uCDN, though possibly
possibly through non-real-time out-of-band audits. It is probably an through non-real-time out-of-band audits. It is probably an overly
overly strict requirement to mandate that such verification be strict requirement to mandate that such verification be possible
possible "immediately", i.e., during the request routing process "immediately", i.e., during the request routing process itself. If
itself. If the uCDN can detect a cheating dCDN at a later stage, it the uCDN can detect a cheating dCDN at a later stage, it should
should suffice for the uCDN to "de-incentivize" cheating because it suffice for the uCDN to "de-incentivize" cheating because it would
would negatively affect the long-term business relationship with a negatively affect the long-term business relationship with a
particular dCDN. particular dCDN.
2.5. Focusing on Main Use Cases 2.5. Focusing on Main Use Cases
To narrow down semantics for "footprint" and "capabilities" in the To narrow down semantics for "footprint" and "capabilities" in the
CDNI context, it can be useful to initially focus on key use cases to 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 be addressed by the CDNI WG that are to be envisioned the main
deployments in the foreseeable future. In this regard, a main deployments in the foreseeable future. In this regard, a main
realistic use case is the existence of ISP-owned CDNs, which realistic use case is the existence of ISP-owned CDNs, which
essentially cover a certain operator's network. At the same time, essentially cover a certain operator's network. At the same time,
skipping to change at page 8, line 21 skipping to change at page 8, line 18
challenging), realistic, and generally imaginable scenario can help challenging), realistic, and generally imaginable scenario can help
in narrowing down the requirements for the CDNI FCI. To this end, in narrowing down the requirements for the CDNI FCI. To this end,
the following (simplified) use case can help in clarifying the the following (simplified) use case can help in clarifying the
semantics of footprint and capabilities for CDNI. In particular, the semantics of footprint and capabilities for CDNI. In particular, the
intention of the use case is to clarify what information needs to be 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 exchanged on the CDNI FCI, what types of information need to be
supported in a mandatory fashion (and which should be considered supported in a mandatory fashion (and which should be considered
optional), and what types of information need to be updated with optional), and what types of information need to be updated with
respect to a priori established CDNI contracts. respect to a priori established CDNI contracts.
In short, one can imagine the following use case: A given uCDN has Use case: A given uCDN has several dCDNs. It selects one dCDN for
several dCDNs. It selects one dCDN for delivery protocol A and delivery protocol A and footprint 1 and another dCDN for delivery
footprint 1 and another dCDN for delivery protocol B and footprint 1. protocol B and footprint 1. The dCDN that serves delivery protocol B
The dCDN that serves delivery protocol B has a further, transitive has a further, transitive (level-2) dCDN, that serves delivery
(level-2) dCDN, that serves delivery protocol B in a subset of protocol B in a subset of footprint 1 where the first-level dCDN
footprint 1 where the first-level dCDN cannot serve delivery protocol cannot serve delivery protocol B itself. What happens if
B itself. What happens if capabilities change in the transitive capabilities change in the transitive level-2 dCDN that might affect
level-2 dCDN that might affect how the uCDN selects a level-1 dCDN how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN
(e.g., in case the level-2 dCDN cannot serve delivery protocol B cannot serve delivery protocol B anymore)? How will these changes be
anymore)? How will these changes be conveyed to the uCDN? In conveyed to the uCDN? In particular, what information does the uCDN
particular, what information does the uCDN need to be able to select need to be able to select a new first-level dCDN, either for all of
a new first-level dCDN, either for all of footprint 1 or only for the footprint 1 or only for the subset of footprint 1 that the transitive
subset of footprint 1 that the transitive level-2 dCDN served on level-2 dCDN served on behalf of the first-level dCDN?
behalf of the first-level dCDN?
4. Semantics for Footprint Advertisement 4. Semantics for Footprint Advertisement
Roughly speaking, "footprint" can be defined as "ability and Roughly speaking, "footprint" can be defined as "ability and
willingness to serve" by a downstream CDN. However, in addition to willingness to serve" by a downstream CDN. However, in addition to
simple "ability and willingness to serve", the uCDN may wish to have simple "ability and willingness to serve", the uCDN may wish to have
additional information to make a dCDN selection decision, e.g., "how additional information to make a dCDN selection decision, e.g., "how
well" a given dCDN can actually serve a given end user request. The well" a given dCDN can actually serve a given end user request. The
"ability and willingness" to serve should be distinguished from the "ability and willingness" to serve should be distinguished from the
subjective qualitative measurement of "how well" it was served. One subjective qualitative measurement of "how well" it was served. One
skipping to change at page 9, line 47 skipping to change at page 9, line 40
o Footprint could be defined based on "resources", where resources o Footprint could be defined based on "resources", where resources
refers to surrogates/caches a dCDN claims to have (e.g., the refers to surrogates/caches a dCDN claims to have (e.g., the
location of surrogates/resources). The dCDN claims that 'from location of surrogates/resources). The dCDN claims that 'from
this footprint' it can serve incoming end user requests. this footprint' it can serve incoming end user requests.
For each of these footprint types, there are capabilities associated For each of these footprint types, there are capabilities associated
with a given footprint, i.e., the capabilities (e.g., delivery with a given footprint, i.e., the capabilities (e.g., delivery
protocol, redirection mode, metadata) supported in the coverage area protocol, redirection mode, metadata) supported in the coverage area
for a "coverage/reachability" defined footprint, or the capabilities for a "coverage/reachability" defined footprint, or the capabilities
of resources (e.g., delivery protocol, redirection mode, metadata of resources (e.g., delivery protocol, redirection mode, metadata
support) for a "resources" defined footprint. support) for a "resource" defined footprint.
It seems clear that "coverage/reachability" types of footprint must It seems clear that "coverage/reachability" types of footprint MUST
be supported within CDNI. The following such types of footprint are be supported within CDNI. The following such types of footprint are
mandatory and must be supported by the CDNI FCI: mandatory and MUST be supported by the CDNI FCI:
o List of ISO Country Codes o List of ISO Country Codes
o List of AS numbers o List of AS numbers
o Set of IP-prefixes o Set of IP-prefixes
A 'set of IP-prefixes' must be able to contain full IP addresses, 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 i.e., a /32 for IPv4 and a /128 for IPv6, as well as IP prefixes with
an arbitrary prefix length. There must also be support for multiple an arbitrary prefix length. There must also be support for multiple
IP address versions, i.e., IPv4 and IPv6, in such a footprint. IP address versions, i.e., IPv4 and IPv6, in such a footprint.
"Resource" types of footprints are more specific than "coverage/ "Resource" types of footprints are more specific than "coverage/
reachability" types of footprints, where the actual coverage/ reachability" types of footprints, where the actual coverage/
reachability are extrapolated from the resource location (e.g., reachability are extrapolated from the resource location (e.g.,
netmask applied to resource IP address to derive IP-prefix). The netmask applied to resource IP address to derive IP-prefix). The
specific methods for extrapolating coverage/reachability from specific methods for extrapolating coverage/reachability from
resource location are beyond the scope of this document. In the resource location are beyond the scope of this document. In the
degenerate case, the resource address could be specified as a degenerate case, the resource address could be specified as a
coverage/reachability type of footprint, in which case no coverage/reachability type of footprint, in which case no
extrapolation is necessary. Resource types of footprints may expose extrapolation is necessary. Resource types of footprints may expose
the internal structure of a CDN network which may be undesirable. As the internal structure of a CDN network which may be undesirable. As
such, the resource types of footprints are not considered mandatory such, the resource types of footprints are not considered mandatory
to support for CDNI. to support for CDNI.
For all of these mandatory-to-implement footprint types, footprints For all of these mandatory-to-implement footprint types, the
can be viewed as constraints for delegating requests to a dCDN: A footprints can be viewed as constraints for delegating requests to a
dCDN footprint advertisement tells the uCDN the limitations for dCDN: A dCDN footprint advertisement tells the uCDN the limitations
delegating a request to the dCDN. For IP prefixes or ASN(s), the 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 footprint signals to the uCDN that it should consider the dCDN a
candidate only if the IP address of the request routing source falls candidate only if the IP address of the request routing source falls
within the prefix set (or ASN, respectively). The CDNI within the prefix set (or ASN, respectively). The CDNI
specifications do not define how a given uCDN determines what address specifications do not define how a given uCDN determines what address
ranges are in a particular ASN. Similarly, for country codes a uCDN 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 should only consider the dCDN a candidate if it covers the country of
the request routing source. The CDNI specifications do not define the request routing source. The CDNI specifications do not define
how a given uCDN determines the country of the request routing how a given uCDN determines the country of the request routing
source. Multiple footprint constraints are additive, i.e., the source. Multiple footprint constraints are additive, i.e., the
advertisement of different types of footprint narrows the dCDN advertisement of different types of footprint narrows the dCDN
candidacy cumulatively. candidacy cumulatively.
In addition to these mandatory "coverage/reachability" types of In addition to these mandatory "coverage/reachability" types of
footprint, other optional "coverage/reachability" types of footprint footprint, other optional "coverage/reachability" types of footprint
or "resource" types of footprint may defined by future or "resource" types of footprint may defined by future
specifications. To facilitate this, a clear process for specifying specifications. To facilitate this, a clear process for specifying
optional footprint types in a IANA registry is specified in optional footprint types in an IANA registry is specified in the CDNI
Section 8. This includes the specification of the level of oversight Metadata Footprint Types registry (defined in the CDNI Metadata
necessary (e.g., WG decision or expert review) for adding new Interface document [I-D.ietf-cdni-metadata](.
optional footprints to a IANA registry as well as the specification
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 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 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 able to serve content to users on behalf of that dCDN, to cover cases
where there is a transitive CDN interconnection. Further, the where there is a transitive CDN interconnection. Further, the
downstream CDN must be able to express its footprint to an interested 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 upstream CDN (uCDN) in a comprehensive form, e.g., as a data set
containing the complete footprint. Making incremental updates, containing the complete footprint. Making incremental updates,
however, to express dynamic changes in state is also desirable. however, to express dynamic changes in state is also desirable.
skipping to change at page 12, line 15 skipping to change at page 12, line 4
Useful capabilities refer to information that does not change highly Useful capabilities refer to information that does not change highly
dynamically and which in many cases is absolutely necessary to decide dynamically and which in many cases is absolutely necessary to decide
on a particular dCDN for a given end user request. For instance, if 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 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 certain protocol (e.g., RTMP), the uCDN needs to know if a given dCDN
has the capabilitity of supporting this delivery protocol. has the capabilitity of supporting this delivery protocol.
Similar to footprint advertisement, it is reasonable to assume that a Similar to footprint advertisement, it is reasonable to assume that a
significant part of the actual (resource) capabilities advertisement significant part of the actual (resource) capabilities advertisement
will happen in contractual agreements between participating CDNs, will happen in contractual agreements between participating CDNs,
i.e. prior to the advertisement phase using the CDNI FCI. The role i.e., prior to the advertisement phase using the CDNI FCI. The role
of capability advertisement is hence rather to enable the dCDN to 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 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 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 supported delivery protocols of a given dCDN, or in case a certain
delivery protocol is suddenly not being supported anymore due to delivery protocol is suddenly not being supported anymore due to
failures). Capabilities advertisement thus refers to conveying failures). Capabilities advertisement thus refers to conveying
information to a uCDN about changes/updates of certain capabilities information to a uCDN about changes/updates of certain capabilities
with respect to a given contract. with respect to a given contract.
Given these semantics, it needs to be decided what exact capabilities Given these semantics, it needs to be decided what exact capabilities
skipping to change at page 12, line 44 skipping to change at page 12, line 33
when needed. Still, agreement needs to be found on which when needed. Still, agreement needs to be found on which
capabilities (if any) should be mandatory among CDNs. As discussed capabilities (if any) should be mandatory among CDNs. As discussed
in Section 2.5, finding the concrete answers to these questions can 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 benefit from focusing on a small number of key use cases that are
highly relevant and contain enough complexity to help in highly relevant and contain enough complexity to help in
understanding what concrete capabilities are needed to facilitate CDN understanding what concrete capabilities are needed to facilitate CDN
Interconnection. Interconnection.
Under the above considerations, the following capabilities seem Under the above considerations, the following capabilities seem
useful as 'base' capabilities, i.e., ones that are needed in any case useful as 'base' capabilities, i.e., ones that are needed in any case
and therefore constitute mandatory capabilities to be supported by and therefore constitute mandatory capabilities that MUST be
the CDNI FCI: supported by the CDNI FCI:
o Delivery Protocol (e.g., HTTP vs. RTMP) o Delivery Protocol (e.g., HTTP vs. RTMP)
o Acquisition Protocol (for aquiring content from a uCDN) o Acquisition Protocol (for aquiring content from a uCDN)
o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
discussed in [RFC7336]) discussed in [RFC7336])
o CDNI Logging (i.e., supported logging fields) o CDNI Logging (i.e., supported logging fields)
skipping to change at page 14, line 10 skipping to change at page 13, line 49
The notion of optional types of footprint and capabilities implies The notion of optional types of footprint and capabilities implies
that certain implementations may not support all kinds of footprint that certain implementations may not support all kinds of footprint
and capabilities. Therefore, any FCI solution protocol must define and capabilities. Therefore, any FCI solution protocol must define
how the support for optional types of footprint/capabilities will be how the support for optional types of footprint/capabilities will be
negotiated between a uCDN and a dCDN that use the particular FCI negotiated between a uCDN and a dCDN that use the particular FCI
protocol. In particular, any FCI solution protocol needs to specify protocol. In particular, any FCI solution protocol needs to specify
how to handle failure cases or non-supported types of footprint/ how to handle failure cases or non-supported types of footprint/
capabilities. capabilities.
In general, a uCDN may ignore capabilities or types of footprint it In general, a uCDN may ignore capabilities or types of footprints it
does not understand; in this case it only selects a suitable does not understand; in this case it only selects a suitable
downstream CDN based on the types of capabilities and footprint it downstream CDN based on the types of capabilities and footprint it
understands. Similarly, if a dCDN does not use an optional understands. Similarly, if a dCDN does not use an optional
capability or footprint which is, however, supported by a uCDN, this capability or footprint which is, however, supported by a uCDN, this
causes no problem for the FCI functionality because the uCDN decides causes no problem for the FCI functionality because the uCDN decides
on the remaining capabilities/footprint information that is being on the remaining capabilities/footprint information that is being
conveyed by the dCDN. conveyed by the dCDN.
7. Capability Advertisement Object 7. Capability Advertisement Object
skipping to change at page 14, line 39 skipping to change at page 14, line 30
7.1. Base Advertisement Object 7.1. Base Advertisement Object
The FCIBase object is an abstraction for managing individual CDNI The FCIBase object is an abstraction for managing individual CDNI
capabilities in an opaque manner. capabilities in an opaque manner.
Property: capability-type Property: capability-type
Description: CDNI Capability object type. Description: CDNI Capability object type.
Type: MIME Type String (from Section 8) Type: FCI specific CDNI Payload type (from the CDNI Payload
Types registry [I-D.ietf-cdni-media-type])
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: capability-value Property: capability-value
Description: CDNI Capability object. Description: CDNI Capability object.
Type: Format/Type is defined by the value of capability-type Type: Format/Type is defined by the value of capability-type
property above. property above.
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
7.2. Delivery Protocol Capability Object 7.2. Delivery Protocol Capability Object
The Delivery Protocol capability object is used to indicate support The Delivery Protocol capability object is used to indicate support
for one or more of the protocols listed in the CDNI Metadata for one or more of the protocols listed in the CDNI Metadata Protocol
Protocols registry (defined in the CDNI Metadata Interface document Types registry (defined in the CDNI Metadata Interface document
[I-D.ietf-cdni-metadata]). [I-D.ietf-cdni-metadata]).
Property: delivery-protocols Property: delivery-protocols
Description: List of supported CDNI Delivery Protocols. Description: List of supported CDNI Delivery Protocols.
Type: List of Protocol Types (from the CDNI Metadata Protocols Type: List of Protocol Types (from the CDNI Metadata Protocol
registry [I-D.ietf-cdni-metadata]) Types registry [I-D.ietf-cdni-metadata])
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
7.3. Acquisition Protocol Capability Object 7.3. Acquisition Protocol Capability Object
The Acquisition Protocol capability object is used to indicate The Acquisition Protocol capability object is used to indicate
support for one or more of the protocols listed in the CDNI Metadata support for one or more of the protocols listed in the CDNI Metadata
Protocols registry (defined in the CDNI Metadata Interface document Protocol Types registry (defined in the CDNI Metadata Interface
[I-D.ietf-cdni-metadata]). document [I-D.ietf-cdni-metadata]).
Property: acquisition-protocols Property: acquisition-protocols
Description: List of supported CDNI Acquisition Protocols. Description: List of supported CDNI Acquisition Protocols.
Type: List of Protocol Types (from the CDNI Metadata Protocols Type: List of Protocol Types (from the CDNI Metadata Protocol
registry [I-D.ietf-cdni-metadata]) Types registry [I-D.ietf-cdni-metadata])
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
7.4. Redirection Mode Capability Object 7.4. Redirection Mode Capability Object
The Redirection Mode capability object is used to indicate support The Redirection Mode capability object is used to indicate support
for one or more of the modes listed in the CDNI Capabilities for one or more of the modes listed in the CDNI Capabilities
Redirection Modes registry (see Section 8.1). Redirection Modes registry (see Section 8.2).
Property: redirection-modes Property: redirection-modes
Description: List of supported CDNI Redirection Modes. Description: List of supported CDNI Redirection Modes.
Type: List of Redirection Modes (from Section 8.1) Type: List of Redirection Modes (from Section 8.2)
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
7.5. Capability Advertisement Object Serialization 7.5. Capability Advertisement Object Serialization
The following shows an example of CDNI FCI Capability Advertisement The following shows an example of CDNI FCI Capability Advertisement
Object Serialization. Object Serialization.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "application/cdni.FCI.DeliveryProtocol.v1+json" "capability-type": "FCI.DeliveryProtocol"
"capability-value": { "capability-value": {
"delivery-protocols": [ "delivery-protocols": [
"HTTP1.1" "http1.1"
] ]
} }
}, },
{ {
"capability-type": "application/cdni.FCI.AcquisitionProtocol.v1+json" "capability-type": "FCI.AcquisitionProtocol"
"capability-value": { "capability-value": {
"acquisition-protocols": [ "acquisition-protocols": [
"HTTP1.1", "http1.1",
"HTTPS1.1" "https1.1"
] ]
} }
}, },
{ {
"capability-type": "application/cdni.FCI.RedirectionMode.v1+json" "capability-type": "FCI.RedirectionMode"
"capability-value": { "capability-value": {
"redirection-modes": [ "redirection-modes": [
"DNS-I", "DNS-I",
"HTTP-I" "HTTP-I"
] ]
} }
} }
] ]
} }
8. IANA Considerations 8. IANA Considerations
This document requests the registration of the following MIME Media 8.1. CDNI Payload Types
Types under the IANA MIME Media Type registry
(http://www.iana.org/assignments/media-types/index.html).
application/cdni.FCI.DeliveryProtocol.v1+json This document requests the registration of the following CDNI Payload
Types under the IANA CDNI Payload Type registry:
application/cdni.FCI.AcquisitionProtocol.v1+json +-------------------------+---------------+
| Payload Type | Specification |
+-------------------------+---------------+
| FCI.DeliveryProtocol | RFCthis |
| | |
| FCI.AcquisitionProtocol | RFCthis |
| | |
| FCI.RedirectionMode | RFCthis |
+-------------------------+---------------+
application/cdni.FCI.RedirectionMode.v1+json 8.1.1. CDNI FCI DeliveryProtocol Payload Type
8.1. Redirection Mode Registry Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported delivery protocols
Interface: FCI
Encoding: see Section 7
8.1.2. CDNI FCI AcuiqisitionProtocol Payload Type
Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported acquisition protocols
Interface: FCI
Encoding: see Section 7
8.1.3. CDNI FCI RedirectionMode Payload Type
Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported redirection modes
Interface: FCI
Encoding: see Section 7
8.2. Redirection Mode Registry
The IANA is requested to create a new "CDNI Capabilities Redirection The IANA is requested to create a new "CDNI Capabilities Redirection
Modes" registry. The "CDNI Capabilities Redirection Modes" namespace Modes" registry. The "CDNI Capabilities Redirection Modes" namespace
defines the valid redirection modes that may be advertised as defines the valid redirection modes that may be advertised as
supported by a CDN. Additions to the Redirection Mode namespace supported by a CDN. Additions to the Redirection Mode namespace
conform to the "IETF Review" policy as defined in [RFC5226]. conform to the "IETF Review" policy as defined in [RFC5226].
The following table defines the initial Redirection Modes: The following table defines the initial Redirection Modes:
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
skipping to change at page 18, line 19 skipping to change at page 18, line 45
confidentially with the uCDN. Protocols implementing these semantics confidentially with the uCDN. Protocols implementing these semantics
SHOULD provide confidentiality services. SHOULD provide confidentiality services.
As specified in this document, the security requirements of the FCI As specified in this document, the security requirements of the FCI
could be met by hop-by-hop transport-layer security mechanisms could be met by hop-by-hop transport-layer security mechanisms
coupled with domain certificates as credentials. There is no coupled with domain certificates as credentials. There is no
apparent need for further object-level security in this framework, as apparent need for further object-level security in this framework, as
the trust relationships it defines are bilateral relationships the trust relationships it defines are bilateral relationships
between uCDNs and dCDNs rather than transitive relationships. between uCDNs and dCDNs rather than transitive relationships.
10. References 10. Normative References
10.1. Normative References [I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-19 (work in progress), July 2015.
[I-D.ietf-cdni-media-type]
Ma, K., "CDNI Media Type Registration draft-ietf-cdni-
media-type-00", August 2015.
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-11 (work in progress), July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
K., and G. Watson, "Use Cases for Content Delivery Network P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Interconnection", RFC 6770, November 2012. Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <http://www.rfc-editor.org/info/rfc6770>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, August 2014. Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[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] [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, Network Interconnection (CDNI) Requirements", RFC 7337,
"CDN Interconnection Metadata", draft-ietf-cdni- DOI 10.17487/RFC7337, August 2014,
metadata-09 (work in progress), March 2015. <http://www.rfc-editor.org/info/rfc7337>.
Appendix A. Acknowledgment Appendix A. Acknowledgment
Jan Seedorf is partially supported by the GreenICN project (GreenICN: Jan Seedorf is partially supported by the GreenICN project (GreenICN:
Architecture and Applications of Green Information Centric Architecture and Applications of Green Information Centric
Networking), a research project supported jointly by the European Networking), a research project supported jointly by the European
Commission under its 7th Framework Program (contract no. 608518) and Commission under its 7th Framework Program (contract no. 608518) and
the National Institute of Information and Communications Technology the National Institute of Information and Communications Technology
(NICT) in Japan (contract no. 167). The views and conclusions (NICT) in Japan (contract no. 167). The views and conclusions
contained herein are those of the authors and should not be contained herein are those of the authors and should not be
 End of changes. 55 change blocks. 
187 lines changed or deleted 220 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/