draft-ietf-cdni-footprint-capabilities-semantics-09.txt   draft-ietf-cdni-footprint-capabilities-semantics-10.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: May 6, 2016 Neustar Expires: September 4, 2016 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
November 3, 2015 March 3, 2016
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-09 draft-ietf-cdni-footprint-capabilities-semantics-10
Abstract Abstract
This document captures 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)" offers within CDNI. The Capabilities Advertisement Interface (FCI)" offers within CDNI. The
document also provides guidelines for the CDNI FCI protocol. It document also provides guidelines for the CDNI FCI protocol. It
further defines a Base Advertisement Object, the necessary registries further defines a Base Advertisement Object, the necessary registries
for capabilities and footprints, and guidelines how these registries for capabilities and footprints, and guidelines on how these
may be extended in the future. registries can 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 May 6, 2016. This Internet-Draft will expire on September 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 44 skipping to change at page 2, line 44
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 . . . . . . . . . . . 14 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 . . . . . . 15 7.5. Capability Advertisement Object Serialization . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16 8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16
8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17
8.1.2. CDNI FCI AcuiqisitionProtocol Payload Type . . . . . 17 8.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 17
8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17 8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17
8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17 8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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. This CDN interconnection (CDNI)
federation should serve multiple purposes, as discussed in [RFC6770], can serve multiple purposes, as discussed in [RFC6770], for instance,
for instance, to extend the reach of a given CDN to areas in the to extend the reach of a given CDN to areas in the network which are
network which are not covered by this particular CDN. 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
the semantics associated with the CDNI Request Routing Footprint & the semantics associated with the CDNI Request Routing Footprint &
Capabilities Advertisement Interface (from now on referred to as Capabilities Advertisement Interface (from now on referred to as
FCI), in particular the type of information a downstream CDN FCI), in particular the type of information a downstream CDN
'advertises' regarding its footprint and capabilities. To narrow 'advertises' regarding its footprint and capabilities. To narrow
down undecided aspects of these semantics, this document tries to down undecided aspects of these semantics, this document tries to
establish a common understanding of what the FCI should offer and establish a common understanding of what the FCI needs to offer and
accomplish in the context of CDN Interconnection. accomplish in the context of CDN Interconnection.
It is explicitly outside the scope of this document to decide on It is explicitly outside the scope of this document to decide on
specific protocols to use for the FCI. However, guidelines for such specific protocols to use for the FCI. However, guidelines for such
FCI protocols are provided. FCI protocols are provided.
General assumptions in this document: General assumptions in this document:
o The CDNs participating in the CDN federation have already o The CDNs participating in the interconnected CDN have already
performed a boot strap process, i.e., they have connected to each performed a boot strap process, i.e., they have connected to each
other, either directly or indirectly, and can exchange information other, either directly or indirectly, and can exchange information
amongst each other. amongst each other.
o The uCDN has received footprint and/or capability advertisements o The upstream CDN (uCDN) receives footprint and/or capability
from a set of dCDNs. Footprint advertisement and capability advertisements from a set of dCDNs. Footprint advertisement and
advertisement need not use the same underlying protocol. 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 o The uCDN receives the initial request-routing request from the
capabilities advertisement as: "[enabling] a Request Routing function endpoint requesting the resource.
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".
It thus considers "resources" and "load" as capabilities to be The CDNI Problem Statement [RFC6707] describes the Request Routing
advertised by the downstream CDN. Interface 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". It thus considers
"resources" and "load" as capabilities to be 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 defines a common understanding of what the terms 'footprint' document defines a common understanding of what the terms 'footprint'
and 'capabilities' mean in the context of CDNI, and detail the and 'capabilities' mean in the context of CDNI, and details the
semantics of the footprint advertisement mechanism and the capability semantics of the footprint advertisement 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.
Some CDNs aspire to cover the entire world, which we will henceforth 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 call global CDNs. The footprint advertised by such a CDN in the CDNI
environment would, from a coverage or reachability perspective, environment would, from a coverage or reachability perspective,
presumably cover all prefixes. Potentially more interesting for CDNI presumably cover all prefixes. Potentially more interesting for CDNI
use cases, however, are CDNs that claim a more limited coverage, but 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 seek to interconnect with other CDNs in order to create a single CDN
fabric which shares resources. fabric which shares resources.
Futhermore, not all capabilities need be footprint restricted. Futhermore, not all capabilities need to be footprint restricted.
Depending upon the use case, the optimal semantics of "footprints Depending upon the use case, the optimal semantics of "footprints
with capability attributes" vs. "capabilities with footprint with capability attributes" vs. "capabilities with footprint
restrictions" are not clear. restrictions" are not clear.
The key to understanding the semantics of footprint and capability The key to understanding the semantics of footprint and capability
advertisement lies in understand why a dCDN would advertise a limited advertisement lies in understand why a dCDN would advertise a limited
coverage area, and how a uCDN would use such advertisements to decide coverage area, and how a uCDN would use such advertisements to decide
among one of several dCDNs. The following section will discuss some among one of several dCDNs. The following section will discuss some
of the trade-offs and design decisions that need to be decided upon of the trade-offs and design decisions that need to be decided upon
for the CDNI FCI. for the CDNI FCI.
skipping to change at page 5, line 10 skipping to change at page 5, line 10
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, and advertises its When such a purpose-built CDN interconnects with other CDNs and
footprint to a uCDN, however, the original intended coverage of the advertises its footprint to a uCDN, however, the original intended
CDN might not represent its actual value to the federation of CDNs. coverage of the CDN might not represent its actual value to the
Consider an ISP-A and ISP-B that both field their own CDNs, which interconnection of CDNs. Consider an ISP-A and ISP-B that both field
they federate through CDNI. A given user E, who is customer of ISP- their own CDNs, which they interconnect via CDNI. A given user E,
B, might happen to be topologically closest to a cache fielded by who is a customer of ISP-B, might happen to be topologically closer
ISP-A, if E happens to live in a region where ISP-B has few customers to a cache fielded by ISP-A, if E happens to live in a region where
and ISP-A has many. In this case, should ISP-A's CDN "cover" E? If ISP-B has few customers and ISP-A has many. In this case, is it ISP-
ISP-B's CDN has a failure condition, should the uCDN understand that A's CDN that "covers" E? If ISP-B's CDN has a failure condition, is
ISP-A's caches are potentially available back-ups - and if so, how it up to the uCDN to understand that ISP-A's caches are potentially
does ISP-A advertise itself as a "standby" for E? What about the available as back-ups - and if so, how does ISP-A advertise itself as
case where CDNs advertising to the same uCDN express overlapping a "standby" for E? What about the case where CDNs advertising to the
coverage (for example, a federation mixing global and limited CDNs)? same uCDN express overlapping coverage (for example, 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
the uCDN wants 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. Alternately, dCDNs could advertise topological optimality decision. Alternately, dCDNs could advertise
the IP addresses of their caches rather than prefix "coverage," and the IP addresses of their caches rather than prefix "coverage," and
let the uCDN decide for itself (based on its own topological let the uCDN decide for itself (based on its own topological
intelligence) which dCDN has better resources to serve a given user. intelligence) which dCDN has better resources to 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) are included as part of the CDNI
if it should focus just on 'binary' footprint. FCI, or if the focus is just on 'binary' footprint.
2.2. Capabilities and Dynamic Data 2.2. Capabilities and Dynamic Data
In cases where the apparent footprints of dCDNs overlap, uCDNs might In cases where the apparent footprints of dCDNs overlap, uCDNs might
also want to rely on other factors to evaluate the respective merits also want to rely on other factors to evaluate the respective merits
of dCDNs. These include facts related to the caches themselves, to of dCDNs. These include facts related to the caches themselves, to
the network where the cache is deployed, to the nature of the the network where the cache is deployed, to the nature of the
resource sought, and to the administrative policies of the respective resource sought, and to the administrative policies of 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 needs to be agreed upon before CDNs can interconnect,
federations, including questions of membership, compensation, including questions of membership, compensation, volumes, and so on.
volumes, and so on. A uCDN certainly will factor these sorts of A uCDN certainly will factor these sorts of considerations into its
considerations into its decision to select a dCDN, but there is decision to select a dCDN, but there is probably little need for
probably little need for dCDNs to actually advertise them through an dCDNs to actually advertise them through an interface - they will be
interface - they will be settled out-of-band as a precondition for settled out-of-band as a precondition for interconnection.
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 can 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 needs to 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 CDNI environment, each dCDN shares some of its state with the
with the uCDN. The uCDN uses this information to build a unified uCDN. The uCDN uses this information to build a unified picture of
picture of all of the dCDNs available to it. In architectures that all of the dCDNs available to it. In architectures that share
share detailed capability information, the uCDN could perform the detailed capability information, the uCDN could perform the entire
entire request-routing operation down to selecting a particular cache request-routing operation down to selecting a particular cache in the
in the dCDN (note: within the current CDNI WG charter, such direct dCDN (note: within the current CDNI WG charter, such direct selection
selection of specific caches by the uCDN is out-of-scope). However, of specific caches by the uCDN is out-of-scope). However, when the
when the uCDN must deal with many potential dCDNs, this approach does uCDN needs to deal with many potential dCDNs, this approach does not
not scale, especially for dCDNs with thousands or tens of thousands scale, especially for dCDNs with thousands or tens of thousands of
of caches; the volume of updates to footprint and capability becomes caches; the volume of updates to footprint and capability becomes
onerous. onerous.
Were the volume of FCI updates from dCDNs to exceed the volume of Were the volume of FCI updates from dCDNs to exceed the volume of
requests to the uCDN, it might make more sense for the uCDN to query 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 dCDNs upon receiving requests (as is the case in the recursive
redirection mode described in [RFC7336]), instead of receiving redirection mode described in [RFC7336]), instead of receiving
advertisements and tracking the state of dCDNs. The advantage of advertisements and tracking the state of dCDNs. The advantage of
querying dCDNs would be that much of the dynamic data that dCDNs 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 cannot share with the uCDN would now be factored into the uCDN's
decision. dCDNs need not replicate any state to the uCDN - uCDNs decision. dCDNs need not replicate any state to the uCDN - uCDNs
skipping to change at page 7, line 19 skipping to change at page 7, line 19
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 over 'competing' dCDNs. It order to convince the uCDN to select it over 'competing' dCDNs. It
could therefore be desirable to take away the incentive for dCDNs to could therefore be desirable to take away the incentive for dCDNs to
cheat (in information advertised) as much as possible. One option is cheat (in information advertised) as much as possible. One option is
to make the information the dCDN advertises somehow verifiable for to make the information the dCDN advertises somehow verifiable for
the uCDN. One the other hand, a cheating dCDN might be avoided or the uCDN. On the other hand, a cheating dCDN might be avoided or
handled by the fact that there will be strong contractual agreements 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 between a uCDN and a dCDN, so that a dCDN would risk severe penalties
or legal consequences when caught cheating. or legal consequences when caught cheating.
Overall, the information a dCDN advertises should (in the long run) Overall, the information a dCDN advertises (in the long run) needs to
be somehow qualitatively verifiable by the uCDN, though possibly be somehow qualitatively verifiable by the uCDN, though possibly
through non-real-time out-of-band audits. It is probably an overly through non-real-time out-of-band audits. It is probably an overly
strict requirement to mandate that such verification be possible strict requirement to mandate that such verification be possible
"immediately", i.e., during the request routing process itself. If "immediately", i.e., during the request routing process itself. If
the uCDN can detect a cheating dCDN at a later stage, it should the uCDN can detect a cheating dCDN at a later stage, it might
suffice for the uCDN to "de-incentivize" cheating because it would suffice for the uCDN to "de-incentivize" cheating because it 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 in 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,
however, the possibility of overlapping footprints should not be however, the possibility of overlapping footprints cannot be
excluded, i.e., the scenario where more than one dCDN claims it can 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 serve a given end user request. The ISPs can also choose to
with a fallback global CDN. interconnect with a fallback global CDN.
It seems reasonable to assume that in most use cases it is the uCDN 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 that makes the decision on selecting a certain dCDN for request
routing based on information the uCDN has received from this routing based on information the uCDN has received from this
particular dCDN. It may be assumed that 'cheating' CDNs will be particular dCDN. It can be assumed that 'cheating' CDNs will be
dealt with via means outside the scope of CDNI and that the dealt with via means outside the scope of CDNI and that the
information advertised between CDNs is accurate. In addition, information advertised between CDNs is accurate. In addition,
excluding the use of qualitative information (e.g., cache proximity, excluding the use of qualitative information (e.g., cache proximity,
delivery latency, cache load) to predict the quality of delivery delivery latency, cache load) to predict the quality of delivery
would further simplify the use case allowing it to better focus on would further simplify the use case allowing it to better focus on
the basic functionality of the FCI. the basic functionality of the FCI.
3. Main Use Case to Consider 3. Main Use Case to Consider
Focusing on a main use case that contains a simple (yet somewhat Focusing on a main use case that contains a simple (yet somewhat
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 can 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.
Use case: A given uCDN has several dCDNs. It selects one dCDN for Use case: A given uCDN has several dCDNs. It selects one dCDN for
delivery protocol A and footprint 1 and another dCDN for delivery delivery protocol A and footprint 1 and another dCDN for delivery
protocol B and footprint 1. The dCDN that serves delivery protocol B protocol B and footprint 1. The dCDN that serves delivery protocol B
has a further, transitive (level-2) dCDN, that serves delivery has a further, transitive (level-2) dCDN, that serves delivery
protocol B in a subset of footprint 1 where the first-level dCDN protocol B in a subset of footprint 1 where the first-level dCDN
cannot serve delivery protocol B itself. What happens if cannot serve delivery protocol B itself. What happens if
capabilities change in the transitive level-2 dCDN that might affect capabilities change in the transitive level-2 dCDN that might affect
skipping to change at page 8, line 40 skipping to change at page 8, line 40
cannot serve delivery protocol B anymore)? How will these changes be cannot serve delivery protocol B anymore)? How will these changes be
conveyed to the uCDN? In particular, what information does the uCDN 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 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 footprint 1 or only for the subset of footprint 1 that the transitive
level-2 dCDN served on behalf of the first-level dCDN? level-2 dCDN served on 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 could want
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
can imagine that such additional information is implicitly associated can imagine that such additional information is implicitly associated
with a given footprint, e.g., due to contractual agreements (e.g., with a given footprint, e.g., due to contractual agreements (e.g.,
SLAs), business relationships, or perceived dCDN quality in the past. SLAs), business relationships, or perceived dCDN quality in the past.
As an alternative, such additional information could also be As an alternative, such additional information could also be
explicitly tagged along with the footprint. explicitly tagged along with the footprint.
It is reasonable to assume that a significant part of the actual It is reasonable to assume that a significant part of the actual
footprint advertisement will happen in contractual agreements between footprint advertisement will happen in contractual agreements between
participating CDNs, i.e., prior to the advertisement phase using the participating CDNs, i.e., prior to the advertisement phase using the
skipping to change at page 10, line 11 skipping to change at page 10, line 11
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, as well as 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 also MUST 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 could
the internal structure of a CDN network which may be undesirable. As expose the internal structure of a CDN network which could be
such, the resource types of footprints are not considered mandatory undesirable. As such, the resource types of footprints are not
to support for CDNI. considered mandatory to support for CDNI.
For all of these mandatory-to-implement footprint types, the For all of these mandatory-to-implement footprint types, the
footprints can be viewed as constraints for delegating requests to a footprints can be viewed as constraints for delegating requests to a
dCDN: A dCDN footprint advertisement tells the uCDN the limitations dCDN: A dCDN footprint advertisement tells the uCDN the limitations
for 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 be 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 an IANA registry is specified in the CDNI optional footprint types in an IANA registry is specified in the CDNI
Metadata Footprint Types registry (defined in the CDNI Metadata Metadata Footprint Types registry (defined in the CDNI Metadata
Interface document [I-D.ietf-cdni-metadata](. Interface document [I-D.ietf-cdni-metadata]).
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 are able
able to serve content to users on behalf of that dCDN, to cover cases to serve content to users on behalf of that dCDN, to cover cases with
where there is a transitive CDN interconnection. Further, the cascaded CDNs. Further, the downstream CDN needs to be able to
downstream CDN must be able to express its footprint to an interested express its footprint to an interested upstream CDN (uCDN) in a
upstream CDN (uCDN) in a comprehensive form, e.g., as a data set comprehensive form, e.g., as a data set containing the complete
containing the complete footprint. Making incremental updates, footprint. Making incremental updates, however, to express dynamic
however, to express dynamic changes in state is also desirable. changes in state is also desirable.
5. Semantics for Capabilities Advertisement 5. Semantics for Capabilities Advertisement
In general, the dCDN must be able to express its general capabilities In general, the dCDN MUST be able to express its general capabilities
to the uCDN. These general capabilities could express if the dCDN to the uCDN. These general capabilities could express if the dCDN
supports a given service, for instance, HTTP delivery, RTP/RTSP supports a given service, for instance, HTTP delivery, RTP/RTSP
delivery or RTMP. Furthermore, the dCDN must be able to express delivery or RTMP. Furthermore, the dCDN MUST be able to express
particular capabilities for the delivery in a particular footprint particular capabilities for the delivery in a particular footprint
area. For example, the dCDN might in general offer RTMP but not in area. For example, the dCDN might in general offer RTMP but not in
some specific areas, either for maintenance reasons or because the some specific areas, either for maintenance reasons or because the
caches covering this particular area cannot deliver this type of caches covering this particular area cannot deliver this type of
service. Hence, in certain cases footprint and capabilities are tied service. Hence, in certain cases footprint and capabilities are tied
together and cannot be interpreted independently from each other. In together and cannot be interpreted independently from each other. In
such cases, i.e., where capabilities must be expressed on a per such cases, i.e., where capabilities need to be expressed on a per
footprint basis, it may be beneficial to combine footprint and footprint basis, it could be beneficial to combine footprint and
capabilities advertisement. capabilities advertisement.
A high-level and very rough semantic for capabilities is thus the A high-level and very rough semantic for capabilities is thus the
following: Capabilities are types of information that allow a uCDN to following: Capabilities are types of information that allow a uCDN to
determine if a downstream CDN is able (and willing) to accept (and determine if a downstream CDN is able (and willing) to accept (and
properly handle) a delegated content request. In addition, properly handle) a delegated content request. In addition,
Capabilities are characterized by the fact that this information may Capabilities are characterized by the fact that this information can
possibly change over time based on the state of the network or change over time based on the state of the network or caches.
caches.
At a first glance, several broad categories of capabilities seem At a first glance, several broad categories of capabilities seem
useful to convey via an advertisement interface, however, advertising useful to convey via an advertisement interface, however, advertising
capabilities that change highly dynamically (e.g., real-time delivery capabilities that change highly dynamically (e.g., real-time delivery
performance metrics, CDN resource load, or other highly dynamically performance metrics, CDN resource load, or other highly dynamically
changing QoS information) should probably not be in scope for the changing QoS information) is beyond the scope for CDNI FCI. First,
CDNI FCI. First, out of the multitude of possible metrics and out of the multitude of possible metrics and capabilities, it is hard
capabilities, it is hard to agree on a subset and the precise metrics to agree on a subset and the precise metrics to be used. Second, and
to be used. Second, and perhaps more importantly, it seems not perhaps more importantly, it seems infeasible to specify such highly
feasible to specify such highly dynamically changing capabilities and dynamically changing capabilities and the corresponding metrics
the corresponding metrics within the CDNI charter time-frame. within the CDNI charter time-frame.
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
skipping to change at page 12, line 23 skipping to change at page 12, line 23
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
are useful and how these can be expressed. Since the details of CDNI 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 contracts are not known at the time of this writing (and the CDNI
interface should probably be agnostic to these contracts anyway), it interface are better off being agnostic to these contracts anyway),
remains to be seen what capabilities will be used to define it remains to be seen what capabilities will be used to define
agreements between CDNs in practice. One implication for agreements between CDNs in practice. One implication for
standardization may be to initially only specify a very limited set standardization could be to initially only specify a very limited set
of mandatory capabilities for advertisement and have on top of that a of mandatory capabilities for advertisement and have on top of that a
flexible data model that allows exchanging additional capabilities flexible data model that allows exchanging additional capabilities
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) will be mandatory among CDNs. As discussed in
in Section 2.5, finding the concrete answers to these questions can 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 that MUST be and therefore constitute mandatory capabilities that MUST be
supported by 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)
o CDNI Metadata (i.e., supported Generic Metadata types) o CDNI Metadata (i.e., supported Generic Metadata types)
It is not feasable to enumerate all the possible options for the It is not feasible to enumerate all the possible options for the
mandatory capabilities listed above (e.g., all the potential delivery mandatory capabilities listed above (e.g., all the potential delivery
protocols or metadata options) or anticipate all the future needs for protocols or metadata options) or anticipate all the future needs for
additional capabilities. It would be unreasonable to burden the CDNI additional capabilities. It would be unreasonable to burden the CDNI
FCI specification with defining each supported capability. Instead, FCI specification with defining each supported capability. Instead,
the CDNI FCI specification should define a generic protocol for the CDNI FCI specification SHOULD define a generic protocol for
conveying any capability information (e.g. with common encoding, conveying any capability information (e.g. with common encoding,
error handling, and security mechanism; further requirements for the error handling, and security mechanism; further requirements for the
CDNI FCI Advertisement Interface are listed in [RFC7337]). In this CDNI FCI Advertisement Interface are listed in [RFC7337]). In this
respect, it seems reasonable to define a registry which initially respect, it seems reasonable to define a registry which initially
contains the mandatory capabilities listed above, but may be extended contains the mandatory capabilities listed above, but can be extended
as needs dictate. This document defines the registry (and the rules as needs dictate. This document defines the registry (and the rules
for adding new entries to the registry) for the different capability for adding new entries to the registry) for the different capability
types (see Section 8). Each capability type MAY have a list of valid types (see Section 8). Each capability type MAY have a list of valid
values. Future specifications which define a given capability SHOULD values. Future specifications which define a given capability MUST
define any necessary registries (and the rules for adding new entries define any necessary registries (and the rules for adding new entries
to the registry) for the values advertised for a given capability to the registry) for the values advertised for a given capability
type. type.
The "CDNI Logging Fields Names" registry defines all supported The "CDNI Logging Fields Names" registry defines all supported
logging fields, including mandatory-to-implement logging fields. logging fields, including mandatory-to-implement logging fields.
Advertising support for mandatory-to-implement logging fields SHOULD Advertising support for mandatory-to-implement logging fields SHOULD
be supported but would be redundant. CDNs SHOULD NOT advertise be supported but would be redundant. CDNs SHOULD NOT advertise
support for mandatory-to-implement logging fields. The following support for mandatory-to-implement logging fields. The following
logging fields are defined as optional in the CDNI Logging Interface logging fields are defined as optional in the CDNI Logging Interface
skipping to change at page 13, line 44 skipping to change at page 13, line 44
The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] does The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] does
not define any optional GenericMetadata types. Advertiseing support not define any optional GenericMetadata types. Advertiseing support
for mandatory-to-implement GenericMetadata types SHOULD be supported for mandatory-to-implement GenericMetadata types SHOULD be supported
but would be redundant. CDNs SHOULD NOT advertise support for but would be redundant. CDNs SHOULD NOT advertise support for
mandatory-to-implement GenericMetadata types. mandatory-to-implement GenericMetadata types.
6. Negotiation of Support for Optional Types of Footprint/Capabilities 6. Negotiation of Support for Optional Types of Footprint/Capabilities
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 might 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 MUST specify how
how to handle failure cases or non-supported types of footprint/ to handle failure cases or non-supported types of footprint/
capabilities. capabilities.
In general, a uCDN may ignore capabilities or types of footprints 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 17, line 17 skipping to change at page 17, line 17
8.1.1. CDNI FCI DeliveryProtocol Payload Type 8.1.1. CDNI FCI DeliveryProtocol Payload Type
Purpose: The purpose of this payload type is to distinguish FCI Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported delivery protocols advertisement objects for supported delivery protocols
Interface: FCI Interface: FCI
Encoding: see Section 7 Encoding: see Section 7
8.1.2. CDNI FCI AcuiqisitionProtocol Payload Type 8.1.2. CDNI FCI AcquisitionProtocol Payload Type
Purpose: The purpose of this payload type is to distinguish FCI Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported acquisition protocols advertisement objects for supported acquisition protocols
Interface: FCI Interface: FCI
Encoding: see Section 7 Encoding: see Section 7
8.1.3. CDNI FCI RedirectionMode Payload Type 8.1.3. CDNI FCI RedirectionMode Payload Type
skipping to change at page 17, line 40 skipping to change at page 17, line 40
Interface: FCI Interface: FCI
Encoding: see Section 7 Encoding: see Section 7
8.2. Redirection Mode Registry 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 in the "Content Delivery Networks Interconnection Modes" registry in the "Content Delivery Networks Interconnection
(CDNI) Parameters" category. The "CDNI Capabilities Redirection (CDNI) Parameters" category. The "CDNI Capabilities Redirection
Modes" namespace defines the valid redirection modes that may be Modes" namespace defines the valid redirection modes that can be
advertised as supported by a CDN. Additions to the Redirection Mode advertised as supported by a CDN. Additions to the Redirection Mode
namespace conform to the "IETF Review" policy as defined in namespace conform to the "IETF Review" policy as defined in
[RFC5226]. [RFC5226].
The following table defines the initial Redirection Modes: The following table defines the initial Redirection Modes:
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
| Redirection Mode | Description | RFC | | Redirection Mode | Description | RFC |
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
| DNS-I | Iterative DNS-based Redirection | RFCthis | | DNS-I | Iterative DNS-based Redirection | RFCthis |
skipping to change at page 18, line 23 skipping to change at page 18, line 23
| | | | | | | |
| HTTP-R | Recursive HTTP-based Redirection | RFCthis | | HTTP-R | Recursive HTTP-based Redirection | RFCthis |
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
[RFC Editor: Please replace RFCthis with the published RFC number for [RFC Editor: Please replace RFCthis with the published RFC number for
this document.] this document.]
9. Security Considerations 9. Security Considerations
This specification describes the semantics for capabilities and This specification describes the semantics for capabilities and
footprint advertisement objects in content distribution networks. It footprint advertisement objects across interconnected CDNs. It does
does not, however, specify a concrete protocol for transporting those not, however, specify a concrete protocol for transporting those
objects. Specific security mechanisms can only be selected for objects. Specific security mechanisms can only be selected for
concrete protocols that instantiate these semantics. This document concrete protocols that instantiate these semantics. This document
does, however, place some high-level security constraints on such does, however, place some high-level security constraints on such
protocols. protocols.
All protocols that implement these semantics are REQUIRED to provide All protocols that implement these semantics are REQUIRED to provide
integrity and authentication services. Without authentication and integrity and authentication services. Without authentication and
integrity, an attacker could trivially deny service by forging a integrity, an attacker could trivially deny service by forging a
footprint advertisement from a dCDN which claims the network has no footprint advertisement from a dCDN which claims the network has no
footprint or capability. This would prevent the uCDN from delegating footprint or capability. This would prevent the uCDN from delegating
any requests to the dCDN. Since a pre-existing relationship between any requests to the dCDN. Since a pre-existing relationship between
all dCDNs and uCDNs is assumed by CDNi, the exchange of any necessary all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary
credentials could be conducted before the FCI interface is brought credentials could be conducted before the FCI interface is brought
online. The authorization decision to accept advertisements would online. The authorization decision to accept advertisements would
also follow this pre-existing relationship and any contractual also follow this pre-existing relationship and any contractual
obligations that it stipulates. obligations that it stipulates.
It is not believed that there are any serious privacy risks in It is not believed that there are any serious privacy risks in
sharing footprint or capability information: it will represent highly sharing footprint or capability information: it will represent highly
aggregated data about networks and, at best, policy-related aggregated data about networks and, at best, policy-related
information about media, rather than any personally identifying information about media, rather than any personally identifying
information. However, particular dCDNs may wish to share information information. However, particular dCDNs could be willing to share
about their footprint with a uCDN but not with other, competing information about their footprint with a uCDN but not with other,
dCDNs. For example, if a dCDN incurs an outage that reduces competing dCDNs. For example, if a dCDN incurs an outage that
footprint coverage temporarily, that may be information the dCDN reduces footprint coverage temporarily, that could be information the
would want to share confidentially with the uCDN. Protocols dCDN would want to share confidentially with the uCDN. Protocols
implementing these semantics SHOULD provide confidentiality services. implementing these semantics 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. References
skipping to change at page 19, line 31 skipping to change at page 19, line 31
[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,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-cdni-logging] [I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R. Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-21 (work in progress), November 2015. logging-22 (work in progress), March 2016.
[I-D.ietf-cdni-media-type] [I-D.ietf-cdni-media-type]
Ma, K., "CDNI Media Type Registration", draft-ietf-cdni- Ma, K., "CDNI Media Type Registration", draft-ietf-cdni-
media-type-06 (work in progress), October 2015. media-type-06 (work in progress), October 2015.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni- "CDN Interconnection Metadata", draft-ietf-cdni-
metadata-12 (work in progress), October 2015. metadata-12 (work in progress), October 2015.
 End of changes. 61 change blocks. 
135 lines changed or deleted 134 lines changed or added

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